Why accessibility overlays are rejected by the people they claim to help
A widget that promises to make your store accessible in one line of JavaScript is the most appealing product in this category, and the most widely condemned by blind and disabled users. It is worth understanding why before you install one.
What an overlay actually is
An overlay is a script you paste into your theme. When a page loads, it runs in the visitor's browser, inspects the page, and tries to work out what is wrong — this button has no label, this image has no description, this contrast is too low — and patches it on the spot. Most also add a floating button that opens a menu of toggles: larger text, higher contrast, a "screen reader mode".
The pitch is genuinely attractive. One line of code, no developer, no theme surgery, and a visible badge suggesting something has been handled.
The objection is not that they are imperfect. It is that they interfere.
The people who object loudest to overlays are the people they are sold as helping. Blind and low-vision users have organised against them, and the reasoning is worth understanding because it is not "they only fix some things".
Screen reader users already have a screen reader
Someone who is blind arrives at your store with JAWS, NVDA or VoiceOver already running, tuned to their preferences, and years of muscle memory in it. An overlay that adds a "screen reader mode" is not adding a capability they lacked — it is a second piece of software trying to mediate a page that their own software was already reading. When the two disagree, the visitor loses.
The guesses are guesses
An overlay deciding at page load what an unlabelled icon button does is inferring from class names, nearby text and heuristics. When it infers correctly, a shopper hears something useful. When it infers wrongly, a shopper hears something confidently incorrect — which is worse than hearing nothing, because "button" signals a gap the visitor can work around, and "Add to wishlist" on a delete control does not.
Nothing is verified
The patch happens in the visitor's browser, at the moment of loading, and nobody checks whether it worked. There is no re-test, no before-and-after, no record. The merchant sees a badge; the shopper sees whatever happened.
It is rented, not fixed
Remove the script and every "fix" disappears, because nothing about the site changed. A year of payments leaves the store exactly as accessible as the day you started. That is not an accident of the technology — it is the business model.
What regulators have said
In 2025 the US Federal Trade Commission fined the overlay vendor accessiBe $1 million. The action was not about the technology being ineffective in the abstract. It was about marketing claims — telling merchants the product made their websites compliant when it did not.
That distinction matters for anyone evaluating this category. The legal exposure did not come from patching a page. It came from what was promised about the result. An overlay vendor and a merchant repeating the vendor's claims are making the same claim.
The part where we admit our own overlap
Remedy is an accessibility app that changes how your storefront renders. It would be disingenuous to attack a category we sit next to without saying exactly where the line is, so:
| Typical overlay | Remedy | |
|---|---|---|
| When the decision is made | In the visitor's browser, at page load | In advance, from a scan of your store |
| How the decision is made | Heuristics, live | Computed per element, then re-tested |
| Verification | None | Re-run the same test; discard anything that fails or causes a new issue |
| Alt text | Injected at runtime, disappears with the script | Written into your Shopify product data, stays if you uninstall |
| Widget on your storefront | Usually | None |
| What you are told about the result | Often a compliance claim | Counts against named criteria, and what is still open |
The honest summary: Remedy corrects a narrower set of things than an overlay claims to, tells you what it could not do, and never says the word an overlay is sold on. Whether that trade is worth it is your call, and it should be — but you should make it knowing the trade exists.
How to evaluate any tool in this category
Four questions. They are uncomfortable ones, and they should be asked of us too.
- Does it claim my site will be compliant? If yes, that is the exact claim the FTC fined. Nothing more needs asking.
- Does it check whether its own fixes worked? Ask specifically: is the page re-tested after the change, and what happens to a fix that fails? "It applies best practices" is not an answer.
- What happens when I uninstall? If everything reverts, you were renting a symptom. Some reversion is honest — corrections served by an app block should stop — but anything written into your own data should stay yours.
- What does it admit it cannot do? A tool that has no list of its own limits has not looked for them. Roughly half of what a scan finds on a typical Shopify store needs a markup change no external tool can safely make.
What to do instead
Fix the mechanical failures properly — contrast, alt text, target sizes are arithmetic and data, not judgement. Get a person to test the things a machine cannot: keyboard-only checkout, a screen reader through a real purchase, form error messages. Keep a dated record of both.
That is slower than a line of JavaScript. It is also the only version that leaves your store actually easier to use.
How Remedy works Scan your store free
Remedy reports what automated testing can measure. It does not assess your store against any legal standard and does not provide legal advice.
Related
What the European Accessibility Act actually requires of a Shopify store