The evidence · Updated April 2026
Why accessibility overlay widgets don't work.
If you're paying $500-$5,000/year for a JavaScript overlay that claims to make your site "WCAG compliant" at the click of a button, this page is for you. The short version: the claim is not true, regulators and plaintiff's lawyers now treat overlay presence as bad-faith evidence, and the FTC has written the legal playbook against this category of product.
1. The $1M FTC settlement (January 2025)
The Federal Trade Commission reached a $1,000,000 settlement with accessiBe, the largest overlay vendor, in January 2025. The FTC complaint alleged two core deceptive practices:
- Representing the widget as automatically achieving WCAG compliance when it did not.
- Using paid "testimonials" and review-farm tactics to create the appearance of disability-community support the product did not actually have.
The settlement is now public case law. Plaintiff's attorneys in ADA accessibility lawsuits routinely cite it to establish that overlay-based remediation does not create a reasonable-effort defence.
2. The Princeton study (2023)
Van Lee et al., Princeton University Center for Information Technology Policy, tested overlay widgets with blind users and screen-reader software in 2023. Their findings:
- Overlay-injected ARIA attributes conflicted with the underlying HTML semantics, causing NVDA and JAWS to announce wrong element roles.
- In multiple scenarios, users with screen readers completed tasks more slowly and with more errors when the overlay was active than when it was disabled.
- Overlay "profiles" (e.g., "ADHD mode", "blind mode") were mostly cosmetic toggles that did not alter underlying accessibility barriers.
Disability advocacy organisations now reference this study routinely. The National Federation of the Blind (NFB) and similar groups have formal public positions against overlays.
3. Regulators look at served HTML, not runtime behaviour
Under EAA 2025 / EN 301 549 / WCAG 2.1 AA, conformance is evaluated against the HTML served by your origin. An overlay that manipulates the DOM after page load does not change the served HTML and does not change the scan result a regulator, consumer association, or court-appointed auditor would run.
Practical test: point axe-core (free, open-source) at your site with the overlay script disabled. That is what regulators see. If it fails, you are non-compliant — regardless of whether the overlay is active for other visitors.
4. What actually works
The pattern that holds up legally and in practice:
- Fix at the source. Edit your HTML / CSS / React templates until axe-core shows zero serious+ violations.
- Prevent regressions in CI. Put a scanner in your pull request pipeline that blocks merges when accessibility regresses. This is what keeps the site clean in the months between human audits.
- Commission one human audit per year. Automated tools (including axe-core 4.11) catch roughly 57% of WCAG issues. The remaining 43% — cognitive load, screen-reader navigation flow, video captioning — needs a certified human auditor.
- Publish an accessibility statement. EAA requires one, and courts and regulators look for it first. It must be dated, name a responsible contact, and link to an escalation channel.
- Keep the audit trail. When a consumer association complains, your defence is evidence of systematic good-faith effort — CI scan reports and audit records serve that purpose.
Try the alternative free.
axle is the overlay-free tool for this: scan every PR with axe-core 4.11, Claude-generated code-fix diffs in the PR comment, published verified statement URL for your lawyer. Unlimited scans on the free tier. Team plan at $49/mo — one twelfth of what overlay vendors charge.