More ARIA Isn't Making Your Site More Accessible

ClearPath Team · 2026-08-09 · 6 min read

If you asked most developers how to make a custom dropdown or a fancy tab panel more accessible, the reflex answer is to sprinkle in some ARIA attributes. Add a role here, an aria-label there, maybe an aria-expanded for good measure. It feels like doing the responsible thing. The problem is that the data keeps showing the opposite result.

WebAIM's most recent Million report, which scans the home pages of the top one million sites on the web, found that home pages with ARIA present had significantly more errors (59.1 on average) than pages without ARIA (42 on average). That gap hasn't been shrinking as ARIA usage grows. It's been widening. In this year's data, 82.7% of the one million home pages used ARIA (excluding ARIA landmark roles), up from 79.4% the year before, and the report's own conclusion was blunt: a primary concern is the significant increase in home page complexity and ARIA code, both of which correlate to increased detectable errors.

This isn't a fluke of one year's data either. The report notes that increased ARIA usage on pages was associated with higher detected errors, and the more ARIA attributes present, the more detected accessibility errors could be expected. Some of that is because complex sites naturally use more ARIA and are more complex overall. But even accounting for that, misapplied ARIA is doing real damage. One analysis of a recent report found that 35% of ARIA menus introduced new accessibility barriers due to missing required interactions or roles. A menu that's supposed to help keyboard and screen reader users is instead confusing them.

Why bad ARIA is worse than no ARIA

There's a saying that's repeated so often in accessibility circles it's practically a proverb: no ARIA is better than bad ARIA. It's not just a catchy line. MDN's own documentation states it directly, citing WebAIM's finding that home pages with ARIA present averaged 41% more detected errors than those without ARIA.

Here's why the damage is worse than doing nothing. ARIA attributes tell assistive technology what something is and how it behaves. When you add role="button" to a div but forget to make it keyboard focusable, or add aria-expanded="false" to a menu but never update it when the menu actually opens, you've told a screen reader user something false about your page. A sighted user just sees a dropdown that doesn't work great. A screen reader user gets confident, specific, wrong information about the state of the interface. That's a worse experience than a plain, unstyled but honest control.

The W3C's own guidance backs this up directly: the first rule of ARIA use is "If you can use a native HTML element or attribute with the semantics and behavior 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." A button element already has keyboard support, focus handling, and a role built in for free. A div with role="button" needs all of that rebuilt by hand in JavaScript, and it's easy to miss a piece.

The two attributes causing the most trouble

Two specific patterns show up again and again in the recent data:

• aria-hidden overuse. This attribute hides content from assistive technology while leaving it visible on screen. It's meant for genuinely decorative elements, like a repeated icon next to text that already says the same thing. Recent analysis found pages now average over 23 instances of aria-hidden="true", a sharp jump from prior years. Used carelessly on a wrapping div, it can hide entire chunks of real content from screen reader users while sighted visitors see it just fine.
• Custom widgets missing required keyboard behavior. ARIA can tell a browser "this div is a tab panel," but it does nothing to actually make that div respond to arrow keys or Enter. Developers add the role and stop there, assuming the label alone does the work.

What this means if you're not a developer

If you run a small business site or manage sites for clients, you probably didn't write this code by hand. Most of it came from a theme, a page builder, or a plugin that promises "accessibility built in." That promise is often only half true. A plugin might add ARIA labels to satisfy an automated scanner without checking whether the underlying interaction actually works for someone using a keyboard or a screen reader. It's worth being clear here that a tool like ClearPath sits on top of this same layer: it can give visitors ways to adjust text size, contrast, and other display settings through 25 tools and 8 preset profiles, but it cannot rewrite a broken custom dropdown's ARIA or add missing keyboard support to it.

This matters because ARIA problems are invisible in a regular visual review. Your site can look polished, pass a quick glance, and still have menus, sliders, or accordions that actively mislead assistive technology. The only way to catch it is testing with a keyboard and, ideally, an actual screen reader, not just eyeballing the design.

What to actually check

1. Tab through your site's interactive elements. If a custom dropdown, modal, or tab panel can't be reached or operated with the keyboard alone, ARIA labels on it won't help anyone.
2. Look for role attributes on elements that already have a native equivalent. A styled div acting as a button is a common culprit.
3. Check that dynamic states like aria-expanded or aria-selected actually change when the interface changes. A label that always says "collapsed" even when the panel is open is worse than no label.
4. Ask whoever built your theme or plugins whether their "accessible" components have been tested with real assistive technology, not just an automated scanner.

The bigger lesson from the data is simple: ARIA is a tool for filling gaps in HTML, not a stamp you add to feel better about a component. When in doubt, a plain, native HTML element that works correctly will always beat a custom one wrapped in ARIA that only sort of works. Fewer, correct attributes beat more, sloppy ones every time. Adding something like ClearPath's one-line widget can still help visitors adjust the experience to their needs in the meantime, even though it won't touch the ARIA or markup issues described above.