Accessibility rule: Roles are invalid, explained

In a nutshell, ARIA roles provide semantic meaning to elements. While many elements in HTML have a default role and therefore do not need additional ARIA roles, there are also non-semantic elements such as div and span. These elements require an ARIA role attribute to provide meaning for screen readers and other technology. 

An ARIA role can also be added to an element to instruct assistive technologies to treat the element differently from its native role. For instance, adding a role="tablist" to an ul will change the element role from an unordered list to a container with a number or tabs.

Nevertheless, it is recommendable always to use the native HTML elements whenever possible. For instance, it does not make sense to create a button using a non-semantic div element with a role of a button when a button element exists. 

Who is impacted by this barrier?

Roles make it easier for assistive technology users to identify important user interface elements and navigate the page. Invalid roles can cause the element to be read incorrectly by assistive technology.

How does the rule work?

The rule detects non-standard, capitalized, or misspelled ARIA attributes that will not deliver the intended user experience for screen reader users.

Two rules address this particular barrier:

• All roles are invalid (WCAG A) - This rule checks that each role attribute has at least one valid token.
• Some roles are invalid  (Best practice) - This rule checks that each role attribute only has valid tokens.

How do I fix the issue?

Use only valid non-abstract ARIA roles. You can check the W3C specification to see what is supported for this type of element.

Role definitions for WAI-ARIA are listed here

Role definitions for Graphics ARIA are listed here 

Role definitions for DPUB ARIA are listed here