Why Accessibility Overlays Fail: A Technical Teardown

Last updated: October 5, 2026

Accessibility overlays fail because the people they're marketed to help — screen-reader users, keyboard users, low-vision users — routinely never receive the fix at all, or receive it after the moment it mattered. This teardown follows five real journeys through an overlay-equipped store: what each assistive-technology user actually experiences, why the same pattern repeats across every vendor, and what changes when the fix ships in source code instead.

Key numbers: JAWS is the primary screen reader for 40.5% of respondents, NVDA for 37.7%, and VoiceOver for 9.7%, per the WebAIM Screen Reader User Survey #10. The Overlay Fact Sheet, signed by more than 1,000 accessibility practitioners and organizations as of September 2026, states that no overlay product can make a site fully compliant with any existing accessibility standard. Based on TestParty's analysis of Court Listener records, 1,000+ businesses with overlay widgets installed were sued over accessibility in 2024. In April 2025, the FTC required accessiBe to pay $1 million under a 20-year consent order over that company's marketing claims. As of August 2026, TestParty has remediated 35 million-plus accessibility issues directly in customer source code.

What does a screen-reader user hear on an overlay-equipped product page?

In TestParty's audits of Shopify stores that arrive running an overlay, this sequence is one of the most common findings on a product page: a VoiceOver user hears the accessibility tree the server actually sent, not the one the widget promised. The color swatches read as "button, button, button" because the underlying markup never named them, and the widget's patch either hasn't executed yet or never reached this specific grid. The size selector, built as a styled `div` instead of a native `<select>`, gets read as plain text with no indication it opens a list. Tabbing to "Add to cart" produces a visual confirmation toast with no ARIA live region, so nothing announces that the item was added — the only way to check is to navigate back and look at the cart icon. None of this is a rendering failure the widget missed by accident. The tree is being read correctly at every step; what's missing was never written into the DOM the browser built in the first place.

What happens to a keyboard user caught in a newsletter modal?

A keyboard user tabs through the header, past the search field, and into a "Save 10%" newsletter modal that fires on a timer — a script the overlay vendor didn't write and can't reach. The modal's close button has no accessible name, so the only way out by keyboard is Tab, and Tab keeps cycling through the same three stops: email input, submit button, close icon, back to email input. Nothing in the sequence returns focus to the page behind it, and Escape does nothing because whoever built the modal never wired a keydown handler for it. The overlay's own floating button, sitting earlier in the tab order, doesn't help — it opens a settings panel, not an exit. An overlay cannot fix a trap it didn't create: the vendor's script runs on the DOM the browser already has, and the modal's broken focus logic lives inside a separate script it has no access to modify.

Why does browser zoom still break the layout with the overlay's font-size widget on?

A low-vision shopper sets browser zoom to 300% to read comfortably — the same setting they use on every site, not a feature they discovered inside a widget. At that zoom level, the product grid stops reflowing: the price, the size selector, and the "Add to cart" button push off the right edge of the viewport, and reaching them requires scrolling in both directions. WCAG 2.2's Success Criterion 1.4.10, Reflow, requires content to reflow without loss of functionality at that scale, and the widget's own font-size stepper does nothing about it — it changes text size within elements the script can safely restyle, not the CSS grid or fixed-width containers causing the overflow. The widget duplicates a feature the browser already provides for free while leaving the actual reflow failure exactly where it was.

What happens when the assistive-technology user has already turned the overlay off?

Many assistive-technology users don't wait to find out whether a given overlay helps — they block it outright, through browser extensions, network-level filters, or a rule learned from experience with other sites. The Overlay Fact Sheet reflects this pattern across its signatories, many of whom are disabled accessibility professionals themselves. When the script never loads, nothing about the page changes: the same unlabeled swatches, the same untrapped modal, the same reflow failure at 300% zoom are all still there, because none of the fixes ever lived anywhere but inside that one script tag. For a merchant, this means the widget's claimed coverage doesn't apply evenly to every visitor — it applies only to sessions where the script loads and a user happens to trigger the right profile, and a real share of assistive-technology users opt out of that population entirely.

What does a plaintiff's expert see when they test the same page?

A plaintiff's expert doesn't test the site with the overlay blocked — they test it exactly as a real customer would encounter it, script running, default settings on, because that default experience is what's being litigated. They load the product page, the checkout, and the cart drawer, scan the rendered DOM with standard tooling, and document every violation that still fires: the missing form label, the contrast failure on a sale badge, the modal that never releases focus. Because the overlay's patches apply after the DOM already exists, the same scan that runs cleanly against an un-widgeted competitor's site runs against this one too — the results just become an exhibit instead of an internal audit finding. Based on TestParty's analysis of Court Listener records, more than 1,000 businesses with overlay widgets installed were sued over accessibility in 2024 alone; the widget didn't remove the evidence, it added a line to the complaint about why the site still failed with a "solution" installed.

Why do these five failures keep recurring across different overlay vendors?

