FrontendAugust 24, 20265 min read

Accessibility Failures Analytics Will Never Show You

Swastika Dey Roy
Swastika Dey Roy
Accessibility Failures Analytics Will Never Show You

Your analytics will never flag an accessibility failure, because the people it blocks leave without a trace. A user who cannot get past your unlabelled checkout form does not file a bug report or trigger an event. They close the tab. In WebAIM's most recent Screen Reader User Survey, 67% of respondents said they never or rarely contact site owners about barriers they hit. The failure is real, the lost revenue is real, and your dashboard shows a perfectly normal bounce.

Accessibility failures are defects that prevent people with disabilities from using your site: text too faint to read, images without descriptions, buttons a keyboard cannot reach. Most are measured against WCAG 2, the standard that regulators and courts lean on. And most sites fail it.

The web is getting worse, not better

The WebAIM Million, an annual automated evaluation of the top one million home pages, found detectable WCAG 2 failures on 95.9% of them in 2026, up from 94.8% the year before. That is the first regression in six years. Average errors per page climbed 10.1% to 56.1, and the average page now carries 1,437 elements, a 22.5% jump in a single year. More components shipped faster means more places to fail.

The failures themselves are boringly consistent. Low contrast text appears on 83.9% of home pages. Missing image alt text affects 53.1%, missing form labels 51%, and empty links 46.3%. None of these are exotic engineering problems. They are the kind of defects a disciplined frontend process catches in review, which is precisely why their persistence says more about process than skill.

One more uncomfortable finding: pages using ARIA attributes averaged 59.1 errors, against 42 for pages without. Bolting accessibility attributes onto broken markup tends to make things worse.

Why your dashboards stay silent

Analytics tools measure what happens, not what could not happen. A screen reader user who abandons your unlabelled form looks identical to any other bounce. There is no "blocked by missing label" event, and there never will be, because the instrumentation lives in the same interface that failed.

Nor do these users announce themselves. Assistive technology is not reliably detectable client side, and as the survey above shows, two thirds of blocked users will not tell you either. You are running a shop where a meaningful slice of customers walk out at the door, silently, every day.

The population is not small. The WebAIM survey drew 1,539 screen reader users, and their tooling is fragmented: JAWS at 40.5%, NVDA at 37.7%, VoiceOver at 9.7%, with the rest spread across other tools. Testing in one screen reader tells you little about the others.

Automated scanners only see about half the problem

The obvious fix is to run a scanner, and you should. But know its limits. Deque's study of 2,000 audits across 13,000 pages found automated testing caught 57% of accessibility issues by volume. The remainder needs a human: keyboard walkthroughs, screen reader passes, judgement calls on whether alt text actually describes the image rather than merely existing.

The regulatory clock is also running. The European Accessibility Act has applied to e-commerce and consumer digital services since 28 June 2025, so an EU customer base now makes accessibility a legal exposure, not a nice-to-have. Teams we work with treat it the way they treat performance: budgets in CI, a frontend accessibility and compliance review at each release, and manual testing on the flows that earn money. Checkout first, marketing pages later.

FAQ

Can analytics detect screen reader users?

No, not reliably. Assistive technology does not expose itself to JavaScript in a consistent, privacy-safe way, and blocked users rarely report problems. You find these failures by testing, not by waiting for the data.

Are automated accessibility tools enough?

No. Automated tools caught about 57% of issues by volume in Deque's audit study. Pair a scanner such as axe-core with manual keyboard and screen reader testing on critical journeys.

Which failures should we fix first?

Start with the six patterns that dominate the WebAIM Million: low contrast, missing alt text, unlabelled forms, empty links, empty buttons and missing document language. They are common, cheap to fix and heavily weighted in audits.

Your first five moves

1.       Run an automated scan on your top ten pages and log every error.

2.       Complete a keyboard-only walkthrough of your primary revenue flow.

3.       Test that same flow with NVDA or VoiceOver and note where you stall.

4.       Fix contrast, alt text and form labels before anything clever.

5.       Add an accessibility gate to CI so regressions cannot ship quietly.

If you would rather not learn three screen readers before your next release, BeyondPixl Studio runs accessibility audits that combine automated scanning with manual assistive technology testing on your critical user journeys. Book an accessibility audit of your checkout flow and get a prioritised fix list within two weeks.

Ready to build something exceptional?

Let’s talk about your project.