WebAIM Million 2026: Same Six Failures, Worse Numbers Tell the Real Story

56,114,377 Errors and the One Number That Explains the Rest

The 2026 WebAIM Million report (opens in new window) detected 56,114,377 distinct accessibility errors across the home pages of the top one million websites. That's an average of 56.1 errors per page — a 10.1% increase from 51 errors per page in 2025, reversing a multi-year downward trend. 95.9% of home pages now contain WCAG 2 A/AA failures detectable by automated tools, up from 94.8% last year.

The same six failure categories continue to dominate. They account for 96% of every error detected. Adding accessibility infrastructure to address just those six categories would meaningfully improve the experience for millions of disabled users.

But there's a buried finding in this year's report that explains why the numbers keep getting worse — and it's not about the six failures at all.

The ARIA Paradox

WebAIM's data shows that pages using ARIA contain an average of 59.1 errors, while pages without any ARIA average just 42 errors. That is not a typo. Adding ARIA correlates with 17 more accessibility barriers per page, not fewer.

ARIA usage has exploded. The average page now contains 133+ ARIA attributes, up from 22 in 2019 — a six-fold increase in seven years. The single-year jump from 2025 to 2026 was 27%. Pages now average **23.3 instances of aria-hidden="true"** alone, up 30% from 2025 and over 250% since 2020. The tabindex attribute appears 30.4 times per page, up 17% in one year and nearly 300% since 2020.

ARIA was designed to bridge gaps where native HTML couldn't express semantics. In practice, it has become a way to wallpaper over inaccessible custom components — and the wallpaper itself is causing harm. WebAIM's own 2026 conclusion: "Pages utilizing ARIA were associated with significantly more errors than those that did not."

This is the systemic story of the 2026 report. Organizations are layering more accessibility code onto pages without building the discipline to use it correctly.

The Six Failures: Some Better, Most Worse

The categories themselves are not exotic. They are the same patterns that have dominated the WebAIM Million for eight consecutive years.

Failure Type	2026	2025	Direction
Low contrast text	83.9%	79.1%	⬆ Worse
Missing alt text	53.1%	55.5%	⬇ Better
Missing form labels	51.0%	48.2%	⬆ Worse
Empty links	46.3%	45.4%	⬆ Worse
Empty buttons	30.6%	29.6%	⬆ Worse
Missing document language	13.5%	15.8%	⬇ Better

Five of six categories got worse year-over-year. Low contrast — already the most prevalent failure — climbed nearly 5 percentage points and now appears on 83.9% of pages. The average affected page has 34 distinct low-contrast text instances, a 15% jump from 2025.

The two categories that improved share something in common: alt text and document language are both server-renderable, single-decision fixes that benefit from CMS automation. The categories that got worse — contrast, form labels, empty links, empty buttons — are all properties of dynamic, interactive components. They reflect what teams ship, not what content authors enter.

Page Complexity Has Doubled in Seven Years

In 2019, the average home page contained 782 HTML elements. In 2026, it contains 1,437 — a 22.5% increase in just one year and nearly double the 2019 figure. The most popular sites in the dataset (top 100,000) average 1,584 elements per page, 20% more than the bottom 100,000.

Error density holds at roughly 1 detectable error per 26 elements. As pages grow more complex, the absolute error count grows with them. The web is not getting more accessible — it is getting more code, with the same defect rate baked in.

WebAIM names the cause directly in the report's conclusion: "Increased reliance on third-party frameworks and libraries, and automated or AI-assisted coding practices ('vibe coding')." When the code is generated rather than authored, accessibility decisions are not being made — they are being inherited from training data that already failed.

The Framework Story: Astro Stands Alone

Among JavaScript frameworks with meaningful sample sizes, the gap between best and worst is staggering.

Best performers (fewer errors than average):

• Astro: 9.0 errors (−84% vs. average) — the standout of the entire report
• Next.js: 40.9 (−27.1%)
• React: 43.5 (−22.5%)

