We intercepted every request from five accessibility tools. Here’s what they actually do to your site.

An independent technical audit of four accessibility overlays and one monitoring-only solution – what they actually change, what they hide from disabled users, and why over 1,000 companies using overlays were sued in 2024 alone.

How we did it: The research methodology

Most reviews of accessibility overlays rely on marketing claims, vendor documentation, or surface-level testing. We took a fundamentally different approach: we intercepted every byte of data flowing between the browser and each tool’s servers, extracted the actual JavaScript fix files and remediation data, and analyzed exactly what each tool does to the live DOM of production eCommerce websites.

The technical setup

We deployed mitmproxy – an open-source HTTPS proxy – configured to capture full request and response bodies for all traffic to the tools’ CDN and API domains. We installed the proxy’s root CA certificate in the browser to enable transparent HTTPS interception, then launched a dedicated Chrome instance routed exclusively through the proxy. We configured domain filters to capture only traffic to the accessibility tool servers – ensuring we analyzed only what these tools inject, not the sites’ own traffic.

We then browsed 14 live eCommerce sites as a normal user would: loading the homepage, navigating to product listing pages, viewing product detail pages, adding items to cart, proceeding to checkout, visiting account and registration pages, and interacting with modals, carousels, and search. Each browsing session was captured as an HTTP Archive (HAR) file with full response bodies – the same format browsers use internally, but enriched with the actual content of every JavaScript file, every CSS stylesheet, every JSON configuration, and every API response the tools served.

After capture, we wrote Python analysis scripts that parsed every response body, classified each file by tool and function, extracted every CSS selector from fix definitions, counted every DOM manipulation pattern in JavaScript code, identified every instance of content being hidden from assistive technology, and mapped every fix to the page area it affects (checkout, cart, product listing, navigation, etc.).

The proxy captured 924 HTTP requests with 579 full response bodies across three capture sessions – including every per-site fix script, every remediation JSON, every configuration file, and every analytics payload. We also saved complete DOM snapshots of pages with overlay modifications applied, allowing us to inspect the exact aria-label values and vendor data attributes injected at runtime. We then wrote automated analysis scripts to parse the JavaScript, count every DOM modification pattern, extract every CSS selector, classify every fix by page area, and identify every instance of content being hidden from assistive technology.

What we analyzed

The sites spanned major fashion retailers, luxury chocolate brands, luggage manufacturers, designer handbag stores, toy companies, a telecommunications provider, a national bank, beverages, stationery, watches, and confectionery brands – covering both EU and US markets.

A critical observation: No page-level scoping in any accessibility overlay

One of the most surprising findings emerged before we even analyzed the fix rules: every accessibility overlay loads its entire fix set on every single page, regardless of page type. Checkout-specific fixes fire on the homepage. Cart quantity rules execute on the “About Us” page. Product tile fixes run on the login form.

This means that on the telecom provider’s site, every visitor to every page downloads a 1.25 MB JSON file containing 4,974 image descriptions and 2,000 PDF remediation entries – even on pages with zero images. On the designer handbag retailer, 383 DOM fix rules execute on every page load, attempting to match selectors that only exist on specific page types. When a checkout-specific selector like #cardNumber fails to match on the homepage, the overlay’s fix engine still spends CPU cycles evaluating it – multiplied across hundreds of rules, this creates measurable performance waste on every page view.

Overlay A scans only 4.5% of sessions

Buried in Overlay A’s analytics POST data, we discovered a field revealing its actual scan sampling rate:

A samplingRate of 0.045 means only 4.5% of visitor sessions trigger a compliance scan on this fashion retailer. On another site – a luxury chocolate brand – the rate was even lower: just 1.7%. It is possible that the overlay vendor performs a more comprehensive initial scan during onboarding or setup, and then reduces the sampling rate for ongoing monitoring. However, the implication for day-to-day operations remains significant.

The accessibility overlay startup bundle’s code confirms three operational tiers: ReleaseVersionReport (full scan + report – the sampled percentage), ShadowVersionReport (shadow scan, no user-facing action), and RunReleaseFixesNoReport (apply all fix rules but run no scan at all). This means that during normal operation, the vast majority of your visitors receive DOM modifications that are not being validated during their session.

