The overlay fact sheet, verified: Our technical evidence for every claim

The accessibility community has warned about overlay tools for years. We intercepted production traffic from four overlays and mapped our findings to each claim in the Overlay Fact Sheet – providing the technical evidence behind every warning.

What is the overlay fact sheet?

The Overlay Fact Sheet is a community-driven statement signed by over 600 accessibility professionals – including contributors and editors for WCAG, ARIA, and HTML specifications, and internal accessibility experts from companies like Google, Microsoft, Apple, Shopify, eBay, and Target. It makes several specific claims about the limitations and risks of accessibility overlay tools.

Our research – 924 intercepted HTTP requests with 579 full response bodies across 14 live eCommerce sites, plus saved DOM snapshots with overlay modifications baked in – provides the first large-scale technical evidence base to verify each claim against actual production data. Here’s what we found.

Claim 1: “Overlays do not repair the underlying code”

The Overlay Fact Sheet states that overlays permit “temporary modifications to the user interface” rather than permanently fixing the source code.

Overlay A loads per-site JavaScript fix files containing 1,023 defineFix rules that use setAttribute, attr(), and hideFromAT() to modify DOM elements at runtime. If the overlay script is removed or fails to load, every fix disappears instantly – the underlying code is unchanged.

Overlay B downloads a 1.17 MB remediation JSON and applies fixes through a separate remediation engine. The fixes are keyed to specific image URLs – when the overlay is removed, all 5,068 alt text entries vanish. The images revert to having no alt text at all.

Overlay C ships a 794 KB monolithic bundle that modifies the DOM via 227 setAttribute calls, 82 role modifications, and 128 aria-label injections. None of these touch the server-side HTML.

Overlay D applies config-driven accessible names via a 649 KB engine with 216 setAttribute calls. The fixes exist only as long as the engine runs.

The monitoring tool, by contrast, doesn’t fix at all – it reports issues to a developer dashboard. Developers fix them in source code, where the fixes are permanent, tested, and deployed through normal CI/CD pipelines.

What happens when the overlay CDN goes down?

The Fact Sheet implies that overlay fixes are temporary. We can quantify exactly how temporary: if the CDN serving the overlay’s JavaScript goes offline, every fix disappears instantly. Our data shows the dependency chain:

Overlay A: The per-site active.js (up to 238 KB) loads from a single CDN. If that CDN is unreachable for even 30 seconds, every page load during that window receives zero accessibility fixes. The 1,023 fix rules, 35 modal focus traps, and all injected ARIA labels simply vanish.

Overlay B: The remediation engine depends on three external domains: a CDN for scripts, an API for tunings and configurations, and a separate CDN for the AI alt-text API. If any of these three goes down, different parts of the fix pipeline break – potentially leaving the DOM in a partially-mutated state where some fixes applied but others didn’t.

Overlay C: The entire overlay is a single 794 KB bundle from one domain. CDN outage = complete widget disappearance. But because the overlay’s MutationObserver was watching the DOM and modifying elements, a partial page load where the observer was initialized but the fix logic didn’t complete could leave the DOM in an inconsistent state.

The monitoring tool has zero CDN dependency for accessibility. If its CDN goes down, the only effect is that page-visit metrics stop being recorded. The site’s accessibility is unaffected because all fixes are in the source code – they don’t depend on any third-party script loading.

Claim 2: “Full compliance cannot be achieved with an overlay”

The Fact Sheet states that “these products’ documented inability to repair all possible issues means that they cannot bring a website into compliance.”

Specific compliance failures we documented:

WCAG 1.1.1 (Non-text Content): Overlay B generates AI alt text that fails the “equivalent purpose” test – a company logo described as “a blue and yellow sign,” a navigation icon described as “a simple black rectangle.” 241 entries were under 15 characters. 323 exceeded 125 characters.

WCAG 2.1.1 (Keyboard): Overlay A hides interactive elements from the accessibility tree, making them unreachable by keyboard. Payment buttons, cart controls, and search result links hidden by hideFromAT() cannot receive focus or be operated via keyboard.

WCAG 4.1.2 (Name, Role, Value): Overlay A injects aria-label="true" on 7 elements across 3 sites – a code bug where the accessible name is the meaningless string “true.” Overlay A also applies role="presentation" to 115 elements, stripping semantic meaning from tables, headings, and landmarks.

WCAG 1.3.1 (Info and Relationships): When role="presentation" is applied to a data table, screen readers can no longer navigate by rows and columns. The table structure disappears from the accessibility tree.

We mapped 776 of Overlay A’s fix rules to specific WCAG success criteria. The breakdown reveals the paradox of overlay compliance:

