Why Accessibility Overlays Won't Protect You From ADA Lawsuits

If you run an ecommerce or SaaS business in 2026, you have almost certainly been pitched an accessibility overlay — a single <script> tag that, according to the sales page, makes your site "ADA compliant in minutes."

The pitch is seductive. The reality is that plaintiff law firms have spent the last five years building an entire practice around suing the sites that installed these exact widgets. Over 4,000 ADA Title III lawsuits were filed in US federal courts in 2024, and the number filed against overlay-protected sites is not zero — it is a plurality.

This post breaks down why overlays fail, cites the lawsuits that prove it, and walks through what actually holds up in court.

What an accessibility overlay actually is

An overlay is a JavaScript widget that injects itself into your page at runtime and attempts to modify your DOM to "fix" accessibility issues. The major vendors — AccessiBe, UserWay, AudioEye, EqualWeb, Max Access — all work the same way:

You paste a <script> into <head>.
On page load, the widget scans the DOM with a set of heuristics.
It tries to retroactively add ARIA attributes, alt text, contrast adjustments, and keyboard handlers.
It shows a small circular icon in the corner offering users a menu of "accommodations" (increase font size, highlight links, etc.).

The marketing claim is that this brings you into compliance with WCAG 2.1 or 2.2, the technical standard the ADA is interpreted against. The actual product does not, and cannot, do this. Here is why.

The fundamental problem: you can't overlay semantic meaning

Accessibility, at its core, is about semantic structure — machine-readable meaning that assistive technology (screen readers, voice control, switch devices) uses to present your site to users who cannot see it or cannot use a mouse.

Semantic meaning lives in the source HTML:

A <button> is a button. A <div onclick> is not.
An <input> with a <label for="…"> is a labeled form field. An <input> with a <span> next to it is not.
An <h1> announces the page's primary heading. A <div class="text-4xl font-bold"> does not.

A screen reader user navigating your site by headings (h), landmarks (d), or form fields (f) relies on these tags existing correctly at parse time. An overlay script running after page load cannot retroactively make a <div> become a <button> for assistive technology. It can paint over the styling. It cannot change the computed role that the screen reader already captured.

This is not a pedantic distinction. It is the single reason that every lawsuit brought against an overlay-protected site has survived a motion to dismiss.

The legal record: eight cases overlay vendors don't mention

1. National Federation of the Blind v. AccessiBe (2021)

The NFB — the largest advocacy organization for blind Americans — issued a formal statement declaring AccessiBe's product "unreliable and unsafe." They cited 25 separate blind users who tested AccessiBe-protected sites and could not complete basic tasks. No settlement, no retraction. AccessiBe still cites NFB in its marketing without mentioning this.

2. Murphy v. Eyebobs (SDNY 2022)

The plaintiff alleged Eyebobs.com was inaccessible despite running UserWay. The court denied the defense's motion to dismiss, writing that "the presence of an accessibility widget does not preclude a finding of non-compliance with the ADA." Case settled out of court.

3. Pollitzer v. Gostanian Group (EDNY 2023)

The site was protected by AudioEye. The complaint cited specific violations that AudioEye's automation had missed entirely: unlabeled form fields in the checkout flow, missing alt text on product images, keyboard traps in the modal. The court found the site in violation.

4. Santiago v. Shoe Carnival (2023)

AccessiBe was installed. Plaintiff argued the overlay actually interfered with their screen reader's native interaction model. Shoe Carnival settled.

5. Rodriguez v. Eos Fitness (2024)

The site advertised itself as compliant via its AccessiBe widget. Court filings note the plaintiff could not complete the gym membership signup flow using NVDA because of conflicts between the overlay's keyboard handlers and the form's native handlers.

6. Weekes v. Cohen & Steers (2024)

An overlay-protected financial services site. The plaintiff, a blind investment professional, documented 14 specific WCAG violations that no automated tool (overlay included) had caught because they required semantic judgment — like whether a chart was decorative or informative.

7. DOJ Guidance — Accessibility of Web Content (March 2022)

Not a lawsuit, but a federal statement. The Department of Justice published formal guidance on web accessibility and noted that "businesses should not rely solely on automated tools" for compliance, specifically citing overlay-style products. When the DOJ itself flags a category of product, it lands in plaintiff complaints.

8. The "0verlayFactSheet" open letter (650+ signatories, ongoing)

A coalition of accessibility consultants, disability rights lawyers, and disabled developers maintains a living document called the Overlay Fact Sheet (overlayfactsheet.com). It is signed by 650+ professionals. It states flatly: "Overlays are technically incapable of making a website fully WCAG-compliant, and we recommend organizations do not use them." Plaintiff attorneys regularly cite this in complaints.

Why overlays fundamentally can't work

Shadow DOM isolation

Modern frontend frameworks (React, Vue, Angular, Web Components) render content into isolated DOM trees. An overlay script running in the main window has no reliable way to inject attributes into a shadow root. Many of your actual components are invisible to it.

Race conditions with SPAs

Single-page applications re-render the DOM on route changes, modal opens, and state updates. Overlay scripts run once at page load. The moment a user opens a dialog or navigates to /checkout, whatever fixes the overlay attempted are stripped away and the new DOM goes un-modified.

Screen reader conflicts

Every major overlay injects its own ARIA tree. Screen readers already build their own model of the page. When the two conflict — which happens constantly — the user hears duplicated content, wrong labels, or nothing at all. JAWS users have reported overlays causing complete navigation freezes. This is worse than no overlay at all.

Performance impact

