The WebAIM Million 2026 found detectable WCAG 2 A/AA failures on 95.9% of the top million home pages, up from 94.8% a year earlier, and an average of 56.1 errors per page against 51 in 2025 (WebAIM). Six error types accounted for 96% of everything detected: low contrast text on 83.9% of pages, missing image alt text on 53.1%, missing form input labels on 51%, empty links on 46.3%, empty buttons on 30.6%, and a missing document language on 13.5%. Those are the same six that topped the 2025 list (WebAIM).
Two other numbers explain the reversal better than the headline does. The average home page carried 1,437 elements in February 2026, 22.5% more than a year earlier, and over 133 ARIA attributes, up 27% in a single year. Pages got bigger, and the errors came with them.
Read the report as a floor rather than a verdict. WAVE detects a subset of conformance failures, and WebAIM says so plainly: "Absence of detected errors does not indicate that a page is accessible or conformant."
What did the WebAIM Million 2026 actually measure?
One page per site, once, with one automated engine.
WebAIM ran the WAVE stand-alone API against the home pages of the top million sites in February 2026, analysing the rendered DOM after scripts and styles had applied. The site list came from the Tranco ranking. This was the eighth year of the same test (WebAIM).
That design is the study's strength and its boundary. Eight years of the same method on the same kind of sample is why the year-over-year movement means something. But a home page is the most cared-for page on most sites. Nobody's checkout, nobody's account settings, and nobody's PDF invoice is in this data, and those are the pages where the barriers that stop a purchase tend to live.
Why did the numbers get worse this year?
Because pages grew faster than the accessibility work did.
The element count is the finding I would lead with. A 22.5% jump in average page complexity in twelve months is not a normal year, and WebAIM ties the error increase to it directly: home pages are "getting larger and more technologically complex at an alarming rate, making accessibility more difficult to achieve and maintain." The report attributes the shift to heavier use of third-party frameworks and libraries, and to AI-assisted coding (WebAIM).
Not every line moved the wrong way, which is worth saying out loud since most coverage of this report skipped it.
| Error type | 2025 | 2026 |
|---|---|---|
| Low contrast text | 79.1% | 83.9% |
| Missing alt text | 55.5% | 53.1% |
| Missing form input labels | 48.2% | 51% |
| Empty links | 45.4% | 46.3% |
| Empty buttons | 29.6% | 30.6% |
| Missing document language | 15.8% | 13.5% |
Alt text and document language both improved. Contrast lost nearly five points, and it is now the single most common detected failure by a wide margin. My read is that alt text and lang attributes improved because linters and CMS fields nag about them at authoring time, while contrast is decided by a design token that no linter sees until the page renders.
Does more ARIA mean more accessibility errors?
In this data, yes, and the gap is not small.
82.7% of home pages used ARIA in 2026, up from 79.4%. Pages with ARIA present averaged 59.1 detected errors; pages without averaged 42 (WebAIM). WebAIM's own framing is that you would expect to meet an additional 17 potential barriers on a page that uses ARIA.
Correlation is not the same as cause here, and it is worth being careful about which way the arrow points. Pages that reach for ARIA are usually the complicated ones, with custom widgets and third-party embeds, so some of that gap is complexity rather than ARIA itself. The rest is ARIA applied to elements that never needed it. The W3C put the fix in a single sentence years ago: "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" (W3C).
A <div role="button" tabindex="0"> with a click handler needs keyboard handling, a focus style, an accessible name, and a disabled state that you write yourself. A <button> arrives with all of it. One of those two shows up in the empty-buttons column and one does not.
What does 95.9% not tell you?
That the remaining 4.1% of pages conform.
This is the part I care most about, and it is where the number gets misquoted. WAVE found no errors on roughly 41,000 home pages. That result means an automated engine found nothing, not that a person could complete a task on the page. Deque's analysis of more than 2,000 audits across roughly 13,000 pages found that automated testing completely covered about 57% of issues by volume, and counting by success criteria instead of issue volume puts the machine-decidable share lower, in the 30 to 40% range (Deque). Either way, an automated pass decides a minority of the questions.
Here is what falls outside it. Whether your alt text describes the right thing, rather than merely existing. Whether focus order follows the visual order. Whether an error message is announced when it appears. Whether a modal traps focus and returns it to the trigger on close. Whether the label on a form field means anything to the person reading it.
So the honest reading of 95.9% is that at least 95.9% of home pages have a WCAG failure. The real figure is higher. Our scanner has the same ceiling as WAVE does, and a report that pretends otherwise is selling you something.
Which of the six should you fix first?
Contrast, because it is the largest and the cheapest.
Low contrast text appears on 83.9% of home pages and it is usually a handful of token values rather than a per-page problem. Fixing one muted grey in your design system can clear thousands of instances at once. WCAG 2.2 asks for 4.5:1 for normal text and 3:1 for large text at AA (W3C). You can check a pair in about ten seconds with our contrast checker.
After that, work the other five in whatever order matches your stack. Missing form labels and empty links are the two that most often break a real task, since an unlabelled input announces as "edit text, blank" and an icon-only link announces as its URL. Both are usually a component-level fix rather than a page-level one: correct the button component once and every instance follows.
The WCAG checklist covers the criteria behind these, including the ones a scan cannot decide for you.
What does this mean for EAA or ADA obligations?
Nothing on its own, and that distinction matters.
The WebAIM Million is research, not an enforcement dataset. No regulator scans the Tranco list. But the standard underneath it is the same one your obligations point to. Under the European Accessibility Act, services placed on the EU market must meet the accessibility requirements in Annex I, and conformance with the harmonised standard EN 301 549 gives a presumption of conformity (EUR-Lex). EN 301 549's web chapter tracks WCAG. In the US, the DOJ's Title II rule names WCAG 2.1 AA for public entities, and Title III litigation has used WCAG as the practical benchmark for years, which the ADA pillar covers in more detail.
So if six error types account for 96% of what automation detects across a million pages, and your site is built with the same frameworks as those pages, the odds that your site is clean are poor. That is the useful takeaway, and it does not need a fine attached to it.
Frequently asked questions
What is the WebAIM Million?
An annual automated accessibility evaluation of the home pages of the top one million websites, run by WebAIM since 2019. The 2026 edition used the WAVE stand-alone API against the rendered DOM in February 2026, with the site list drawn from the Tranco ranking (WebAIM).
What percentage of websites are accessible according to WebAIM 2026?
The report found detected WCAG 2 A/AA failures on 95.9% of home pages, up from 94.8% in 2025. The inverse is not a conformance rate: WebAIM states that absence of detected errors does not indicate that a page is accessible or conformant, so pages with no detected errors have not been shown to conform (WebAIM).
Why did web accessibility get worse in 2026?
WebAIM ties the increase to page complexity. Average elements per home page rose 22.5% to 1,437 and ARIA attributes rose 27% to over 133 per page, both of which correlate with more detected errors. The report points to heavier use of third-party frameworks and libraries and to AI-assisted coding (WebAIM).
Does using ARIA make a page less accessible?
Not by itself, but the data is not kind. Home pages with ARIA averaged 59.1 detected errors against 42 for pages without it (WebAIM). Much of that reflects complexity rather than ARIA, and the rest reflects ARIA used where native HTML would have worked, which the W3C's first rule of ARIA warns against (W3C).
Can an automated scan tell me if I conform to WCAG?
No. Automated testing covers roughly 30 to 57% of issues depending on how you count (Deque). A scan finds the machine-decidable failures quickly and at scale. Judgements about alt-text quality, focus order, and whether a task can be completed with a screen reader still need a person, and a conformance claim needs that human review behind it.
See where your site sits against the six
The six error types in this report are the ones a scan is good at. Run a free scan and you get the failing selector for each one, which turns "83.9% of pages have contrast problems" into a list of the specific elements on yours. Fix those first, then use the checklist for the criteria a machine cannot judge, and keep the export with a date on it so next year's comparison means something.
Pavel Charkasau, founder, wcagc.com. Last updated 5 September 2026.
Sources
- The WebAIM Million: the 2026 report on the accessibility of the top 1,000,000 home pages, WebAIM — February 2026 analysis using the WAVE stand-alone API on the rendered DOM, Tranco site list; 95.9% of home pages with detected WCAG 2 A/AA failures; 56,114,377 errors detected, 56.1 per page; six error types accounting for 96% of all errors; 1,437 average page elements, up 22.5%; 133,589,803 ARIA attributes, over 133 per page, up 27%; 82.7% of pages using ARIA; 59.1 average errors with ARIA vs 42 without; "Absence of detected errors does not indicate that a page is accessible or conformant." Accessed 5 September 2026.
- The WebAIM Million: the 2025 report, WebAIM — 94.8% of home pages with detected WCAG 2 failures; 51 average errors per page; 1,257 average page elements; nearly 106 ARIA attributes per page; the same six most common errors with 2025 percentages. Accessed 5 September 2026.
- Using ARIA, W3C — the first rule of ARIA use: prefer a native HTML element or attribute with the required semantics and behaviour built in over re-purposing an element with an ARIA role, state or property. Accessed 5 September 2026.
- WCAG 2.2, Success Criterion 1.4.3 Contrast (Minimum), W3C — 4.5:1 contrast ratio for normal text and 3:1 for large text at Level AA. Accessed 5 September 2026.
- Automated testing study identifies 57% of digital accessibility issues, Deque — more than 2,000 audits across roughly 13,000 pages and nearly 300,000 issues; about 57% of issues completely covered by automated testing. Accessed 5 September 2026.
- Directive (EU) 2019/882 (European Accessibility Act), EUR-Lex — Annex I accessibility requirements; Article 15 presumption of conformity for products and services conforming to harmonised standards published in the Official Journal. Accessed 5 September 2026.