# The Web Is Less Accessible Than a Year Ago — The WebAIM Million 2026 Report

> WebAIM Million 2026 scanned the top million home pages: errors per page rose to 56.1, up 10.1% in a year, reversing years of progress. Covers the top 6 recurring errors and the ARIA paradox.

**Published:** 2026-07-28 | **Updated:** 2026-07-28

---


What happens when you run one million home pages through an automated accessibility checker?

**About 56 million accessibility errors** come pouring out. That's an average of 56.1 per page.

The number alone might get a shrug — "that's just the web." The problem is the direction. Last year it was 51. In a single year, errors grew by **10.1%**. After years of slow-but-steady progress, web accessibility just took a step backward.

What grew, and why? Let's dig into the WebAIM Million report — built on February 2026 data and released that March.

{{< img src="images/contents/og_bg_thumb.png" alt="A falling line chart and the number 56.1 - an illustration symbolizing the WebAIM Million 2026 finding that web accessibility regressed after years of progress" >}}

## What Is the WebAIM Million, Anyway?

First, some background on the survey itself.

**WebAIM** (Web Accessibility In Mind) is a web accessibility organization based at Utah State University — also known as the maker of the **WAVE** testing tool. Since 2019, WebAIM has run an annual automated analysis of the **home pages of the top one million websites** using the WAVE engine. That's the **WebAIM Million** report.

Two things to keep in mind before reading:

1. **It measures automated checks only.** It counts errors a machine can reliably detect — missing alt text, insufficient contrast, unlabeled form fields, and so on. Problems you only find by actually using a page, like keyboard traps or illogical focus order, aren't included.
2. Which means these numbers are **flattering**. Passing an automated scan doesn't make a page accessible. Treat this as a *floor*, not a ceiling.

Keep that in mind: the *floor* is 56 errors per page. Now, this year's report card.

## This Year's Report Card: The Trend Reversed

The headline numbers:

- **95.9%** of home pages had detectable WCAG 2 failures (94.8% last year)
- **56.1** errors per page on average (51 last year, **+10.1%**)
- **1,437** elements per page on average (**+22.5%** in a single year)

{{< img src="images/contents/errors-trend-en.png" alt="Chart of average accessibility errors per page from 2019 to 2026 - a gradually declining line that bends back up to 56.1 in 2026" >}}

Looking at the trend, average errors had settled around 50 since 2021. There was a spike in 2024, a return to 51 in 2025 — and now a climb back to 56.1.

One detail worth noting is **error density**. Errors as a share of all page elements sit at 3.9%, which suggests individual elements didn't suddenly get worse — rather, **pages got much heavier**, so the absolute error count ballooned. A single home page now carries nearly twice as many elements as it did seven years ago (782 in 2019).

That's not just an accessibility problem. It's a sign that quality control isn't keeping pace with how fast the web is growing more complex.

## The Culprits Are the Same Six, Every Year

This report has a tradition that would be funny if it weren't sad: the top of the error list **barely changes**. This year, six error types accounted for 96% of all detected errors.

{{< img src="images/contents/top6-errors-en.png" alt="Bar chart of the six most common accessibility error types by share of pages affected - from low-contrast text at 83.9% down to missing document language at 13.5%" >}}

| Error type | Pages affected |
|-----------|-----------------|
| Low-contrast text | 83.9% |
| Missing image alt text | 53.1% |
| Missing form labels | 51.0% |
| Empty links | 46.3% |
| Empty buttons | 30.6% |
| Missing document language (lang) | 13.5% |

Here's the thing: every one of these is **first-semester web development material**. These aren't errors caused by a lack of advanced technology.

- Low-contrast text → one pass with a contrast checker at the design stage catches it.
- Missing alt → it's one line: `<img alt="...">`. The million pages contained 66.6 million images, and 16.2% had no alt text. Worse, 45% of those alt-less images were **used as links** — a screen reader user has no way of knowing where that link goes.
- Missing form labels → a `<label for="...">` association. Pages now average 6.9 form inputs (up 36% in three years), and 33.1% of them sit there unlabeled.
- Empty links and buttons → usually an icon with no accessible name.
- Missing lang → `<html lang="en">`. Genuinely, one word.

The easiest questions are the ones most people get wrong — like fumbling question #1 on a big exam. Not from lack of skill, but because **nobody looked**.

## The ARIA Paradox: More ARIA, More Errors?

Here's the most talk-worthy part of this year's report.

ARIA (Accessible Rich Internet Applications) is a set of attributes for conveying role and state information to assistive technology when HTML alone can't express it. Used well, it makes complex widgets accessible. It's genuinely a good tool.

But the statistics paint a curious picture.

{{< img src="images/contents/aria-paradox-en.png" alt="Comparison of average errors on pages with and without ARIA - pages using ARIA average 59.1 errors versus 42 for pages without" >}}

