WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) is a powerful tool for improving accessibility. Also known as ARIA, it’s a set of attributes that can be added to HTML elements to define semantics that aren’t available with native HTML alone.
ARIA lets you communicate information about your website to assistive technologies (AT). That includes screen readers, eye-tracking systems, and other technologies that people with disabilities use to browse the web.
But while ARIA is extremely useful in certain cases, it’s not always essential. In fact, you should not use ARIA if at all possible — if you can use HTML, you should always do that instead.
Why Overusing WAI-ARIA Leads to Accessibility Issues
By one estimate, WAI-ARIA usage has nearly quadrupled since 2019. That’s not necessarily good news for accessibility: Misusing ARIA can cause serious issues for AT users. ARIA is an extension of HTML, not a replacement, and the first rule of ARIA is to avoid using it.
Why? For starters, ARIA is quite powerful. It contains roles and attributes that change the way that AT presents content. If developers use ARIA without understanding precisely how it works, the user experience suffers.
The ARIA “application" role, for example, is intended for web apps that have desktop-like functionality. That role also prevents AT from using traditional HTML interpretation techniques. Screen readers may be unable to navigate the website by using headings or landmarks, and default shortcuts may be disabled. Users might be unable to regain control of their browsers, and they might feel “trapped" within the content.
Needless to say, that’s not a great experience for users — and if you’re not testing your content regularly, you might be completely unaware that your website is broken for a portion of your audience.
If you misuse ARIA markup, your website may become less accessible than if you’d never messed with ARIA at all. And unfortunately, ARIA mistakes are quite common; many developers use ARIA simply because they feel like they should.
Related: 4 Questions to Ask Before Using ARIA
When Using ARIA Improves Accessibility
Here’s a simple rule to keep in mind: If you can use HTML to define semantics, you don’t need ARIA.
That also applies to <div> and <span> containers, by the way! If you’re overusing <div> and <span> — the two HTML elements that are not semantic — you may find yourself using a lot of ARIA to fill in the gaps. In many cases, another HTML element would make more sense, and using plain old semantic HTML may help you minimize ARIA usage.
However, complex and dynamic content often needs ARIA markup to work well with assistive devices. Some quick examples:
- Your website contains an element that will be updated, and you want to inform AT users of the types of updates they can expect from that element. In that case, you’d need the aria-live attribute — native HTML would not have an equivalent alternative.
- Your website contains an interactive button without any visible text. You may need to use aria-label to provide a text alternative for AT users.
- Your website has drag-and-drop elements, and you need to convey information about those elements to AT users. Attributes like aria-dropeffect and aria-grabbed may be essential.
Remember, if you’re using ARIA, you’re making a big commitment. You must test your markup carefully (ideally, using several different screen readers and web browsers). Because ARIA can seriously impact accessibility, we recommend working with an accessibility partner when developing complex content.
Your partner can help you establish a testing strategy and implement ARIA in a way that provides the best possible experience to real users — and conforms with the best practices of the Web Content Accessibility Guidelines.
To learn more, send us a message or get started with a free WCAG Level AA compliance summary.
