Many digital accessibility initiatives fail — or, at least, they’re less successful than they could be — because they’re assigned solely to a single developer or group of developers. Regardless of the size of your business or your industry, every person on your team needs to understand the importance of accessibility. That includes content creators, designers, and customer service representatives.
And if you put the responsibility on developers alone, don’t be surprised when they gravitate towards WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications, also known as ARIA).
After all, ARIA is designed to improve experiences for people who use assistive technologies. Proper ARIA markup can make your website much friendlier for folks who use screen readers and speech recognition tools — and if you’re staring down a particularly difficult accessibility issue, there’s probably some ARIA markup that could solve that problem.
But when you treat ARIA as a “quick fix,” you’re setting yourself up for serious accessibility issues. Here’s what developers should know about WAI-ARIA and its use cases for accessibility compliance.
In WebAIM’s 2025 analysis of the internet’s top 1 million home pages, 79.4% used ARIA (excluding landmark roles), a significant increase from 74.6% in 2024.
That indicates that devs are spending more time thinking about accessibility — but it doesn’t translate to better accessibility. Per WebAIM:
We should note here that adding ARIA doesn’t necessarily “break" pages — complex content may need ARIA, and by nature, complex content is more likely to have accessibility issues. In other words, while ARIA usage is correlated with more accessibility barriers, correlation doesn’t equal causation.
But ARIA isn’t an all-in-one accessibility solution (and it’s not intended for that purpose). It improves experiences for AT users in very specific circumstances, when used correctly.
The first rule of ARIA is to avoid using it when semantic HTML could be used instead. That’s important because native HTML works with virtually every internet-focused technology — including screen readers and other AT.
ARIA is supported by AT software, but it’s far less reliable: Screen readers like JAWS and NVDA may interpret ARIA markup differently, and since screen readers are not web browsers, their output will change depending on whether the user is using Firefox, Chrome, or something else.
That’s a problem because ARIA is used to define semantics when those semantic elements cannot be defined with native HTML.
For example, developers often create buttons out of <div> elements, then add ARIA attributes to fill in the gaps:
<div role="button" tabindex="0">Submit</div>
Screen readers will usually announce this as a “button,” but because of the <div>, the button will lack the functionality of an HTML button. The developer would need to add extra JavaScript to make sure that the “button" is usable with both a mouse and a keyboard. The native <button> element is keyboard accessible by default, so it works universally across all browsers and assistive technologies — without extra scripting.
When you use ARIA to change the semantics of an element, you are making a contract with the user to manually recreate all the functionality that the native element provides by default. You must test your work using different types of AT (for example, multiple screen readers with multiple browsers).
That’s a lot of extra work, and it’s wholly unnecessary. While <div> and <span> elements provide developers with a lot of freedom, they’re a waste of time if you could simply plug in some semantic HTML.
So, why do developers make that mistake? It’s often due to a fundamental misunderstanding about web accessibility: They see digital access as something to “check" when writing their code and markup.
They’ll build content, then run that content through Google Lighthouse or another automated accessibility checker, then open tickets for any failures that show up.
This checklist approach is where development efforts go wrong. When accessibility is treated as an afterthought, ARIA becomes a sort of magic wand — and unfortunately, it’s a magic wand that doesn’t really work.
To build truly accessible experiences, developers should adopt a more proactive approach:
If you’re ready to build a comprehensive accessibility compliance strategy, the Bureau of Internet Accessibility can help. Get started with a free automated web analysis powered by AudioEye or send us a message to connect with a subject matter expert.