The most alarming row is WCAG 1.1.1 (Non-text Content): of 108 fix rules targeting this criterion, 80 are harmful – 52 hide images from AT entirely via hideFromAT(), and 28 mark content images as decorative via alt="". The overlay is making non-text content less accessible, not more. This is the exact opposite of what WCAG 1.1.1 requires.

The U.S. Federal Trade Commission confirmed this finding when it fined one overlay vendor $1 million in April 2025, stating the tool “fails or has failed to make basic and essential website components like menus, headings, tables, images, recordings, and more, compliant with WCAG.”

Claim 3: “Overlays can create new accessibility barriers”

The Fact Sheet warns that overlay products can “actively get in the way of people with disabilities.”

The most damaging examples occur in checkout and cart flows:

In one luxury retailer, Amazon Pay, Shop Pay, and Klarna buttons are hidden from assistive technology. A blind user at checkout sees fewer payment options than a sighted user. Cart quantity inputs and update buttons are hidden on a fashion retailer – a blind user cannot adjust their order.

Product search result links are hidden on two sites – blind users’ product discovery is impaired. Star ratings are hidden – blind users cannot assess product quality the same way sighted users can.

Germany’s federal monitoring body (BFIT-Bund) confirmed this pattern in its official joint assessment: “It frequently occurs that the use of such tools creates additional barriers in the website that would not have existed without the tool.”

Claim 4: “Users will already have the tools they need”

The Fact Sheet argues that “the end users that these features claim to serve will already have the necessary features on their computer.”

When a screen reader user has configured their keyboard shortcuts and navigation preferences, an overlay that intercepts keydown, keyup, and keypress events can override those preferences. Overlay C’s 47 keyboard event references in its 794 KB bundle represent a substantial keyboard interception surface. Overlay D’s engine contains 282 addEventListener registrations – any of which could conflict with assistive technology event handlers.

Claim 5: Overlay widgets’ “practical value is largely overstated”

The Fact Sheet states that widget features like contrast and text-size controls provide limited value because users already have system-level equivalents.

Overlay B’s worst single page generated 48 requests consuming 12.8 seconds of network time. For context, Google’s Core Web Vitals threshold for “poor” Largest Contentful Paint is 2.5 seconds. The overlay alone exceeded that budget by 5×.

Overlay A spent 75% of its 33.9 seconds of network time on behavioral analytics – 58 tracking POSTs to its own endpoint. The accessibility-related CDN requests consumed only 25% of the total time. The majority of the performance cost is vendor data collection, not accessibility improvement.

Claim 6: “Site owners should use more robust, independent, and permanent strategies”

The Fact Sheet advocates “the removal of web accessibility overlay” in favor of permanent accessibility strategies.

The fundamental divide our data reveals is architectural: overlays maintain a parallel set of fix definitions that mirror the site’s DOM structure and go stale on every deployment. A monitoring tool scans whatever DOM exists at scan time, reports what it finds, and starts fresh on the next scan. There is no accumulated technical debt, no stale selectors, no orphaned alt text entries, and no possibility of applying the wrong fix to the wrong element.

Beyond the Fact Sheet: What Our Data Adds

Our research uncovered findings that go beyond the Overlay Fact Sheet’s scope:

PCI DSS 4.0 conflict: Overlay fix rules actively target payment-page elements – we documented selectors for #cardNumber, #billingState, payment buttons, and checkout forms. Under PCI DSS Requirement 6.4.3 (mandatory since March 2025), every payment-page script requires documented authorization and integrity verification. Overlays fail this requirement. On one luxury goods group, identical payment-targeting selectors are shared across two brand sites (96% codebase overlap), doubling the blast radius of any supply chain compromise.

Scan sampling rates as low as 1.7%: We discovered that one overlay’s analytics POST data contains a samplingRate field showing only 1.7–4.5% of sessions trigger a compliance scan. The remaining 95–98% receive DOM fixes without any verification.

GDPR violations: Three overlays send user identifiers, device fingerprinting data, and behavioral analytics before any consent mechanism can activate – automatic non-compliance under the CJEU’s Planet49 ruling. One overlay sends a persistent UUID identical across all page loads, enabling complete cross-page browsing profiles.

German regulatory rejection: The BFIT-Bund (Germany’s federal monitoring body) officially rejected overlays for compliance testing, and BIK testing bodies refuse to issue compliance seals to websites using overlays. Under Germany’s BFSG (EAA transposition), fines range from €10,000–€100,000 per violation.