Worst performers:

• jQuery UI: 79.9 (+42.3%)
• prettyPhoto: 80.4 (+43.3%)
• FancyBox: 90.0 (+60.3%)
• SweetAlert2: 101.6 (+81.0%)

Astro at 9 errors per page is not a rounding-error result. It is roughly six times better than the report's average. The pattern: server-rendered, minimal-JavaScript architectures ship less code, expose less surface area, and inherit fewer of the accessibility defects that come bundled with carousel and modal libraries written years ago.

The legacy carousel and lightbox libraries — Slick (70.9), OWL Carousel (70.7), Lightbox (70.5), Swiper (74.0) — are the connective tissue of a generation of marketing sites. They are also accessibility liabilities at scale. jQuery itself, still on 560,294 pages in the dataset, correlates with 64.9 errors per page versus the 56.1 average.

The .gov Anomaly: Section 508 Actually Works

Pages on the .gov top-level domain average 18.5 errors — 67.1% fewer than the overall mean. .edu averages 23.0 errors (−59%). These are the two best-performing TLDs in the entire report, and the gap to .com (56.2 errors) is enormous.

This is the cleanest piece of evidence in the 2026 dataset that mandates work. Federal agencies and universities operate under Section 508, the DOJ Title II final rule (opens in new window), and state procurement requirements that demand WCAG 2.1 AA conformance. Compliance requirements are routinely framed as bureaucratic burden in the private sector. The data shows that organizations subject to enforceable accessibility standards build more accessible products. Not perfectly accessible — but measurably, materially better.

The opposite pattern shows up at the bottom of the TLD ranking: .ru (75.4), .vn (78.6), .cn (82.6), .ua (103.1). These represent jurisdictions with weak or absent digital accessibility enforcement.

The Language Access Disparity Nobody Is Talking About

WebAIM Million identifies the document language for 87.3% of analyzed pages and breaks down errors by declared language. The disparity is brutal.

Language	Avg Errors/Page	vs. Average
English	46.0	−18.0%
Dutch	46.5	−17.1%
German	46.9	−16.4%
French	58.5	+4.2%
Japanese	62.2	+10.8%
Spanish	64.3	+14.7%
Russian	78.1	+39.2%
Korean	94.6	+68.7%
Chinese	136.2	+142.8%

Pages declaring lang="zh" average nearly three times more accessibility errors than pages declaring lang="en". This is not a translation problem. It is an infrastructure problem. The frameworks, CMS templates, component libraries, and accessibility tooling that the global web relies on were built primarily in English-speaking markets, tested on English content, and documented for English-speaking developers.

The compounding effect is profound: a Chinese-speaking screen reader user encountering the average top-million website is hitting roughly 136 distinct accessibility barriers before they read a word of content. Tools like idioma.chat (opens in new window) — which translate the full accessibility layer including ARIA labels, form errors, and dynamically loaded content — exist precisely because this multilingual accessibility gap is real and measurable. WebAIM's report just put a number on it.

What This Means Through a Systems Lens

Through the CORS framework, the 2026 WebAIM Million data reveals an operational capacity failure, not a knowledge failure. Detection has scaled. Automated scanning is cheap, ubiquitous, and reasonably accurate. What hasn't scaled is the organizational discipline to act on what scanning finds — to integrate accessibility into design systems, content workflows, code review, and component libraries before issues ship.

The strategic lesson hiding in the framework data is that architectural choices upstream of accessibility work harder than remediation downstream. Astro's 84% error reduction did not come from a heroic accessibility team auditing every page. It came from shipping less JavaScript, rendering on the server, and inheriting fewer of the patterns that produce empty buttons and unlabeled controls.

The risk lens points to the .gov data: the organizations subject to enforceable standards have measurably better outcomes. As the DOJ's April 2024 Title II rule (opens in new window) takes effect for state and local governments through 2026 and 2027, we should expect to see those entities migrate toward .gov-style numbers — if they invest in capacity, not just compliance theater.

