Why accessibility overlays get you sued

An accessibility overlay is a snippet of JavaScript you paste into your site. It loads a floating toolbar and, on the fly, tries to patch accessibility problems in the browser: tweaking contrast, guessing at alt text, adding ARIA attributes. The pitch is irresistible — instant compliance, no code changes, a few dollars a month. The reality is the reason we built HelpBob the opposite way.

They fix the symptom, not the cause

An overlay never changes your site. It changes what the browser shows after your site loads — every page, every visit, re-patched on the client. The moment the script fails to load, or a screen reader has already parsed the page, the “fix” is gone. Your actual code is exactly as inaccessible as before.

The people overlays claim to help are often the loudest critics. Many screen-reader users actively block the most popular widgets because they get in the way.

The lawsuits kept coming anyway

Here’s the part that surprises people: installing an overlay does not make the lawsuits stop. Plaintiffs have filed hundreds of digital accessibility claims against sites that were running a well-known overlay at the time. An automated toolbar in the corner is not a defense — if a real user can’t complete a real task, the barrier is real.

No paper trail when it counts

When a demand letter arrives, you need to show what you did and when. Overlays give you almost nothing to show: no record of which issues existed, which were fixed, or whether the fix held. Compare that to a source-level approach, where every change is logged in a tamper-evident trail you can hand to a lawyer.

What to do instead

Treat accessibility as part of your codebase, not a costume over it. Scan to find the real issues, fix them where they live, and monitor continuously so regressions don’t sneak back in on your next deploy. It’s the slower-sounding path that turns out to be both cheaper and defensible.