Common ARIA Mistakes That Break Accessibility

ARIA — Accessible Rich Internet Applications — was meant to make complex web components usable by screen readers. In practice, it is the single most misused tool in accessibility. Anyone who tells you that sprinkling ARIA attributes onto a page makes it “accessible” is selling you something. Done wrong — and it is usually done wrong — ARIA makes your site actively harder to use than if you had left it alone. Here is the honest guide to the mistakes we see most, and how to stop making them.

What ARIA Actually Does (and What It Doesn't)

ARIA is a set of HTML attributes — roles, states, and properties like role, aria-label, and aria-expanded— that describe an element to assistive technology. It changes what a screen reader announces. That is the whole job.

Here is what ARIA does not do: it does not add behavior. Putting role="button" on a <div>tells a screen reader “this is a button,” but it does not make the div focusable, does not make it respond to the Enter or Space key, and does not give it a click handler. You have promised the user a button and delivered a decoration. That gap — announcing a capability the element doesn't actually have — is the root of nearly every ARIA failure in this article. The rules of what each role requires are defined in the WAI-ARIA spec and echoed throughout WCAG 2.2.

The First Rule of ARIA Is: Don't Use ARIA

This sounds like a joke, but it is the official guidance from the people who wrote the spec. The first rule of ARIA authoring is that if you can use a native HTML element or attribute with the semantics and behavior you need, use it — instead of repurposing an element and bolting ARIA on top.

A native <button> is focusable, keyboard operable, announced correctly, and styleable, all for free. A <div role="button">gives you none of that and asks you to reimplement every piece of it by hand — and most developers only reimplement the parts they remember. The same is true for <a>, <input>, <select>, <nav>, <main>, and headings. The best ARIA is the ARIA you never wrote, because you reached for the right element first.

The ARIA Mistakes We See Most Often

Across real-world scans, the same handful of mistakes show up again and again. If you fix only these, you have cleared most of the ARIA problems on a typical site:

Roles without keyboard support. role="button" or role="link" on a non-interactive element with no tabindex, no key handlers, and no focus style. It announces as interactive but can't be operated without a mouse.
Redundant roles. <button role="button"> or <nav role="navigation">. Harmless in theory, but it signals a copy-paste habit that usually comes with the harmful mistakes too.
aria-hidden on focusable content. Hiding an element from screen readers while it's still in the tab order creates a “ghost” stop — focus lands somewhere the screen reader announces nothing.
Labels that fight the visible text. An aria-labelof “Submit” on a button that visibly reads “Send message” breaks voice control and confuses screen-reader users who hear one thing and see another.
Invalid or broken references. aria-labelledby or aria-describedby pointing at an ID that doesn't exist, so the accessible name silently resolves to nothing.
States that never update. aria-expanded hard-coded to false on a menu that opens, or aria-checked that never flips. The screen reader confidently reports the wrong state.
Overusing role="presentation". Stripping semantics off real content — tables, lists, landmarks — to force a visual layout, erasing the structure screen-reader users navigate by.

Want to know where your site stands?

Run a free scan →

Why Bad ARIA Is Worse Than No ARIA

This is the part people underestimate. A plain, unlabeled <div>is invisible to a screen reader — the user simply moves past it. But a <div> dressed up as a button is a broken promise: the screen reader announces “button,” the user presses Enter expecting something to happen, and nothing does. You have converted a harmless gap into an active dead end.

Incorrect states are even more corrosive because they destroy trust. If aria-expandedsays a menu is collapsed when it's open, the user isn't just missing information — they're being actively misled by the one tool they rely on to understand the page. This is the same failure pattern behind accessibility overlays and widgets, which inject piles of automated ARIA and frequently make the experience worse for the people they claim to help.

What a Scanner Catches — and What It Can't

Automated testing is genuinely good at the mechanical half of ARIA. A scanner built on axe-core — which is what CompliaScan runs — reliably flags invalid roles, broken aria-* references, aria-hiddenon focusable elements, required attributes that are missing, and values that aren't allowed for a given role. Run your pages through our WCAG checker or ADA compliance checker and these will surface fast.

But be honest about the ceiling: automated tools only detect roughly 30–40% of WCAG success criteria, and ARIA lives partly in the other 60%. A scanner can tell you aria-expandedis present and valid; it cannot tell you whether the value actually matches the menu's real state, or whether your aria-label is a gooddescription. That half is a human job — keyboard testing and a real screen reader, the kind of manual pass a full accessibility audit covers. Any vendor claiming a scan alone makes you compliant is overselling; nothing here makes anyone “lawsuit-proof.”

How to Fix ARIA Without Making It Worse

You don't need to become an ARIA expert. A short, repeatable discipline handles the vast majority of cases:

Reach for native HTML first. Before adding any ARIA, ask whether a <button>, <a>, or real form control would do the job. Nine times out of ten it will, and it will be more robust.
If you add a role, add the behavior with it. A custom widget needs tabindex, key handlers, a visible focus style, and the state attributes that update as it changes. Roles and behavior ship together or not at all.
Test with a keyboard, then a screen reader. Tab through the component with no mouse. Then turn on VoiceOver or NVDA and confirm the announced name, role, and state match reality.
Delete ARIA you can't justify. If you can't explain what an attribute does and why it's correct, remove it. Absent ARIA is almost always safer than wrong ARIA.
Scan, then re-scan. Use our WCAG checklist to catch the mechanical errors, fix them, and verify the count actually dropped. Frameworks and components change, so this is a habit, not a one-time cleanup.

See your lawsuit risk in 30 seconds

Over 5,100 ADA website lawsuits were filed in 2025 — a 20% year-over-year increase. Scan your site now and know exactly how exposed you are before a plaintiff's firm runs the same check.

Free scan · No signup required · Results in ~30 seconds

See plan pricing Read the compliance guides Free accessibility tools