Why WebAIM's report only found 6 issues on a million pages

Published 16 February 2026

Why WebAIM's report only found 6 issues on a million pages

Video transcript

The web isn't failing accessibility because it's hard; it's failing because it keeps repeating the same basic defects at a massive scale.

This is the story of WebAIM's 2025 report.

For the 7th year in a row, WebAIM evaluated the homepages of the top 1 million websites, and the findings are surprising.

94% of homepages had detectable WCAG 2 failures.

Over a million homepages on the web are failing basic accessibility checks in the same few ways, over and over again.

And WebAIM found that 96% of those detected errors fell into just six categories.

Six.

But it's not because accessibility is too hard.

It's because we keep mass-producing the six same defects year on year, in the 2025 report.

Low contrast text featured in 79% of pages, where text blends into the background.

It looks sleek, nice, minimal, and on brand, and yet it's unreadable for a huge number of people.

Missing alt text featured in 55% of pages.

If an image is communicating something, it needs a meaningful text description.

Without it, screen reader users can't understand the content.

Missing form labels featured in 48% of pages, which breaks basic usability.

Every input needs a programmatic label.

Without one, screen reader users can't tell what they're filling in.

Empty links featured in 45% of pages.

A link exists but has no accessible name.

In a screen reader, the blank link is announced as "link."

Empty buttons featured in 29% of pages.

Icon-only buttons or SVG-only controls, with styling so aggressive the label effectively disappears.

And lastly, missing document language featured in 15% of pages.

This is where the language at the top of the HTML is missing, which sounds minor, until you realise it can change how a screen reader pronounces the entire page.

Now, if you fixed only these basic accessibility defects, you'd eliminate the vast majority of the errors WebAIM detected.

So the real question is: why are these still everywhere?

Let's take a look at colour contrast. It occurs a lot, averaging 29 instances per page.

That's not someone forgot.

That's a design token or style guide problem.

Because if your secondary text colour fails, it fails everywhere.

If your hover state fails, it fails everywhere.

This isn't random.

These six defects are repeatable outcomes from flawed procedures.

They come from templates, standard components, shared components, design systems, CMS themes, and workflows.

Here's the thing: modern teams don't ship pages; they ship patterns.

These six errors are cheap to catch.

Automation is actually pretty good at finding them, and yet they persist at a massive scale.

So that implies one of a few things is happening.

Either checks aren't running in continuous integration tools, or they run but they're not enforced and are warnings only.

Or teams can't fix upstream issues, things like themes, vendor content, embedded scripts, and ads.

Or regressions keep coming back; they're fixed today and reintroduced in the next design, in the next few sprints.

And WebAIM's report is only what automation can detect reliably.

The true conformance rate is almost certainly worse.

The root cause isn't just people forget.

It's incentives.

Teams are rewarded for shipping features, conversions, brand polish, performance.

They're not rewarded for every form control being consistently labelled.

The high-friction work gets deferred.

Accessible names, robust labelling patterns, testing with assistive tech all get deferred until it becomes a legal risk, or a contractual risk, or a headline risk.

And by then it's systemic.

It's baked into the design system, baked into the component library, baked into the CMS workflow.

Accessibility breaks hardest at the handover points: designer to developer, developer to tester.

In fact, each of the top six errors maps neatly to a handoff point.

For contrast, a designer chooses tokens and a developer implements, but nobody hard gates it.

For alt text, authors upload images, except the CMS doesn't enforce the text descriptions and team training is missing.

A preference for a clean UI drops visible labels, placeholders pretend to be labels, and ARIA labelling is inconsistent.

Injected content from upstream creates empty links and buttons.

Template defaults aren't set for language; nobody owns it, so it slips through.

It's not one person being careless.

It's the pipeline not guaranteeing the outcome.

This is a pipeline problem. The fix isn't try harder.

The fix is to treat accessibility as a production constraint, like security, like build-breaking tests, like payments.

If this fails, we don't ship.

Until accessibility becomes a non-negotiable gate in design tokens, component libraries, CMS authoring tools, and continuous integration, the same six defects will keep reappearing in reports time and again.

Because the web is built by repetition, and repetition amplifies whatever your system allows.

The question isn't, how do we get people to care more?

The question is: build better gates so these failures can't reproduce.

Because when you fix the basics upstream, you don't just improve one page; you improve the entire system.

Improving the system and making accessibility work better is what we are good at.

If you want to improve your digital accessibility and stay on top of the fast-changing accessibility landscape, click the like button and make sure you've subscribed to CANAXESS.

Until next time, bye for now.

Contact us

We’re here to help bring your ideas to life. Whether you need expert support on a project, guidance to solve an accessibility challenge, or just want to explore an idea, we’d love to hear from you.

Contact us

Sign up to our newsletter

Sign up for our occasional emails packed with insights, tips, and updates we think you'll find valuable and inspiring.