Manually check all custom controls have appropriate ARIA roles

Check all custom controls have appropriate role and any required ARIA attributes that confer their interactive state. For example, a custom checkbox needs a role=”checkbox” and aria-checked=”true|false” to properly convey its state. See the Introduction to ARIA for a general overview of how ARIA can provide missing semantics for custom controls.

How to manually test

To check all custom interactive controls have appropriate ARIA roles, test the page using a Screen Reader. This example compares a <div> to a <button> (you'll need to click "Enable ChromeVox Lite" to test it):

Using CSS, it's possible to style the <div> and <button> elements so they convey the same visual affordances, but the two experiences are very different when using the screen reader. A <div> is just a generic grouping element, sp the screen reader only announces the div's text content. The <button> is announced as a "button", a much stronger signal to the user that this is something with which they can interact. See also Semantics and screen readers.

How to fix

So the simplest, and reasonably the best solution to this problem is to aviod custom interactive controls all together. For example, replace the <div> that's acting like a button with an actual <button>.

If you must keep the <div>, then add role="button"and aria-pressed="false" to the <div>:

Now the screen reader announces the role and interactive state for the <div>.

Why this matters

The only way to truly understand how screen reader users experience your content is to check that content yourself using a screen reader. Using a screen reader first hand will give you a clear understanding of how your content is labeled, and if there are any obstructions to screen reader navigation. If you’re unfamiliar with how semantic markup gets interpreted by assistive technology, see the Introduction to Semantics for a refresher.

See also How to Do an Accessibility Review.

More information

Last updated: Improve article