The practical risk is this: if a site deployment changes the DOM structure and breaks one or more fix rules, the low ongoing sampling rate means the regression may go undetected for an extended period. With only 1.7–4.5% of sessions being scanned, a broken fix could affect thousands of visitors before the next sampled session happens to trigger on the affected page and flag the issue. During that window, every visitor receives stale or mis-targeted fixes – and neither the site operator nor the overlay vendor may be aware of the problem.

The findings: Fix rules and DOM modifications

Overlay A: Per-site JavaScript fix files

This overlay maintains a separate JavaScript fix file for each client site, containing rules that target specific CSS selectors. Across the five sites we analyzed, we found:

We also found 7 instances where the literal string "true" was injected as an aria-label – a code bug where a boolean value was passed instead of descriptive text. Screen readers announce “button, true” – completely meaningless. On another site, “Search” was misspelled as “Seacrh” in an injected label.

Overlay B: AI-generated alt text at scale

This overlay downloads massive remediation JSON files containing AI-generated image descriptions. Across three sites:

Real examples from the remediation data:

323 descriptions exceeded 125 characters – causing screen reader verbosity where the reader drones on for 10–15 seconds per image. 156 redundantly started with “image of” – a WCAG anti-pattern since screen readers already announce the element type.

Monitoring Tool: Zero modifications – verified in source code

What “Hide from AT” means for real users

When an overlay hides an element from assistive technology, the element remains visible on screen but becomes completely invisible to screen readers. We classified every hidden element by the page area it affects:

Data from actual per-site active.js fix files extracted via mitmproxy. Each count represents a unique CSS selector targeted by hideFromAT().

On one luxury retailer’s checkout page, the elements hidden from screen readers included:

This is how accessibility overlay tools create a two-tier shopping experience: sighted users see all payment options and can choose between credit card, PayPal, Amazon Pay, Shop Pay, and Klarna. Blind users can only find whichever payment methods the overlay didn’t hide. On one fashion retailer, the cart quantity input and update button were both hidden – a blind user could add items but couldn’t change quantities.

This raises a fundamental question: is an overlay that hides payment buttons from blind users making the site more accessible or less accessible?

Performance impact

What happens after a site deployment

Perhaps the most insidious risk of overlay tools only becomes visible over time: the fixes degrade silently. Unlike a JavaScript error that crashes visibly or a broken layout that someone notices, a stale overlay fix produces no error, no alert, and no visual change. It simply stops working – and the accessibility barrier it was masking reappears without anyone knowing.

To understand this, consider how each overlay type couples itself to your site’s DOM structure.

Selector-based fixes: A ticking clock

Overlay A – like most accessibility overlay solutions – maintains per-site JavaScript fix files containing rules like this (reconstructed from the actual captured code):

This rule targets a Slick carousel’s previous-arrow button using three CSS classes: .js-recommendation_carousel, .slick-prev, and .slick-arrow. Every part of this selector is fragile. If the site team renames the carousel container class, switches from Slick to Splide or Swiper, or simply updates the Slick library to a version that changes its class naming convention – the selector matches nothing. The button loses its “Previous slide” label. Screen reader users can no longer identify it.

Across the five sites we analyzed for Overlay A, we found 98% of all selectors contain framework-specific class names – classes prefixed with .js-, .b-, .chakra-, .splide__, or CSS-in-JS hashes like .css-acuo7n. These are not stable, semantic identifiers – they are implementation details that change with every framework update, component refactor, or build-system modification.

On one designer handbag retailer, we found selectors targeting Chakra UI components. Chakra UI releases breaking changes in major versions – class names, component structure, and ARIA patterns all evolve. When this site upgrades Chakra, potentially hundreds of overlay fix rules will silently break. The overlay vendor must then manually audit the new DOM structure, rewrite every affected selector, and deploy updated fix files. During the gap between the site’s deployment and the overlay vendor’s update, the site runs with stale fixes – some doing nothing, others potentially applying to the wrong elements.

