Why Accessibility Overlays Won't Make You Compliant

If you have been shopping for a web accessibility solution, you have probably seen the pitch: install one JavaScript snippet, become WCAG compliant overnight, and get full legal protection. Accessibility overlays — widget-based products that inject automated fixes into your live site — make this promise explicitly in their marketing.

The problem is that the legal record, the technical evidence, and now a federal enforcement action all say the promise is false.

What Overlays Promise

Accessibility overlay products — companies like accessiBe and UserWay — offer JavaScript widgets that load on top of your existing website. The typical pitch includes:

• Automated scanning and remediation of WCAG violations
• AI-powered accessibility fixes applied in real time
• A "compliance" or "certification" guarantee that provides legal protection if you are sued
• A user-facing toolbar that lets visitors customize display settings (larger text, high contrast, etc.)

The user toolbar component is the most defensible part of the product. Offering display customization options is genuinely useful for some users. The problem is the compliance claim: that installing the overlay means your site is WCAG-compliant and that you are protected from ADA litigation.

Why Overlays Fail Technically

Overlay products operate by injecting JavaScript that runs after your page loads in the browser. This architecture has fundamental limits:

Screen reader conflicts. Screen readers (JAWS, NVDA, VoiceOver) parse the DOM as rendered. An overlay that adds ARIA attributes via JavaScript after initial page load can conflict with what the screen reader already read, announce duplicate content, or create focus management issues. Users who rely on screen readers often report that overlays make pages harder to use, not easier. The National Federation of the Blind has published statements opposing overlay products on these grounds.

Keyboard navigation gaps. Many WCAG failures are not detectable by JavaScript scanning — particularly issues around focus order, focus visibility, and custom interactive widget behavior. An overlay cannot reliably detect or fix keyboard traps in custom dropdowns, date pickers, or modal dialogs because the fix requires understanding the interaction model, not just the static DOM.

Dynamic content blindspot. Single-page applications (React, Next.js, Angular, Vue) frequently update the DOM after initial render. Overlay scripts that run once at page load miss violations introduced by client-side navigation, lazy-loaded content, or user-triggered state changes.

False positive remediation. Automated tools, including overlay AI engines, have known false positive rates. Generating alt text from image filenames, adding generic ARIA roles to elements, or adjusting contrast by overlaying a CSS filter can introduce new violations while claiming to fix existing ones.

The Legal Record

The legal record on overlays is clear and consistent: no published court ruling has accepted an overlay as a compliance defense under the ADA or any analogous statute.

Courts and enforcement bodies have repeatedly seen overlay installations as irrelevant to whether the underlying site is accessible. The standard is functional accessibility for users with disabilities — not whether a JavaScript widget is present. In settlements involving sites that had overlays installed, defendants were typically required to remediate the underlying code, not simply keep the overlay.

The litigation statistics are striking: approximately 25% of web accessibility lawsuits filed in 2024 targeted websites that had accessibility overlays already installed. These are not cases where a site had no accessibility investment — these are sites that paid for overlay products and were sued anyway.

The FTC Action Against accessiBe

In April 2025, the Federal Trade Commission fined accessiBe $1 million for deceptive advertising practices related to its accessibility overlay product. The FTC's complaint centered on accessiBe's marketing claims that its product could make websites fully WCAG-compliant and provide legal protection against ADA lawsuits.

The FTC found these claims to be false and misleading. The $1 million fine and accompanying consent decree required accessiBe to stop making specific compliance and legal-protection claims that the FTC determined were unsubstantiated.

This is a significant enforcement moment. The FTC action is not an accessibility lawsuit brought by a disabled plaintiff — it is a federal agency finding that the core compliance promise made by overlay products constitutes deceptive advertising. The implication for organizations relying on overlays as their accessibility strategy: the legal shield the vendor sold you has been found by a federal regulator to be a misrepresentation.

UserWay and similar overlay providers make comparable claims in their marketing. While UserWay was not a party to the FTC action, the underlying regulatory principle applies broadly: claiming that a JavaScript overlay provides WCAG compliance or ADA legal protection is a claim that requires substantiation, and current evidence does not support it.

What Courts and Regulators Actually Look At

When a plaintiff or enforcement agency evaluates whether a site is accessible, the analysis focuses on whether users with disabilities can accomplish meaningful tasks:

• Can a screen reader user complete a purchase, fill out a form, or navigate to the information they need?
• Is the page navigable by keyboard alone?
• Does video content have accurate captions?
• Are form errors identified in a way that assistive technology can communicate to the user?

These questions cannot be answered by checking whether an overlay is installed. They require testing with actual assistive technologies — screen readers on the live site, keyboard-only navigation, and user testing with people who have disabilities.

An overlay that adds ARIA attributes programmatically but leaves the underlying interaction model broken does not change the functional answer to any of those questions.

What Real Compliance Requires

Source-level remediation — fixing accessibility issues in the actual code that renders your pages — is the only path to reliable compliance. This means:

Semantic HTML. Interactive elements should be native HTML elements (<button>, <a>, <input>) or properly implemented custom widgets with complete ARIA roles, states, and properties. Accessibility is easier to get right at authoring time than to patch at runtime.

Component-level testing. Each UI component — navigation, modals, dropdowns, forms, tables — should be tested with a screen reader and keyboard before it ships. Component-level testing with tools like jest-axe catches violations before they reach production.

CI-integrated scanning. Automated accessibility checks in your pull request pipeline prevent regressions from entering the codebase. Every new PR is a potential accessibility regression if nobody is checking.

Regular manual audits. Automated tools catch roughly 30–40% of WCAG failures. The rest require keyboard testing, screen reader testing, and human judgment. Quarterly or annual audits with a qualified evaluator are the standard for organizations serious about compliance.

Overlays can be a useful supplementary tool — the user preference toolbar, in particular, has value for some users. What they cannot do is substitute for the underlying work of building an accessible product. The legal record, the FTC action, and the lawsuit statistics all say the same thing: the compliance shortcut is not a shortcut at all.