WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications), also known as ARIA, is a technical specification that enhances accessibility by defining semantics for certain attributes. The specifications are set by the World Wide Web Consortium (W3C), and when used properly, ARIA improves accessibility for screen readers and other assistive technologies.
However, ARIA can also create digital accessibility barriers. Before using WAI-ARIA on your website, make sure you understand how it works — and be prepared to test your content. Below, we’ll discuss a few basic tips for using ARIA appropriately.
Related: What is ARIA? Common Misconceptions About Accessible Rich Internet Applications
ARIA isn’t always the best way to make your website accessible for people who use assistive technologies. In fact, it’s often the least effective choice: Assistive tools may implement ARIA to varying degrees. HTML5 is much more widely recognized, and it’s a better choice when authoring for accessibility.
Semantic HTML5 tags can describe the functionality of most web elements. The language includes new tags to describe media players, drag-and-drop functions, web forms, microdata, and more — in other words, ARIA may not be necessary unless your website has complex functionality.
If you determine you need ARIA, we strongly recommend working with an accessibility partner to ensure that your implementation is correct. You’ll also need to monitor future changes in semantic HTML; if a new HTML tag is equivalent with an ARIA role, the best practice is to switch to HTML.
Ultimately, ARIA requires significant investment and expertise. It can greatly improve your website, but semantic HTML is simpler to implement and much more effective.
Related: Leveraging HTML for Web Accessibility
Like semantic HTML, ARIA roles provide content with semantic meaning. The goal is to enable assistive tools to present interactions in a predictable and intuitive way. ARIA is not intended to provide a tremendous amount of detail — as with semantic HTML, the goal is to support user interaction.
Remember, ARIA is specifically intended for content where appropriate HTML semantics are not available. For ARIA to work properly on all devices, developers should avoid changing native semantics. Here’s an example from the W3C. The developer wants to build a heading that’s a tab:
Do not do this:
<h2 role=tab>heading tab</h2>
Do this:
<div role=tab><h2>heading tab</h2></div>
Adding the role of the tab to the heading element is incorrect implementation, since the heading element has its own semantic meaning. Instead, the generic <div> element should receive the ARIA role.
Keyboard accessibility is always a crucial consideration, but it’s especially important when using ARIA: Many (if not most) technologies that use ARIA rely on keyboard navigation. If an ARIA control doesn’t support keyboard navigation, the user will be forced to use another method to interact with the control.
Here’s an example from the W3C:
If using role=button the element must be able to receive focus and a user must be able to activate the action associated with the element using both the enter (on WIN OS) or return (MAC OS) and the space key.
When using ARIA, authors must provide keyboard support, which requires total understanding of visible focus and predictable focus movement. Authors must assign and reveal keyboard shortcuts and prevent conflicts with assistive technology keyboard commands.
Related: What is Keyboard Accessibility?
Many ARIA mistakes stem from misunderstandings — for instance, misusing the “application" role, which is intended for web apps that simulate desktop applications — but others can be caused by basic, avoidable mistakes. A common example: ARIA roles should be written in lowercase.
W3C recommends using lowercase for “all role token values and any state or property attributes whose values are defined as tokens.” For example: div role=”MAIN” is incorrect.
Some browsers and assistive devices can interpret ARIA roles that use uppercase letters, but that’s not always the case. This is one reason that testing with different devices and software is extremely important: A quick test might indicate that your ARIA roles conform with standards, but one of your users might not have the same experience.
Developers implement ARIA for a good reason: They’re concerned about the experiences of users with disabilities, and they want to author content that works with screen readers and other assistive technologies. However, adding ARIA won’t necessarily make your site more accessible, and if ARIA is implemented incorrectly, your site may create serious barriers for users.
If you decide to use ARIA, you’ll need to audit your content regularly. Audits should utilize both automated accessibility scans and manual testing. Manual testers should use a variety of assistive tools, browsers, and operating systems. In addition to ARIA implementation, you’ll need to test for improper semantic HTML5 implementation, poor color contrast usage, and other common accessibility issues.
The Bureau of Internet Accessibility can help you meet your goals and expand your website’s reach. To learn more, contact the Bureau of Internet Accessibility for a free consultation. Our experts can help you use ARIA effectively — and set up a long-term plan for accessibility compliance.