URL-based fixes: Even more fragile

Overlay B’s remediation JSON keys every alt text entry to the exact image source URL. We found entries like:

Notice the fragility: the URL contains a device ID (13555), a thumbnail dimension (86x86), and a file name that includes the product name. Any of these can change independently. If the CMS regenerates thumbnails at a different size, the thumb_86x86 part of the URL changes and the entry no longer matches. If the product team uploads a new photo with a different filename, the entry is orphaned. If the site migrates its media to a CDN with a different domain, every single entry in the 1.17 MB JSON becomes dead weight – and every image on the site loses its alt text simultaneously.

The worst scenario is a partial match failure: some images keep their old URLs (and get alt text), while new or updated images don’t match any entry (and get nothing). The result is an inconsistent experience where some images are described and others are silently skipped – far more confusing for a screen reader user than a consistent absence of alt text.

Global-scope fixes: The cascade problem

Overlay C’s approach – attaching a MutationObserver to the entire document and applying generic fixes to all elements of certain types (a, button, input, img, h1) – creates a different but equally dangerous breakage pattern. Rather than failing silently when selectors go stale, this overlay actively fights with new code.

Consider a common scenario: the site team deploys a new accessible modal dialog component that correctly implements focus trapping, escape-to-close, and ARIA attributes. The overlay’s MutationObserver detects the new DOM elements, evaluates them against its generic rules, and – finding elements that match its patterns – applies its own focus management, keyboard handlers, and ARIA attributes on top of the component’s existing, correct implementation. The result is a double-trapped focus, duplicate keyboard handlers, and conflicting ARIA attributes. The modal that worked perfectly before the overlay was loaded now behaves erratically.

This is not a theoretical concern. Framework component libraries like Radix UI, Headless UI, and Chakra UI invest significant engineering effort into correct ARIA implementation. An overlay that blanket-applies its own ARIA attributes to all button and a elements is likely to conflict with these well-tested implementations, making correctly accessible components less accessible.

The monitoring tool: Nothing to break

The monitoring tool we analyzed has no selector-based fixes, no URL-keyed entries, no MutationObserver, and no generic element targeting. When the site deploys new code, the monitoring tool’s next scan automatically evaluates the new DOM against axe-core’s standardized rule set and reports any new violations – without modifying anything. The scan results appear in the tool’s dashboard with severity levels, affected element counts, and standardized WCAG rule IDs. Developers review the findings and implement fixes in their own codebase, where the fixes go through code review, automated testing, staging validation, and controlled deployment.

This process is inherently resilient to change: the tool scans whatever DOM exists at the time of the scan, reports issues it finds, and starts fresh on the next scan. There is no accumulated technical debt of fix definitions, no stale selectors, no orphaned alt text entries, and no possibility of applying the wrong fix to the wrong element.

What breaks when you redeploy

Every accessibility overlay fix is coupled to the site’s current DOM structure. We found that 98% of one overlay’s selectors target framework-specific class names – classes like .chakra-, .splide__, .js-, .b-, and CSS-in-JS hashes like .css-acuo7n that change on every build.

The monitoring tool has “Unaffected” in every row because it has zero selector-based fixes. There is nothing to become stale, nothing to target the wrong element, nothing to break.

GDPR, privacy, and the consent problem

Our analysis confirmed three of the four accessibility overlays send data to external servers before any consent banner can be interacted with:

Under the CJEU’s Planet49 ruling, non-essential tracking requires prior opt-in consent. Two overlays fire persistent identifiers on the first network request – before any consent mechanism can activate. For EU-facing sites, this is automatic GDPR non-compliance.

The legal landscape

In April 2025, the U.S. Federal Trade Commission finalized a $1 million settlement against one of the accessibility overlay vendors in our study for misrepresenting that its AI-powered tool could make any website WCAG-compliant. The FTC found the tool failed to make basic website components – menus, headings, tables, images, and recordings – accessible. In one cited example, a photo of filet mignon received the AI-generated description “Brown bread on white ceramic plate.”

