By Sarah Horton and David Sloan — Visual user interface characteristics enable perception and understanding of content and the operation of functionality. A control may look like a button because of its shape and border and the presence of a text label or icon within the control. But this visual information is not available for assistive technologies that use alternative modalities for output, particularly the audio channel.
For nonvisual channels to be effective output and input modalities, a way is needed to communicate information about the interface, its content, and its controls in a way that can be rendered in speech and interacted with through alternative means. Critical accessibility information about a control that needs to be conveyed programmatically includes:
- Name: What unique function does the control perform? For example, “Save” or “Submit”.
- Role: What kind of control is it? For example, a menu, button, or slider.
- State: What state is the control currently in? For example, a menu could be expanded or collapsed; a checkbox could be checked or not checked.
- Value: What value does the control hold? For example, a slider control could have a value anywhere between the minimum and maximum value it can hold.
Understanding what accessibility information is provided by default to an assistive technology helps you as an engineer understand:
- What code to provide in order to accurately communicate accessibility information about the control.
- What values to provide for specific attributes so that they complement what is already communicated programmatically rather than duplicate, contradict, or override valid accessibility information.
For example, in HTML, a save button labeled with an image of a floppy disk can be coded as follows:
<button><img src="saveicon.jpg" alt="Save"></button>
The button element communicates the role of the control to assistive technology, and the alt attribute of the image element provides the name. Together, a screen reader might announce “Button, Save”. But if the alt attribute’s value was "Save button", then the control’s name now also includes the control’s role (a button), unnecessarily duplicating information already provided programmatically. In that case, a screen reader might announce the button as “Button, Save button”.
And if a control was visually labeled correctly but inadvertently provided with the wrong accessible name, then there could be severe consequences for an assistive technology user, as in the following example of a delete button with an accessible name of “Save”:
<button><img src="deleteicon.jpg" alt="Save"></button>
From Horton, S., & Sloan, D. (2024). What Every Engineer Should Know About Digital Accessibility. CRC Press, Boca Raton, Florida.
Know About Accessibility 