Accessibility Overlays Don't Work: The Evidence and What to Do Instead

Accessibility overlays are JavaScript widgets added to a website that claim to automatically detect and fix accessibility issues. Products like accessiBe, UserWay, AudioEye, and EqualWeb are sold as ADA compliance solutions that can make any site compliant without touching the underlying code. More than 100,000 websites have installed them. Independent testing consistently shows they do not work as advertised — and in many cases make sites less accessible.

What the research shows

The Overlay Fact Sheet (overlayFactSheet.com), signed by over 800 accessibility professionals, documents specific, tested failures. Key findings from independent audits:

• Overlays introduce new WCAG failures that did not exist before installation
• They conflict with user-configured assistive technology settings — AT users often find overlay-modified content harder to use than the original broken version
• They cannot fix semantic HTML issues, missing ARIA relationships, or broken keyboard patterns because they run after the DOM is rendered
• Many overlays add their own controls (accessibility menu buttons) that are themselves inaccessible via keyboard
• Screen reader users frequently report that overlays interfere with JAWS and NVDA's ability to read page content

Why overlays have been named in lawsuits

Multiple ADA lawsuits have named overlay vendors or companies using overlays as defendants — including a class action against accessiBe filed in 2021. The legal argument: an overlay does not bring a site into compliance, and a company that relies on an overlay to satisfy ADA requirements has not actually made good-faith efforts to comply. Courts have not been sympathetic to the defense that 'we installed a widget.'

The fundamental technical problem

Overlays work by injecting JavaScript that attempts to modify the page's DOM after it loads. This approach has a structural limitation: it cannot fix problems that exist in the server-rendered HTML. Missing label associations, incorrect heading structure, broken keyboard navigation patterns, and inaccessible custom components all require fixes in the actual source code. A script running after the fact cannot reliably fix what the underlying HTML never had.

What actually works

• Fix accessibility issues in your source code — the only approach that produces reliable, assistive-technology-compatible results
• Integrate automated testing (axe-core) into your CI/CD pipeline to catch regressions
• Conduct regular manual audits with real screen readers — at minimum annually, and after major feature releases
• Train your development team — accessibility issues are easiest and cheapest to fix at authorship
• Establish an accessibility feedback channel so users can report barriers directly

If you have already installed an overlay

Remove it. It is not providing compliance coverage, it may be actively harming screen reader users, and it will not protect you in litigation. Use the money you were paying in overlay subscription fees to fund a real accessibility audit and remediation sprint. The audit will identify what actually needs fixing. The overlay was hiding that from you.