WAI-ARIA: Top 6 Mistakes to Avoid

Before we dive into the common mistakes of ARIA, let’s reiterate what ARIA does. ARIA stands for “accessible rich internet applications” and helps make web content or web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies. With WAI-ARIA, developers can make advanced Web applications accessible and usable to people with disabilities.

There is nothing wrong with using ARIA to remediate accessibility issues, so long as the authors have a thorough knowledge of how and when to use ARIA. It is important to note that the misuse of ARIA creates a more inaccessible experience than one without ARIA. A common saying in the accessibility community is, “No ARIA is better than bad ARIA.” Below, I will highlight some of the common mistakes that can occur while remediating accessibility issues with ARIA.

The common mistakes below come from first-hand experiences my team and I have seen in the field of accessibility remediation. At Deque, we use a quality assurance testing tool called WorldSpace Assure for our assessment projects. We have logged more than 7,000 ARIA-related issues in the past two years on this tool. Below are the top six WAI-ARIA mistakes from the data set.

WAI-ARIA Mistake #1: Incorrect WAI-ARIA Syntax

Most technologies require a certain syntax, similarly, WAI-ARIA also requires a certain syntax. Failing to provide the correct syntax can lead to unexpected results. Let’s discuss some of the common syntax errors that authors often introduce in their code, which result in an inaccessible experience.

• Role values are assumed to not be case sensitive: Role values define the purpose of objects in the page. Authors often fail to implement these values following the lowercase convention established by the WAI-ARIA specification. For example, role=”LINK” can be provided with the value types in as uppercase letters and, as a result, assistive technologies cannot identify the object as a link. Authors need to remember that role values are case sensitive and need to be typed in lowercase.
• Incorrect spelling for attributes or values: Attributes are often spelled incorrectly. For example, aria-label might be spelled out as “aria-lable”. As a result, screen readers fail to announce the accessible name of the control. Authors need to be mindful that attributes are spelled correctly.
• Incorrect or invalid role declarations: Authors often declare roles incorrectly. For example, role=”alert” might be declared as aria-role=”alert”. As a result, screen readers will fail to announce the live message. Authors need to avoid such mistakes and declare the roles appropriately using role=””, not aria-role=””.
• Role does not exist or is invalid: Authors sometimes provide a role that does not exist according to the WAI-ARIA specification. For example, authors might provide role=”error” for the error message in an attempt to convey the error semantics, but there is no such thing as role=”error” in the specification. Authors should become very familiar with the correct role values to avoid such issues.

WAI-ARIA Mistake #2: Children roles without parent roles

Authors frequently define children roles on objects without first defining their parent role. As you may know, certain roles cannot be used without their related parent/context roles. For example, a tab role might be defined without its tablist parent role.

As a result, screen readers may not work as expected. Some screen readers and browser combinations will still provide the information as expected, but others won’t, making it a very unreliable solution. Authors need to ensure that children roles are provided with their contextual or related parent roles.

WAI-ARIA Mistake #3: Parent roles without children roles

Many times, authors provide a parent role without first defining the expected related children roles. Certain roles cannot be defined without also defining their related children roles. For example, when menu or menubar roles are defined without the expected menu item children roles for related objects, screen readers may not be able to convey the relationship as expected. Again, some screen reader and browser combinations will still provide the information as expected, but others won’t, making it an unreliable solution. Authors need to make sure that parent roles are provided with their contextual or related children roles.

WAI-ARIA Mistake #4: Invalid ID value references

We frequently see authors providing incorrect or inaccurate ID reference values for certain attributes. Attributes are set to only accept ID references as their respective values, such as the aria-labelledby, aria-describedby, and aria-errormessage attributes.

If authors provide an incorrect ID value or assign an ID that does not exist in the document, then screen readers will not be able to create the reference and announce the information as expected (e.g. the element’s label, the related instructions, the error message, etc). To avoid these situations, authors need to make sure that the ID values that are defined for WAI-ARIA attributes are valid.

WAI-ARIA Mistake #5: Allowed WAI-ARIA attributes missing

We often see authors use WAI-ARIA attributes in ways that go against what is defined in the specification, hoping to make things better for accessibility. Certain roles only allow for certain attributes. For example, authors might assign aria-selected=”true” to the anchor/link element, falsely thinking that screen readers will announce the selected state of the anchor/link.

However, since aria-selected is not allowed on link elements as per the WAI-ARIA spec, screen readers will NOT announce the selected state of such an element. On the other hand, when aria-selected attributes are used with certain roles such as treeitem, tab, gridcell and so on, the experience will be accessible. Authors should double-check that the attributes they assign to particular roles are allowed for those roles.

WAI-ARIA Mistake #6: Required WAI-ARIA attributes missing

We sometimes see authors define WAI-ARIA roles without defining their expected required attributes. Again, certain WAI-ARIA roles cannot be defined without also defining their expected required attributes. For example, when the slider role is defined on an object, certain attributes such as aria-valuemin, aria-valuemax and aria-valuenow must also be defined. Failing to do so results in screen readers not conveying the information as expected. Therefore, authors need to make sure they provide all expected required roles and attributes when a particular WAI-ARIA role is used.

One last quick tip!

All of these mistakes can be caught through automated testing by simply using axe, Deque’s free testing tool.

References: WAI-ARIA 1.1 specification