Why an Accessibility Overlay Is Not a Compliance Solution
Overlay tools are marketed as a fast, affordable path to ADA compliance. They are not. Here is what they actually do, why they fail technically, and why installing one may give you false confidence without reducing your legal exposure.
If you’ve looked into website accessibility, there’s a good chance someone has already tried to sell you an overlay.
The pitch is consistent across vendors: a small JavaScript snippet added to your website will automatically detect and remediate accessibility barriers, bring your site into compliance with WCAG 2.1 AA, and protect you from legal action, all for a few hundred dollars a year. The appeal is obvious. Accessibility compliance can feel like a large, undefined problem. A vendor who promises to solve it with a single line of code is easy to listen to.
The technical reality doesn’t support the pitch.
What Overlays Actually Do
Accessibility overlays are third-party scripts that load after your page has rendered and attempt to apply changes on top of the existing DOM, the underlying structure of the page as your 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 attempt automated detection and remediation, scanning the page and applying corrections to things like missing alt text or unlabeled form fields before the user interacts with them.
The display toolbar is a legitimate usability aid for some people. What it’s not is compliance. A tool that lets a user increase text size has not made the underlying page accessible. The structural barriers are still there. The tool has given that user a workaround, not a solution.
The automated remediation layer is where the technical case against overlays becomes decisive.
Why Automated Remediation Cannot Work
Website accessibility is not a surface problem. The barriers that create real legal exposure, and real exclusion, are embedded in the code: missing or incorrect ARIA attributes, form fields without programmatic labels, keyboard focus management that traps or loses the cursor, heading structures that skip levels and break navigation for screen reader users.
Assistive technology, the software that blind and low-vision users rely on to navigate the web, interacts with the DOM directly. It parses what the code actually says, not what the visual presentation suggests. An overlay that injects a correction on top of the rendered page may change what a visual user sees. It does not reliably change what a screen reader encounters in the underlying markup.
A missing <label> element is not fixed by adding text near the form field. A link that reads “click here” is not adequately described by an overlay that guesses at the surrounding context. A keyboard trap inside a modal is not resolved by a script that runs once on page load. These are code problems. They require code fixes.
This is not a theoretical limitation. It’s a documented and consistent finding from accessibility professionals and disabled users who have tested overlay products against real assistive technology. The gap between what overlays claim to fix and what they actually fix is large, measurable, and not improving materially.
What the Legal Record Shows
Overlays have been installed. Demand letters have still arrived.
Businesses that installed AccessiBe, UserWay, and comparable tools have subsequently received ADA Title III demand letters citing the same types of barriers the overlay was supposed to address. Several cases have resulted in litigation. In none of those cases has the presence of an overlay been established as a legal defense, because an overlay is not compliance documentation. It is a product from a third-party vendor whose marketing claims have no legal standing.
The disability rights community’s position on overlays is not ambiguous. The National Federation of the Blind and the American Council of the Blind have both issued statements against overlay tools. More than 700 accessibility practitioners and researchers signed the Overlay Fact Sheet, a public document cataloging the technical failures of overlay products. Several overlay companies have faced their own litigation, not from businesses that used them, but from disabled users who found that the tools made their experience worse.
That last point is worth sitting with. Overlays can interfere with native assistive technology by attempting to override behavior that the user’s own software handles more effectively. A screen reader user who has configured their own settings may find that an overlay’s corrections conflict with those configurations. The tool marketed as accessibility help can, in practice, make the site harder to use for the people it claims to serve.
The False Confidence Problem
The most consequential thing about overlay tools is not that they fail. It’s that they fail quietly.
A business that installs an overlay has done something visible. There’s a widget on the page. There’s a vendor invoice in the books. Someone made a decision. From inside the business, this looks like action taken on a known risk.
What it doesn’t do is tell you what barriers your site actually has, which ones are most likely to generate legal exposure, or whether any of them were meaningfully addressed. The overlay provides the appearance of a response without the substance of one.
An accessibility audit tells you specifically what is present: where the failures are, how they interact with real assistive technology, and what order of operations makes sense for remediation. You can’t get that information from a script that runs on top of a rendered page. It requires inspecting what the code actually says.
What Compliance Actually Requires
Real accessibility compliance under WCAG 2.1 AA isn’t a product install. It’s an ongoing practice with three components.
First, a genuine audit, conducted by a person or a team with direct experience using assistive technology, not just automated scanning tools. Automated tools catch roughly 30–40% of WCAG failures. The rest require human judgment: understanding context, testing real user flows, evaluating whether the technical implementation matches the intent of each criterion.
Second, remediation, fixing what the audit identified, in the underlying code, in the order that addresses the highest-exposure barriers first. Some fixes take hours. Others require developer involvement. The scope depends on what’s actually present.
Third, ongoing monitoring, because websites change. New content is added. Third-party widgets are integrated. Plugins update. What was accessible last year may not be accessible after a redesign. Accessibility is not a one-time certification.
None of that is what an overlay offers. An overlay offers the impression of action at a price point that makes it easy to purchase without scrutiny.
If your business has an overlay installed, that’s not the end of your options. It’s the beginning of a more honest assessment. The barriers the overlay was supposed to address may still be there. An audit is the only reliable way to find out what you actually have, and what the real path forward looks like. The COREaccess™ Accessibility Leadership System covers the full framework — audit, remediate, train, and monitor — for organizations that need documented, standards-based conformance.
If your site has an overlay and you’re not certain what it’s actually covering, a 15-minute conversation with COREaccess™ is a practical place to start.