A homepage banner that says "This site is accessible to all" is not evidence. It is a claim. So earlier this year, our audit team decided to test the claim directly: we ran a full manual-plus-automated WCAG 2.2 AA review against 50 live, public websites that already advertised themselves as accessible, most of them running an overlay widget, a compliance badge, or both.
47 of the 50 failed at least one Level A or AA success criterion inside the first hour of testing.
No names. No screenshots of anyone's homepage. This isn't a takedown of specific companies, it's a pattern report, because the pattern is the useful part. If you run a website and you're relying on a plug-in script or a badge in the footer to cover your legal and ethical exposure, this is what we actually found underneath.
What "accessible" was supposed to mean
Every one of the 50 sites in our sample made some form of public accessibility claim: a statement page, a footer badge, or an overlay widget with a visible toggle icon. None of that is inherently bad. An accessibility statement is good practice. The problem is that a badge or a script is not a substitute for the underlying site actually meeting WCAG 2.2 success criteria at the code level, and in 47 of 50 cases, it wasn't.
The sample spanned small business sites, mid-market SaaS products, and ecommerce storefronts. Roughly two-thirds were running a third-party accessibility overlay or widget. The rest had a written accessibility statement but no active tooling. Failure rates were high in both groups.
The 5 patterns we saw over and over
We didn't find 47 unique failures. We found the same handful of mistakes, repeated across almost every site in the sample. In order of frequency across the 47 failing sites:
1. Low-contrast text (36 of 47 sites)
Body copy, form placeholders, or button labels rendered at a contrast ratio below the 4.5:1 minimum required by SC 1.4.3. This is the single most common failure on the modern web, and an overlay's font-size slider does nothing to fix a color pairing baked into the CSS.
2. Missing or meaningless alt text (33 of 47 sites)
Product photos, icon buttons, and hero images either had no alt attribute or had one that said image1.jpg or simply photo. A screen reader user gets nothing usable from either.
3. Unlabeled form fields (29 of 47 sites)
Checkout fields, newsletter signups, and contact forms with a visual placeholder but no programmatic <label> tied to the input. The field looks labeled to a sighted user and is anonymous to a screen reader.
4. Keyboard traps and unreachable controls (24 of 47 sites)
Modal dialogs, custom dropdowns, and "close" buttons that a mouse user can click but a keyboard-only user cannot reach, or worse, cannot escape once focus lands inside them. This is one of the clearest signs that a component was built without ever testing it without a mouse.
5. Broken heading structure (21 of 47 sites)
Pages that skip from an <h1> straight to <h4>, or use heading tags purely for font size instead of document structure, which strips out the page outline that screen reader users rely on to navigate quickly.
The Stat: Our findings track closely with the industry-wide WebAIM Million report, which found detectable WCAG failures on 95.9% of the top one million home pages tested. Claiming accessibility and having it are two different projects.
The 3 that passed, and what they had in common
The three sites in our sample with zero detected Level A/AA failures shared one trait: none of them relied on an overlay as their primary accessibility strategy. All three had gone through a manual audit that combined automated scanning with real keyboard and screen reader testing, and all three had fixed issues in their actual markup rather than patching them at runtime with an injected script.
That is really the entire finding. Automated scanners like axe and WAVE catch roughly a third of WCAG issues on their own; the rest, like logical reading order, meaningful alt text, and correct ARIA usage, require a person to actually test the page. If you want the process spelled out, we have a full WCAG audit checklist that walks through exactly what a real audit covers, and a deeper look at why overlay widgets keep getting sued anyway despite being installed specifically to prevent that.
A 10-minute self-check before you make any claims
You don't need a full audit to sanity-check your own site today:
- Unplug your mouse and tab through your homepage and your checkout or contact form. If focus disappears or gets stuck, that's a keyboard trap.
- Right-click three product or hero images and check the alt text in "Inspect." If it's blank or a filename, that's a real failure.
- Run your homepage through a free contrast checker and a free automated scanner. Neither is sufficient on its own, but both will surface obvious problems in minutes.
- Read your own accessibility statement. If it names a specific WCAG conformance level, ask when that claim was last independently verified.
None of this replaces a real audit, but it will tell you in ten minutes whether your site is more likely to land in the 3 or the 47.
Get the real number for your own site
Self-checks catch the obvious stuff. A full audit catches the rest, and gives you a prioritized, fixable list instead of a guess. Get a free accessibility audit and find out where your site actually stands, not where its badge says it stands.