The community lens is the most uncomfortable. The Chinese-language data point should be a five-alarm fire for anyone who frames accessibility as a global mission. The web's accessibility infrastructure is conspicuously English-shaped, and the people most disadvantaged by that are also the people most likely to be invisible in the rooms where accessibility tools, frameworks, and standards are built.

Transcript with visual descriptions

Title

On screen: Title card on a dark teal background: "Language access is accessibility". Four floating language chips read "Inscríbase" (Spanish), "报名" (Chinese), "등록하기" (Korean) and "Sign up".

I want to talk to you today about language access.

Every year, WebAIM tests the home pages of the top one million websites.

In 2026, the same six failures showed up again.

This episode is about the one that looks smallest: missing document language.

The statistic

On screen: A large amber "13.5%" beside the text "of the top million home pages don't declare a language". Below it: "Down from 15.8% in 2025, one of only two failures that improved." A row of the six WebAIM failures with 2026 rates: Low contrast 83.9%, Missing alt text 53.1%, Missing form labels 51.0%, Empty links 46.3%, Empty buttons 30.6%, and Missing language 13.5% (highlighted).

13.5% of home pages never tell the browser what language they’re written in.

It’s one of the only two failures that improved this year. But across a million sites, that’s still about 135,000 pages.

And it sits alongside five others that mostly got worse.

The problem

On screen: A mock browser window for "Northstar Events" with a heading "Community events this fall" and a boxed Spanish newsletter notice: "Boletín en español. Inscríbase para recibir noticias de eventos comunitarios." Beside it, the page source shows an opening html tag with no lang attribute, marked "Fail: No lang attribute. Assistive tech has to guess." A speech bubble shows a screen reader with an English voice reading the Spanish text.

Here’s a community events page with a Spanish newsletter sign-up.

The page never declares its language, so a screen reader has to guess.

Often it guesses English, and reads the Spanish like this:

[Screen reader, English voice, mispronouncing Spanish] Inscríbase para recibir noticias de eventos comunitarios.

For a Spanish speaker using a screen reader, that’s hard to understand.

How to test

On screen: Heading "Testing for it takes about a minute" over three numbered steps. 1: Check the html tag, shown as html lang="?". 2: Run a checker (WAVE and axe both flag "Language missing or invalid"). 3: Scan the content for passages in another language, with the example "Inscríbase…".

Testing for it takes about a minute.

First, view the page source or open developer tools, and check the opening html tag. Is there a lang attribute, and is it the right language?

Second, run an automated checker like WAVE or axe. Both flag a missing or invalid language.

Third, scan the content for passages in another language, like banners, quotes, or notices.

The fix

On screen: Heading "The fix is one attribute, used twice". Code shows html lang="en" at the top and a paragraph with lang="es" around the Spanish sentence, marked "Pass: WCAG 3.1.1 Language of Page and 3.1.2 Language of Parts". A speech bubble shows a screen reader with a Spanish voice reading the sentence.

The fix is one attribute, used twice.

Set lang on the html element for the page, then add lang to any passage in a different language.

That meets WCAG success criteria 3.1.1, Language of Page, and 3.1.2, Language of Parts.

Now the screen reader switches voices:

[Screen reader, Spanish voice] Inscríbase para recibir noticias de eventos comunitarios.

Why it matters for people

On screen: Bar chart of average detectable errors per home page by declared language, from WebAIM Million 2026: English 46.0, Spanish 64.3, Korean 94.6, Chinese 136.2 (highlighted, longest bar).

So why does that matter? Start with people.

WebAIM also compared pages by their declared language. English pages average 46 errors.

Pages that declare Chinese average about 136, nearly three times as many.

Much of the web’s tooling was built and tested in English first, and people who speak other languages pay for it.

Why it matters for search

