Skip to Main Content


PRESENTER: Recently, there's been a growing trend for developers to include ARIA attributes in their applications. While this might seem like a good thing, it's not always the case. ARIA attributes can be misused, and this often leads to all sorts of problems for assistive technologies. This tutorial explores how not to use ARIA. We're going to cover issues with redundancy, issues with being too verbose, issues with copy and paste, and the five rules of using ARIA.

Section 1, Issues with Redundancy. ARIA is sometimes used by overzealous developers to provide additional ARIA attributes to native HTML elements that already have accessible APIs. For example, some developers apply role equals radio to the radio import. Another example is where developers use the required attribute as well as the aria-required equals true attribute. In some cases, this can cause assistive technologies to announce the element's state twice.

Section 2. issues with Being too Verbose. There are times when developers use ARIA attributes to provide detailed information for assistive technologies. An example is where additional information for form fields is explicitly associated with a field, so it's announced every time the field is in focus. This can sometimes lead to excessive amounts of information being presented to assistive technology users.

Section 3, Issues with Copy and Paste. There are times when developers simply copy chunks of code from an existing parent library without understanding how the ARIA attributes work. An example is where developers copy code for a modal dialog but don't realize that the aria-labelled attribute points to a heading inside the modal. In some cases, developers replace the heading or delete the ID value. And that means that these users may not be aware that the modal's even been triggered or the purpose of the modal.

Section 4, The Five Rules of Using ARIA.

Rule number 1, if you can use a native HTML element or attribute with the semantics of behavior you require already built into it, then do so. Developers, thinking they're doing the right thing, sometimes add the role of button to the button element. However, there's no need to override the existing native API. The button element doesn't require a role.

Rule number 2, don't change native semantics, unless you really have to. Developers sometimes apply a role to an element that has a different semantic meaning, for example, adding a role of tab to a heading element. A preferred method is to wrap the heading inside a div element and then apply the role to this generic element instead.

Rule number 3, all interactive ARIA controls must be usable with the keyboard. Keyboard only users must be able to navigate any widget and interact with it using the keyboard only.

Rule number 4, don't use role equals presentation or aria-hidden hidden true on a visible focusable element. The role equals presentation attribute informs assistive technologies that the element has no semantics. Adding this attribute to a button element cancels the button's native API so it not be announced as a button. The aria-hidden true attribute indicates that the element and all of its descendants are not perceivable to any users. In supporting browsers with supporting assistive technologies, the content is not conveyed to the user at all. In this case, the link would not be announced to assistive technology users.

Rule 5, all interactive elements must have an accessible name. An interactive element only has an accessible name when its accessible name or equivalent property has a value. For example, some developers don't use an explicit label associated with an input element. The preferred method is to use the label element and explicitly associate it with a relevant import using the for and ID attributes.

Another example could be a region of a page for dynamically adding weather information. If this was an interactive element, such as allowing user to open or close the region, it would require an accessible name. However, there may not be a heading within this region that could be used as a label in order to create an accessible name. In these cases, an accessible name can be assigned using the aria-label attribute.

Conclusion, in almost all cases developers make these mistakes while trying to help assistive technology uses. This is why it's important to understand how ARIA works with assistive technology users before applying these attributes throughout an application. So there you have it, a simple explanation on how not to use ARIA.

Except where otherwise noted, this work is licensed under Creative Commons by Attribution-ShareAlike 4.0 license. Copyright 2018. California Community Colleges Chancellor's Office. These works are licensed under Creative Commons Attribution 4.0 international license. They're available to everyone and may be repurposed to meet the unique needs of educational institutions.