WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications), also referred to as ARIA, is a technical specification that enhances accessibility by providing semantic information that isn’t available in native HTML.
If you’re designing complex web content, ARIA is indispensable: It can improve the user experience for people who use screen readers and other assistive technologies. By providing roles for certain elements, it can also help your website conform with the Web Content Accessibility Guidelines (WCAG).
The World Wide Web Consortium (W3C) publishes ARIA specifications, along with detailed usage guides for developing in HTML, JavaScript, Ajax, and other technologies. For developers, the W3C’s Using ARIA guide provides an excellent starting point.
However, before you decide to use ARIA, make sure you understand its benefits and limitations. Here are four questions to ask before using ARIA markup on a page.
Related: Introduction to ARIA for Web Accessibility
1. Can I use semantic HTML instead of ARIA?
ARIA is an excellent tool for providing complex web elements and custom widgets with accurate semantics. With that said, ARIA support varies from one application to the next — many assistive technologies fully support ARIA 1.1, but older browsers and screen readers may not correctly identify certain ARIA roles.
Semantic HTML is much more widely supported. The W3C’s first rule of WAI-ARIA is to use native HTML elements or attributes instead of ARIA wherever possible. In other words: Don’t use ARIA unless you really need it.
The W3C identifies three circumstances where ARIA implementation is preferable to semantic HTML:
- The feature is available in HTML but it is not implemented or it is implemented, but accessibility support is not.
- The visual design constraints rule out the use of a particular native element, because the element cannot be styled as required.
- The feature is not currently available in HTML.
Put simply, most simple websites do not need to use much ARIA. If your site’s features can be defined with native HTML, that’s always a preferable option.
Related: What is ARIA? Common Misconceptions About Accessible Rich Internet Applications
2. Do I understand the risks of poor ARIA implementation?
When used improperly, WAI-ARIA can make your website less accessible. That’s not to say you should avoid using it altogether — but if you're going to use it, you need to use it correctly.
Some common examples of barriers caused by poor ARIA implementation:
- Using role="presentation" or aria-hidden="true" on a focusable element can prevent users from perceiving controls.
- Improper usage of the “application" role can prevent a user from regaining control of their software.
- By changing native semantics, developers might unintentionally confuse users.
Remember, by using ARIA, you’re making a commitment to use it correctly. Mistakes have consequences for real-world users, so review the W3C’s ARIA usage guide (linked at the top of this article) when planning.
3. Am I prepared to test my ARIA implementation?
ARIA isn’t an afterthought. You should consider your ARIA implementation throughout the development cycle and test your markup regularly. Developers can test ARIA in several ways:
- Automated Accessibility Testing - Automated testing can find some major accessibility issues, but all artificial intelligence testing tools have serious limitations. Don’t rely on automated testing alone to verify your ARIA implementation.
- Manual Testing - By accessing your site with a screen reader like JAWS, NVDA, or VoiceOver, you can test markup. However, remember that ARIA support varies; developers should test with several screen readers to make sure ARIA works as intended.
- Full Accessibility Audits - Performed by independent experts, a full accessibility audit identifies ARIA issues along with other barriers that might affect users with disabilities. Comprehensive audits use both manual and automated testing methods and provide guidance for remediation.
If you decide to use ARIA, make sure you have a process in place to test your content. The best practice is to use automated and manual testing regularly and to engage full audits at key stages of development.
Related: Can You Check Web Accessibility By Downloading a Screen Reader?
4. Does my site have other accessibility barriers?
Using WAI-ARIA doesn’t make your site accessible. It can improve digital accessibility, but ARIA is not intended to address every type of barrier. For example, ARIA can’t fix poor color contrast ratios, missing image alternative text, or other serious issues.
Published by the W3C, WCAG provides the most comprehensive framework available for ensuring digital accessibility. To reach the widest possible audience, and provide an equivalent experience for all users, most sites should conform with WCAG’s Level AA and Level A checkpoints.
Meeting this goal is much easier (and much less expensive) when accessibility is prioritized from the first stages of development. An accessibility partner can help you determine whether ARIA is appropriate for your site — and provide a roadmap that helps you earn and maintain accessibility conformance.
To get started, contact the Bureau of Internet Accessibility or read about our WCAG 2.1 Level AA accessibility audits.
