Accessibility Overlays Won't Save You From an ADA Lawsuit

Your client is paying for an accessibility overlay. They might still get a demand letter.

That is not a hypothetical. EcomBack's 2025 annual web accessibility lawsuit report counted 983 ADA website accessibility lawsuits filed against sites that were running an accessibility widget, out of 3,948 filed in 2025. That is 24.90% of the year's cases, up from 722 cases (22.65%) in 2024.

This post explains why that keeps happening, what the FTC said about it on the record, and what an agency can offer a client instead.

What an overlay promises

Overlays are JavaScript add-ons you drop onto a page with a script tag. Widgets like accessiBe's accessWidget and UserWay are the best known. The pitch is simple: add the script, and the site becomes "WCAG compliant". Some vendors have gone further and marketed their product as protection against ADA lawsuits.

Those claims did not survive regulatory scrutiny. In April 2025 the Federal Trade Commission approved a final consent order requiring accessiBe to pay $1 million. The order bars the company from claiming its automated product makes websites compliant with the Web Content Accessibility Guidelines, or keeps them compliant, unless the claim is supported by evidence. It also bars accessiBe from presenting reviews and articles about its own product as the independent opinions of impartial users (FTC, April 2025).

That is a useful thing to be able to show a client who has been sold a widget.

Why overlays fail technically

An overlay injects JavaScript that tries to patch the rendered DOM after the page loads: adding ARIA attributes, adjusting color values, inserting labels where the HTML has none. That sounds plausible until you look at what actually reads the page.

An audit tool reads your HTML source, or the DOM at the moment it settles. A plaintiff's attorney captures screenshots and scan output. A screen reader parses the document as it arrives, and a user who already has assistive technology running may have moved through the page before the overlay script finishes. If the fix is not in the markup, it is not reliably there when it counts.

The broken version, which is what is in the HTML

<!-- Broken: a clickable element built as a div -->
<div class="btn" onclick="doSubmit()">Submit order</div>

An overlay may inject role="button" and tabindex="0" into the live DOM. It still leaves you with three problems:

• The element has no keyboard event handlers, so pressing Enter or Space does nothing.
• Assistive technology may have parsed the page before the overlay ran.
• The source HTML still contains none of it, which is what gets captured in a scan, a cache or a crawl.

The fixed version, which is what needs to be in the HTML

<!-- Fixed: a semantic button, accessible before any JavaScript loads -->
<button type="submit">Submit order</button>

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

This is not a corner case. The barriers the Department of Justice names in its guidance on web accessibility are the same ones: images without alt text, poor color contrast, text that cannot be resized, videos without captions, inaccessible online forms, and mouse-only navigation. Every one of those is a markup or CSS change. An overlay can mask some of them in some configurations. It cannot change the code that produced them.

Why the lawsuit pattern repeats

There are three reasons the widget keeps showing up in the filings.

Overlays create false confidence. Once the widget is installed, teams stop auditing. The vendor dashboard shows green. The underlying HTML does not change, and every release adds to it.

Overlays are least reliable for the people most likely to complain. Someone running a screen reader has their own, tuned setup. If the overlay conflicts with it, or executes after the document has been parsed, the user gets the unpatched page. That is the same group most likely to file.

The widget is visible. A floating accessibility icon in the corner is a public signal of which tool a site uses, and it is trivial to spot at scale.

The underlying failure rate has not improved either. The 2026 WebAIM Million found detectable WCAG failures on 95.9% of home pages tested, averaging 56.1 errors per page, up from 51 the year before.

What actually reduces risk

No tool, AccessGuard included, can make a site "lawsuit proof" or confirm that it conforms to WCAG. Automated checks find many real problems, and they miss things only a person can judge. What reduces risk is fixing the failures in the code, and keeping them fixed.

Find the failures in the real markup. Run an automated pass over the templates first, because it is fast and it reliably catches the highest-volume issues: missing alt text, unlabelled form inputs, low contrast, missing page language. Use our color contrast checker and form label checker to see what a scan reports for a given page.

Then test by hand. An automated tool cannot tell you whether alt text is meaningful, whether focus order matches the visual order, or whether a checkout flow can be completed with a keyboard. Tab through each template, check the reading order, and run one key flow in a screen reader. That is the part that decides whether a real user can buy something.

Put the fix in the code. A fix in the HTML works before JavaScript loads, after it fails, in cached copies and in crawled snapshots, for every user on every setup. A DOM patch does none of that reliably.

Rescan after every release. Sites regress. A template change that ships on Thursday can undo a fix from March, and nobody notices until the next audit.

What to tell a client who already bought one

You do not need to make this a fight. Three points usually settle it:

• The FTC order against accessiBe is public, and it is specifically about the claim that an automated product makes a site WCAG compliant.
• Widgets do not keep sites out of court: nearly one in four of 2025's ADA website cases named a site that had one installed, by EcomBack's count.
• Keeping the widget is their call. It does not substitute for fixing the templates, and the budget is better spent on the templates.

The bottom line

An overlay is a JavaScript file. It patches a handful of surface properties in a rendered DOM and leaves the source markup, and the exposure that comes with it, largely untouched.

Filings are not slowing down. Seyfarth Shaw counted 3,117 federal website accessibility lawsuits in 2025, 665 more than 2024's 2,452, a 27% increase (ADA Title III blog, March 2026). EcomBack, which counts state cases as well as federal ones, put the 2025 total at 3,948.

Fix the markup. Test what automation cannot see. Rescan after each release. There is no shortcut that skips those three steps.

Run a free scan on a client page, or read how to audit a website for accessibility and the 10 WCAG issues behind ADA website lawsuits for the checks to run first.