Common ARIA Mistakes That Make Websites Less Accessible

ARIA is a promise, not a polish

ARIA attributes exist to describe custom interface components to assistive technology. Used well, they make a complex widget understandable. Used carelessly, they make a working page worse.

The reason is simple. ARIA changes what a screen reader announces without changing what the element actually does. Every ARIA attribute is a promise about behavior. When the promise is false, the visitor acts on bad information.

The first rule published in the official ARIA authoring guidance is to avoid ARIA when a native HTML element already does the job. A real button element is focusable, clickable, keyboard operable, and correctly announced, all for free. A div with role button is none of those things until someone writes the code.

Most ARIA findings in audit reports trace back to ignoring that rule.

Mistake one: the role without the behavior

The most common pattern is a clickable div or span dressed up with role equals button.

The role changes the announcement. A screen reader now says button. The visitor presses Enter or Space, because that is what buttons do, and nothing happens. The click handler only listens for the mouse.

The element also is not in the tab order unless someone added tabindex. So the button announces itself correctly to a screen reader that cannot reach it.

The fix is almost always to use a real button element and style it. The cases that genuinely need a custom control also need the full contract: tabindex zero, keydown handling for Enter and Space, and the role. The role is the smallest part of the job.

Mistake two: aria-hidden on things people need

The attribute aria-hidden equals true removes an element and everything inside it from assistive technology.

It has legitimate uses, like hiding a decorative icon sitting next to a text label. The damage happens when it lands on containers. A template tweak that puts aria-hidden on a wrapper can silently erase the navigation, a form, or the page footer for screen reader users while everything still looks perfect.

Worse is aria-hidden on an element that can still receive keyboard focus. The visitor tabs onto something that does not exist for their screen reader. Silence. Audit tooling flags this combination specifically because it is so disorienting.

Treat aria-hidden like a power tool. Small, deliberate, and never on anything interactive.

Mistake three: labels that fight the visible text

An aria-label overrides everything else when assistive technology computes the name of an element.

When a button says Submit Request on screen and its aria-label says Send, a voice control user who says click submit request gets nothing, because the accessible name of the button is Send.

WCAG added Success Criterion 2.5.3 for exactly this case. The accessible name should contain the text that is visible. The safest practice follows from it: let the visible text be the name, and reach for aria-label only on controls with no visible text at all, like an icon-only close button.

Stale aria-labels are the slow version of this bug. The visible text gets updated during a redesign, the attribute does not, and the two drift apart where nobody on the team can see it.

Mistake four: live regions and states that never update

ARIA can announce dynamic changes through live regions, and it can describe state through attributes like aria-expanded and aria-selected.

Both fail in the same way: they get set once in the template and never maintained. The menu button that says expanded false forever, no matter what the menu is doing. The cart count that updates visually while the live region stays silent. The accordion that announces collapsed while it is open.

A false state is worse than no state, because the visitor trusts it. If the team is not prepared to keep an ARIA state synchronized with the real behavior, leaving the attribute off is the more honest choice.

Mistake five: copy-pasted ARIA from snippets

A large share of broken ARIA arrives by copy and paste. A snippet from a forum answer, a theme demo, or a code generator carries roles and attributes that made sense in the original context and are wrong in the new one.

This is how pages end up with duplicate landmark roles, required ARIA children missing from composite widgets, and roles that contradict the element they sit on. Validation oriented checks flag these as violations of Success Criterion 4.1.2, which asks every component to expose an accurate name, role, and value.

The defense is mundane. Understand what each attribute promises before shipping it, and test the widget with a keyboard after pasting.

How to clean up an ARIA-heavy site

Start from the audit findings rather than hunting attribute by attribute.

A free scan surfaces invalid roles, broken references, and hidden focusable elements in about a minute. The full audit report groups those findings by pattern with screenshots and WCAG references, and the code level version points at the markup itself.

Then apply one principle across the fixes: prefer native HTML, and keep only the ARIA that describes something true. Most components end up simpler after the cleanup, not more complex.

No tool can certify a site as compliant, and ARIA correctness alone does not finish the job. But removing false promises from the markup is real progress that assistive technology users feel immediately, and it supports remediation toward WCAG 2.1 and 2.2 AA with changes a developer can verify line by line.