The pitch is hard to resist. Install one line of code, and your website becomes accessible overnight. No audit, no developer time, no remediation. Just a small widget in the corner of your site and a promise that you are now covered.
We understand why organizations buy this. Accessibility feels complicated and the legal pressure is serious, so a one-click fix sounds like exactly what a busy team needs. But the truth is, accessibility overlays cannot deliver what they promise. In some cases, they make things worse for the very people they claim to help, and they will not protect you if someone files a complaint. So, let’s break down what overlays actually are, why they structurally cannot work and what actual accessibility looks like instead.
What Is an Accessibility Overlay?
An accessibility overlay is a third-party JavaScript widget that loads on top of your existing website. It runs after your page has finished rendering, scans the page and tries to patch accessibility on the fly. It usually adds a small toolbar that lets visitors adjust contrast, change text size or turn off animations.
The key thing to understand is that an overlay does not touch your underlying code. The HTML, CSS and ARIA that make up your actual site stay exactly as they were. The overlay sits on top and attempts to compensate at runtime.
In other words: An overlay is a layer draped over your site, not a change to the site itself. This distinction is the root of every problem that follows.
What Overlays Promise vs. What They Deliver
The core promise of an overlay is that a single script equals an accessible site. That is where the whole idea falls apart, because accessibility is not something you can bolt on from the outside.
To be fair, overlays can do a few genuinely helpful things. They can increase text size, toggle a high-contrast mode and add a reading guide. These are conveniences for some users, and there is nothing wrong with offering them as an enhancement.
The problem is everything they cannot do. An overlay cannot:
- Add meaningful alt text to images in your source code
- Fix a broken or illogical heading structure
- Repair keyboard navigation that does not work
- Correct ARIA errors baked into your markup
Some overlays claim to solve these with AI. In practice, that AI is pattern-matching against common errors, not understanding the context or intent behind your content. It might generate alt text from a file name, which produces a description that is technically present — and completely useless. Recognizing that an image exists is not the same as knowing why it matters on the page.
Why Overlays Can’t Fix Inaccessible Code
Picture a landlord who repaints a unit before showing it instead of fixing what’s actually wrong. From the doorway, the place looks clean and move-in ready. But the tenant who has to live there still finds the sink leaking, the outlets dead, and the lights burnt out. Worse, the rushed paint job has sealed a window shut and covered a light switch. Accessibility overlays work the same way. They make a website look accessible to anyone glancing at it, while the people who actually depend on it still run the barriers that were never fixed in the underlying code, plus new ones the overlay itself created.
Real-World Problems Overlay Users Report
This is not a hypothetical concern. People who rely on assistive technology routinely turn overlays off because they make sites harder to use, not easier.
Screen readers and overlays frequently fight each other. The overlay tries to manage focus, and it conflicts with the screen reader’s own focus management. It injects ARIA attributes that break the page’s landmarks, so a user can no longer navigate by region. And the overlay’s own toolbar, the widget itself, is often not accessible, which means the tool marketed as an accessibility solution becomes one more barrier.
The disability community has been clear about this. The National Federation of the Blind passed a resolution in 2021 condemning overlay providers for making misleading and unproven claims about their technology. More than 1,000 accessibility professionals have signed an open letter at overlayfactsheet.com opposing the use of these widgets. It’s worth listening when the people a product claims to serve are the ones asking you to stop using it.
The Legal Reality: Overlays Don’t Protect You
Here is the part that should concern any organization navigating ADA or Section 508 exposure. An overlay is not a legal shield, and the data increasingly shows it can be a liability.
In 2025, roughly 27.7% of all ADA web accessibility lawsuits targeted sites that already had an overlay installed. Plaintiff attorneys have figured out that a widget is not evidence of compliance. Their automated scanners read the underlying HTML your server sends, not the runtime-patched version the overlay creates, making the overlay effectively invisible to the exact tools driving most complaints. In some courts, the presence of an overlay reads as awareness of a problem without genuine remediation, which is a worse position than having done nothing at all.
Regulators have taken notice too. In January 2025, the Federal Trade Commission fined accessiBe, a major overlay vendor, $1 million for misrepresenting what its widget could actually do for compliance. The vendors themselves know the limits: read the fine print and most disclaim any compliance guarantee in their own terms of service.
None of this is legal advice, and your specific situation deserves proper counsel. But the pattern is consistent enough to state plainly: courts have not accepted overlay use as evidence of good-faith compliance.
What Actual Accessibility Looks Like
Born Accessible, Kept Accessible.
“By embedding accessibility from the very beginning — through design, development, and procurement — organizations can ensure that technology is inclusive, efficient, and future-proof. This approach is not only about compliance; it’s about creating better experiences for everyone, reducing costs, and fostering innovation.”
“A Born-Accessible Approach to Technology Design”
by Jonathan Lazar, Kyle Shachmut et al
For years, disability rights and advocacy groups have consistently pushed for accessibility to be considered earlier in the process.
Born Accessible: to be accessible at implementation through the integration of development best practices that include accessibility during the design and development phase.
Accessibility should never be an afterthought. It should be baked into every stage of the site process.
- Accessibility-First Design: Upwards of 67% of accessibility issues can be prevented entirely through mindful, inclusive design.
- Audit/Test often: Evaluate your existing site against WCAG, using both automated tools and manual expert review, including keyboard and screen reader testing. Identify shortcomings early and plan the entire project around identified accessibility needs and technical requirements.
- Remediation. Fix the issues at the source, in the actual HTML, CSS and ARIA, so the page the browser receives already conforms.
- Testing with actual users. Nothing replaces feedback from people who use assistive technology every day. They will find what checklists miss.
- Ongoing monitoring. Accessibility is not a one-time project. Sites change, content gets added and new issues appear. Staying compliant means staying attentive.
This is also where documentation matters. A remediation log, an accessibility statement and a record of ongoing testing demonstrate genuine effort if your compliance is ever questioned. An overlay produces none of that.
The Bottom Line
Overlays were not born of bad intentions, and many organizations installed them in good faith after being told it was enough. But the promise does not match the architecture. You cannot fix inaccessible code from the outside; real users disable these tools because they get in the way, and courts have not treated them as a defense.
If you already have an overlay, the answer is not to panic and rip it out tomorrow. Removing it does not make your site more accessible either. The goal is to fix the underlying issues so your site actually works, and then decide whether the preference widget is still worth keeping as an enhancement.
Our view on AI in accessibility is the same as our view on AI everywhere: it should amplify real work, not pretend to replace it. AI can be a useful starting point for auditing and for drafting things like alt text, as long as a human stays in the loop. We will dig into exactly where AI helps and where it falls short in an upcoming post on AI-assisted auditing.
If you are not sure where your site stands, we are happy to help you find out. Reach out to learn more about our accessibility services.