A sighted user gets many visual cues that tell them the status and state of elements on the page. This may be a highlight or a change in colors. We need to make sure that screen reader users get this same information as well.

WCAG 4.1.2: Name, Role, Value Opens in a new window

Details

  • All visible states are audible while screen reader focus is on the element.
  • Audible states should change with a change in visible state.
  • When possible, ARIA attributes are used to give the state instead of visually hidden text.

Examples

Disabled button

Just like a sighted user sees that an element is dimmed and knows it's disabled, a screen reader user should hear this information. Without this it will be unclear why the element doesn't work. This can be done by adding aria-disabled="true" to the button.

Invalid form field

When a sighted user submits a form with an error they see a red outline around those fields in error making it very easy to find the problem. For a screen reader user we want to have a similar experience by reading out "invalid" on the field. This can be done by adding aria-invalid="true" to the field.

Selected tab

When using a tab component it is easy to see that one of the tabs is visually selected. This tells you what content you are seeing below the controls. A screen reader user also needs to know which tab is currently selected so they know what they are viewing as well as if they need to change it to get what they want. This can be done by adding aria-selected="true" to the tab.

Expanded toggle

When a user navigates to a toggle element, they should hear that it is either expanded or collapsed. This lets the user know what the component will do when they trigger it. This can be done by toggling the value of aria-expanded. Visually this is frequently represented with an up or down facing arrow.

Tools & Resources