When to use ARIA: the first rule is don't
As rarely as you can, because the W3C’s first rule of ARIA is to use a native HTML element instead whenever one exists — a principle usually shortened to “no ARIA is better than bad ARIA.” The reason is that ARIA only adds information to the accessibility tree; it does not add behaviour, so it gives you no keyboard support, no focus management and no state handling. That’s why the most common accessibility disaster on the web is a <div> dressed up as a button, and why WebAIM found pages using ARIA average 41% more errors than pages without it. Reach for the native element first — <button>, <nav>, <main>, <a href>, <input> arrive with their role, keyboard, focus ring and name already built in. Save ARIA for the narrow cases that need it: a widget HTML doesn’t have, like a tab interface, or a state a native element can’t express, like aria-expanded on a real button or aria-describedby pointing at an error. And remember that the moment you take on a widget role, you take on its entire keyboard contract. If ARIA feels like it’s doing heavy lifting, the markup is fighting the browser.
What does ARIA actually do?
ARIA is a labelling system, not a styling system and not a behaviour system. Its whole job is to tell assistive technology what an element is — a button, a checkbox, a dialog, a navigation region — when the underlying HTML tag doesn’t already say so (Greadme, 2026). Crucially, it only adds information to the accessibility tree; it does not add behaviour, which means an ARIA role brings no keyboard support, no focus management and no state updates of its own (WebAbility, 2026).
That distinction is the key to using it well. ARIA is best understood as a repair mechanism — it fixes what HTML can’t yet express, rather than acting as a shortcut for markup you didn’t want to write (RatedWithAI, 2026). Native HTML elements, by contrast, carry their ARIA semantics implicitly and for free: a <button> is already exposed to the accessibility tree as a button, is already keyboard-focusable, already fires on Enter and Space, and already announces its label (Accsible, 2026). The moment you write <div role="button">, you take on the job of recreating all of that yourself.
Why is “no ARIA better than bad ARIA”?
Because the data shows ARIA is misused more often than it’s used well. In WebAIM’s analysis of the top one million homepages, pages with ARIA present averaged 41% more detected accessibility errors than pages without any ARIA at all (MDN, 2026). That isn’t an argument against ARIA — it’s an argument for using it correctly, and a warning about how easy it is not to.
The reason bad ARIA is so damaging is that a control labelled incorrectly is worse than one left unlabelled. Misusing ARIA produces a more inaccessible experience than using none, because a screen-reader user is actively told the wrong thing about what an element is or does (Deque, 2025). An unlabelled button is a puzzle; a button announced as something it isn’t is a trap.
The five rules that reduce to one
The W3C defines five rules of ARIA, and they point in a single direction. First: if you can use a native HTML element with the semantics you need, do — a real <button> beats <div role="button"> every time (Greadme, 2026). Second: don’t change native semantics unless you must, because putting role="button" on an <h1> erases the heading from the accessibility tree (Greadme, 2026).
The remaining three guard the edges. All interactive ARIA must be keyboard-accessible, so a <div role="button"> requires tabindex="0" plus Enter and Space handlers, with no exceptions (Greadme, 2026). Don’t put role="presentation" or aria-hidden="true" on a focusable element, or a keyboard user lands on something their screen reader can’t see (Greadme, 2026). And every interactive element must have an accessible name (Deque, 2025). Read together, all five are really one instinct: start from the native element.
The clickable div: the canonical mistake
The single most-cited ARIA error is a clickable <div>, and it’s worth seeing why it fails so completely. A <button> is keyboard-accessible by default, supports the disabled attribute, submits forms, fires on both Enter and Space, and gets a default focus ring — all at once (Greadme, 2026). A <div> styled to look like a button has none of that, and role="button" supplies only the label, not the behaviour.
Doing it correctly without a native button means writing role="button", then tabindex="0", then a keydown handler that checks for Enter and Space and calls the action — four lines recreating what <button> gives for free, and four lines that are easy to get subtly wrong (Greadme, 2026). The lesson from one developer who learned it the hard way is blunt: the biggest accessibility improvement wasn’t learning more attributes, it was trusting the ones browsers already understand (CSS-Tricks, 2026).
When is ARIA genuinely necessary?
ARIA is essential in a handful of real cases, and it’s worth naming them so the rule doesn’t tip into dogma. The clearest is a complex widget that has no native HTML equivalent — a tab interface, a combobox with autocomplete, a tree view — where you must use ARIA to supply the missing meaning (Accsible, 2026). The others cluster around constraints: remediating legacy markup where restructuring the DOM would be too costly, building a web component that needs custom semantics, or working around a native element whose browser support is unreliable enough that ARIA behaves better in practice (Accsible, 2026).
The catch is that using a widget role is a commitment, not a label. When you adopt a role like tablist or dialog, you accept full responsibility for its keyboard interaction, and the ARIA Authoring Practices Guide defines the exact patterns expected — arrow keys between tabs, Escape to close a dialog, Home and End to jump within a list (Accsible, 2026). Skip that, and your widget is technically labelled but functionally unusable for keyboard-only users — the same keyboard contract our guide on keyboard accessibility and focus covers in full.
Where ARIA legitimately helps: state, not semantics
The safest, most valuable ARIA doesn’t replace native elements — it adds state and relationships to them. A native <button> with aria-expanded is the correct way to build an accordion or disclosure trigger, because the button supplies the behaviour and ARIA supplies only the open-or-closed state (RatedWithAI, 2026). In the same spirit, aria-describedby ties a form field to its help text or error message, aria-invalid marks a field that failed validation, and an aria-live region announces a dynamic change — used politely, not with the constant interruptions that assertive causes (RatedWithAI, 2026).
Naming is the one area to handle with care. aria-label and aria-labelledby are appropriate for custom widgets that lack a visible label, but adding them to an element that already has a proper <label> creates a confusing double announcement (Easy A11y Guide, 2025). This is the same labelling discipline that makes or breaks a form, which our guide on accessible forms walks through field by field.
The misuses that make things worse
Most ARIA damage comes from a short list of predictable mistakes. Redundant ARIA is the mildest — role="button" on a <button> just adds noise — but the harmful ones are worse than noise. A hidden accessible name, where aria-label="Submit" sits on a button that visually reads “Click Here,” tells a screen-reader user one thing while a sighted user sees another (WebAbility, 2026).
Two more are especially costly because automated tools often can’t catch them. Setting aria-expanded but forgetting to toggle it when the dropdown opens makes the screen reader announce the wrong state on every use — worse than no ARIA at all (WebAbility, 2026). And applying aria-hidden="true" to a focusable element, or to its ancestor, tells assistive technology to ignore something a keyboard user can still land on (W3C, 2026). The pattern in every case is the same: ARIA that describes a reality the page doesn’t actually deliver.
The tell you’ve gone wrong: effort
There’s a reliable signal that you’ve reached for ARIA too soon, and it’s how hard it’s working. If ARIA feels like it’s doing heavy lifting, that’s usually a sign the markup is fighting the browser rather than working with it (CSS-Tricks, 2026). A common version of this mistake is treating ARIA as a styling hook — reaching for a role to attach CSS to — when the fix was a native element plus a plain class name all along (CSS-Tricks, 2026).
The reframe that solves it is to stop seeing semantic HTML as the baseline you move past. It’s the foundation everything else depends on, and native elements are better supported and need far less maintenance than anything you rebuild with ARIA and JavaScript (Accsible, 2026). When a page needs a lot of ARIA to be accessible, the honest question isn’t “which attribute did I miss” but “why isn’t this made of the elements that already work.”
Why our sites are nearly ARIA-free by construction
Everything above explains why our own pages carry almost no ARIA, and why that’s a feature rather than an omission. When a site is built from semantic, static HTML with almost no JavaScript, the native elements are already doing the exact job ARIA exists to patch — the buttons are buttons, the nav is a <nav>, the headings are headings, and each one arrives with its role, keyboard and name intact. There’s simply little left for ARIA to repair.
This is the same convergence we keep meeting: the accessible choice and the lightweight choice turn out to be one choice. A site heavy with ARIA is usually a site heavy with the custom JavaScript widgets that made the ARIA necessary in the first place, which is the performance cost our guide on JavaScript and web performance measures. Reach for the native element, and you get accessibility, speed and less code to maintain in a single decision — which is the whole practical argument of our pillar on whether web accessibility is the law: the most reliable way to comply is to build so that compliance is the default, not the patch.
Frequently asked
- What is the first rule of ARIA?
- The W3C's first rule of ARIA is: if you can use a native HTML element or attribute that already has the semantics and behaviour you need, use it instead of adding an ARIA role to a generic element. It's often summarised as 'no ARIA is better than bad ARIA,' because incorrect ARIA can make a page less accessible than using none at all. The rule exists because native elements like button, nav and input come with their role, keyboard support, focus handling and accessible name built in, whereas ARIA only adds information — it never adds behaviour.
- Does adding ARIA make a website more accessible?
- Not automatically, and often the opposite. In WebAIM's analysis of the top one million homepages, pages with ARIA present averaged 41% more detected accessibility errors than pages without it. ARIA is powerful but easy to misuse, and a control that is labelled incorrectly is worse for a screen-reader user than one that isn't labelled at all. ARIA improves accessibility only when it's applied correctly to fill a genuine gap in HTML's semantics; used as a shortcut or a styling hook, it degrades the experience.
- What's wrong with a clickable div?
- A div styled to look like a button has no role, no keyboard support, no focus behaviour and no accessible name — a screen reader doesn't announce it as a button, and a keyboard user often can't reach or activate it. Adding role='button' supplies the label but not the behaviour, so you must also add tabindex='0' and JavaScript handlers for Enter and Space, which is several lines recreating what a native button element provides for free, including disabled state and form submission. The fix is almost always to use a real button.
- When is ARIA actually necessary?
- In a few specific situations: when you're building a complex widget that has no native HTML equivalent, such as a tab interface, a combobox with autocomplete or a tree view; when you need to communicate a state a native element can't, such as aria-expanded on a disclosure button or aria-describedby pointing to an error message; when you're remediating legacy markup that can't be restructured; or when native browser support is unreliable enough that ARIA works better in practice. Outside those cases, semantic HTML should be your first instinct.
- What ARIA is safe and useful to add?
- The most useful ARIA adds state or relationships to native elements rather than replacing them: aria-expanded on a real button to indicate an accordion is open, aria-describedby to tie a form field to its help text or error, aria-invalid to mark a field with a validation error, and an aria-live region to announce a dynamic change politely. Accessible names via aria-label or aria-labelledby are appropriate on custom widgets that lack a visible label — but not on elements that already have one, since that creates a confusing double announcement.