April 5, 2026 · 9 min read

Why 96.3% of Websites Fail WCAG: What axe-core Actually Tests (and What It Misses)

The WebAIM Million headline is real. But the tool behind it can only check 57% of what WCAG requires. Here's what that means for your accessibility strategy.

Every year, WebAIM crawls the home pages of the top million websites and runs automated accessibility checks. The 2024 results found detectable WCAG 2 failures on 96.3% of home pages. An average of 56.8 errors per page.

That number makes headlines, gets cited in vendor pitches, and shows up in procurement justification emails. It deserves more scrutiny than it gets. Because the tool doing the testing — axe-core, the same engine behind Google Lighthouse, Microsoft Accessibility Insights, and AccessPulse — can only detect a subset of WCAG violations in the first place.

According to Deque's own research, automated testing catches approximately 57% of accessibility issues. That means the 96.3% failure rate is measuring less than two-thirds of what WCAG actually requires. The real failure rate is almost certainly higher.

I built AccessPulse on axe-core because it's the best automated engine available. But “best available” is not the same as “complete.” Here's what it actually tests, what it doesn't, and what that means for your compliance strategy.

What axe-core actually tests

axe-core runs approximately 90 rules against the rendered DOM. Not the HTML source — the live, JavaScript-rendered page. That distinction matters. A React component that conditionally renders an <img> without altwon't get caught by a static HTML linter. axe-core catches it because it tests what the browser actually paints.

Here's what those 90 rules cover, mapped to the four WCAG principles.

Perceivable

Color contrast (WCAG 1.4.3, 1.4.6).axe-core computes the contrast ratio between foreground text and its background. The thresholds: 4.5:1 for normal text, 3:1 for large text (18pt or 14pt bold). This is the single most common failure in the WebAIM Million — 81% of home pages have at least one contrast violation.

axe-core handles layered backgrounds, opacity, and some CSS gradients. It does not handle text over images reliably, which is why it flags those as “needs review” rather than pass/fail.

Image alt text (WCAG 1.1.1). Missing alt attributes on <img> elements, empty alton images that aren't decorative, missing text alternatives on <input type="image">, SVGs without accessible names. The second most common failure — 54% of home pages have images with no alt text at all.

Text resize and reflow (WCAG 1.4.4, 1.4.10). axe-core can verify that content isn't clipped at certain zoom levels, though this is one of the weaker automated checks. Most reflow testing still requires a human resizing a browser window and watching what breaks.

Operable

Keyboard access (WCAG 2.1.1).axe-core checks that interactive elements — links, buttons, form controls — are reachable via keyboard. It flags elements with click handlers that aren't keyboard-focusable. It catches tabindex values greater than 0, which scramble focus order in ways developers rarely intend.

Focus visible (WCAG 2.4.7). Partially automated. axe-core can flag elements with outline: nonein CSS, but it can't fully evaluate whether a custom focus style — a box-shadow, a border change, a background shift — provides sufficient visual indication. That judgment call is still human.

Page titles (WCAG 2.4.2). Every page needs a descriptive <title>. Simple check. Still, 14% of the top million pages fail it.

Understandable

Form labels (WCAG 1.3.1, 4.1.2). Missing <label> elements, labels not programmatically associated with inputs, aria-label and aria-labelledby usage. 49% of home pages have unlabeled form controls. Third most common failure, and one of the most impactful — an unlabeled search field is completely opaque to screen reader users. They hear “edit text” and have no idea what the field is for.

Language declaration (WCAG 3.1.1). The <html lang="en">attribute. Trivial to fix, but 17% of home pages don't declare a language. Without it, screen readers don't know what language to speak in. A French screen reader user visiting an English page hears garbled pronunciation.

Robust

ARIA validity (WCAG 4.1.2). This is where axe-core earns its keep. It validates that role values exist, aria-* attributes are allowed on their elements, required ARIA properties are present, and aria-hiddenisn't slapped on focusable elements. The ARIA spec is dense enough that even experienced developers get it wrong. axe-core has over 20 rules just for ARIA.

Unique IDs. Duplicate id attributes break aria-labelledby, aria-describedby, and label-input associations. axe-core catches all of them.

What axe-core misses

Here's the uncomfortable part. That 43% gap isn't edge cases. Some of the most impactful accessibility barriers are completely invisible to automated testing.

Alt text quality (WCAG 1.1.1)

axe-core can tell you an image is missing alt text. It cannot tell you that alt="image" or alt="DSC_0042.jpg" or alt="logo"is useless to someone who can't see the image. The WCAG 1.1.1 requirement isn't “has alt attribute.” It's “provides a text alternative that serves the equivalent purpose.”

I've seen sites pass automated scans with a 100% score while having alt text like “banner” on a hero image that contains critical product information. That's a compliance failure no automated tool will flag.

Reading order (WCAG 1.3.2)

