Why an Accessibility Overlay Is Not a Compliance Solution
Overlay tools are marketed as a fast, affordable path to ADA compliance. Here is what they do, why code-level barriers remain, and what the FTC found when it examined one vendor's compliance claims.
Updated with additional research.
Anyone who has looked into website accessibility has probably been pitched an overlay.
The pitch is consistent across vendors: a small JavaScript snippet added to a website will automatically detect and fix accessibility barriers, bring the site into WCAG conformance, and protect the owner from legal action, at a low annual price. The appeal is obvious. Accessibility compliance can feel like a large, undefined problem. A vendor who promises to solve it with one line of code is easy to listen to.
The technical picture does not support the pitch. The guide to website accessibility for small businesses covers the wider context. This post covers overlays.
What Overlays Do
Accessibility overlays are third-party scripts that load after a page has rendered and apply changes on top of the existing DOM, the structure of the page as the browser has already assembled it.
Some overlays add a toolbar that lets individual users adjust display settings: larger text, higher contrast, a dyslexia-friendly font, reduced motion. Others scan the page and apply automated corrections to things like missing alt text or unlabeled form fields.
The display toolbar can be a useful aid for some people. It is a workaround for one user, though, and the structural barriers on the page are still there.
The automated remediation layer is where the technical case against overlays gets stronger.
Why Automated Remediation Falls Short
The barriers that create legal exposure and keep people out are in the code: missing or incorrect ARIA attributes, form fields without programmatic labels, keyboard focus that gets trapped or lost, and heading structures that skip levels.
Assistive technology, the software blind and low-vision users rely on, reads the page’s underlying markup. An overlay can change what a sighted visitor sees. It does not reliably change what a screen reader finds in the code.
A missing <label> element is not fixed by adding text near the form field. A link reading “click here” is not described by a script guessing at surrounding context. A keyboard trap inside a modal is not resolved by a script that runs once on page load. These are code problems, and they need code fixes.
The Overlay Fact Sheet, a public statement signed by more than 1,000 people at the time of writing, takes the same view. It says no overlay product can make a website fully compliant with any existing accessibility standard, and it commits signers to calling for overlays to be removed.
What the Record Shows
The strongest primary-source evidence comes from a regulator. In April 2025 the Federal Trade Commission finalized an order against accessiBe. The FTC alleged that the company’s claims that its accessWidget could make any website WCAG-compliant were false, misleading, or unsubstantiated, and that the widget did not make all user websites WCAG-compliant. The order requires a $1 million payment. It bars accessiBe from claiming its automated products can make a website WCAG-compliant, or keep it compliant, without supporting evidence.
Installing an overlay has not ended legal claims either. In Murphy v. Eyebobs, an online retailer that used the accessiBe overlay was sued and settled in October 2021. In the cases I have followed, an installed overlay did not end the claim. A vendor’s compliance claim is not a legal defense.
Disability organizations have also taken positions. The American Council of the Blind passed a resolution on website overlays in September 2021.
The False Confidence Problem
The most consequential thing about overlays is that they fail quietly.
A business that installs an overlay has done something visible. There is a widget on the page and a vendor invoice in the books. From inside the business, this looks like action on a known risk.
What the overlay does not do is identify which barriers the site has, which are most likely to generate legal exposure, or whether any were addressed. It gives the appearance of a response without the substance.
An accessibility audit names what is present: where the failures are, how they behave with assistive technology, and what order of remediation makes sense. A script running on top of a rendered page cannot produce that, because producing it means inspecting the code.
What Conformance Requires
Conformance to WCAG, commonly at the 2.1 or 2.2 AA level, is an ongoing practice with three components.
The first is an audit by a person or team with direct experience using assistive technology, not only automated scanning. Automated tools find a large share of issues, but not all. Deque’s analysis, a vendor study of over 2,000 audits and over 13,000 pages, found that its automated testing covered 57 percent of issues by volume. The rest took human judgment: understanding context, testing user flows, and evaluating whether an implementation matches the intent of each criterion.
The second is remediation of what the audit found, in the underlying code, with the highest-exposure barriers first. Some fixes take hours. Others need developer involvement.
The third is monitoring, because websites change. New content arrives, third-party widgets are added, and plugins update. A site that was accessible last year may not be after a redesign.
None of that is what an overlay offers. An overlay offers the impression of action at a price that makes it easy to buy without scrutiny.
A business that already has an overlay still has options. The barriers the overlay was meant to address may remain, and an audit is the reliable way to learn which ones.
If your site has an overlay and you are not sure what it covers, a 15-minute conversation with COREaccess™ is a practical place to start.