Here's a strange truth about legal risk: the vaguer your accessibility statement, the safer you are.
"We care about accessibility for all our users" is basically unfalsifiable. Nobody can prove it wrong because it doesn't actually claim anything. It's a feeling wearing the costume of a policy.
But the moment you put a badge in your footer that says "WCAG 2.2 AA Compliant," you've done something very different. You've made a specific, testable, checkable claim. And testable claims are exactly what a plaintiff's expert goes looking for first.
The Stat: UsableNet's ADA web accessibility lawsuit tracking has found that a meaningful share of filed lawsuits name sites that carried some form of accessibility statement, overlay, or widget at the time of the complaint. (Source: UsableNet)
Read that again. The presence of a statement or a badge did not prevent these lawsuits. In some cases, it may have helped invite them.
A statement is a promise you have to keep
Think about why a vague statement is legally inert. It doesn't reference a standard. It doesn't name a conformance level. It's a mission statement, not a warranty.
A specific claim is a different animal entirely. When your footer says "WCAG 2.2 AA Compliant," or your accessibility statement names a conformance target, you've told the world exactly what to test you against. That's not a bad thing in principle - transparency is good. The problem is when the claim and the code stop matching.
This is precisely why independent conformance evaluation exists as a discipline in the first place. The W3C's WCAG-EM conformance evaluation methodology was built because conformance to WCAG is meant to be evaluated by someone checking your actual pages against the actual success criteria, not simply asserted. And WCAG's own conformance requirements are explicit about what "conforming" actually means at a technical level: full pages, complete processes, no exceptions buried in fine print.
A plaintiff's accessibility expert knows this methodology cold. When they see a badge, the first thing they do is run the same kind of independent evaluation the W3C describes - keyboard-only navigation, screen reader passes, color contrast checks, form label audits - and compare the results to your public claim.
What the gap actually looks like in practice
In our own testing work, the mismatch between "claimed" and "actual" tends to cluster around a small set of recurring, very findable failure categories. None of these require exotic tools to discover:
| Claim on the badge | Common reality found in audit |
|---|---|
| "Fully keyboard accessible" | Modal dialogs or dropdown menus trap or skip focus |
| "AA color contrast" | Body text or muted UI copy falls below the required contrast ratio |
| "Screen reader compatible" | Form fields with no programmatic label, or icon-only buttons with no accessible name |
| "Compliant navigation" | Skip links missing, heading order broken, or landmark regions absent |
| "All images have alt text" | Decorative images marked up as informative, or alt text that's empty on meaningful content |
None of these are hidden. They are the exact categories an expert witness is trained to look for, and every one of them is checkable in an afternoon by anyone who knows where to look.
The statement isn't the problem. The mismatch is.
To be clear: having an accessibility statement is not what creates risk. Silence isn't safer, and a well-maintained statement that accurately describes your current state is a genuinely good practice. The risk is specifically in the gap between what the badge says and what the code does.
That gap turns your own marketing copy into an exhibit. A plaintiff doesn't need to argue that accessibility matters in the abstract - your own footer already conceded that. They just need to show the claim was false.
Here's a simple gut check before you publish or renew any compliance claim:
- The stated conformance level matches an actual, current, page-by-page audit - not a one-time review from a year ago
- Every major user flow (checkout, signup, search, forms) has been tested with a keyboard and a screen reader, not just the homepage
- The claim doesn't rely on an overlay or widget as the sole remediation method
- Someone can point to the specific audit or methodology behind the claim if asked
- The statement is dated and gets re-verified on a schedule, not left to go stale
If you can't check every box, the honest move is to soften the claim until you can, or to close the gap in the code. We've read our related piece on why overlay widgets keep getting sued if you want the fuller version of why bolting on a script doesn't close this gap - it just adds another layer between your claim and the reality underneath it.
Make the badge true before you hang it
None of this means you should take the badge down and go quiet. It means the badge should follow the audit, not replace it.
The fix is straightforward, if not always fast: test the real pages against the real success criteria, fix what's broken, and only then let the claim go public. That order matters more than the wording.
If you're not sure whether your current statement matches your current code, that's a fixable, fairly quick thing to find out. You can verify your own claim actually holds up with a free audit and get a clear picture of where the gap actually is before anyone else finds it for you.