Accessibility Overlays Won't Save You From an ADA Lawsuit

Nearly 1 in 4 ADA lawsuits in 2025 hit sites that already had a widget installed. Here's why overlays don't work — and what does.


You're paying for an overlay. You might still get sued.

That's not a hypothetical. EcomBack's 2025 annual web accessibility lawsuit report found that 24.90% of ADA website lawsuits in the first half of 2025 targeted companies that already had an accessibility overlay widget installed on their site. More than 456 businesses paid for a tool marketed as protection — and still got a demand letter.

This post explains why that keeps happening, what the FTC said about it, and what actually reduces your legal exposure.


What an overlay promises

Overlays — widgets like accessiBe's accessWidget, UserWay, and similar tools — are JavaScript add-ons you include on a page with a script tag. The pitch is straightforward: add the widget, and your site becomes "WCAG compliant." Some vendors have gone further, claiming their product provides legal protection from ADA lawsuits.

Those claims are false. The FTC said so in writing.

In April 2025, the Federal Trade Commission approved a final consent order requiring accessiBe to pay $1 million and barring the company from claiming their AI product makes websites compliant with Web Content Accessibility Guidelines. The order's language is clear: automated tools cannot make any website WCAG-compliant. The order stays in effect for 20 years.

FTC Final Order, April 2025 →


Why overlays fail technically

An overlay injects JavaScript that tries to patch the rendered DOM after your page loads: adding ARIA attributes, adjusting color values, inserting labels where the HTML doesn't have them. This sounds plausible until you consider what accessibility audits — and assistive technology — actually evaluate.

A WCAG audit tool reads your HTML source or the DOM at the moment it loads. A plaintiff's attorney captures screenshots and automated scan results. A screen reader parses the document as it arrives. If the fix isn't in your HTML, it may not be there when it counts.

The broken version (what's in your HTML)

<!-- A clickable element built incorrectly as a div -->
<div class="btn" onclick="doSubmit()">Submit Order</div>

An overlay may inject role="button" and tabindex="0" into the live DOM. But:

  • The element has no keyboard event handlers — pressing Enter or Space does nothing
  • Screen readers may have already parsed the page before the overlay JavaScript fires
  • Your raw HTML source still contains none of this — which is what gets captured in a scan, cached, or indexed

The fixed version (what needs to be in your HTML)

<!-- A semantic button — accessible by default, before any JavaScript loads -->
<button type="submit">Submit Order</button>

A native <button> element is keyboard-focusable by default, fires on both Enter and Space, carries an implicit ARIA role of "button," and works correctly whether or not JavaScript has loaded. No overlay can retrofit this. It has to be in the HTML.

This isn't a corner case. The violations that actually trigger ADA lawsuits — missing form labels, images without alt text, inaccessible modal dialogs, keyboard traps, unlabeled icon links — all require code changes to fix. An overlay can mask some of these in some configurations. It cannot fix the underlying code.


The lawsuit pattern

The reason 22.64% of 2025 lawsuits hit overlay-equipped sites isn't difficult to explain:

Overlays create false confidence. Teams stop auditing and fixing code once the widget is installed. The dashboard shows green. The underlying HTML doesn't change.

Overlays are unreliable in assistive technology environments. A user who already has a screen reader running may not see overlay changes at all — their AT parses the document before the overlay script executes. The group most likely to file an accessibility complaint is the group least likely to benefit from the overlay.

Plaintiffs' attorneys know overlays don't work. Of the more than 5,000 digital accessibility complaints filed in 2025, roughly 40% came from self-represented individuals — often guided by known lawsuit patterns. Sites with visible overlay widgets are a known signal that real remediation hasn't happened.


What actually reduces risk

No tool — AccessGuard included — can make your site "lawsuit-proof" or claim to make it "100% ADA compliant." What reduces risk is fixing actual WCAG violations in your code. Consistently, over time.

Find violations in your actual HTML. Automated scanning catches roughly 30–40% of all WCAG issues — but those issues reliably include the violations most likely to show up in a complaint: missing alt text, unlabeled form inputs, insufficient color contrast, missing page titles.

Prioritize by legal exposure. Not every violation carries equal risk. The issues behind the majority of ADA web lawsuits are a short list: images without alt text on product pages, inaccessible checkout forms, navigation that breaks under keyboard-only use, video content without captions. Fix those first.

Put the fix in the code. A fix in your HTML works before JavaScript loads, after it crashes, in cached versions, in crawled snapshots, and for every user with every screen reader in every configuration. A DOM patch from an overlay does none of those things reliably.

AccessGuard scans against WCAG 2.1 and 2.2 AA/AAA, flags issues by severity and legal risk, and generates code-level fixes you can apply directly. Three free scans, no card required.

Run your free scan →


The bottom line

An overlay is a JavaScript file. It patches a handful of surface-level properties in a rendered DOM and leaves your HTML — and your legal exposure — largely untouched.

In 2025, 3,117 federal ADA website lawsuits were filed — a 27% increase from 2024. More than one in five of those complaints targeted businesses that had already paid for an overlay. The FTC has put a $1 million fine and a 20-year order on record to make the point official: automated tools cannot make a site WCAG-compliant.

Plaintiffs' attorneys know this. The overlay is not a shield. In some cases, it's a signal that you haven't done the work.

Fix the code. Scan regularly. There's no shortcut that skips those two steps.

Start scanning for free

Join thousands of developers making the web more accessible.

Get started