WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) helps define web components for screen readers and other assistive technologies (AT). When used correctly, it’s a valuable tool for accessibility.
However, ARIA can actually create accessibility issues when misused — and unfortunately, many developers try to use ARIA to fix issues with their site structure. That’s not ideal: ARIA is intended to complement structural HTML, not to replace it.
In fact, the first rule of ARIA is to avoid using ARIA when you can use HTML instead. To explain the importance of this rule, let’s look at one of the most common ARIA mistakes.
Related: 5 Common Misconceptions About WAI-ARIA and Accessibility
Let’s say you’re adding a simple hyperlink to your website. Your site uses custom JavaScript and fairly complex CSS, and you want to keep the appearance and functionality of your links consistent.
You decide to use the HTML <span> element, which is a generic inline container — it doesn’t deliver semantic information. To make the link accessible, you use the ARIA link role. Your markup looks something like this:
<span class="link" onclick="..." role="link">
Link
</span>
This will enable screen readers to announce the link as a “link,” but it’s not ideal: You’ll need to make sure that the link is focusable, and you’ll need to use CSS to make it look like a link. You’ll also need to check that the link appears in the correct tab order.
If you don’t test your website thoroughly, you’ll create accessibility issues — and even if you address all of these problems, you’re doing quite a bit of unnecessary work.
The HTML <a> element is a much better tool for the job. It’s fully supported by every type of assistive technology, and you can still use CSS to adjust the presentation as needed.
Related: Plain Old Semantic HTML: A Perfect Basis for Accessibility
Most developers have great intentions when using ARIA. Unfortunately, using ARIA won’t always improve the experiences of real-life users with disabilities.
WebAIM (Web Accessibility In Mind), a digital accessibility advocacy organization, performs an annual automated audit of the internet’s top 1 million homepages. While automated testing has limitations, the WebAIM Million report provides a useful overview of the state of digital accessibility.
In their 2022 audit, WebAIM found that ARIA code usage has increased 26% since 2021 — but home pages with ARIA had an average of 70% more errors than those without ARIA. In other words, ARIA usage was a strong predictor of accessibility issues.
That doesn’t mean that ARIA makes websites less accessible by default. WebAIM notes that the pages that use ARIA are more likely to contain complex content, and when used properly, ARIA is an excellent tool. But many websites use ARIA as a “quick fix" for complex content, which introduces new problems for AT users.
If you’re considering ARIA, ask yourself a few quick questions:
ARIA is intended for complex web elements that cannot be defined with HTML alone. If your content doesn’t meet that description — for example, if you’re adding a link, a button, or a heading — don’t use ARIA.
Related: 4 Questions to Ask Before Using ARIA
Our goal isn’t to scare people away from ARIA. If you’re building a large eCommerce website, a desktop-like web application, or even a personal website with interactive JavaScript widgets, you may need to use ARIA to provide AT users with a better experience.
Just understand that by using ARIA, you’re making a commitment to those users. Be prepared to audit your content using both manual and automated accessibility tests. Review your markup carefully before publishing changes, and make sure you understand how each ARIA role, property, or state functions.
Finally, remember that plain old semantic HTML is powerful, robust, and flexible enough for most web components — especially when you’re structuring your content.
For guidance with specific WAI-ARIA issues, send us a message to connect with a digital accessibility expert.