According to industry tracking data, 25% of all digital accessibility lawsuits in 2024 explicitly cited overlay widgets as barriers – not solutions. In the first half of 2025, lawsuits against overlay-using companies continued at over 100 per month. Two of the overlay vendors in our study have been directly involved in litigation: one in three separate patent/trade secret cases, and another facing a class action from a small business customer who was sued despite using the overlay.

The monitoring tool in our study has no litigation history related to accessibility failures – a logical consequence of its architecture: because it never modifies the DOM, it cannot introduce accessibility barriers.

Inside the code: What overlays actually modify

To understand the scale of DOM manipulation, we counted every modification pattern in each tool’s JavaScript. The differences are dramatic:

Overlay C deserves particular attention. Its 794 KB monolithic bundle attaches a MutationObserver to document.documentElement with the configuration {subtree: true, childList: true, attributes: true, attributeOldValue: true}. This means every single DOM change on the entire page – whether from React’s virtual DOM reconciliation, an A/B testing script, a chat widget, or the site’s own JavaScript – triggers the overlay’s observer, which then re-evaluates and potentially re-applies its fixes. After a site redeploy, this creates a cascade of re-fix attempts on elements that may already be correctly accessible, potentially overwriting correct ARIA attributes with incorrect ones.

We confirmed that Overlay C sends USER-BEHAVIOR-ANALYTICS POST requests to its own log receiver, with payloads containing the site domain, widget version, user language, and interaction events. Combined with localStorage persistence and device fingerprinting via navigator.userAgent and navigator.maxTouchPoints, this represents a data processing operation that most site operators are unaware is occurring.

The remediation JSON problem

Overlay B downloads a massive JSON file (up to 1.17 MB for one telecom site) containing all fix definitions. On one site, we observed it being fetched four separate times in a single browsing session – 4.7 MB of bandwidth for a file that should have been cached. The JSON contains 11 categories, but the overwhelming majority are AI-generated image descriptions: 4,974 of 6,975 entries for one site. Each is keyed to a specific image URL – when the CMS renames a file, changes thumbnail dimensions, or migrates CDN domains, the entries silently stop matching. The replacement images get no alt text at all, making the page less accessible than before the overlay was installed.

This overlay also deploys runtime modules that actively rewrite the page: a 110 KB remediation engine, a 23 KB navigation menu helper that restructures menu keyboard handling, a 5.8 KB carousel patch, and a 53 KB client-side scanner using proprietary logic rather than the industry-standard axe-core engine – meaning its findings cannot be independently verified.

The most transparent overlay – still risky

Overlay D had the most transparent architecture: human-readable JSON configuration files with explicit enable/disable switches. Options like addAriaHidden, overwriteAlt, and adjustMetaViewport were explicitly set to false. However, the underlying engine (649 KB) contains 216 setAttribute calls, 47 aria-hidden references, 282 addEventListener registrations, and 9 MutationObserver instances. The engine supports aggressive DOM mutation even if the current configuration is conservative – a vendor-side configuration change could activate risky features without the site operator’s knowledge.

We found per-site selectors containing JavaScript-generated hash suffixes like button.topHeader__infoButton.js-exclusions85ada2b86bb632424e3ad77c14 that change on every build, and social media URL selectors that become stale when the site updates its Facebook or Instagram links.

The European Accessibility Act: Why overlays won’t satisfy the EAA

Starting June 28, 2025, the European Accessibility Act (EAA) requires digital products and services sold in the EU to meet accessibility standards aligned with EN 301 549, which references WCAG 2.1 AA. Unlike the ADA – which is enforced primarily through private lawsuits – the EAA is enforced by national market surveillance authorities with the power to impose fines, order corrective measures, and withdraw non-compliant products from the market.

Germany’s official rejection of overlay tools

Germany has taken the clearest regulatory position of any country on accessibility overlays. The BFIT-Bund (Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik) – Germany’s federal monitoring body for accessibility of information technology – together with all state-level monitoring bodies, issued a joint assessment explicitly rejecting overlay tools for accessibility compliance:

