More ARIA, More Barriers: The Accessibility Paradox in the 2026 Data

May 18, 2026

Pages with ARIA attributes have 41% more accessibility errors than pages without them.

That statistic comes from WebAIM's Million 2026 report, which analyzed the home pages of one million websites for accessibility failures. It's been cited as a paradox. ARIA — the Accessible Rich Internet Applications specification — exists specifically to make complex web interfaces more accessible. It provides screen readers with semantic information that HTML alone can't communicate. It's the thing you're supposed to reach for when native HTML falls short.

And yet the data shows it correlates with more errors, not fewer.

The standard explanation is: this is correlation, not causation. Complex pages use ARIA because they need it, and complex pages also have more accessibility failures because complexity introduces failure modes. ARIA isn't causing the errors. It's present at the scene.

That explanation is correct. It's also incomplete. And the part it leaves out is where the actual design problem lives.

What the WebAIM Data Actually Shows

The WebAIM Million is the most comprehensive regular audit of web accessibility. One million pages, automated accessibility testing via WAVE, results published annually. The 2026 edition documents several significant trends beyond the ARIA correlation:

Average page complexity reached 1,437 detectable elements per home page — a 22.5% increase year-over-year. This is the fastest growth in the dataset's history.

The use of aria-hidden (which hides elements from assistive technology) is up 250% since 2020. The role="menu" attribute — one of the most commonly misused ARIA roles — appears on 22% of pages that use ARIA, and most of those implementations are incorrect.

Home pages with ARIA had an average of 46.7 accessibility errors, compared to 33.7 for pages without ARIA. The gap has widened in each of the last three years.

The correlation isn't subtle. And the complexity trend that underlies it is accelerating.

Why Teams Reach for ARIA in the First Place

ARIA was designed for a specific problem: native HTML can't communicate all the semantic information that complex interfaces need to convey to screen readers. A collapsible accordion, a live search results region, a custom dropdown — these patterns don't have HTML elements that express their behavior. ARIA fills that gap with attributes that tell assistive technology: "this element is a button," "this region updates dynamically," "this item is expanded."

Used correctly, ARIA is essential. The spec's first rule of ARIA is actually: "Don't use ARIA." Native HTML elements — <button>, <nav>, <input>, <select> — carry built-in accessibility semantics that don't require additional markup. A screen reader already knows what a <button> is. You don't need role="button" unless you're using a <div> that looks like a button.

The problem is that "using a <div> that looks like a button" describes a significant fraction of the modern web. Component libraries built on generic container elements, design system components that prioritize visual flexibility over semantic HTML, JavaScript frameworks that render everything as <div> trees — these create interfaces where ARIA isn't optional. It's the only way to communicate structure to assistive technology.

And this is where design decisions, made long before a single line of ARIA is written, determine whether accessibility is achievable.

The Design Constraint Nobody Is Counting

When a design system starts with visually flexible container elements rather than semantically meaningful HTML elements, it makes ARIA mandatory rather than supplementary. Every custom component now requires ARIA to be accessible. The team has to:

Implement the correct role for every interactive element
Manage aria-expanded, aria-selected, aria-checked, and similar state attributes manually as component state changes
Handle focus management explicitly, including keyboard navigation patterns that native HTML elements handle automatically
Wire up aria-live regions for dynamic content correctly, accounting for how different screen readers process updates

This is significant engineering surface. Each attribute is a potential error. The WebAIM data's most common ARIA errors — incorrect roles, missing required ARIA children, aria-hidden on focusable elements, aria-label on elements that don't need them — all follow directly from teams implementing ARIA at scale without deep familiarity with how screen readers process the attributes in practice.

The growth in page complexity is the driver. Accessibility complexity grows roughly proportionally to interface complexity, but the correct ARIA implementation complexity grows faster than proportionally, because interactions between ARIA attributes are non-obvious and the failure modes are silent.

A <button> that isn't labeled communicates nothing to a screen reader. But a <div role="button"> that isn't labeled with aria-label or aria-labelledby, and doesn't manage focus correctly, and doesn't handle keyboard events, produces an experience that actively misleads screen reader users while appearing functional to sighted users. The errors compound.

The Design Decision That Sets the Ceiling

There's a point in every design system's architecture where the foundational choice gets made: do components abstract over semantic HTML elements, or over visual primitives?

The first approach builds a <Button> component that renders a <button>. The second builds a <Pressable> or <Clickable> that renders a <div> and expects consumers to manage semantics.

The first approach constrains visual design — you're working with what HTML gives you for button-like elements, and some visual designs don't fit neatly into those constraints. The second approach provides visual flexibility but makes accessibility a perpetually open question that ARIA has to answer at the point of use.

Most enterprise design systems have drifted toward the second approach over the past decade, because product teams demanded design flexibility and the accessibility cost was diffuse and hard to measure. The WebAIM data now measures it. The 22.5% growth in page complexity is partly the result of this architectural choice accumulating at scale.

The WCAG neurodivergent gap coverage here examined how WCAG compliance doesn't guarantee usable experiences for neurodivergent users — a related pattern where passing audits doesn't mean accessibility work is done. The ARIA situation is the upstream version of that problem: the structure that makes auditing even possible is compromised by architectural choices made before anyone opened an accessibility checker.

What the Correct Response Looks Like

Telling teams to "just use native HTML" is accurate advice that fails in practice. Large codebases built on div-heavy component systems can't be refactored to semantic HTML overnight, and the business pressure that created those systems hasn't changed.

More useful interventions:

Audit components at the design system level, not the page level. If the foundational <Button> component is accessible, every instance of it is accessible. If it's not, every instance isn't. The WebAIM Million approach — testing pages — catches downstream failures. Fixing upstream in the component library is more efficient.

Track ARIA complexity as a design metric. If a design requires custom ARIA to be accessible, that's a signal the design might be structurally inaccessible without it. Some complexity is unavoidable; a lot of it isn't. Requiring ARIA in every component review creates visibility into which design decisions are generating accessibility debt.

Treat aria-hidden as a red flag in code review. The 250% increase in aria-hidden usage since 2020 is largely a symptom of teams hiding decorative elements or broken ARIA implementations from screen readers rather than fixing the underlying issue. A component that needs to be hidden from assistive technology to work correctly usually needs to be redesigned.

The 41% figure isn't a ARIA problem. It's a design complexity problem that ARIA makes visible.

Photo by Bibek Ghosh via Pexels