Runtime form label injection that makes forms worse: One overlay’s remediation engine (110 KB) runs 24 DOM mutation rules at runtime, including an EmptyControls handler that attempts to label unlabeled form fields. On a live contact form with seven fields, the engine injected aria-label values derived from the HTML name attribute rather than the visible labels – resulting in two fields sharing the identical label “Name” (from name="first-name" and name="last-name"), three fields labeled with generic element types (“Text field”, “Single select”, “Text area”), and two using validation-type descriptions instead of the actual visible label. The saved DOM snapshot confirms every modified element carries the overlay’s vendor-specific data attribute marker. The original HTML had correct visible labels (“First Name”, “Company Name”, etc.) but they lacked for attributes – a straightforward fix in source code that the overlay’s runtime engine failed to replicate correctly.

Remediation JSON contaminated with foreign domain content: One overlay’s pre-built remediation JSON for a banking site contained 7 alt text entries – of which only 1 was actually from the bank’s own domain (with an alt text of a single space). The remaining 6 entries described images from completely unrelated domains: a Polish accessibility testing tool (ANDI bookmarklet icons), a Chinese price comparison API (chat widget icons), a Russian teaser advertising network (ad creative), and Xiaomi’s browser CDN (translation prompt UI). The overlay’s scanner had captured these during a previous session where the person browsing had third-party browser extensions and ad injections active – and permanently stored the AI-generated descriptions in the bank’s remediation file, downloaded by every visitor on every page. The JSON is publicly accessible on the overlay’s CDN with no authentication.

The Overlay Fact Sheet’s warnings, written by accessibility professionals based on their experience, are now substantiated by intercepted production data from 14 live eCommerce sites. Every major claim holds up – and the reality, in several areas, is worse than the Fact Sheet describes.

Claim 7: “Overlays undermine legitimate accessibility efforts”

The Overlay False Claims documentation warns that overlays create a “false narrative that accessibility is solved” and are “antithetical to the underpinnings of the ADA.”

The deeper problem is that overlays shift the mental model from “we need to build accessible products” to “we installed a widget that handles accessibility.” Our data shows what this looks like in practice: one designer handbag retailer has 383 fix rules in its overlay – but the underlying HTML still has every original accessibility issue. If the overlay vendor’s CDN goes down for 30 minutes, every barrier returns instantly. The site was never truly fixed.

Claim 8: Privacy and tracking concerns

While not a primary focus of the Overlay Fact Sheet, privacy concerns have been raised by disability advocates who note that overlays can detect assistive technology usage.

Overlay A: 58 analytics POST requests per session to its own endpoint, each containing a session ID (sid), full page URL (pg), page load ID (plid), device category, and event type. 75% of its total network time is spent on these tracking calls.

Overlay B: A persistent UUID (uid) sent in every tunings POST – the same identifier across all pages in the session, enabling the vendor to build a complete browsing profile. The UUID is the same – we observed it unchanged across all five pages of one telecom site.

Overlay C: USER-BEHAVIOR-ANALYTICS POST data including domain, widget version, and interaction events. Device fingerprinting via navigator.userAgent, navigator.userAgentData, and navigator.maxTouchPoints. Three localStorage keys persisting state across sessions.

All three fire their tracking on page load – before any consent mechanism can activate. Under the CJEU Planet49 ruling, non-essential tracking requires prior opt-in consent. These overlays are in automatic GDPR non-compliance on every EU-facing site.

Claim 9: “Overlays carry legal risk”

The Fact Sheet notes that overlays cannot “eliminate legal risk” despite vendor claims.

Our court case database (8,541 ADA case files) contains direct litigation involving overlay vendors: three patent/trade secret cases between two vendors (2020–2022), a class action by a customer against one vendor (2024), and an active lawsuit against another vendor by a small business that was sued despite using the overlay (2024, motion to dismiss denied by magistrate in 2026).

The monitoring tool has no litigation history related to accessibility failures – a logical consequence: because it doesn’t modify the DOM, it cannot introduce the barriers that trigger lawsuits.

The еvidence gap is now closed

For years, the overlay fact sheet and the accessibility community’s warnings about overlays were based on professional experience, user reports, and manual testing. Critics could dismiss them as anecdotal or biased. Our research closes that gap by providing the first large-scale technical evidence base: intercepted production data from 924 network requests, 579 extracted source files across 14 live eCommerce sites over three independent capture sessions, supplemented by saved DOM snapshots that preserve the exact runtime modifications overlays inject into production pages.

Every major claim in the Overlay Fact Sheet is supported by our data. Several claims are understated relative to what we found. And the areas the Fact Sheet doesn’t cover – PCI DSS conflicts, scan sampling rates, GDPR pre-consent tracking, German regulatory rejection – represent additional risk dimensions that the accessibility community identified through experience but could not previously quantify.

The evidence is in the code. The code is in the intercepted traffic. The traffic is from production sites serving real customers. The findings speak for themselves.