On March 12, 2025, the Committee for Accessible Information Technology (Ausschuss für barrierefreie Informationstechnik, established under §5 BITV 2.0) reaffirmed this position in its session, stating with concern that public bodies continue to attempt to meet their accessibility obligations by embedding overlay tools. The committee concluded that “a temporary accessible rendering of a website by software – possibly only after settings are configured by the user – for the duration of their visit does not meet the requirements of the applicable legal provisions.”

The committee explicitly warned that public bodies using overlay tools risk making their websites less accessible, not more – creating a worsening of accessibility (“Verschlechterung der Barrierefreiheit”). This directly mirrors our technical finding that 26% of overlay fix rules introduce new WCAG violations.

BIK testing seal: Denied for overlay-using websites

Germany’s BIK testing network – the accredited bodies that evaluate websites against BITV 2.0, EN 301 549, and WCAG 2.1 AA – has taken an operational step: websites using overlay tools cannot receive the BIK test seal. The testing bodies stated that they cannot make a reliable conformity assessment when an overlay is present, because the overlay modifies the DOM at runtime in ways that make the test results unreliable. The BIK seal is widely used across Germany as evidence of BITV 2.0 compliance – and it is now unavailable to any website that uses an overlay.

This is not a theoretical policy concern. It means that a German eCommerce site using any of the four overlays we tested cannot obtain the standard compliance certification used across the German market.

European-level confirmation

This regulatory position extends beyond Germany. The European Disability Forum and the International Association of Accessibility Professionals issued a joint statement in 2023 warning that accessibility overlays do not make websites accessible or compliant with European accessibility legislation, including the European Accessibility Act. The European Commission has also commented on overlay conformity claims, concluding that overlays cannot ensure compliance with the applicable standards.

Under Germany’s BFSG (Barrierefreiheitsstärkungsgesetz – the German transposition of the EAA, in force since June 28, 2025), market surveillance authorities can impose fines of €10,000 to €100,000 per violation. The BFIT-Bund assessment and the BIK testing network’s refusal to certify overlay-using sites effectively mean that overlay tools provide zero regulatory cover in Germany – and may actively increase the risk of enforcement action.

Security and supply chain risk

Every overlay tool operates by injecting third-party JavaScript into the global scope of your production pages. This JavaScript runs with the same privileges as your own code – it can read and modify any DOM element, intercept form submissions, access cookies, redirect users, and exfiltrate data. The security implications of this arrangement are significant and often overlooked.

The attack surface

Consider the supply chain: when you add an accessibility overlay to your site, you are granting a third-party vendor continuous, unrestricted write access to your live production DOM. The vendor’s CDN serves the JavaScript, the vendor’s team maintains the code, and the vendor’s deployment pipeline pushes updates directly to your site – without your code review, without your QA process, and without your approval.

If the overlay vendor’s CDN is compromised, the attacker gains the ability to inject malicious code into every site using that overlay. If a vendor employee pushes a bad update, every customer site is affected simultaneously. If the vendor’s API endpoint is hijacked, the remediation JSON or configuration data served to your site can be manipulated to modify form fields, redirect links, or inject phishing content.

The scale of this risk correlates directly with the overlay’s DOM footprint:

Overlay B presents the largest supply chain risk surface: 228 API calls per session across 3 external domains, with a 1.17 MB JSON payload that defines how the DOM should be modified. A compromised API response could instruct the remediation engine to inject arbitrary content into any element on the page. Overlay C’s 1,285 KB monolithic bundle is the largest single JavaScript payload – and because it’s minified and obfuscated, neither the site operator nor a security auditor can meaningfully review what it executes at runtime.

PCI DSS compliance: A direct conflict

For any eCommerce site that processes credit card payments, PCI DSS compliance is not optional. And our findings reveal a direct conflict between accessibility overlay tool architecture and PCI DSS requirements.

PCI DSS Requirement 6.4.3 (introduced in PCI DSS v4.0, mandatory from March 31, 2025) requires that all payment page scripts that load and execute in the consumer’s browser are managed as follows: a method must be implemented to confirm that each script is authorized, the integrity of each script must be assured, and an inventory of all scripts must be maintained with written justification for why each is necessary.

