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.
ARIA doesn't necessarily improve accessibility
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:
- Home pages with ARIA present had more than twice as many errors than pages without ARIA.
- The more ARIA attributes that were present on a given page, the more detected accessibility errors could be expected.
- 35% of ARIA menus (role=”menu") introduced accessibility barriers due to the lack of necessary ARIA menu markup and interactions.
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.
ARIA is widely supported, but HTML is practically universal
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.
Using unnecessary ARIA creates extra work, with no benefits for real users
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.
Make sure your development process prioritizes accessibility
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:
- Use semantic HTML wherever possible. Before reaching for a <div> or <span>, always ask if a native HTML element can accomplish the same thing.
- Integrate accessibility from the start. Don't treat accessibility as a final step before deployment. Discuss accessibility requirements during design mockups, create user experience (UX) personas with disabilities, and test your content throughout development.
- Test manually with assistive technology. Automated checkers are helpful, but they only catch a fraction of potential issues. Work with your accessibility partner to include manual checks in your audits, and you’ll spend less time remediating issues.
- Use ARIA for enhancement, not as a foundation. ARIA is for making complex, dynamic web components accessible when no native HTML solution exists. When you use it, consult the WAI-ARIA Authoring Practices — and wherever possible, work with an accessibility partner to test the results.
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.
