All articles
WCAGCheck Editorial

95.9% of Websites Still Fail Accessibility Standards: What the 2026 WebAIM Data Means for Your Projects

The 2026 WebAIM Million study found 95.9% of top websites fail WCAG standards. Here's what's breaking and how to fix the most common issues.

95.9% of Websites Still Fail Accessibility Standards: What the 2026 WebAIM Data Means for Your Projects

The latest WebAIM Million study is out, and the headline figure is grim: 95.9% of the top one million homepages have detectable WCAG failures. Each page averages 56.1 errors.

These aren't obscure technical edge cases. They're the same problems we've been talking about for years—low contrast text, missing alt attributes, empty links. The kind of issues that automated tools catch easily, which makes the persistence of these failures genuinely baffling.

Let's break down what's actually going wrong and what you can do about it on your projects.

The Six Most Common Failures

WebAIM's automated testing consistently finds the same categories of errors dominating the results. Here's what they found this year:

1. Low Contrast Text (WCAG 1.4.3)

This remains the single most common accessibility failure, appearing on over 80% of tested pages. WCAG 1.4.3 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold).

The fix is straightforward: check your colour combinations. Grey text on white backgrounds is the usual culprit. Tools like the WebAIM Contrast Checker give you instant feedback. If your brand colours don't meet the ratios, you need to have that conversation with your design team now, not after launch.

2. Missing Alternative Text (WCAG 1.1.1)

Images without alt attributes, or with meaningless alt text like "image" or "photo.jpg", appeared on 54% of homepages.

Every image needs an alt attribute. Decorative images get alt="". Functional images (buttons, links) need alt text describing their purpose. Informative images need alt text describing their content. If an image contains text, that text goes in the alt attribute.

3. Empty Links (WCAG 2.4.4)

Links with no accessible name—often icon links without text or aria-labels—appeared on 45% of pages.

That social media icon linking to your Twitter? It needs accessible text. Either add visually hidden text inside the link, or use aria-label="Follow us on Twitter". Screen reader users shouldn't have to guess where a link goes.

4. Missing Form Labels (WCAG 1.3.1, 3.3.2)

Form inputs without associated labels affect 44% of homepages. Placeholder text doesn't count—it disappears when users start typing and isn't reliably announced by all screen readers.

Every input needs a <label> element with a for attribute matching the input's id. Or wrap the input inside the label element. Either works. Placeholders are supplementary hints, not replacements for labels.

5. Empty Buttons (WCAG 4.1.2)

Buttons without accessible names appeared on 27% of pages. Like empty links, these are often icon buttons missing text alternatives.

A hamburger menu button needs aria-label="Open menu" or visually hidden text. A search button with just a magnifying glass icon needs aria-label="Search". Users need to know what the button does before they activate it.

6. Missing Document Language (WCAG 3.1.1)

Pages without a lang attribute on the <html> element appeared on 17% of homepages. This single attribute helps screen readers use correct pronunciation.

Add <html lang="en-GB"> to your pages. That's it. One attribute, significant impact for screen reader users.

Why These Errors Persist

These aren't difficult fixes. A developer can address all six issues in an afternoon. So why do they keep appearing?

A few reasons:

  • Accessibility isn't in the workflow. If nobody checks for these issues before launch, they ship.
  • Templates and themes carry errors forward. One bad WordPress theme or React component library spreads problems across thousands of sites.
  • Teams don't test with real assistive technology. Automated tools catch these issues. Manual testing catches even more. Neither happens consistently.

Building Accessibility Into Your Process

The WebAIM data tells us that awareness alone isn't solving the problem. You need process changes:

Run automated checks during development. Browser extensions like axe DevTools or WAVE catch these common errors in seconds. Make it part of your local development workflow, not just a pre-launch checklist item.

Add accessibility to your code review criteria. If a pull request adds an image without alt text or a button without an accessible name, it shouldn't merge.

Test with keyboard navigation. Tab through your pages. Can you reach and operate every interactive element? Can you see where focus is? This catches a surprising number of issues.

Schedule regular audits. Content changes, new features ship, third-party scripts update. What passed last quarter might fail today.

The Bottom Line

56.1 errors per page is not a technology problem. It's a process problem. The fixes are documented, the tools exist, and the techniques are well-established. The gap is between knowing what to do and actually doing it consistently.

The 4.1% of sites that pass automated testing aren't using secret techniques. They're just checking their work.

WCAGCheck scans your website for WCAG compliance issues and tells you exactly what to fix. Try it free at wcagcheck.co.uk