Accessibility overlays do not fix the HTML underneath your site. They load a script after the page has already rendered and try to patch the result from the outside, which means the structural problems that actually block disabled users are still there, and a plaintiff can find them in minutes.

The evidence on this is no longer ambiguous. More than 800 businesses running an overlay were sued anyway during 2023 and 2024 (testparty.ai), and in April 2025 the Federal Trade Commission fined accessiBe, the largest vendor in the category, $1,000,000 over its claims that the product could make websites compliant.

What an overlay actually is

An overlay is a single line of JavaScript you paste into your site. Once loaded, it does two things. It adds a floating toolbar offering visitors options such as larger text, higher contrast, or a "screen reader mode". And it attempts automated repairs to the page, for example guessing alt text for images or adding ARIA attributes to elements it thinks are controls.

Both halves sound reasonable at first. The problem is what they assume. The toolbar assumes a disabled visitor will find and use a widget on your site rather than the assistive technology they already have configured on their own machine. The automated repair assumes a script can work out what a page means from the outside. Neither assumption survives contact with how people actually use the web.

The record so far

What has actually happened to overlays
FindingFigureSource
Businesses running an overlay that were sued anyway, 2023 to 2024 800+ testparty.ai
FTC penalty against accessiBe for deceptive claims, April 2025 $1,000,000 FTC
Federal ADA website lawsuits projected for 2026 6,000+ accessible.org
Share of defendants earning under $25M in revenue 64% UsableNet, 2025
WCAG success criteria that automated tooling can detect at all roughly 30 to 40% industry consensus, see our article on automated testing limits

That last row is the arithmetic that undoes the whole category. An overlay is an automated tool operating on a page it did not build. Even in the best case it inherits the same ceiling that every automated checker has, and it is working with less information than a checker running against your source, because it only ever sees the rendered result.

What the FTC actually said

The FTC action in April 2025 was not about whether overlays are useful. It was about advertising. The complaint concerned representations that the product could make a website compliant with WCAG and the ADA, and it also addressed reviews and endorsements that did not disclose the connection between the vendor and the reviewers.

The objection from the regulator was to the claim, not merely to the code. A vendor may sell an imperfect tool. A vendor may not sell an imperfect tool by telling buyers it delivers compliance.

This matters for you as a buyer because the marketing claim is usually the reason the overlay was purchased. If a business owner installs a widget because a landing page told them it would make the site compliant, they have paid for a legal outcome they did not receive, and they have often stopped doing the actual remediation work because they believed it was handled.

Why an overlay cannot reach a structural problem

Most serious accessibility barriers are not decoration applied to a page. They are the page. Here are the categories overlays cannot repair, with the reason in each case.

Meaning that only a human knows

An image of a chart showing quarterly revenue needs alt text that conveys the finding, not the word "chart". An overlay using image recognition can produce a plausible description of what is visually present and still miss entirely what the image is there to communicate. A product photo on an e-commerce page might need to convey the colour and the pattern, because those are the purchase decision. No script knows that.

Reading order that lives in the DOM

A screen reader follows the order of elements in the document, not the visual layout. CSS can place a sidebar to the right while the markup puts it before the main content, so a screen reader user hears the sidebar first on every page. Fixing that means reordering the source. An overlay running after render cannot restructure the document without breaking the page it is sitting on.

Programmatic relationships in forms

A form label must be associated with its input, an error message must be tied to the field it describes, and a group of radio buttons needs a grouping element with a name. An overlay guessing which visual text belongs to which input is guessing, and when it guesses wrong the user is told the wrong thing with complete confidence. A silent wrong answer is worse than a visible gap.

Custom widgets and focus management

A modal dialog built out of divs needs focus moved into it when it opens, needs focus trapped while it is open, needs to close on Escape, and needs focus returned to the trigger afterwards. That is application behaviour written into your code. It is not a property a passive script can add from outside.

Media and documents

Captions on video, audio description, and transcripts require someone to produce accurate content. So do accessible PDFs, which are a common source of complaints and sit entirely outside anything a page script touches. An overlay has no ability to caption your video.

The interference problem

There is a second issue that is less discussed and arguably more serious. Overlays can actively degrade the experience for people already using assistive technology.

A blind visitor arrives with a screen reader they have used for years, configured to their own speech rate and verbosity settings. An overlay that injects its own ARIA attributes, or announces its toolbar, or intercepts keyboard shortcuts, is competing with software that was already working. Surveys of screen reader users have consistently reported low confidence in overlay products, and hundreds of accessibility practitioners, including people who use assistive technology daily, have signed public statements against them.

That is the part that turns a wasted purchase into a liability. A site with untreated accessibility problems is a site with untreated problems. A site with untreated problems plus a script that interferes with the tools the visitor already relies on is worse than it was before.

Why plaintiffs are not deterred

Consider it from the other side. An overlay is trivially detectable: the script tag is in your page source and the toolbar is visible on screen. Testers filing these claims specifically look for it, because a site advertising an accessibility widget while still failing basic keyboard navigation is an easier claim to write, not a harder one. The widget documents that the business knew accessibility was an obligation and chose a $490-a-year script over doing the work.

Settlements in this area have required removal of overlays as a term. That is a strong signal about how the tools are viewed by the people negotiating these agreements.

What to do instead

  1. Run an automated scan to find the machine-detectable failures. This is fast, free at small scale, and finds real problems, but it covers only part of the picture.
  2. Test with a keyboard only. No mouse, no trackpad. If you cannot complete a purchase or submit a contact form, neither can a large group of your visitors.
  3. Test with a screen reader on the pages that matter. NVDA on Windows and VoiceOver on macOS are both free and already installed or one download away.
  4. Fix the structural problems in the source: labels, headings, focus order, contrast, and alt text that says what the image means.
  5. Keep a dated record of what you found and when you fixed it, so that the work you did is evidenced rather than asserted.
  6. Publish an accessibility statement that describes your actual position, including known problems and how someone can report a barrier. An honest statement is defensible. A statement claiming compliance you cannot support is a new liability.

Automated testing detects roughly 30 to 40% of WCAG success criteria. It cannot determine whether a site is legally compliant, and it is not a substitute for manual review and assistive-technology testing. AccessLedger sells a dated record of what automated checks found on a given day. Nothing more, and nothing less.

We sell scanning, so we have an obvious interest in step one of that list. We would rather say the awkward thing plainly: our scans find part of the problem, a person has to find the rest, and no product we sell, or that anyone sells, can promise you compliance or protection from a claim.