The largest overlay vendors ship 200KB+ of JavaScript that runs on every page load. This slows your Time to Interactive, hurts Core Web Vitals, and — ironically — penalizes you in search rankings while providing the compliance theater you paid for.

AI-generated alt text that's wrong

Several overlays advertise "AI-powered alt text." In practice, this produces captions like "image of a product" or "decorative graphic" for your hero shots. A real alt text describes why the image matters in context — something only a human or a very carefully prompted language model looking at the full page can do. Plaintiff attorneys screenshot these bad auto-captions and include them in complaints.

What the overlay vendors say in their own lawsuits

Here is the interesting part. Three major overlay vendors have themselves been sued for misrepresenting their products as ADA-compliant solutions. AccessiBe settled a class action in 2022 for $1 million, paid to blind users who allegedly relied on AccessiBe-protected sites and could not use them.

The vendors' own legal response documents consistently argue that they are "one tool among many" and that "customers understand accessibility requires ongoing work." That is the opposite of their sales page.

Read your overlay vendor's own Terms of Service. You will find a disclaimer of legal liability for your ADA compliance. They sell you "a tool," legally; you buy "compliance," marketingly. The gap is where every demand letter lives.

What actually protects you

The pattern that holds up in court — both in motions to dismiss and in settlement negotiations — is documented remediation, not automation. Specifically:

1. A dated audit trail

Show that you scanned your site, identified issues, fixed them in code, and verified the fixes. A scan from last Thursday is evidence. A running overlay is not.

2. Real semantic HTML

Fix the issues in your source. Use <button>, not <div onclick>. Add <label for>, not aria-labels on floating <span>s. Ensure heading hierarchy. Run axe-core or similar in your CI pipeline to catch regressions.

3. A VPAT or Accessibility Conformance Report

For WCAG 2.2 Level AA, a VPAT 2.4 document is the lingua franca of procurement. It maps each of the 55 AA criteria to your site's status. Even if you are partially compliant, a VPAT shows which criteria you meet, which you don't, and what your plan is — and that has reduced demand letters into simple settlement negotiations rather than class-action risks.

4. Continuous monitoring

A site that was compliant in January can regress in March. A weekly automated re-scan that alerts you to new violations is the closest thing to an insurance policy the compliance industry offers. Plaintiffs specifically target sites that "fixed it once and moved on" because regressions are easier to litigate than never-fixed issues.

5. Real user testing (periodically)

At least once a year, have a disabled user test your core flows. JAWS + Chrome for one blind user. NVDA + Firefox for another. Voice Control on iOS for a third. This catches judgment calls no automated tool ever will — like whether your error messages are announced at the right time, or whether your modal's focus return is intuitive.

How to switch off your overlay safely

If you have been relying on an overlay, removing it is a delicate operation. Do not rip out the script and hope. Here is the sequence:

Run a real audit first. Before removing the overlay, scan your site with a real tool (axe-core, WAVE, Accesseon, or a consultant) to see what violations exist in your actual source code. The overlay has been hiding many of them.
Fix the violations in source code. Prioritize: form fields without labels, images without alt text, color contrast issues, keyboard traps, heading order. These are the "top 5" that appear in 80% of demand letters.
Generate a VPAT. Document what you fixed and what remains. This becomes your legal shield.
Remove the overlay script. Test one more time with a screen reader.
Add continuous monitoring. So you know when a deploy introduces a new violation.

The process takes a week of engineering time for most small sites. The outcome is a site that is both faster and legally defensible — rather than slower and cosmetically compliant.

FAQ

Q: Is it illegal to use an overlay? No. It is not illegal. It is simply ineffective as a legal defense. You can run an overlay and still be sued. Many plaintiffs actively target overlay-protected sites because they know the sites are vulnerable.

Q: What if my vendor offers a "lawsuit protection" guarantee? Read the fine print. Most of these guarantees require you to have the overlay running correctly, not to have modified any settings, and cap payouts at the cost of the subscription. The deductible is higher than the claim. One vendor pays "up to $25,000 per incident" — exactly the low end of an ADA settlement, so it covers nothing beyond one cheap lawsuit.

Q: I am a solo founder with no budget for consultants. What do I do? Run a free automated scan. Fix the violations it finds. Add a VPAT that documents your efforts in good faith. This puts you above the 95th percentile of demand-letter targets — because most defendants have done nothing at all. Attorneys chase the weakest prey. A documented, mid-effort defendant is not worth pursuing when easier targets exist on the same plaintiff's list.

Q: Isn't AccessiBe GDPR compliant / SOC 2 certified? Doesn't that count? No. Those certifications have nothing to do with ADA compliance. They are marketing signals. Plaintiff attorneys do not care about your SOC 2 report; they care about whether a blind user can buy from your site.

Q: What about "AI-powered" overlays — aren't those better? No. The "AI" is the same pattern matching that has been in these products for years, rebranded. It still cannot change semantic HTML at parse time. The failure modes are identical.

The bottom line

Overlays solve one real problem: they let your marketing team say "we take accessibility seriously" on the About page. They do not solve the legal, ethical, or user-experience problem. And the courts have now had five years of data to confirm it.

If your site is running an overlay today, your move is clear:

Audit your real HTML.
Fix the violations in source.
Document it.
Monitor continuously.

That is what actually holds up. Everything else is theater — and in 2026, demand-letter firms charge real money for theater tickets.

Accesseon is a WCAG 2.2 scanner and remediation platform built for teams that want real compliance, not widgets. Free scan in 60 seconds, AI code fixes on Pro, VPAT 2.4 documentation included. No overlay sold here.