Skip to main content
Reachablr

The 2026 WebAIM Million: Web Accessibility Is Getting Worse, Not Better

7 min read
The 2026 WebAIM Million: Web Accessibility Is Getting Worse, Not Better

WebAIM published its 2026 Million report in the spring, and the headline number moved in the wrong direction: 95.9% of the top one million home pages had detectable WCAG failures, up from 94.8% in 2025.

That single percentage point understates it. The report identified 56,114,377 distinct accessibility errors across the million pages — an average of 56.1 errors per home page, a 10.1% increase over 2025. The web did not stand still. It got measurably less accessible over twelve months in which accessibility regulation tightened on two continents.

Worth being precise about what this measures: WebAIM tests home pages only, with automated tooling. Automated testing catches roughly 30–40% of WCAG issues. So 95.9% is not the failure rate — it is the floor. It is the share of home pages that fail so obviously that a machine can prove it without human judgment. The real number is higher.

The Same Six Failures, Seven Years Running

96% of all detected errors fall into six categories. They have been the same six categories for seven consecutive years.

Failure type20262025Change
Low contrast text83.9%79.1%worse
Missing alternative text53.1%55.5%better
Missing form input labels51.0%48.2%worse
Empty links46.3%45.4%worse
Empty buttons30.6%29.6%worse
Missing document language13.5%15.8%better

Five of the six got worse year over year. Only alt text and document language improved, and both improvements were small.

The striking thing about this list is not its content. It is that none of these are hard problems.

Low contrast text is a design token decision, checkable at build time. Missing alt text is a required attribute. Missing form labels is a <label for> association. Empty links and empty buttons are almost always icon-only controls where nobody added an accessible name. Missing document language is one attribute on the <html> element — a single line, on the single most cacheable element on the page, still absent from more than one in eight home pages.

Every one of the six is detectable by axe-core in under a second. This is not a knowledge problem or a difficulty problem. It is a "nothing in the pipeline was checking" problem.

ARIA Is Being Used, and It Is Making Things Worse

The report detected 133,589,803 ARIA attributes — over 133 per page on average, a 27% increase in a single year.

And pages using ARIA averaged 59.1 errors, compared to 42 errors on pages without it.

The correlation is not causal in a simple way; pages that reach for ARIA tend to be more complex applications, and complexity brings errors on its own. But the finding has held across multiple years of the report and it is consistent with what practitioners see in audits: ARIA is frequently applied as a patch over a structural problem rather than as a fix for it.

The characteristic pattern is a <div role="button"> with an onClick handler, where a <button> element would have given you the role, the keyboard activation, the focus behavior, and the correct announcement for free. Or aria-label layered onto an element that already had a perfectly good accessible name, now overriding it with something worse. Or aria-hidden="true" on a container that still holds focusable children, producing an element that screen reader users cannot perceive but keyboard users can still tab into.

What to do: Treat every ARIA attribute in a code review as a question — what native element would have made this unnecessary? The first rule of ARIA has not changed: do not use ARIA if a native HTML element with the semantics and behavior you need already exists. Most of those 133 attributes per page are not doing useful work.

Pages Are Growing Faster Than Anyone Is Testing Them

The average home page contained 1,437 elements in February 2026 — a 22.5% increase in one year, and roughly double where it was seven years ago.

WebAIM frames the consequence bluntly: users with disabilities would expect to encounter errors on 1 in every 26 home page elements.

Element count is the variable that makes manual accessibility testing unsustainable. A reviewer can hold a 400-element page in their head. At 1,437 elements, growing 20%+ annually, spot-checking stops being a strategy. The surface area is expanding faster than any human review process can cover it, which is exactly why the automated-detectable failures are climbing rather than falling.

What the Framework Data Shows

The 2026 report broke down error rates by detected technology, and the spread is wide.

Among content management systems, Adobe Experience Manager averaged 29.9 errors per page, Squarespace 33.0, and Wix 33.3 — all sharply better than the 56.1 overall average, and all down more than 40% against the baseline. At the other end, 1C-Bitrix averaged 106.5 errors, nearly 90% worse.

Among JavaScript frameworks, Astro pages averaged 9.0 errors — 84% below the average, and by a wide margin the best result in the report. Next.js averaged 40.9 and React 43.5, both better than average but not dramatically so. Firebase-associated pages averaged 82.9.

The caveat WebAIM attaches matters: the presence of nearly all popular JavaScript libraries was associated with an increase in detected errors relative to pages without them. Framework choice correlates with results, but the mechanism is confounded — sites built on heavier stacks are usually more complex applications, and Astro's advantage is partly that Astro sites tend to be content sites with less interactive surface.

The useful reading is not "migrate to Astro." It is that no framework gives you accessibility for free, and that shipping less client-side complexity is one of the more reliable accessibility interventions available.

The Practical Takeaway

The 2026 data makes an uncomfortable argument: the accessibility problem on the open web is not primarily a problem of hard, judgment-dependent issues. It is dominated by six mechanically detectable defects that have been the same six defects for seven years, on pages that are growing 20% a year, at organizations where nothing in the development pipeline checks for them.

That is a tooling and process gap, not a knowledge gap.

A pragmatic sequence:

  1. Fix contrast at the design token layer, not page by page. Low contrast text affects 83.9% of pages because it is usually a small number of token values reused thousands of times. Correcting the palette fixes it everywhere at once.
  2. Make the four "missing name" failures a lint error. Missing alt text, missing form labels, empty links, and empty buttons are all catchable by eslint-plugin-jsx-a11y before code is committed.
  3. Set the document language attribute once in your root layout and never think about it again.
  4. Gate pull requests on net-new violations against a baseline from your main branch, so existing debt does not block shipping but new debt cannot enter.
  5. Audit with a screen reader quarterly for the 60–70% that automation cannot reach.

Reachablr's URL scanning covers the six categories above against deployed pages, code scanning surfaces the ARIA anti-patterns that only appear in component source, and PR scanning enforces the baseline so the error count moves down instead of up. For React and JavaScript codebases, auto-fix handles the mechanical cases — missing labels, empty accessible names, incorrect roles — directly as suggested changes.

The six failures have not changed in seven years because most teams have no continuous check for them. That is the part that is actually fixable.

Related Posts

Scan Your Site for Free

Reachablr scans live URLs, analyzes your source code, checks every pull request, and auto-fixes React and JavaScript — WCAG 2.1 AA coverage across your entire development workflow.

Get Started Free