Screen readers follow the DOM order, not the visual order. CSS Grid and Flexbox make it trivial to visually reorder content while the DOM stays scrambled. A user tabbing through a form might hit Submit before reaching half the fields.

axe-core can flag some tabindex issues, but it cannot evaluate whether the overall reading sequence makes semantic sense. That requires a human navigating the page with a screen reader.

Keyboard traps in complex widgets (WCAG 2.1.2)

A custom date picker, modal dialog, or autocomplete dropdown needs careful keyboard management. Can you Tab in and out? Does Escape close it? Do arrow keys navigate options? axe-core checks that elements are focusable. It does not test interaction patterns.

The ARIA Authoring Practices Guide publishes expected keyboard behaviors for every widget pattern. Nobody tests compliance with those automatically, because the interaction model for a combobox is fundamentally different from a tree view is fundamentally different from a data grid.

Cognitive accessibility (WCAG 2.2)

WCAG 2.2 added criteria like Focus Not Obscured (2.4.11), Dragging Movements (2.5.7), and Consistent Help (3.2.6). Most of these require human judgment. Is the help link in a consistent location across pages? Can a user complete a drag action with a single pointer alternative? These aren't yes/no DOM queries.

Video and audio content (WCAG 1.2.x)

axe-core can detect <video> elements without <track>elements. It cannot evaluate whether captions exist, are accurate, or are synchronized. It can't check for audio descriptions. The entire 1.2 guideline family — seven success criteria covering captions, transcripts, audio descriptions, and sign language — is largely manual.

Why the gap matters

If 96.3% of sites fail the 57% of checks that can be automated, the real failure rate against full WCAG 2.2 conformance is effectively 99%+. Almost no website fully meets WCAG without deliberate, ongoing effort that includes manual testing.

This has real consequences. In 2025, there were 8,667 ADA Title III federal lawsuits related to web accessibility. The FTC fined accessiBe $1 million for claiming their automated overlay widget made websites WCAG compliant. It didn't. No automated tool can make that claim.

But that doesn't make automated testing useless. It makes it necessary but insufficient. The 57% that axe-core catches includes the highest-frequency violations: contrast, alt text, labels, ARIA. These are the issues that affect the most users, on the most pages. Catching them automatically, on every deploy, prevents regressions from reaching production.

What to actually do

1. Automate the 57%.Run axe-core in CI/CD so contrast regressions, missing labels, and broken ARIA don't ship. Fail the build when automated checks fail. This is what AccessPulse does — it runs axe-core against your pages on every deploy and reports violations by severity.

2. Schedule manual audits for the 43%. Quarterly or semi-annually, have someone navigate your critical user flows with a screen reader. NVDA is free. VoiceOver is built into macOS. Test keyboard navigation end-to-end. Review alt text for accuracy, not just existence.

3. Prioritize by user impact. A missing form label on your signup page blocks users. A heading order skip on your changelog page is low priority. Automated severity ratings (critical, serious, moderate, minor) help here, but use judgment.

4. Don't buy an overlay.The FTC has made this clear. DOM-injection widgets that claim to fix accessibility automatically are making promises they cannot keep. accessiBe's $1M fine wasn't an anomaly — 22.6% of ADA lawsuits in 2025 targeted sites using overlay widgets. They make you a bigger target, not a smaller one.

5. Track over time.A single scan is a snapshot. Accessibility is a moving target — every deploy can introduce new issues. Continuous monitoring catches regressions before your users do.

I built AccessPulse to automate the 57% that machines can catch — the contrast violations, missing labels, broken ARIA, and absent alt text that make up the bulk of accessibility failures. It runs on every deploy, reports violations by severity, and integrates into GitHub Actions.

It won't make your site WCAG compliant. Nothing automated will. But it catches the most common and most impactful issues before they ship, and that's where automated testing earns its keep.

Run a free scan →

Related reading

Frequently asked questions

What percentage of WCAG issues can axe-core detect?

Approximately 57%, per Deque's own research. This covers color contrast (WCAG 1.4.3), missing alt text (1.1.1), unlabeled form inputs (4.1.2), ARIA errors, and other machine-detectable rules. The remaining 43% — alt text quality, reading order, keyboard traps, cognitive accessibility — requires manual human testing.

Why do 96.3% of websites fail WCAG?

The WebAIM Million found detectable WCAG 2 failures on 96.3% of the top million homepages, averaging 56.8 errors per page. The most common failures are low color contrast (83.6%), missing alt text, empty links, missing form labels, and missing document language. Most websites are never tested for accessibility at all.

Can automated testing make a website WCAG compliant?

No. Automated testing catches about 57% of WCAG issues. Full compliance requires pairing automated scanning (axe-core, WAVE) with manual audits — screen reader testing, keyboard navigation review, alt text accuracy checks, and cognitive accessibility evaluation.

Sources: WebAIM Million 2024, Deque automated testing study, FTC v. accessiBe, ADA Title III lawsuit data.