ARIA: Accessibility’s Double-Edged Sword
When it comes to accessibility, ARIA is one of the most misunderstood tools in the web developer’s toolkit. Used well, it can make complex interfaces accessible to people using assistive technology. Used poorly, it can create more barriers than it removes.
The latest 2025 WebAIM Million report highlights that ARIA usage has increased nearly 20% since 2024, and is five times higher than in 2019. While ARIA is intended to improve accessibility, home pages with ARIA present have over twice as many errors on average (57) than pages without ARIA (27).
Home pages with ARIA present have over twice as many accessibility errors on average than pages without ARIA
These WebAIM findings are a wake-up call to any web developer thinking about introducing ARIA to improve accessibility. ARIA was never intended to replace semantic HTML — yet that’s often how it’s used in practice.
What is ARIA and Why Does It Exist?
ARIA stands for Accessible Rich Internet Applications. It’s a specification from the W3C designed to help make modern, interactive web content accessible to people who use assistive technologies like screen readers.
Think of the web in its early days: mostly static text, headings, and links. These elements had clear meaning and worked well with assistive technology. But as websites evolved into complex applications with tabs, sliders, modals, and dynamic content, many of these patterns had no direct HTML equivalent.
That’s where ARIA comes in. It allows developers to:
Define roles for elements that don’t have semantic HTML equivalents.
Communicate states, such as whether an accordion is expanded or collapsed.
Provide relationships between elements, like linking labels to controls.
In other words, ARIA fills the gaps where semantic HTML doesn’t go far enough. It’s not meant to replace native elements — it’s meant to enhance accessibility in situations where HTML alone can’t describe what’s happening on the page.
Why Less ARIA Is Often More Accessible
Semantic HTML should always be the starting point. Elements like <button>, <nav>, <header>, and <form> come with accessibility baked in. When developers bypass these in favour of generic <div>s and <span>s patched with ARIA roles, they create unnecessary complexity.
ARIA can’t fix poor structure. In fact, it often makes it worse. The WebAIM data shows that the more ARIA attributes are present, the more accessibility errors are detected.
Put simply: no ARIA is better than bad ARIA.
Getting ARIA Right on Your Website
ARIA isn’t the enemy. It’s essential for making certain patterns accessible, but only when used correctly. Here are some examples:
Good practice
Using aria-expanded on an accordion button – lets screen reader users know whether content is expanded or collapsed.
Applying role="dialog" and aria-modal="true" on a modal – keeps focus within the modal for a clear, accessible interaction.
Marking dynamic updates with aria-live="polite" – alerts users to content changes without interrupting their workflow.
Bad practice
Replacing <button> with <div role="button"> – breaks built-in keyboard support and focus behavior.
Using role="menu" without required keyboard interactions – creates menus that are unusable for screen reader and keyboard users.
Overusing aria-hidden="true" – hides important content from assistive technology, making pages inaccessible.
For developers looking to implement ARIA correctly, following the W3C’s official guidance is essential. The WAI-ARIA 1.2 Specification and the ARIA Authoring Practices Guide provide detailed instructions, patterns, and best practices to ensure accessible, user-friendly web experiences.
Closing Thoughts
ARIA is a powerful W3C specification, but it’s not a shortcut. Accessibility starts with semantic HTML — ARIA should only ever be layered on top where it’s truly needed.
The WebAIM Million report makes one thing clear: more ARIA doesn’t mean more accessible. In fact, the data shows the opposite when it’s applied without care. Adding attributes for the sake of it often introduces more barriers than it removes.
If developers treat ARIA as a patch for weak markup, accessibility will continue to lag. But if we see ARIA for what it is — a targeted enhancement to fill gaps in HTML — it can genuinely help deliver more inclusive websites.
The future of web accessibility depends on a balance between the strong foundations of semantic HTML, supported by ARIA only when necessary.