ARIA, the poison of web accessibility
Table of contents
The tool that closes doors
Open the developer tools on any website. Search for aria-. You'll find them
everywhere — aria-label, aria-hidden, role, aria-live. On average,
133 ARIA attributes per page
across the million most visited sites in the world. Six times more than in 2019.
You might think that's good news. More ARIA, more accessibility. Except the WebAIM Million 2026 report says exactly the opposite: pages that use ARIA have 59.1 accessibility errors on average, compared to 42 for those that don't. 17 more barriers.
These pages also tend to be the most complex: rich applications, dashboards, dynamic interfaces. ARIA doesn't create errors on its own, but its massive presence signals a complexity that, poorly managed, produces more barriers than it removes. The correlation is clear, and the result is the same: the tool designed to open doors is closing more of them.
The W3C itself sums it up in one sentence, in the introduction to its ARIA Authoring Practices Guide: "No ARIA is better than bad ARIA."
This article will show you why ARIA exists, what rules the W3C laid down to prevent the worst, and how to check in 30 seconds whether your ARIA helps or poisons.
The one who hears your mistakes
You probably don't know her, but Léonie Watson has spent more time than anyone navigating the web without seeing it — and explaining to developers why their code doesn't work.
Léonie lost her sight in her mid-twenties, over the course of twelve months, due to
diabetic retinopathy. After a few years of rebuilding, she became an accessibility
engineer, then co-founder of TetraLogical, then co-Chair of
the W3C Board of Directors. Today, she navigates the web with a
screen reader eight hours a day. Every <div> disguised as a
button, every aria-label that contradicts the visible text, every aria-hidden="true"
placed on an interactive element — she hears them.
And what she hears sounds like this.
When a developer writes this:
<div role="button" onclick="save()">
Save
</div>The screen reader announces: "Save, button." Sounds correct. And when Léonie
activates it, her screen reader simulates a click: save() fires. The trap is elsewhere.
When she navigates with Tab, the fake button is invisible — because a <div> isn't
focusable by default. And for a keyboard user without a screen reader, it's worse: even
with focus placed on it via a bolted-on tabindex, Enter and Space trigger nothing,
because a <div> has no native keyboard behavior. The screen reader lied. It announced
a button that offers neither the access nor the behavior.
With native HTML:
<button type="button" onclick="save()">
Save
</button>Same announcement. But this time, Enter works. Tab works. Focus is visible. The button
is a button — not a <div> pretending to be one. Zero ARIA needed.
This is the lesson Léonie has been repeating for over twenty years: the problem isn't that there's not enough ARIA — it's that you put it where HTML is enough.
The first rule of ARIA: don't use it
The W3C published four rules for using ARIA in Using ARIA. The document is now archived (a "Discontinued Draft" since February 2026), but its rules remain the reference, carried forward by the APG. The first is also the most important:
If you can use a native HTML element with the semantics and behavior you need, use it. Don't reinvent with ARIA what HTML already does.
That's exactly what you just saw with Léonie's fake button. A <button> is focusable,
keyboard-activatable, announced correctly — without a single line of ARIA. A
<div role="button"> requires a tabindex, a keydown handler for Enter and Space, and
an explicit role. More code, more bug surface, same result at best — and a degraded
result as soon as you forget a detail.
The other three rules follow the same logic:
Rule 2 — Don't change native semantics, unless you really have to.Sometimes, the choice is justified. When you build a widget that HTML doesn't offer — like a tab system or a navigable tree view — ARIA must modify the semantics of HTML elements so that assistive technologies announce the component correctly. But that's the exception, not the rule. I detail the legitimate cases and their implementations in ARIA, the scalpel of web accessibility.
Rule 3 — Every interactive ARIA control must work with the keyboard.If you create a widget with ARIA roles, you're responsible for all the keyboard behavior. Arrow keys to navigate, Enter to activate, Escape to close. Native HTML gives you this behavior for free. ARIA gives you the semantics (the role, the states, the name) — the behavior is your code's responsibility to implement.
Rule 4 — Never hide a focusable element.<!-- ❌ The button is hidden from the screen reader
but remains focusable via keyboard -->
<button aria-hidden="true">Close</button>
<!-- ✅ If it needs to be hidden,
use the native HTML attribute -->
<button hidden>Close</button>aria-hidden="true" on a focusable element creates a ghost: the screen reader ignores it,
but Tab takes the user there. They land on an element with no name, no role, no announced
existence. That's exactly the kind of experience that drives Léonie mad. The HTML hidden
attribute does the job correctly: the element disappears from the visual rendering and
from the accessibility tree.
The decisive test
You don't need a full audit to know if your ARIA helps or hurts. Open your browser's developer tools, Accessibility tab — the accessibility tree is there. Each element shows its role, its accessible name and its ARIA states as assistive technologies see them.
Three checks in 30 seconds:
-
Does the accessible name match the visible text? Click on a button or link in the tree. If the Name displayed doesn't match what you read on screen, a voice navigation user won't be able to activate it.
-
Are the roles consistent? An element announced as "button" must behave like a button — focusable and keyboard-activatable. If it's a
<div role="button">, press Tab then Enter. If nothing happens, the role is lying. -
Are there ghosts? Navigate with Tab through the page. If focus stops on an element that the accessibility tree doesn't show, you have an
aria-hidden="true"on a focusable element — the exact trap you saw above.
The overall criteria
WCAG covers ARIA usage through several criteria, from role conformance to the relevance of accessible names. All converge on the same idea: ARIA is not a decorative tool. Every role placed is a commitment — the component must behave as that role promises. Every accessible name is a contract — it must match what the user sees and can speak.
You now know why ARIA is problematic and what rules the W3C laid down to limit the damage. If you want to know when ARIA is the right answer, which anti-patterns to avoid, and how to test in depth with a screen reader: ARIA, the scalpel of web accessibility.