Why ARIA Usage Is Increasing, But Accessibility Isn't Improving

Here’s an interesting trend (at least, it’s interesting for folks in the digital accessibility space): Usage of ARIA (Accessible Rich Internet Applications) is increasing — but many of the websites that use ARIA fail basic accessibility checks. 

We know about this thanks to WebAIM, which publishes an annual analysis of the internet’s top 1 million home pages. According to the 2025 analysis:

• 105,509,338 ARIA attributes were detected on the tested home pages, an average of about 106 attributes per page.
• 79.4% of the one million home pages used ARIA, an increase from 74.6% in 2024. 
• Home pages with ARIA present had over twice as many errors (57 on average) than pages without ARIA (27 on average).
  
  

ARIA was created to make the internet more accessible for screen readers (software that outputs text as audio) and other assistive technologies. Shouldn’t more ARIA mean a more accessible internet?

Why ARIA is Necessary for a More Accessible Internet

Let’s start with the basics: ARIA is used to communicate semantic information about a website to AT software and devices.

Semantic info is important because it tells web browsers and assistive technologies what each element is and how it behaves. A user might want to skip around to hyperlinks or fill out a form; semantic markup says, “here’s a link,” “here’s a form field,” and so on.  

Usually, HTML delivers this semantic information. But while HTML5 has come a long way, some features cannot be described through HTML alone — particularly if the web content is dynamic (frequently changing) or complex. 

ARIA provides roles, states, and properties that allow developers to add missing semantic information for assistive technologies (AT) like screen readers. For instance: 

• You can use role="tablist", role="tab", and aria-selected="true" to make a set of <div> elements behave like tabs. 
• You can use aria-live="polite" to announce dynamic content updates. 
• You can use the aria-label attribute to provide elements with accessible names, which may be necessary if HTML doesn’t have a default accessible name that accurately describes the element.
  
  

In these scenarios, when native HTML lacks the required semantics, ARIA is essential for accessibility.

But ARIA is neither a first resort or a magic bullet — and the very first rule of ARIA is clear: Don’t use it unless you really, really need it. 

Related: Should My Website Use WAI-ARIA for Accessibility?

Why ARIA Should be Avoided Wherever Possible

ARIA is complex, flexible, and powerful. It’s fairly widely supported, but not as widely supported as native HTML. It also needs to be tested thoroughly using assistive technologies wherever possible. 

We used a bold typeface for that last point, and as we’ve discussed in other articles, we’re very careful about using typeface for emphasis. Developers, if you take nothing else from this article, remember that you must test your ARIA markup!

Otherwise, you’re bound to make avoidable mistakes:

• Redundant ARIA: Applying ARIA roles or attributes that duplicate the native semantics of an HTML element. For example, writing <button role="button">Click Me</button> is unnecessary; the <button> element already conveys its role. This adds noise to the screen reader output (and frustration for the user). 
• Incorrect Roles/Properties: Assigning a role that doesn't match the element's function (for example, using role="button" on a link that navigates) or using states and properties incorrectly (e.g., aria-checked="true" on something that isn't a checkbox or radio button).
• Static ARIA States: Applying ARIA states like aria-expanded or aria-selected but failing to update them dynamically with JavaScript when the user interacts with the component. Learn more: What Does "Aria-Expanded" Mean?
• Breaking Native Behavior: Overriding default browser behaviors or keyboard navigation patterns expected by users (for example, by misusing the ARIA application role). A custom ARIA widget must replicate all of the expected keyboard interactions of its native counterpart.

ARIA can make your website much, much worse for AT users — in some cases, the content may be completely unusable.

Using ARIA Responsibly: Simple Principles

The most crucial guideline for ARIA implementation is outlined in the World Wide Web Consortium (W3C) ARIA Authoring Practices Guide:
 

If a native HTML element or attribute has the semantics and behavior you need, use it instead of repurposing an element and adding ARIA. 

This is important because native HTML elements have built-in accessibility features (for example, default keyboard focusability) and widely supported semantics. 

Before reaching for role="button", ask: Can I use a <button> element? Before role="navigation", can I use <nav>? Before role="checkbox" and complex state management, can I use <input type="checkbox">? Prioritizing native HTML leads to more robust, predictable, and maintainable accessibility.

The Missing Link: Consistent Testing with Assistive Tech

Even when ARIA is deemed necessary and developers attempt to follow best practices, implementation errors can still occur. The only way to verify that ARIA is actually helping real-life users is through consistent testing with the tools they use.

This means going beyond automated checkers. Automated tests are useful for fixing some ARIA issues, but they should be supplemented with manual checks:

• Keyboard Navigation Testing: Can you reach and operate every interactive element using only the Tab, Shift+Tab, Enter, Space, and Arrow keys? Does the focus order make sense?
• Screen Reader Testing: Tests should use actual screen readers like NVDA, JAWS, or VoiceOver — and ideally, all tests should be performed by regular screen reader users. Does the screen reader announce roles, states, and properties correctly? Can you understand the purpose and operation of custom widgets?
  

Without this feedback loop, developers are essentially flying blind, deploying ARIA that might look correct in the code but fails in practice. The lack of widespread, proficient assistive technology testing is a major reason why increased ARIA usage hasn't correlated with a more accessible internet. 

Related: How Screen Readers Are Used in Accessibility Testing

Use ARIA Wisely and Test Thoroughly

Once again, we’re not saying that you should never use ARIA under any circumstances. It’s an extremely important part of a developer’s toolkit when used correctly. 

But if you use ARIA because you really like loading your pages with <div> and <span> attributes — or if you use ARIA because you’re “supposed to use it,” and you have no plan for testing your work — you may be creating barriers for your audience.

We’re here to help. If you have questions about ARIA implementation, send us a message to connect with a subject matter expert. To test your content for common errors, get started with a free automated analysis from AudioEye.