On screen: Heading "Why it matters for search". A note shows html lang="es" with the text "Google says it doesn't use this. It reads your visible text to tell the language." Two panels: "Found: each language has its own page" (its own URL like /es/, versions linked with hreflang, a real link to switch languages, with a link rel="alternate" hreflang="es" example) and "Missed: translation only on request" (appears after a click, cookie or browser setting; auto-redirects by guessed language; Googlebot usually crawls from the US and sends no language preference).

Now, search. Here’s something most people get wrong: Google says it doesn’t use the lang attribute. It works out a page’s language from the visible text.

So lang is for people and their assistive technology. Showing up in search in other languages takes something else.

Give each language its own page and URL, link the versions together with hreflang, and let people switch with a real link instead of an automatic redirect.

Google’s crawler usually comes from the US and doesn’t ask for a language, so translations that only appear on request may never be found.

Search and screen readers overlap

On screen: Heading "Search engines read a page a lot like a screen reader does". A three-column table. Alt text: a screen reader user gets what the image shows; a search engine gets help understanding the image. Link text: where the link goes; what the linked page is about. Headings: a way to jump through the page; how the content is organized. Page title: which page they're on; the likely title in results. Footnote: Google doesn't grade accessibility directly.

Accessibility and search overlap in other places too. Google doesn’t grade accessibility directly, but search engines read a page a lot like a screen reader does.

Alt text helps Google understand images. Descriptive link text tells it what’s on the other end. Headings and page titles show how the content is organized.

Fix these for people, and you give search engines a clearer page too.

idioma.chat

On screen: Heading "idioma.chat translates the whole experience". Five cards, each with a Spanish example: Content ("Horario"), Labels ("Correo electrónico"), Instructions ("Paso 2 de 3"), Errors ("Falta el correo"), and What assistive tech announces ("Enviar, botón"). A line below reads "PDFs: inaccessible documents are converted on request, in the reader's language."

That’s why we built idioma.chat.

It translates every word and element on the page, including the parts most tools skip: form labels, instructions, error messages, and what assistive technology announces.

And when a PDF isn’t accessible, idioma.chat converts it on request, in the reader’s language.

Close

On screen: Closing card: "Language access is accessibility." with "idioma.chat and accessibility.chat". Small print lists sources: WebAIM Million 2026, the accessibility.chat analysis article, and Google Search Central on multi-regional and multilingual sites. "Educational content, not legal advice."

In the end, language access is about accessibility, and accessibility is language access.

Learn more about these topics at idioma.chat and accessibility.chat. Thank you.

Sources

• WebAIM Million 2026
• Google Search Central: Managing multi-regional and multilingual sites

The Forward Path

The WebAIM Million is a measurement instrument, not a prescription. But the 2026 data points toward three conclusions that are hard to argue with.

First, the six core failure categories are not getting fixed by accessibility scanners. They are the output of organizational processes that lack accessibility integration. Adding more scanning will not change the result. Adding accessibility decisions to the design system, content workflow, and component library will.

Second, the ARIA paradox is a warning. ARIA is not free. Every additional aria-hidden, role="button", and custom widget pattern is a chance to introduce a barrier. The teams achieving the lowest error counts are not adding the most ARIA — they are using less, more deliberately, on top of native semantics that work without it.

Third, the era of "vibe coding" — AI-assisted code generation that surfaces in production without human review — is going to make this worse before it makes it better. AI coding tools trained on the existing web inherit the existing web's accessibility defects. The 56 million error baseline is what those models learned from. The next several WebAIM Million reports will likely show that pattern compounding. Organizations that want to escape it will have to make accessibility a generation-time concern, not a post-hoc fix.

The full WebAIM Million 2026 report (opens in new window) is worth reading in detail. The numbers in this analysis are a small selection; the report itself contains category breakdowns by industry, CMS, advertising network, and more. For anyone responsible for accessibility decisions in their organization, it is the most important annual data point in the field.