That accessibility widget in the corner of your site isn't protecting you

Somebody is probably trying to sell you a widget right now. One line of code, dropped into your site, and a little icon appears in the corner — click it, and a panel offers to enlarge text, boost contrast, pause animations, maybe read the page aloud. The pitch is instant legal compliance for visitors with disabilities, no redesign required, problem solved before lunch. It is one of the fastest-growing purchases in web design, and it is close to useless for the thing it claims to do.

Start with what these tools actually touch. This kind of add-on — usually called an accessibility overlay — runs after your page has already finished loading, layering visual tweaks on top of a page that was never built with accessibility in mind to begin with. It can make text bigger. It cannot describe a photo to someone using a screen reader — software that reads a webpage aloud to a visitor who is blind or has low vision — if that photo was never given a description when the page was built. It can raise the contrast on a colour it recognises as text. It cannot fix a form box with no label attached, a button that announces itself as nothing more than "clickable," or a pop-up that traps a keyboard user inside it with no way out. Those are problems baked into the page's underlying code, and a script running in the visitor's browser afterwards cannot rewrite code that was already sent to them.

The people these widgets are supposedly built for are often their harshest critics — not despite relying on screen readers every day, but because of it. An overlay frequently interrupts how a screen reader normally works, to insert its own controls instead, and when that interruption goes wrong it can leave a visitor worse off than if the widget had never been installed at all. Search online for what screen-reader users say about these overlays, and you will find years of first-hand complaints describing exactly that. That is not a fringe opinion. It is the people the product claims to help, saying it frequently gets in their way.

Then there is the legal worry, which is the actual reason most businesses buy one of these — not civic duty, but because a demand letter arrived, or someone warned them one might. Here the case for overlays is weaker than the sales pitch suggests. Several of the companies that sell these widgets have themselves been sued over how their own widgets behave. A tool bought specifically to avoid a lawsuit, that has separately ended up a defendant in that same kind of lawsuit, is not the shield it is marketed as. None of this is legal advice, and if a demand letter has actually shown up, that is a conversation for a lawyer, not a blog post — but "we installed the popular widget" is not the airtight defence it is sold as.

What actually works is less exciting and far more effective: building the page correctly in the first place. Structuring the page so a screen reader can tell a heading from a paragraph from a button, instead of guessing. Writing a short description for every photo that carries meaning, and skipping that description on purely decorative images. Labelling every form box so a visitor knows what it's asking for. Choosing colours with enough contrast between text and background from the start, not patching it in later. Making sure every clickable thing on the page can also be reached and used with just a keyboard, in an order that makes sense, with a visible outline showing where you are. Turning animations off for visitors who've told their device they'd rather not see constant movement. None of this is exotic or specialist. It is the accepted international standard for building accessible websites, and any competent build achieves it — it doesn't need to be bolted on afterward by someone else's script.

We went through exactly this exercise on this site, not as a hypothetical. A full accessibility review turned up real problems: two colours that looked fine to the eye but didn't actually have enough contrast to pass, background animations that ran forever with no way to stop them, and a flip-card element where what a screen reader announced didn't match what a sighted visitor actually saw on the same card. All of it got fixed directly in the code — a "skip to content" link for keyboard users, a clear outline that appears when you tab through the page, decorative elements hidden from screen readers so they don't clutter the experience, and every animation respecting a visitor's request for less motion. No widget was involved, because a widget could not have found or fixed a single one of those problems — they lived in places a corner-of-the-screen script never reaches.

None of which means every accessibility feature you can buy is worthless — the distinction is where the work actually happens. A genuine text-size or high-contrast toggle that a developer builds and tests against the real page is a real feature. What fails is the promise that one universal script can retrofit accessibility onto a site that was never built with it in mind, without anyone actually opening up the code. Accessibility isn't a coat of paint you apply after the fact. It's a property of how the page was built in the first place — the same way a building is only wheelchair-accessible if the ramp was poured into the concrete, not propped up afterward as a loose wooden board.

If you already have one of these widgets installed and are wondering whether to remove it: the honest answer is that it depends entirely on what's underneath it — which is exactly the part it was never able to fix. Getting a real answer means an actual review: a person, or a proper testing tool, checking the page itself, not the marketing copy on the widget's own website. That's worth doing before a demand letter forces the question, not after — fixing it ahead of time is dramatically cheaper than responding to a legal complaint, and it's also simply more likely to work for the people it's meant to help.