- **82.7%** of home pages use ARIA, averaging **133** attributes per page (+27% in one year)
- Pages **with** ARIA: **59.1** errors on average
- Pages **without** ARIA: **42** errors on average

Pages using ARIA have **more** errors. This is correlation, of course — complex pages use more ARIA and have more errors to begin with. But there's a reason the W3C's own documentation carries this official warning:

> **No ARIA is better than Bad ARIA.**

ARIA is like pepper. Applied in the right places, it elevates the dish — but if you're worried about accessibility and just dump the whole jar in, that's not cooking. The moment you add `role="button"`, you own the keyboard event handling too. Misplace an `aria-hidden="true"` and perfectly good content vanishes from screen readers entirely. Speaking of which: `aria-hidden="true"` now averages 23.3 instances per page, up 30% in one year.

The fundamentals haven't changed. **If semantic HTML can express it, use HTML.** ARIA comes second.

## Why the Regression, and Why Now?

The report points to two broad currents.

**First, pages are exploding in complexity.** Elements +22.5%, ARIA +27%, headings +20.4% — all in a single year. As third-party frameworks, components, and widgets pile up, a growing share of markup is code developers don't directly control.

**Second, code is being produced faster than it's being reviewed.** With AI-assisted coding going mainstream, markup output has surged — and accessibility review isn't keeping up, according to several analyses. The accessibility problems in AI-generated markup have been flagged for a while now; those concerns are finally starting to show up in the statistics.

WebAIM's Christopher Phillips diagnosed the result as a **cultural problem**, not a technical one: barriers persist because their impact on disabled users remains too easy for organizations to overlook. The line he invoked sticks with you:

> **"Every system is perfectly designed to get the results it gets."**

A system whose accessibility regressed is a system designed to let accessibility regress. Feel that one land?

## How Korea Compares

You might hope things look better closer to home. If home is South Korea — unfortunately, not really.

Korea's national web accessibility survey for 2025, published in March 2026, found an **alt text compliance rate of just 17.1%**. The methodologies differ (Korea's survey measures per-criterion compliance; WebAIM measures error detection), so a direct comparison is shaky. But one conclusion matches exactly: **the most basic items are the most broken**, at home and abroad. I analyzed the Korean survey in [this post]({{< relref "/posts/2025-web-accessibility-survey" >}}).

That the whole world shares this problem isn't much consolation. The better way to read it: **just getting the basics right puts you ahead of the pack**.

## What We Can Do Tomorrow

The paradoxical good news in this report: 96% of the errors are **basic issues detectable by automated tools**. If they can be detected, they can be prevented.

**① Wire automated checks into CI**

Put axe-core, Lighthouse CI, or pa11y into your build pipeline, and most of the usual six get caught before deployment. Don't rely on human goodwill — let the system do the catching.

**② Validate contrast at the design stage**

Low-contrast text, the one affecting 83.9% of pages, is a design-token problem, not a code problem. Lock in contrast ratios (4.5:1 for body text) when you define the color palette, and every page downstream inherits the fix.

**③ Treat accessibility review of AI-generated markup as a default**

Don't merge AI-generated components as-is. `<div onclick>` buttons, odd alt text on decorative images, and scattershot ARIA are regulars in AI output.

**④ Fix existing errors before writing new code**

Most of those 56 errors per page weren't created today — they've been sitting there. One sprint spent clearing the usual six makes a bigger difference to users than most new features.

## Wrapping Up

For the seventh year running, the conclusion writes itself: the biggest barrier to web accessibility isn't hard technology — it's **basics left undone**.

But this year adds a warning light. As the web grows more complex and code generation gets faster, the interest rate on "we'll get to it later" keeps climbing. Fifty-six million errors might just be the invoice.

Tomorrow at work, try running your page through WAVE or axe. If you come in under the average (56.1), congratulations — you're already beating the world. Now walk it down toward zero, one fix at a time.

---

## References

- <a href="https://webaim.org/projects/million/" target="_blank" title="Opens in new window">The WebAIM Million — The 2026 report on the accessibility of the top 1,000,000 home pages (WebAIM)</a>
- <a href="https://webaim.org/blog/tolerating-inaccessibility/" target="_blank" title="Opens in new window">Tolerating Inaccessibility (WebAIM Blog, Christopher Phillips)</a>
- <a href="https://www.nexerdigital.com/news-and-thoughts/the-webaim-million-report-2026-what-it-tells-us/" target="_blank" title="Opens in new window">The WebAIM Million Report 2026: what it tells us (Nexer Digital)</a>
- <a href="https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/" target="_blank" title="Opens in new window">Read Me First — No ARIA is better than Bad ARIA (W3C ARIA Authoring Practices Guide)</a>

