If you’re looking for ways to make your web content more accessible for people who use assistive technologies, WAI-ARIA (Web Accessibility Initiative — Accessible Rich Internet Applications) might help. However, correctly implementing WAI-ARIA can be challenging.
WAI-ARIA, which is also referred to as ARIA, is a specification designed to support accessible web applications. It provides semantic definitions for certain on-page elements. Assistive technologies like screen readers can interpret ARIA to provide more accurate information to users.
Before using ARIA, make sure you understand what it does — and what it can’t do. Below, we’ll address a few of the most common WAI-ARIA myths.
1. Myth: ARIA is a replacement for semantic HTML.
Semantic HTML5 includes the necessary attributes for most web content, and in most situations, HTML is preferable to ARIA. Here’s what the Web Accessibility Initiative (WAI) recommends:
“If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so (author’s emphasis).”
The World Wide Web Consortium (W3C) updates HTML5 every few years to include more semantic features, and HTML is supported by every web browser and assistive technology. Unfortunately, different tools may not support 100% of WAI-ARIA.
The takeaway: If you have the option to use semantic HTML, use it. HTML is widely supported and relatively easy to use.
2. Myth: Using ARIA will always make a website more accessible.
Poor ARIA implementation may introduce barriers that affect people with disabilities. If a developer uses the wrong ARIA role or makes mistakes when writing markup, the website (and users) may suffer.
For example, role=’application' is a landmark role used to identify web applications that operate similarly to desktop applications. It may disable default shortcuts to enable users to browse naturally. When misused, visitors may not understand how to regain control of their browser or assistive technology.
Put simply, WAI-ARIA is a powerful tool, and you’ll need to use it carefully. If you can’t test your content frequently, the safest option is to stick with standard HTML.
Related: Avoid Accessibility Issues When Using ARIA's "Application" Role
3. Myth: ARIA is never necessary for improving web accessibility.
Semantic HTML5 has limitations, and ARIA can greatly improve accessibility for certain types of content. For example, ARIA might be used to clearly identify errors within a form field or to define navigation elements within a web application.
Before using ARIA, ask:
- Can I provide users with enough information by using semantic HTML5?
- Am I using ARIA to fix poorly written HTML?
- Could adding ARIA attributes create new accessibility issues?
If you answer “no" to every question, you can proceed — but remember, by using WAI-ARIA, you’re making a commitment to use it correctly.
Related: How ARIA Can Help Make Your Website Accessible
4. Myth: ARIA is only for screen readers.
Most ARIA resources focus on screen readers, and for good reason: Screen reader accessibility is a vital consideration. Many people with vision disabilities use screen readers regularly, and popular readers like JAWS and NVDA can also accommodate people with hearing, motor, and neurocognitive conditions.
However, support for ARIA is growing. Web browsers, JavaScript toolkits, screen magnifiers, and text-to-speech tools may utilize ARIA. When properly implemented, ARIA can provide more users with ways to access your content.
For example, a complex web application may have features that can’t be semantically defined through HTML. Text-to-speech tools may enable users to navigate, fill out forms, and perform other interactions by using ARIA labels.
Related: What is ARIA? Common Misconceptions About Accessible Rich Internet Applications
5. Myth: Automated tools can find all ARIA implementation issues.
By testing your content frequently, you can ensure that your website reaches the widest possible audience. However, you’ll need an appropriate testing methodology.
We strongly recommend using a combination of manual and automated tests. While automated tests can identify some problems with WAI-ARIA, you’ll need to check whether your content delivers a decent experience for people who regularly use assistive technology.
Some potential issues with automated ARIA accessibility testing include:
- ARIA state, role, and property values are case sensitive. Some automated tools may accurately identify values regardless of case — but some assistive technologies might encounter issues.
- Automated tools can’t determine whether certain options are appropriate. For example, aria-live=”assertive" is intended to announce crucial updates to live regions. Depending on the content, aria-live=”polite" may be more appropriate.
- Many automated tools will miss keyboard navigation issues, third-party widget implementations, and other common barriers that affect real-world users.
Remember, some devices and software have limited support for WAI-ARIA. If you decide to use ARIA, you should work with an experienced accessibility partner to create a long-term strategy — and to avoid shutting out a sizable portion of your audience.
To learn more, contact the Bureau of Internet Accessibility or read about our four-point hybrid testing methodology.
