The WebAIM Million: What a Website Accessibility Audit of 1,000,000 Homepages Reveals

A million-homepage scan, and what it actually measured

The WebAIM Million is an annual, automated accessibility evaluation of the home pages of the top one million websites, run by WebAIM, the accessibility unit at Utah State University's Center for Persons with Disabilities. Each home page is tested with the same engine used in the widely deployed WAVE tooling, and the results are aggregated into one of the few public datasets large enough to describe the state of the web rather than a single sector or sample.

Two facts about the method matter before any number is read. First, the scan looks only at home pages, which are typically the most maintained page a business owns, so a whole-site audit would tend to find more, not less. Second, an automated engine can only detect the WCAG success criteria that are machine-testable, such as missing alternative text or insufficient color contrast, and cannot judge the criteria that require a human, such as whether alternative text is meaningful or whether a reading order makes sense. Every figure below is therefore a conservative floor.

Failure is the statistical norm, not the exception

The headline finding is blunt: 95.9 percent of the one million home pages had at least one detectable WCAG 2 failure. Inverted, that means a home page with zero automatically detectable accessibility errors is roughly a one-in-twenty rarity across the measured web. Compliance is not the baseline that a few laggards fall below. It is the outlier.

This reframes how a business owner should hear the phrase "our site probably has some accessibility issues." Against the population data, the realistic prior is not "probably some" but "almost certainly several, and more than an automated tool can even see." The relevant question is not whether a given site fails the standard, but how far from it the site sits and which barriers block real transactions.

The recurring categories: where the errors cluster

Year after year, the WebAIM Million reports the same small set of error categories accounting for the bulk of detected failures. The most common are low-contrast text, missing alternative text on images, empty links, missing form input labels, empty buttons, and missing document language. These are among the most common accessibility errors precisely because they are foundational: each maps to a basic WCAG 2.2 success criterion that a site either satisfies at build time or fails everywhere.

The pattern is instructive. None of these is exotic. Contrast is a color choice, a label is one attribute, a document language is one line in the page head. That the same handful dominate a million-page dataset tells us the failures are systemic defaults of how sites are assembled, not rare edge cases, which is also why they are cheap to prevent and comparatively cheap to remediate when a real audit maps each to the criterion it fails.

Rising complexity is making it worse, not better

The most important trend in the 2026 data is directional. The average error count did not hold steady or fall as awareness of accessibility grew. It rose 10.1 percent year over year, and WebAIM ties that increase to a 22.5 percent year-over-year increase in average page complexity, measured by the number of page elements and ARIA attributes present.

The mechanism is not mysterious. More elements mean more controls that can be unlabeled, more interactions that can trap a keyboard, and more markup where structure can break. ARIA is a particular hazard here: it is a specification for describing custom widgets to assistive technology, and applied incorrectly it actively misleads a screen reader rather than helping it, so a page that adds ARIA without testing can raise its error count by adding it. As pages accumulate heavier interfaces, the surface area for barriers grows faster than the diligence applied to them.

This connects to a much older result in human factors. Hick's Law (Hick, 1952) established that decision time rises with the number of choices, and Fitts's Law (Fitts, 1954) that pointing time rises as targets shrink and scatter. Those are laboratory findings about pointing and choosing, and the extrapolation to full-page web behavior is inferential rather than proven, but the direction is consistent with the WebAIM trend: complexity is a cost, and for a disabled visitor operating a page by keyboard or screen reader, that cost is often a wall rather than a slowdown.

Why an automated scan is a floor, not a ceiling

The single most important caveat in reading these numbers is that they understate the problem. The WebAIM Million is an automated evaluation, and automated tools can only reliably detect the subset of WCAG success criteria that are machine-testable. Whether a link's text describes its destination, whether an image's alternative text conveys its meaning, whether a form's error message is understandable, whether focus moves in a sensible order: these require human judgment and sit largely outside what any scanner reports.

The practical consequence is that a 95.9 percent detected-failure rate is the conservative reading. A site that passes an automated scan clean has cleared only the machine-checkable bar, not the standard. This is exactly why a credible website accessibility audit pairs automated scanning with manual testing, operating the site by keyboard alone, listening to it through a screen reader, checking reflow at high zoom, and measuring contrast against the WCAG ratio of 4.5 to 1 for normal text (W3C, 2023). Tooling narrows the search; a specialist confirms the barrier.

From statistical norm to commercial and legal exposure

An accessibility failure is not an abstraction. An unlabeled booking button, a checkout field a screen reader cannot announce, or a menu that traps a keyboard user is, in plain terms, a customer who came to transact and could not. On the conversion side, a barrier is a lost booking in the same way a slow form or a broken payment step is, except it silently excludes an entire class of visitor rather than frustrating a general one.

On the legal side, the exposure has grown concrete. US courts widely treat business websites as places of public accommodation under the Americans with Disabilities Act, and industry legal trackers reported over 5,100 ADA digital-accessibility lawsuits filed in 2025, described as the highest annual volume on record. Those same trackers report that a meaningful share of the suits targeted sites that had already installed an accessibility overlay widget, the single-line script marketed as instant compliance. This litigation data is compiled by commercial tracking firms rather than drawn from a court-records primary source, so it should be read as a directional trend and not as an audited count, and none of it is legal advice. The underlying point survives the caveat: the shortcut of bolting a widget onto broken markup does not resolve the barriers the WebAIM data shows are nearly universal, and remediation at the source is what actually does.

How to read your own site against the standard

The WebAIM Million gives a business owner a defensible prior about their own site: on the population evidence, it almost certainly has multiple detectable WCAG failures on the home page alone, and more that an automated tool cannot see. That prior is a starting point, not a verdict, because the numbers that matter are your own.

Reading them rigorously means the same method the population data implies. Run the machine-checkable scan to find the obvious defects, then test the site the way a disabled visitor uses it: by keyboard, by screen reader, at high zoom, and against measured contrast, mapping each barrier to the specific WCAG 2.2 success criterion it fails and its severity for a real user. That produces a findings register you can act on and, once remediated in the code and re-verified, a documented record that the work was actually done. Accessibility is also one of the technical foundations that a site's search and answer-engine visibility rests on, which is why it belongs in any clear read of where a site stands, not in a separate compliance silo.