Accessibility overlays vs code fixes: what actually changes for screen reader users

This guide explains how overlays work, what a runtime script can and can't repair, and what changes for a screen reader user when the theme itself is fixed. It sticks to how the technology works and to published facts. It doesn't rate individual products.

What an overlay is

The Overlay Fact Sheet, an open statement signed by accessibility practitioners, describes overlays as technologies that apply third-party code, typically JavaScript, to a website's front end to try to improve its accessibility. In practice they come in two parts, often sold together:

1. A toolbar or widget. A button, usually floating in a corner, opens settings such as bigger text, higher contrast, a dyslexia font, stopping animations or a "screen reader mode".
2. Automated repair. A script scans the page after it loads and tries to fix problems in the markup: guessing alt text for images, adding labels to fields, adding ARIA roles and attributes to elements.

On Shopify, both usually arrive as an app with an app embed, a single script tag in the theme.

What the toolbar does for screen reader users

Very little, by design. People who rely on a screen reader, magnification or high contrast already have those tools on their own device, set up the way they need them, and they work on every website. A toolbar on one store duplicates settings they already have, and it's another control to find and get past. The Fact Sheet also raises a privacy problem: overlays that switch on settings automatically do so by detecting assistive technology on the device, which reveals that the visitor has a disability.

What automated repair can and can't change

This is the part that matters. Here's a typical failure in a Shopify theme: color swatches built as <div>s.

<div class="swatches">
  <div class="swatch" data-value="Forest" style="background:#2f4a3a"></div>
  <div class="swatch" data-value="Slate" style="background:#4a5563"></div>
</div>

A screen reader user hears nothing useful here, and a keyboard user can't reach the swatches at all. A runtime repair script can patch attributes after the page loads, for example:

// The kind of patch a runtime script can apply (illustrative)
document.querySelectorAll('.swatch').forEach(function (el, i) {
  el.setAttribute('role', 'radio');
  el.setAttribute('tabindex', i === 0 ? '0' : '-1');
  el.setAttribute('aria-label', el.dataset.value || 'Color option');
});

Now each swatch is announced as a radio button with a name. That's an improvement, but it isn't a working control yet:

• State. A radio button must report whether it's selected (aria-checked), and that has to update every time the selection changes. The patch above doesn't know when the theme's own JavaScript changes the selection.
• Behavior. Radio buttons are operated with the arrow keys and Space (APG radio group pattern). Adding a role doesn't add those key handlers, and a generic script doesn't know what selecting "Slate" should do in this theme.
• Grouping. The options need a group with a name ("Color"), which the script has to infer.
• Guesswork. If the data-value attribute isn't there, the best a script can do is a generic label like "Color option".
• Re-rendering. Shopify themes often replace whole sections of the page with fresh HTML when a variant changes or an item is added to the cart, through the Section Rendering API. The new HTML arrives without the patched attributes until the script finds it and runs again.

The Fact Sheet lists the same limits in general terms: automated repair of alt text, of field labels, error handling and focus control, and of keyboard access isn't reliable, and interfaces that update themselves can change the page independently of the overlay. Its conclusion on standards is blunt: "full compliance cannot be achieved with an overlay."

The hardest problems on a store are behaviors, not attributes:

• a cart drawer that has to take focus, keep it, and give it back on close;
• a popup that has to close with Escape;
• an "added to cart" message that has to be announced at the right moment.

Those need code that understands the theme.

What a code fix changes

When the theme itself is fixed, the swatches look like this in the HTML your store sends:

<fieldset class="option">
  <legend>Color</legend>
  <input type="radio" class="visually-hidden" name="color" id="color-forest" value="Forest" checked>
  <label for="color-forest" class="swatch" style="background:#2f4a3a"><span class="visually-hidden">Forest</span></label>
  <input type="radio" class="visually-hidden" name="color" id="color-slate" value="Slate">
  <label for="color-slate" class="swatch" style="background:#4a5563"><span class="visually-hidden">Slate</span></label>
</fieldset>

For a screen reader user, the differences are concrete:

• It's there from the first byte. The role, name, group and state come from the HTML, before any script runs.
• The browser does the work. Native radio buttons get arrow-key behavior and selected state for free, and they report it consistently to VoiceOver, NVDA, TalkBack and JAWS.
• It survives updates. When Shopify re-renders the product section, the template produces the same accessible markup again. There's nothing to re-patch.
• Nothing is added on top. No toolbar, no extra announcements, no detection of assistive technology.
• It can be tested and retested. An auditor can check it, a developer can see it in version control, and it stays fixed until someone changes that template.

The full version, with Liquid and CSS, is in our accessible swatches guide.

What the public record says

• The FTC order. In April 2025 the FTC finalized an order requiring overlay vendor accessiBe to pay $1 million and barring it from claiming, without evidence, that its automated tool can make any website WCAG-compliant (FTC press release). accessiBe neither admitted nor denied the allegations.
• Lawsuits. Lawsuits tracked by UsableNet named companies that were using accessibility widgets more than 1,400 times in 2025 (UsableNet 2025 year-end report). That shows using a widget didn't stop those companies from being sued. It isn't legal advice, and it doesn't predict what happens to any one store.
• Automation in general. In April 2026 the US Justice Department wrote that generative AI "does not yet reliably automate the remediation of inaccessible content at scale" (DOJ interim final rule, 91 FR 20902).

If your store has an overlay today

You don't need to panic, and you don't need to rip it out before you know what's underneath.

1. Find out what's actually broken. Test the store with a keyboard and a screen reader, once with the overlay's settings untouched and once with the overlay disabled, so you can see what the theme itself does. A review that maps each issue to a theme file gives you a fix list.
2. Fix the theme code, starting with anything that blocks a purchase (see our Shopify accessibility checklist).
3. Remove the overlay. Uninstall the app, turn off its app embed in the theme editor, and check the theme for leftover script tags.
4. Retest the same journeys, so you have before and after evidence.

Sources

• Overlay Fact Sheet (open statement by accessibility practitioners)
• US Federal Trade Commission, FTC approves final order requiring accessiBe to pay $1 million (April 22, 2025)
• UsableNet, 2025 Year-End Digital Accessibility Lawsuit Report
• US Department of Justice, Interim final rule, 91 FR 20902 (April 20, 2026)
• W3C WAI, ARIA Authoring Practices Guide: Radio Group Pattern and Understanding 4.1.2 Name, Role, Value
• Shopify, Section Rendering API

Want to know what's broken under the widget? Our Accessibility Review covers your key templates with automated scans plus manual keyboard and screen reader testing, and gives you a prioritized issue list mapped to theme files. It's not a certified audit or a VPAT. If you want the fixes too, we make them in your theme on staging and show you the before and after. Ask about a review.