Skip to content

Overlays

The accessibility widget you’re considering doesn’t fix your site.

You’ve seen them — the little blue button in the corner of a website that pops open “accessibility options.” They’re sold as a one-line fix: paste a script, your site is “compliant.” Here’s the honest version of what they actually do, why they don’t work, and why the toolbar on this site is something different.

What an overlay widget is

An accessibility overlay is a piece of JavaScript you paste into your site’s code. It scans the page after it loads and tries to “fix” accessibility problems on the fly — adding alt text to images, adjusting contrast, adding keyboard shortcuts. The selling point is that you don’t have to touch your actual website. The promise is: one script, done.

It sounds great. It doesn’t work.

Why overlays don’t work

They sit on top of a site that’s still broken

The overlay runs after your page loads. The actual HTML — the code a screen reader hits first, the code Google crawls — is unchanged. A visitor using a screen reader encounters the broken page before the overlay ever runs. The fix is layered on top of the problem, not at the source.

They fight the tools they claim to help

Overlays inject their own controls, shortcuts, and DOM changes — which often conflict with the assistive technology a user is already running. Screen reader users report overlays hijacking their navigation, trapping focus, and breaking keyboard commands that worked before the overlay was there. The tool meant to help them becomes another barrier.

They can’t fix what they can’t see

An overlay can’t add a meaningful alt text to a photo it’s never seen. It can guess — “image of food” — but a generic guess isn’t accessibility. Real alt text is written by a person who knows what the photo shows. An overlay can’t fix a booking form that’s missing labels, because it doesn’t know what each field is for. The problems that require human judgment are the ones overlays can’t solve.

They’ve been named in lawsuits

Accessibility overlay products have been named as defendants in lawsuits and have received demand letters from advocacy organizations. The argument: a vendor that claims its product makes a site “compliant” while the underlying code remains inaccessible is selling a false promise. Using an overlay doesn’t reduce your legal exposure — in some cases it’s been cited as evidence that the owner knew the site had problems and chose a patch instead of a fix.

So why does this site have an accessibility toolbar?

Fair question — and it’s the one you should ask. The toolbar on this site (the blue button in the corner) looks like an overlay. Here’s the difference, and it’s the whole difference:

What it is
Overlay widget · A script pasted onto a broken site, trying to fix it after the fact
Remi · A comfort layer on a site that's already accessible — bigger text, more spacing, calmer colors
Does the site need it
Overlay widget · Yes — without it the site fails WCAG 2.2 AA
Remi · No — the site meets WCAG 2.2 AA without it. Every toggle defaults off
What it fixes
Overlay widget · Nothing at the source. The HTML is still broken
Remi · Nothing — there's nothing to fix. It adds personalization options on top of an already-working site
Screen readers
Overlay widget · Fights them — hijacks navigation, traps focus, conflicts with existing assistive tech
Remi · Works with them — the site is semantic HTML a screen reader can read natively, toolbar or not
Alt text
Overlay widget · Auto-generates generic guesses ('image of food')
Remi · Written by a person, enforced at the database level — you can't upload a photo without a real description
Legal exposure
Overlay widget · Has been named in lawsuits; may increase it
Remi · None — the site is accessible at the source, which is what the law points to

The short version: an overlay is a fix for a broken site. Our toolbar is a feature of a site that’s already fixed.The site works without it. The toolbar is there for people who want to personalize how it looks and reads — bigger text, higher contrast, a more legible font — the same way you might adjust your phone’s display settings. It adds comfort; it doesn’t patch problems.

What actually works

Accessibility isn’t something you add to a site. It’s something you build into it — in the HTML, in the CSS, in the content, in the code. The standard is WCAG 2.2 Level AA, and it’s the same standard the ADA points to. A site that meets it:

  • Uses semantic HTML — real headings, real lists, real labels — so a screen reader can navigate it natively.
  • Has alt text written by a person who knows what each photo shows, not a guess from a script.
  • Works with a keyboard alone — no mouse required, no keyboard traps.
  • Meets contrast ratios in its own design — not via a toggle that adjusts it after the fact.
  • Is kept that way — monitored and scanned so it doesn’t drift back.

That’s what Remi builds. Not an overlay — a site that’s accessible at the source, monitored nightly, with an editor that can’t reintroduce the common violations. The toolbar is a bonus, not a fix.

The bottom line

If your site is broken, an overlay doesn’t fix it. If your site works, you don’t need one.

Remi builds sites that work — accessible at the source, to WCAG 2.2 AA, monitored nightly. The toolbar is there because some people like bigger text or higher contrast, and that’s a good thing to offer. But the site is accessible without it, and that’s the part that matters.

Take online orders through Square and your whole site is free — $0/mo, no bill, ever. Dine-in only? A flat $99/mo, reservations included.

Industry context, not legal advice. WCAG 2.2 AA is published by the W3C and referenced by the ADA, Section 508, the European Accessibility Act, and the AODA.