Our analysis confirmed that overlay fix rules actively target payment-page DOM elements on multiple sites:

This is not a theoretical risk – these are actual fix rules we extracted from production sites, actively modifying credit card number fields, billing address selectors, payment provider buttons, and checkout form containers. Under PCI DSS 6.4.3, every one of these third-party scripts requires documented authorization, integrity verification, and written justification.

Consider what an overlay vendor’s script can do on your checkout page:

The monitoring tool, by contrast, has zero DOM write capability. Its 4.2 KB script cannot modify form fields, cannot intercept input events, and cannot access or alter checkout elements. Even if the monitoring vendor’s CDN were compromised, the attacker would gain access to a script that can only read the page URL and device type – not one that can rewrite the checkout form. For PCI DSS scoping purposes, the monitoring tool creates no additional risk surface on payment pages.

The discrimination question

This is the discrimination problem at the heart of every accessibility overlay: The most troubling finding is not a technical defect – it is a pattern of systematically denying disabled users access to functionality that sighted users take for granted.

When an overlay hides an Amazon Pay button from the accessibility tree, a blind user sees fewer payment options than a sighted user. When a cart quantity input is hidden, a blind user cannot adjust their order. When search result links are hidden, product discovery is impaired. When star ratings are hidden, a blind user cannot assess product quality the way a sighted user can.

These are not edge cases – they are core eCommerce workflows being broken by the very tools that promise to make them accessible.

The disability community has been vocal about this for years. The Overlay Fact Sheet – signed by hundreds of accessibility professionals – warns that accessibility overlays “do not repair the underlying HTML” and “often actively get in the way of people with disabilities.” Our technical analysis provides the evidence: 141 functional elements hidden from screen readers, 7 meaningless labels injected, and 5,066 unreviewed AI descriptions deployed to production – across just 14 sites.

For site operators, the question is not whether overlays are “good enough” – it is whether deploying a tool that creates a two-tier experience can be justified: one version for sighted users who get full functionality, and a filtered, broken, sometimes nonsensical version for disabled users.

Impact on ADA compliance: Do these fixes actually help?

The core promise of every overlay is that it improves ADA compliance by fixing WCAG violations at runtime. But our analysis reveals a disturbing paradox: a significant percentage of overlay fixes actively introduce new WCAG violations while attempting to fix existing ones.

We mapped every captured fix rule from Overlay A to the specific WCAG 2.1 success criterion it targets. Of 776 rules that could be mapped, the results split into two categories: fixes that genuinely address a WCAG issue, and fixes that create a new WCAG violation in the process.

To be fair, three-quarters of the mapped fixes are genuine improvements – adding missing button labels, fixing heading hierarchies, correcting autocomplete attributes, and implementing modal focus traps. But the remaining quarter is actively harmful, and the harm falls disproportionately on the very users the tool claims to help.

How each risky pattern violates WCAG

The issue is not just that these fixes fail – it is that they introduce violations of specific WCAG success criteria that did not exist before the overlay was applied. In an ADA lawsuit, a plaintiff’s expert can point to these overlay-created violations as evidence that the site discriminates against people with disabilities.

Overlay B: AI alt text and WCAG 1.1.1

WCAG 1.1.1 requires that non-text content has a “text alternative that serves the equivalent purpose.” An AI-generated alt text that describes a company logo as “a blue and yellow sign” does not serve the equivalent purpose – the purpose of a logo is brand identification, not color description. An alt text of “text” for a promotional banner, or “city” for a hero image, fails the same criterion in a different way – it is so vague as to be useless.

Of the 5,068 AI-generated alt texts we captured from Overlay B, 241 were under 15 characters (too vague to be useful), 323 exceeded 125 characters (violating best practices for screen reader usability), and 156 started with “image of” or “photo of” (redundant because screen readers already announce the element type). Only 2 had been approved by a human reviewer.

