ARIA: The Tool Most Developers Use Wrong

WAI-ARIA (Web Accessibility Initiative — Accessible Rich Internet Applications) was created to bridge the gap between complex web interfaces and assistive technologies. It's a powerful specification. It has made many things possible that weren't before.

It has also, in my experience, broken more websites than it has fixed.

I don't say this lightly. I use a screen reader for every interaction I have with the web. And I can tell you: bad ARIA is worse than no ARIA at all.

The Five Rules of ARIA (That Most Developers Never Read)

The W3C's WAI-ARIA specification comes with five rules of usage. The very first one is the most important:

"If you can use a native HTML element or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so."

In other words: use a <button> instead of a <div role="button">. Use a <select> instead of building a custom dropdown from scratch. Use a <nav> instead of <div role="navigation">.

Native HTML elements come with built-in keyboard support, focus management, and screen reader semantics. When you use ARIA instead, you're taking on the responsibility of recreating all of that yourself. Most developers don't.

The Patterns I See Every Week

1. The DIV That Thinks It's a Button

<div class="btn" onclick="submitForm()" role="button">
  Submit
</div>

This looks like a button. It has role="button". But when I navigate to it with my screen reader, I can hear it announced as a button. So far, so good. Then I press Enter. Nothing happens. Because a <div> doesn't respond to Enter or Space by default. The developer added the click handler but forgot that keyboard users don't click.

They also forgot to add tabindex="0", so in some cases I can't even reach it with Tab.

<button type="button" onclick="submitForm()">
  Submit
</button>

One element. No ARIA needed. Keyboard support is built in. Focus is built in. Screen reader announcement is built in.

2. aria-label vs. Visible Text

I regularly find elements where the aria-label says something completely different from the visible text on screen:

<a href="/account" aria-label="Navigate to your personal account dashboard page">
  My Account
</a>

A sighted user sees "My Account." I hear "Navigate to your personal account dashboard page." This creates a disconnect. If someone tells me to click "My Account," I can't find it — because my screen reader is announcing something else entirely.

WCAG 2.5.3 (Label in Name) exists specifically because of this problem. The accessible name should include the visible text, at minimum.

3. aria-hidden Hiding Things That Shouldn't Be Hidden

I've encountered pages where entire sections of content have aria-hidden="true" on them. The developer probably added it to hide a decorative element and accidentally applied it to a parent container. The result? I can't see any of that content. It simply doesn't exist for my screen reader.

The most extreme case I've seen: an entire form was inside a container with aria-hidden="true". Sighted users could see it and fill it out. For me, the form didn't exist.

4. Redundant Roles on Native Elements

The WebAIM Million report, which analyses the accessibility of the top one million websites annually, consistently finds that ARIA is one of the most misused technologies. One common pattern:

<nav role="navigation">
<main role="main">
<button role="button">
<a href="/home" role="link">

Every one of these is redundant. The <nav> element already has an implicit role of "navigation." Adding role="navigation" doesn't help — but it signals that the developer doesn't understand how HTML semantics work, which often means there are bigger problems elsewhere.

5. ARIA Live Region Overload

Live regions are meant to announce dynamic content changes to screen reader users. When a form error appears, or a notification pops up, or a counter updates — a live region makes sure I know about it.

The problem is when developers make everything a live region. I've tested pages where every section of content had aria-live="polite". Every time anything changed on the page, my screen reader would interrupt what I was doing to announce it. On one e-commerce site, scrolling through a product list triggered dozens of announcements per second. My screen reader became essentially unusable.

The other extreme is using aria-live="assertive" for non-urgent updates. Assertive live regions interrupt whatever the screen reader is currently announcing. They should be reserved for critical alerts — error messages, session timeouts, urgent notifications. Not "3 items in your cart."

6. Custom Widgets Without Keyboard Support

This is where the most damage is done. A developer builds a custom tab panel, adds role="tablist", role="tab", and role="tabpanel". The screen reader announces it as a tab interface. I expect standard keyboard behaviour: Arrow keys to move between tabs, Enter or Space to activate.

But the developer only added the ARIA roles. They didn't implement the keyboard interactions. So I press Arrow Right and nothing happens. I press Tab and it moves to the next focusable element on the page, skipping all the other tabs.

The ARIA roles created an expectation. The missing keyboard support broke it. Now I'm worse off than if there had been no ARIA at all — at least then I wouldn't have expected tab-like behaviour.

The Data Behind the Problem

The WebAIM Million report has tracked this trend for years. Their findings consistently show:

• Pages with ARIA present had more detected accessibility errors on average than pages without ARIA
• The correlation is clear: the more ARIA on a page, the more errors detected
• This doesn't mean ARIA causes errors — it means that developers who use ARIA often don't use it correctly

ARIA is a power tool. In skilled hands, it enables complex, accessible interfaces. In untrained hands, it creates a worse experience than plain HTML.

When ARIA Is Actually Necessary

There are legitimate cases where ARIA is the right choice:

• Single-page applications that need to announce route changes
• Custom widgets with no native HTML equivalent (tree views, grids, comboboxes with autocomplete)
• Live regions for dynamic content updates (used sparingly and appropriately)
• Labelling relationships that can't be expressed with native HTML (e.g., aria-describedby linking an input to a hint paragraph)
• State management for custom controls (aria-expanded, aria-selected, aria-pressed)

In these cases, ARIA is essential. But even then, it must be implemented correctly, with full keyboard support and tested with actual screen readers.

What I Recommend

1. Start with semantic HTML. Use the right elements for the right purpose. This alone solves the majority of accessibility issues.
2. Add ARIA only when HTML falls short. If you're reaching for ARIA, ask: is there a native element that does this already?
3. Follow the ARIA Authoring Practices Guide. The W3C publishes detailed patterns for every common widget. If you're building a custom component, follow these patterns exactly.
4. Always implement keyboard support. If you add ARIA roles, you must add the expected keyboard interactions. Roles without keyboard support are worse than no roles at all.
5. Test with a screen reader. Not just "does it announce something?" but "does it announce the right thing, at the right time, and can I complete the task?"

The Bottom Line

ARIA is a tool, not a solution. Using it without understanding it is like using a power drill without knowing which way the bit turns — you'll make a hole, but probably not where you wanted it.

If your team is working with ARIA and wants to make sure they're using it correctly, I'm happy to help. I've spent over 16 years navigating the web with these patterns — I know what works, what breaks, and why.