The sales pitch is simple: paste one line of JavaScript into your site, and an overlay widget will "make you ADA compliant" overnight. It's an appealing offer, because real remediation takes weeks and a script takes minutes. It's also, on both the technical and the legal evidence, close to the opposite of what actually happens.
The pitch versus what the code can do
An accessibility overlay is a script that runs after your page has already loaded. From that position, it can do a genuinely useful handful of things: resize text, adjust contrast, pause animations, add a visible focus outline. What it cannot reliably do is rewrite the underlying structure of your page: fix a <div> that should have been a <button>, add a real programmatic label to a form field that never had one, restore a logical heading outline, or correct a reading order that was wrong in the markup to begin with.
Those are exactly the categories of failure that make up most of WCAG 2.2 Level A and AA, and they are structural. A runtime script layered on top of broken HTML is patching the symptom while the underlying non-conformance stays in the DOM, often invisible to the very people the widget claims to help, because many overlays actively conflict with the screen readers and browser extensions users already rely on.
How a "shield" becomes evidence against you
Here is the part that should worry anyone using an overlay as their sole accessibility strategy: the overlay itself is now something plaintiffs' counsel look for.
The logic is straightforward once you see it. A visible overlay icon is a public admission that you knew accessibility mattered enough to buy a product for it. If a tester or a plaintiff can still show that the underlying site fails to work with a screen reader, or that the overlay conflicts with assistive technology the visitor was already running, the widget stops looking like a defense and starts looking like Exhibit A: proof the company was aware of the issue and chose a shortcut. We've covered the litigation pattern behind this in detail in why accessibility overlay widgets get sued too and in our review of companies sued despite running an overlay.
This isn't theoretical regulatory risk either. In 2023 the FTC and the Department of Justice took action against overlay vendor accessiBe over deceptive claims that its product made websites compliant, resulting in a settlement in the seven figures. We broke down what that case means for anyone relying on similar compliance claims in the FTC's fine against an overlay vendor.
Why "compliant" isn't a checkbox a vendor can sell you
WCAG conformance is measured against specific, testable success criteria, things like contrast minimum (1.4.3), name, role, value (4.1.2), and keyboard accessible (2.1.1). Conformance is a property of the actual code that ships to the browser. No third-party script injected after page load can retroactively make a <div onclick> behave like a real, keyboard-operable button in every assistive technology combination a visitor might be using. The W3C's own Web Accessibility Initiative has published guidance cautioning against exactly this category of "accessibility overlay" product for this reason.
Questions worth asking before you sign an overlay contract
If your team is already evaluating or currently paying for an overlay, these are the questions that separate a genuinely useful accessibility tool from a compliance placebo:
- Does the vendor claim "full compliance" or "ADA compliant" anywhere in their marketing? That specific language is what drew regulatory attention in the accessiBe case. A vendor who is careful about this distinction, describing the product as an assistive add-on rather than a compliance guarantee, is a better sign than one who isn't.
- Has anyone tested your site with an actual screen reader since the overlay was installed? Overlays occasionally introduce new conflicts with NVDA, JAWS, or VoiceOver rather than resolving existing ones. The only way to know is to test with the real assistive technology, not the overlay's own preview mode.
- What does the underlying markup look like with the overlay disabled? If a visitor's browser extension, ad blocker, or corporate firewall blocks the overlay script, which happens more often than most teams realize, your site reverts to whatever state it was in before the overlay, unlabeled forms and all.
- Is there a remediation plan, or just the widget? A widget without a underlying-code roadmap is the whole problem in miniature: it's the entire strategy, not step one of one.
What an actual shield looks like
Real legal and practical protection comes from the boring version of this work:
- A manual audit against WCAG 2.2 AA, combining automated scanning with a person testing keyboard navigation and a screen reader, not just an automated crawler.
- Remediation in the actual codebase, fixing markup, ARIA, contrast, and focus order at the source, not at runtime.
- A documented VPAT/ACR that states your real conformance level, so you have evidence of a genuine, ongoing effort if you're ever challenged.
- Regression testing after every redesign or new feature, since accessibility is a moving target, not a one-time badge.
None of that fits in a single line of JavaScript. All of it is what actually reduces legal exposure, because it changes what happens when someone using a screen reader tries to use your site, not just what your footer claims about them.
Start with a real audit, not another script
If your current accessibility strategy is a widget in the corner of the screen, the fastest way to find out where you actually stand is a proper audit. Get a free accessibility audit and see the gap between what your overlay claims and what your code actually does.