Open a random website, inspect the code, and there’s a decent chance that you’ll see dozens of WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) roles. Those roles are intended to provide semantic information for screen readers and other assistive technologies (AT), which helps those technologies present content to users with disabilities.
These days, ARIA markup is everywhere. For the accessibility community, that’s encouraging — and also slightly frustrating.
It’s encouraging because we love to see businesses prioritize digital accessibility, and ARIA is solely intended for accessibility. If you’re using ARIA, you’re at least thinking about your users with disabilities.
And when used correctly, ARIA certainly improves web experiences for users with disabilities. It’s an essential tool for complex digital products (such as feature-rich web applications or websites with dynamic content).
But ARIA’s popularity is also frustrating, because ARIA should be a last resort. You can absolutely build an accessible website without using a single ARIA role — and if you have the opportunity, you should do so. Here’s why.
The first rule of ARIA: Wherever possible, don’t use ARIA
In many ways, ARIA is an extension of HTML (HyperText Markup Language). Both types of markup provide semantic information about on-page elements.
For example, let’s say your website has subheadings. HTML <h> tags identify the subheadings as — well, subheadings. Visual users can easily see subheadings, but without the appropriate HTML tag, that information wouldn’t be available to non-visual users. The semantic HTML provides that info.
ARIA works the same way, but it’s intended for dynamic, complex content. Some elements cannot be semantically identified through native HTML, particularly when the content changes regularly. When that’s the case, ARIA markup can make the content more accessible to AT users.
But the WAI’s first rule of ARIA is crucial:
If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of repurposing an element and adding an ARIA role, state or property to make it accessible, then do so.
In other words: Don’t use ARIA unless you absolutely need it.
This is why ARIA frustrates many accessibility specialists: Developers with good intentions often use ARIA roles for elements that don’t actually need ARIA. Usually, this is because they’re in the habit of using <div> and <span> — the two HTML elements that do not have semantic value — to control the visual presentation of content.
Related: 4 Questions to Ask Before Using ARIA
Overusing ARIA can hurt accessibility
So, why is it a bad idea to use ARIA instead of semantic HTML?
For starters, when ARIA is used incorrectly, it can break your website for AT users. The “application" role, for example, can prevent screen reader users from browsing the site by using landmarks or headings.
And in extreme cases, improper ARIA may prevent a user from regaining control of their web browser — obviously, that’s a terrible experience for users.
In most instances, poor ARIA won’t break a website; it’ll simply create unnecessary confusion for AT users. And since ARIA support varies significantly depending on the user’s screen reader and browser, you need to test your ARIA implementation carefully when employing it. That adds to the cost of development and makes your project much more difficult.
Wherever possible, use plain old semantic HTML (POSH). When you absolutely need ARIA, use it — but make a commitment to using it correctly. Read through the official ARIA usage recommendations, test your markup, and re-test your work after making major changes to your content.
Related: Introduction to ARIA for Web Accessibility
A web accessibility partner can help you use ARIA correctly
If you’re using ARIA, we strongly recommend working with an experienced accessibility partner. Experts can help you test your implementation with a variety of assistive technologies and web browsers — and test your content for other barriers that may impact your users.
To learn about the Bureau of Internet Accessibility’s testing, training, and remediation services, send us a message. Or, if you’re ready to learn more about accessibility, download our free eBook: The Ultimate Guide to Web Accessibility.
