The Accessibility Overlay Trap — Why the Widget Won't Save You

There’s a product category that exists because of a wish. The wish goes like this: my website probably has accessibility problems, I don’t want to touch my code, and I would like the problems to go away for a monthly fee. The products that grant this wish are called overlays. You paste one script tag into your site, a little widget appears in the corner, and a badge assures visitors the site is now accessible. I understand why people buy this. I want to explain why it doesn’t deliver what they think they’re buying.

Start with what an overlay actually is. It’s JavaScript that runs in the visitor’s browser after your page loads. It can do two kinds of things. It can offer a control panel of adjustments: bigger text, higher contrast, a reading mask, paused animations. And it can try to repair your page on the fly, guessing descriptions for images that lack them, guessing labels for buttons that don’t say what they do. The control panel is the part you see in the demo. The guessing is the part doing the compliance work you’re paying for.

The control panel has a quiet flaw: the people it’s meant for mostly don’t need it, because they already have better versions of those tools. A blind visitor arrives with a screen reader they’ve used for years. A low-vision visitor already has the whole operating system zoomed, or a high-contrast mode enabled globally, so it works on every site, not just yours. These tools are configured to their needs and driven by muscle memory. A widget that offers its own font-size buttons on your site alone is like a restaurant proudly offering wheelchairs at the door of a building with stairs. The visitor has a wheelchair. What they need is a ramp.

The repair half has a deeper flaw: the hard problems can’t be fixed from the outside. If your photo has no text description, software can guess at the pixels, but it can’t know what the image means in your context, and the meaning is the whole point. A picture of a person at a laptop might be decoration, or it might be your founder, or it might be the “click here to start” illustration, and each needs a different description, including possibly none. If your checkout is a pile of divs wired to click handlers, no script can reliably infer which ones are buttons, what they do, and what order keyboard focus should move through. These aren’t rendering problems. They’re missing information. The knowledge of what your interface means lives in your head and belongs in your markup, and no third party can inject knowledge it doesn’t have. When it guesses wrong, and it will, a blind user now hears a confident wrong answer instead of an honest silence, which is worse.

There’s also a stack of practical failure modes. An overlay is a script injected into a page it has never seen, rewriting the very attributes a screen reader depends on, sometimes fighting the user’s own assistive software for control. It adds another dependency, another thing that loads, another party with a script tag on your checkout page. And it changes nothing about the actual HTML you serve, which is what matters to anyone who evaluates your site seriously, whether that’s an auditor, a determined user, or a lawyer. I won’t wade into legal specifics, because I’m not a lawyer and the details vary, but the logic is available to anyone: if the underlying page is broken, a badge saying otherwise doesn’t repair it, and a claim of accessibility that a five-minute keyboard test can falsify is not a strong position to defend.

The frustrating thing is that the honest path is not even that much harder. Most accessibility problems on most sites are a modest list of concrete defects: images without descriptions, form fields without attached labels, text without enough contrast, pages that trap or lose keyboard focus, buttons that announce themselves as nothing. Each defect has a known, boring fix, usually a line or two of HTML. What people lack isn’t ability. It’s a list. The overlay is seductive precisely because it substitutes for the list: pay monthly and never find out what’s actually wrong. That’s the trap in one sentence. You’re not buying a fix. You’re buying not-knowing.

This shaped how I built GazeSite, and I’ll admit the overlay category is something I think about as a cautionary tale. The temptation in this business is to promise that software alone makes your site accessible. It doesn’t, and I don’t. What software can honestly do is look at your real pages the way a browser and a screen reader would, find the specific defects, and tell you the remedy for each, so a developer can fix the site itself. The output is a to-do list, not a badge. Less magical, admittedly. But when the work is done, it’s done in your HTML, where it survives audits, works with the tools your visitors already use, and doesn’t stop working the day you cancel a subscription.

Wishes are fine. But the wish behind the overlay, accessibility without ever looking at your own site, is the one wish no vendor can grant. Someone has to look. It should be you.