Do Accessibility Overlays Actually Work?

We sell an accessibility scanner, so we have an obvious interest in your answer to this question. Read this page accordingly: everything below links to a primary source, and if you only take one thing from it, take the sources rather than our summary of them.

We are also not lawyers, and nothing here is legal advice.

What overlays claim

An accessibility overlay is a snippet of JavaScript you add to your site. The marketing proposition is consistent across the category and it is genuinely attractive: one line of code, installed in minutes, and your accessibility problem is handled — automatically, continuously, without touching your codebase or hiring anyone.

If you are a store owner who has just received a demand letter, that is exactly the thing you want to be true. It is worth knowing what the record says about it before you spend money on it.

How they actually work

Two mechanisms, usually bundled:

The widget. A floating button opens a panel of user-facing toggles — larger text, higher contrast, a “screen reader mode”, a dyslexia-friendly font, sometimes a cursor size control.

The Overlay Fact Sheet addresses this directly: it argues that while these features may look beneficial, their practical value is largely overstated, because the users who need them already have these controls built into their operating system, browser, and assistive technology — and have them configured the way they like across every site they visit, not just yours.

Automated repair. The script inspects the page as it loads and attempts to patch problems in the browser: guessing alt text for images, injecting ARIA attributes, adjusting colours, rewriting form field associations.

This is the substantive claim, and it is the one the sources below address.

The important structural fact about both: nothing is changed in your source code. The repairs exist only while the third-party script is loading, running, and working correctly. Remove it — or have it fail to load — and the site is exactly as it was.

The FTC action

In January 2025 the Federal Trade Commission announced that software provider accessiBe would pay $1,000,000 to settle allegations that it misrepresented the ability of its AI-powered accessibility tool, accessWidget, to make any website meet the Web Content Accessibility Guidelines (FTC, 3 January 2025).

The specifics, from the FTC’s own release:

The complaint alleged that, despite the company’s claims, accessWidget did not make all user websites WCAG-compliant, and that the claims were therefore “false, misleading, or unsubstantiated” under the FTC Act.
A second count concerned marketing rather than the product: the FTC alleged accessiBe presented third-party articles and reviews as though they were independent opinions by impartial authors, and did not disclose the company’s material connections to those reviewers.
The order bars the company from representing that its automated products can make any website WCAG-compliant, or ensure continued compliance with WCAG over time, unless it has the evidence to support such claims.
The Commission approved the order as final on 22 April 2025, by a 3-0 vote, after a public comment period (FTC, 22 April 2025).

Read that conditional clause carefully, because it is the most useful sentence in the whole matter. The regulator did not rule that automation is worthless. It ruled that a specific claim about what this automation achieves was made without evidence, and it left the door open: produce the evidence and you may make the claim. As far as we are aware, that evidence has not been produced.

One action against one vendor is not the whole category, and we are not going to pretend it is. It is, however, the only regulator’s finding of fact available on the central claim, and it went against the claim.

Why more than a thousand practitioners signed the Overlay Fact Sheet

The Overlay Fact Sheet is a public document setting out what overlay products can and cannot do. Its position on the central question is that while an overlay may improve conformance with a handful of provisions in the major standards, full compliance cannot be achieved with an overlay.

It is specific about which repairs are unreliable rather than making a blanket assertion:

Automated application of text alternatives for images is not reliable.
Automated repair of field labels, error management, error handling and focus control on forms is not reliable.
Automated repair of keyboard access is not reliable.

Those three cover most of what actually stops someone completing a purchase.

As of 1 September 2026, the signatory list on the fact sheet numbered 1,031 names. The list is open and grows, so check the page for the current count rather than quoting ours. The signatories describe themselves as people who are experts in the field and have spent their careers on accessibility, or who are end users with disabilities, or both. They also make a pledge: never to advocate, recommend, or integrate an overlay that markets itself as providing automated compliance with laws or standards.

The obvious objection is that many signatories work in accessibility and therefore compete with overlay vendors. The fact sheet anticipates it and answers that a substantial share of signatories are disabled users of the web rather than vendors of anything, and that the technical claims stand or fall on their own. We think that is a fair answer, and we would say the same about ourselves: check the technical claims, not our motives.

The document also collects accounts from disabled users describing overlays making sites harder to use rather than easier — conflicting keyboard commands, a control panel that interferes with a screen reader’s own controls, workarounds needed to reach content. That is the failure mode people miss. The question is not only “does it help?” but “does it get in the way?”

Sites using overlays are still being sued

UsableNet reads the actual complaints filed in federal and key state courts and publishes counts each year. In its analysis of 2025, more than 5,000 digital accessibility lawsuits were filed (UsableNet, ADA web lawsuit trends).

On widgets specifically, UsableNet reports that they appear in complaints frequently — but as a subject of the complaint rather than as a defence:

Monthly filing data showed no meaningful reduction in lawsuits against companies using widgets across 2025, with volume peaking above 150 cases in a single month.
An increasing number of filings explicitly referenced an accessibility widget while alleging that code-level barriers remained unresolved.
Some filings alleged that the widget itself interfered with screen readers or introduced additional obstacles.

Two limits on what that shows, stated plainly. It is one organisation’s count, and we have not independently reproduced it — though the filings themselves are public if you want to. And filing counts describe what plaintiffs do, not what courts conclude; a lawsuit is an allegation. What the data does establish is narrower and still decisive for a purchasing decision: installing a widget did not stop people being sued.

What the underlying problem is

Automated repair is hard for reasons that are not going to be solved by a better vendor.

Take image alt text, the single most commonly promised repair. A machine can see that an image has no text alternative. To write one it has to know what the image means in this context — the same photograph needs “Blue trail running shoe, side view” on a product page, an empty alt attribute when it is decorative, and the destination of the link when it is a linked logo. Image recognition can describe pixels. It cannot know your intent.

The same applies down the list. Whether a form error message tells someone what to do next, whether the reading order tells a coherent story, whether a custom date picker lets a keyboard user out again — these need someone to understand your content and try to use it.

We hold ourselves to this too, and it is the reason we do not claim to solve accessibility. Our scanner runs axe-core, whose maintainer Deque states in the project README that it finds on average 57% of WCAG issues automatically. That is Deque’s figure, reported as theirs. Other practitioners put the number lower. The honest summary is “about half”, and our methodology page lists exactly which failures fall on each side of that line.

The difference between an overlay and a scanner is not that one is automated and the other is not. Both are automated and both are limited by the same wall. The difference is what each does at the wall: a scanner hands you the remaining list and says a person is needed; an overlay’s proposition has historically been that no person is needed.

What works instead

Nothing here is novel, which is rather the point:

Find out what is actually in your code. An automated scan is cheap and catches the high-volume, template-level failures — the ones that repeat across every page. Start there because the effort-to-benefit ratio is the best you will ever get.
Fix it in the source. A fix in your repository survives the vendor, the subscription, and the script failing to load. It is also what an expert reviewing your site actually sees.
Get a human to test the rest. A qualified practitioner with a screen reader and a keyboard finds the half no tool sees. If you have a legal deadline or a complex application, this is not optional and it is not something we can sell you.
Keep checking. Sites change weekly. A report is accurate for about a week. This is the argument for monitoring rather than a one-off audit, and it is the part most people skip.
Write it down. Dated records of what you found, what you fixed and what is scheduled show ongoing effort in a way a subscription receipt does not.

If you already have an overlay installed

No gloating, and a real suggestion. Plenty of people installed one in good faith, on the strength of marketing that a regulator has since found unsupported.

A sane transition:

Scan the underlying code to see what is actually there beneath the script. This is the information you have been missing, and it is what tells you the size of the real job.
Do not cancel anything yet. Removing the widget changes nothing about your code, but it also changes nothing about your risk, and sequencing the removal after the fixes gives you a cleaner record.
Fix the highest-impact issues in your source, starting with templates and with the paths that matter — checkout, contact, navigation.
Test the overlay itself with a keyboard and a screen reader, or have someone do it. This is a human test. If it is intercepting keystrokes or fighting your visitors’ own assistive technology, that is an active harm and it changes the calculation immediately.
Then decide whether the subscription is still earning its money, with actual information instead of a promise.
Set up monitoring so the fixes you have paid for do not silently revert on the next theme update.

The thing to stop doing today is treating the installed widget as evidence that the work is done. That specific assumption is what the FTC order, the fact sheet, and the filing data all address.

Sources

Every source below was fetched and read while this article was drafted.

Source	What it confirms
FTC press release, 3 Jan 2025	accessiBe Inc./Ltd. to pay $1,000,000; complaint alleged accessWidget did not make all user websites WCAG-compliant and that the claims were false, misleading, or unsubstantiated; separate count on undisclosed connections to reviewers.
FTC press release, 22 Apr 2025	Final consent order approved 3-0 on 22 April 2025; bars representing that its automated products can make any website WCAG-compliant or ensure continued compliance over time, absent supporting evidence.
Overlay Fact Sheet	Full compliance cannot be achieved with an overlay; automated alt text, form repair and keyboard repair are not reliable; widget features’ practical value largely overstated; 1,031 signatories on 1 September 2026; signatory pledge.
UsableNet, ADA web lawsuit trends	More than 5,000 digital accessibility lawsuits filed in 2025; no meaningful monthly reduction in lawsuits against widget users; peak above 150 cases in a single month; filings reference widgets while alleging unresolved code-level barriers.
axe-core	Deque’s own stated figure of 57% of WCAG issues found automatically on average; rule coverage for WCAG 2.0/2.1/2.2 at A, AA, AAA plus best practices.

See what’s actually in your code, not what a script says about it. No signup. No credit card. First scan free.

Scan my site free

Do accessibility overlays actually work? What the evidence shows