Your site can score 94/100 on accessibility and still be a live ADA lawsuit. Free scanners don’t test the part that gets you sued.
Can a website pass an automated accessibility scan and still get sued under the ADA?
Yes. It happens all the time.A site passes every free scan — clean axe-core, zero violations flagged — and still has a barrier on it that fails the ADA.
Here’s why. The free engines almost everyone runs, widgets included, check the page while it just sits there. They never touch the keyboard. So they can’t see what breaks when a real person tries to tab through your site.
We ran our multi-layer scan on a US e-commerce site that scored 94/100 with zero axe-core violations, and found a keyboard trap on it: a WCAG 2.1.2 Level A failure. We confirmed it by hand, walking all 40 tab stops. For scale — in 2025 there were 8,667 ADA Title III website lawsuits, and 22.6% of the sites sued already had an accessibility widget installed.
trap
A live US e-commerce site scanned by Fix47, July 2026. The trap is reproducible by anyone who tabs through the page.
Same page, same moment. The two tests flat-out disagreed. The keyboard one is the version that counts, because it’s how a real user moves through a site. It’s also how a plaintiff’s expert moves through it.
Why a clean automated score can still hide a Level A failure
Automated scanners test the page at rest. That includes axe-core, the open-source engine behind most free checkers and the “AI audits” baked into accessibility widgets. They load the page, read the code as it sits, and report what’s there. Fine for missing alt text or weak contrast. It falls apart on anything that only shows up after someone interacts, because the scanner never interacts.
The clearest case is a keyboard focus trap. A keyboard user hits Tab, lands inside a component, and can’t get back out. Everything past that point is unreachable for them: the nav, a contact form, the checkout. That’s a WCAG 2.1.2 failure — No Keyboard Trap — at Level A, the most basic bar there is. And a static scan can’t see it, because on a page that’s just sitting there, there’s no keyboard focus to trap.
| Type of defect | Static automated scan (axe-core) | Keyboard-path layer (Fix47) |
|---|---|---|
| Missing alt text | Detected | Detected |
| Weak colour contrast | Detected | Detected |
| Keyboard focus trap (interaction) | Not visible at rest | Found |
| Broken focus order (interaction) | Not visible at rest | Found |
A score isn’t conformance.
Any product built purely on automated detection has this blind spot baked in, and an overlay widget’s engine is exactly that kind of product. It’s not sloppiness on their part. It’s just what you get when you test a page that’s standing still. So our process doesn’t stop at the scan. A person tabs through the site by hand and spot-checks it, because the stuff automated tools miss is usually the stuff that gets you sued.
Three real scans
Every number below comes straight from the production Fix47 scanner. We kept the first site anonymous. The two named ones are our own clients, and they said yes to being named.
| Site | Fix47 scan | What we found |
|---|---|---|
| A US e-commerce site | 94/100 · 0 axe-core violations | A WCAG 2.1.2 Level A keyboard trap, confirmed across 40 tab stops |
| Pinsilike (our client) | Started at 73 axe-core violations | Remediated to zero — monitored every month since |
| promuoviamoci (our client) | 100/100 | Zero violations — monitored every month since |
What the public record says
- 8,667 ADA Title III lawsuits were filed in federal court in 2025, per Seyfarth Shaw’s tracking at adatitleiii.com. This is a steady, measurable volume, not a fringe risk.
- 22.6% of accessibility lawsuit filings in the first half of 2025 targeted websites that already had an overlay installed, per UsableNet’s 2025 Midyear Digital Accessibility Lawsuit Report. Whatever a widget does, the data shows it doesn’t take a site off plaintiffs’ target lists.
What no scan can do — ours included
No scan proves you’re safe. Not a free one, not ours. A scanner reports what it finds. It can’t hand you a legal status, and nobody honest is going to promise you’ll never get sued.
What a real process can do is smaller than that, and it’s enough. It finds the actual defects, including the ones the tools can’t see. It fixes them in your code so they stay fixed. It rescans every month so regressions get caught before a plaintiff does. And it leaves you dated evidence reports of the work. That’s a real record of what was broken and what got fixed. Not a screenshot of a toolbar.
Frequently asked questions
Can a website pass an accessibility scan and still get sued under the ADA?
Yes. Automated scanners test a page while it's sitting still, so they're blind to failures that only appear once a real person interacts with it. On one US e-commerce site that scored 94/100 with zero axe-core violations, a keyboard test found a focus trap, a WCAG 2.1.2 Level A failure, confirmed by walking 40 tab stops by hand. A clean automated score is a starting point, not proof that no barrier exists.
Does a 94/100 accessibility score mean my site is compliant?
No. A score from an automated scanner reflects the checks that tool can run on its own, which are mostly static issues like missing alt text and weak contrast. It can't measure defects that only happen during interaction, and it doesn't grant any legal status. The score isn't the conformance; it's one input among several.
Why can't automated scanners catch every accessibility problem?
Because they test the page while it sits still. Engines like axe-core, which power most free checkers and the audits inside accessibility widgets, load the page, read the code as it is, and report what they see. They never press Tab, open a menu, or move through a form, so interaction failures like keyboard traps and broken focus order are outside what they can find by design.
What is a keyboard focus trap?
It's when a keyboard user presses Tab, lands inside a component, and can't get back out. The rest of the page, the navigation, contact details, checkout, becomes unreachable without a mouse. It's a failure of WCAG 2.1.2 (No Keyboard Trap), a Level A criterion, which is the most basic conformance level the standard defines. It's also invisible to a static scan, because on a page at rest there's no keyboard focus to trap.
Do accessibility widgets catch these interaction failures?
The detection inside an overlay widget is automated, so it has the same blind spot as any static scanner: it tests the page at rest. The litigation data underlines the point. In the first half of 2025, 22.6% of the websites sued over accessibility already had a widget installed (UsableNet). A widget running automated detection doesn't, on its own, surface a keyboard trap.
How do I find out whether my site has one of these hidden failures?
Run a scan that goes past a static check and actually tests the page by keyboard. Fix47's free scanner pairs automated engines with a keyboard-path layer, the one that found the Level A failure described above. Your score and the full issue report show instantly — no signup, no email.
See what your score is hiding
A good score on a free checker isn’t evidence you’re safe. It’s the exact spot the 94/100 site was in, right before we found its keyboard trap. Run the same test on your own site. Takes about a minute, and it includes the keyboard-path layer the static tools skip. You’ll see your score and the full issue report right away — no signup, no email.
Run the free scanRelated reading: Does an accessibility widget stop ADA lawsuits? · accessiBe alternative: widget vs. real remediation · Got an ADA demand letter? What to do