Under ADA litigation standards, a plaintiff’s accessibility expert would flag these as failures of WCAG 1.1.1 – the most commonly cited criterion in ADA web accessibility lawsuits. The overlay is not resolving the violation; it is replacing one form of non-compliance (missing alt text) with another (inaccurate or vague alt text), while creating a false sense of compliance for the site operator.

Overlay B: Runtime form label injection – when “fixing” makes it worse

Beyond the consolidated JSON, Overlay B runs a 110 KB remediation engine (remediation-tool.js) that performs 24 distinct DOM mutation rules at runtime on every page load. One of these rules – the EmptyControls handler – targets unlabeled form fields and attempts to inject accessible names by finding nearby <label> elements.

The mechanism works as follows: for each form control without an accessible name, the engine calls a label-finder function that searches for <label for=”id”> elements matching the input’s ID. If found, it injects the label’s text content as an aria-label:

We verified this behavior on a live site – a web agency’s contact page with six form fields. The original HTML had visible labels (“First Name”, “Company Name”, “Last Name”, “Work Email”, “Phone Number”, “Message”) but they were not programmatically associated with their inputs via <label for> or aria-label. Without the overlay, a screen reader would announce each field with no name at all.

With Overlay B’s remediation engine active, a screen reader announced:

We verified this by examining the saved HTML source with the overlay’s modifications baked in. Every modified element carries a vendor-specific data-*-form=”fx” attribute – the overlay’s own marker confirming it injected the aria-label. The original HTML has <label> elements with correct text (“First Name”, “Last Name”, “Work Email”, etc.) but they have no for attribute and the inputs are not nested inside the labels – so there is no programmatic association. The overlay’s label-finder function only looks for label[for=id], and since the inputs have no id attribute at all, it returns null for every field. The engine then falls back to constructing labels from the name attribute (“first-name” → “Name”, “last-name” → “Name”), input validation type (“email” → “Please enter email address”), or the raw element type (“text” → “Text field”, “select” → “Single select”, “textarea” → “Text area”).

The result is worse than the original unlabeled form. Before the overlay, a screen reader user would encounter seven unlabeled fields – confusing, but at least consistently so. They might use tab order and context to guess which field is which. After the overlay’s intervention, the user encounters two fields with the same label (“Name” for both First Name and Last Name), two fields with fabricated validation-style labels that don’t match the visible text, and three fields with meaningless type-based names. The partial, incorrect labeling is more disorienting than no labeling at all, because it creates a false impression that the form has been made accessible when critical fields remain unlabeled or mislabeled.

This finding also reveals Overlay B’s remediation JSON blind spot. The JSON contained 87 AI-generated alt text entries and zero form remediation entries for this site. The form label injection happens entirely at runtime via the EmptyControls rule handler – it is not visible in the consolidated remediation JSON, not tracked in any dashboard the site operator can review, and not subject to human approval. The site operator has no way to know that their contact form is being mislabeled unless they test it themselves with a screen reader.

The remediation engine’s 24 rule handlers collectively perform: aria-label injection on form fields, links, images, and dialogs; aria-hidden toggling; role modification (heading, presentation, menuitem, button, img); tabindex injection to make non-interactive elements focusable; alt text from the AI JSON; style overrides to make hidden elements visible; aria-required injection; aria-describedby associations between fields and error messages; heading text rewrites; broken link URL corrections; <meta viewport> modification; and <html lang> changes. All of this executes at runtime in the visitor’s browser on every page load – none of it is visible in the consolidated remediation JSON.

The net ADA compliance effect

The fundamental problem is that overlay tools conflate coverage with compliance. An overlay can point to 1,058 fix rules and claim it addresses over 40 WCAG success criteria. But when 26% of those fixes introduce new violations – including Level A failures created by hiding functional elements – the net compliance position may be worse than the unmodified site.

A site without an overlay that has 50 WCAG violations is in a clearer legal position than a site with an overlay that has 30 original violations plus 203 overlay-introduced violations – because the overlay-introduced violations demonstrate that the site operator deployed a tool that actively discriminates against disabled users, which undermines any good-faith defense.

The bottom line