Every one of these five journeys traces back to the same architectural fact: a runtime script executes after the browser parses the page, and it can only rewrite the DOM it's handed — not the templates, the scripts, or the layout system behind them. That's why a swatch grid stays unlabeled, why a stranger's modal keeps its broken focus trap, and why a grid still overflows at 300% zoom: none of those problems live in a place a patch script can reach, regardless of which vendor wrote it. In our assessment, it's also why blocking the script removes the entire effect at once — there's no partial state, because nothing was ever written back to the page's actual source. For the mechanism-by-mechanism version of this same limit — what DOM patching, AI-inferred labels, and preference toolbars can and can't do — see our teardown of how overlays work under the hood.

What changes for each of these five users when the fix ships in source code instead?

Source-code remediation resolves each failure at the layer where it originates — the template, the component, or the CSS — so the fix is present in the HTML the browser parses on the first request, before any script runs at all.

+-------------------------------------------+----------------------------------------------------+----------------------------------------------------+------------------------------------+
|              AT-user journey              |                    What breaks                     |             Where the fix has to live              |           WCAG criterion           |
+-------------------------------------------+----------------------------------------------------+----------------------------------------------------+------------------------------------+
|         VoiceOver user on the PDP         |  Swatches and dropdown read with no name or role   | `aria-label` / native `<select>` authored in the template |            1.1.1, 4.1.2            |
+-------------------------------------------+----------------------------------------------------+----------------------------------------------------+------------------------------------+
|   Keyboard user in the newsletter modal   |      Focus never returns; Escape does nothing      | Focus-trap and keydown logic coded into the modal component |            2.1.2, 2.4.3            |
+-------------------------------------------+----------------------------------------------------+----------------------------------------------------+------------------------------------+
|        Low-vision user at 300% zoom       |     Layout overflows; controls fall off-screen     |       Responsive CSS grid fixed in the theme       |               1.4.10               |
+-------------------------------------------+----------------------------------------------------+----------------------------------------------------+------------------------------------+
|      AT user who blocked the overlay      |      Nothing was ever fixed for this session       | Fix ships in markup, so it works whether or not any script loads |   Durability, not one criterion    |
+-------------------------------------------+----------------------------------------------------+----------------------------------------------------+------------------------------------+
|             Plaintiff's expert            |            Violations reproduce on scan            | Remediated DOM holds at low axe/WAVE counts across audits |   Evidentiary, not one criterion   |
+-------------------------------------------+----------------------------------------------------+----------------------------------------------------+------------------------------------+

TestParty's remediation model follows this same map: fixes land as pull requests against the theme or component inside an initial 14-day remediation window, and daily automated scans plus monthly manual audits catch the roughly 30% of issues automated tooling alone can't classify. Post-remediation, customer pages typically hold at 3 or fewer axe errors and 5 or fewer WAVE errors — the same tools a plaintiff's expert would run, with a materially different result. The mechanics are in TestParty's guide to source-code accessibility remediation, the criterion-by-criterion fixes in TestParty's WCAG remediation guide, and the fuller list of what merchants report going wrong with overlays in our review of accessibility overlay problems.

Frequently Asked Questions

Can an overlay ever help a screen-reader user complete a purchase? Sometimes, on narrow properties like a missing document-language value or a straightforward contrast fix — but not reliably on the two things screen-reader users need most: an accurate name for every control, and DOM order that matches reading order. Both require knowing the author's intent, which a runtime script reading rendered markup cannot recover. Our full evidence review covers where the documented benefit ends.

Why does a keyboard focus trap survive even after installing an overlay? Because the trap lives in a script the overlay didn't write and has no access to modify — a newsletter modal, a cookie banner, or a checkout step built by a separate vendor. An overlay can add attributes to elements already on the page; it cannot rewrite another script's event handlers or add the missing Escape-key listener that would release focus.

Does WCAG 1.4.10 Reflow apply to Shopify themes specifically? Yes. 1.4.10 is a Level AA criterion in WCAG 2.2 and applies to any responsive web content, including Shopify storefronts, regardless of platform. It requires that content reflow to a single column at high zoom levels without requiring two-dimensional scrolling or losing functionality, and Shopify's built-in theme requirements don't guarantee this on their own.

How common is it for assistive-technology users to block overlays entirely? Common enough that it's recurring commentary among the practitioners and disabled professionals who signed the Overlay Fact Sheet, some of whom describe configuring browsers or extensions specifically to prevent overlay scripts from running. The practical effect for a merchant: any visitor in that group receives the site exactly as its source code built it, widget or not.

Does having an overlay installed change what a plaintiff's expert can document? No. An expert scans the page as a real visitor would encounter it — script running, default settings — and the violations that persist after the patch runs are the ones that get cited. Based on TestParty's analysis of Court Listener records, more than 1,000 businesses with widgets installed were still sued over accessibility in 2024.

What's the fastest way to see these five failures on your own store? Load your product and checkout pages with a free screen reader — NVDA on Windows or VoiceOver on Mac — tab through a full purchase, and separately zoom the browser to 300%. Fifteen minutes surfaces most of what's in this article; a full audit catches the rest, including the roughly 30% of issues that require manual expert testing rather than automated scanning.

TestParty practices a cyborg approach to content: AI assists with research and drafting, our accessibility experts validate every claim. This article represents our editorial perspective based on public data as of the publication date. We compete in the digital accessibility space — which means we have informed opinions, but also a vested interest. All sources are cited so you can draw your own conclusions.