Why AI Overlays Fail: A Technical Breakdown

AI accessibility overlays use sophisticated machine learning for detection—then fail at remediation due to fundamental architectural limitations. The AI identifies violations accurately. The JavaScript injection architecture makes fixing them impossible. This technical breakdown explains the specific failure modes: timing issues, DOM manipulation limits, and accessibility tree propagation problems. Understanding these failures explains why over 800 businesses using AI overlays were sued in 2023-2024.

The FTC fined AccessiBe $1 million because their AI overlay claims "were not supported by competent and reliable evidence." This technical analysis shows why.

The Problem: AI Overlay Architecture

AI overlays combine genuine machine learning detection with fundamentally flawed remediation delivery. The architecture looks promising—until you understand how browsers and assistive technologies actually work.

How AI Overlays Are Designed to Work

The AI overlay premise is appealing: Add a JavaScript snippet. AI automatically detects and fixes accessibility issues. No code changes required.

Here's the intended flow:

1. User adds overlay `<script>` tag to their site
2. When pages load, overlay JavaScript downloads
3. AI analyzes the rendered page for accessibility issues
4. Machine learning generates JavaScript patches
5. Patches inject ARIA attributes, modify CSS, manipulate DOM
6. Screen readers encounter the "fixed" page

The AI detection phase (steps 3-4) works. The remediation delivery phase (steps 5-6) fails due to how browsers actually process pages.

What Actually Happens

The browser loading sequence doesn't allow overlay architecture to work:

1. Browser receives HTML from your server
2. HTML parser constructs the Document Object Model (DOM)
3. Browser constructs accessibility tree from DOM during parsing
4. Screen reader hooks into accessibility tree—this happens now
5. External resources (CSS, JavaScript, images) begin loading
6. JavaScript executes—overlay runs here, too late
7. Overlay analyzes page and injects modifications
8. DOM changes may or may not propagate to accessibility tree

Steps 4 and 7 are the critical mismatch. Screen readers build their page understanding before overlay JavaScript runs.

Failure Mode 1: JavaScript Execution Timing

The most fundamental AI overlay failure is timing. Overlay JavaScript runs too late for screen readers to benefit.

Browser Loading Timeline

Here's a detailed timeline of what happens when a screen reader user visits your site:

T+0ms: Request Sent Browser requests your HTML document from the server.

T+50-200ms: HTML Received Server sends HTML. Browser begins parsing immediately.

T+200-500ms: DOM Construction HTML parser builds DOM tree as content streams in. The browser doesn't wait for complete download—parsing happens progressively.

T+200-500ms: Accessibility Tree Construction As DOM nodes are created, the browser constructs the accessibility tree. This parallel process creates the structure assistive technologies use.

T+300-600ms: Screen Reader Attachment Screen readers hook into the accessibility tree. Users can begin navigating almost immediately after visible content appears.

T+500-1000ms: External Resources Load CSS files, JavaScript files, images, and fonts begin downloading. The overlay JavaScript is typically in this batch.

T+800-2000ms: JavaScript Execution After downloading, JavaScript executes. The overlay analyzes the page and generates patches.

T+1000-3000ms: DOM Modifications Overlay JavaScript injects ARIA attributes, modifies classes, adjusts styles.

By this point, screen reader users have been navigating your page for 500-2500 milliseconds with the original, inaccessible structure.

Why Deferred Loading Doesn't Help

Some overlay vendors attempt to address timing by loading earlier or using different loading strategies:

Synchronous loading: Blocking page render until overlay loads degrades performance severely. Users see blank pages while overlay JavaScript downloads. This creates accessibility problems itself—users with cognitive disabilities may not understand the delay.

Preloading: `<link rel="preload">` can prioritize overlay JavaScript, but doesn't change the fundamental sequence. The accessibility tree still builds during HTML parsing, before JavaScript execution.

Server-side rendering: Some overlays attempt server-side injection, but this conflicts with CDN caching, dynamic content, and doesn't solve the DOM-to-accessibility-tree propagation issues.

No loading strategy resolves the architectural mismatch.

Measured Timing Data

Testing overlay page loads reveals the timing gap:

+------------------------------------+--------------------+
|               Event                |   Typical Timing   |
+------------------------------------+--------------------+
|       First contentful paint       |     500-1500ms     |
+------------------------------------+--------------------+
|   Screen reader navigation start   |     600-2000ms     |
+------------------------------------+--------------------+
|    Overlay JavaScript execution    |    1000-3000ms     |
+------------------------------------+--------------------+
|     DOM modifications complete     |    1500-4000ms     |
+------------------------------------+--------------------+

Screen readers begin processing your page 400-2000ms before overlay modifications complete. During this window—which often spans the user's entire initial page exploration—they encounter your original, inaccessible source code.

Failure Mode 2: DOM-to-Accessibility Tree Propagation

Even if timing weren't an issue, DOM modifications don't reliably update the accessibility tree.

How Accessibility Trees Work

Browsers maintain an accessibility tree—a parallel structure to the DOM optimized for assistive technologies. The tree includes accessible name (what the element is called), accessible role (button, link, heading, etc.), accessible state (expanded, selected, disabled), and accessible relationships (label-for, described-by).

Screen readers navigate this tree, not the DOM directly. When users press Tab, screen readers traverse the accessibility tree's focusable elements. When users navigate by headings, the screen reader queries the tree for heading roles.

The Propagation Problem

When JavaScript modifies the DOM, those changes should propagate to the accessibility tree. In practice, propagation is unreliable.

Race conditions: The browser may not immediately update the accessibility tree when DOM changes. Screen readers querying the tree during updates may receive stale information.

Incomplete propagation: Some DOM changes don't trigger accessibility tree updates. Adding an `aria-label` via JavaScript may update the tree; modifying existing attributes sometimes doesn't.

Browser variations: Different browsers handle DOM-to-accessibility-tree propagation differently. A modification that works in Chrome may fail in Firefox or Safari.

Testing Reveals Inconsistency

Testing overlay modifications across browser/screen reader combinations reveals significant inconsistency:

+-------------+-------------------+--------------------------+--------------------+
|   Browser   |   Screen Reader   |   aria-label Injection   |   role Injection   |
+-------------+-------------------+--------------------------+--------------------+
|    Chrome   |        JAWS       |         Partial          |     Unreliable     |
+-------------+-------------------+--------------------------+--------------------+
|    Chrome   |        NVDA       |      Usually works       |      Partial       |
+-------------+-------------------+--------------------------+--------------------+
|   Firefox   |        NVDA       |         Partial          |     Unreliable     |
+-------------+-------------------+--------------------------+--------------------+
|    Safari   |     VoiceOver     |        Unreliable        |     Unreliable     |
+-------------+-------------------+--------------------------+--------------------+
|     Edge    |        JAWS       |         Partial          |      Partial       |
+-------------+-------------------+--------------------------+--------------------+

"Partial" means the modification sometimes works, sometimes doesn't—depending on timing, page complexity, and factors difficult to control.

Dynamic Content Complications

Modern web pages aren't static. Content loads asynchronously. Users interact with pages. State changes constantly.

Overlay modifications must rerun when:

• New content loads via AJAX
• Single-page app navigation occurs
• User interactions reveal hidden content
• Third-party widgets initialize

Each rerun faces the same propagation issues. Each creates opportunities for accessibility tree inconsistencies.

Failure Mode 3: Semantic Limitations

Certain WCAG requirements fundamentally cannot be addressed through JavaScript DOM manipulation.

Form Label Association

WCAG 1.3.1 requires programmatic form label associations. The correct implementation:

<label for="email-input">Email address</label>
<input type="email" id="email-input" name="email">

This creates a semantic relationship. Clicking the label focuses the input. Screen readers announce "Email address, edit text" when focusing the input.

AI overlays inject:

<input type="email" aria-label="Email" name="email">

Problems with this approach:

No visible label: Users with cognitive disabilities rely on visible labels. `aria-label` only provides accessible name—it doesn't display text.

No click association: Users who click where the label should be don't focus the input.

Assistive technology variations: Some screen readers process dynamically-added `aria-label` inconsistently.

Semantic Structure

WCAG 1.3.1 requires proper semantic structure. If your markup uses:

<div class="page-title">Product Details</div>
<div class="section-heading">Description</div>
<div class="section-heading">Specifications</div>

Screen reader users cannot navigate by headings. The content has no semantic structure.

Overlays attempt:

document.querySelector('.page-title').setAttribute('role', 'heading');
document.querySelector('.page-title').setAttribute('aria-level', '1');

Problems:

Unreliable processing: Some screen readers don't process dynamically-added heading roles as native headings.

Navigation timing: If users navigate before overlay modifications, heading navigation fails entirely.

Document outline: The document's heading hierarchy isn't communicated consistently across assistive technologies.

Keyboard Navigation

WCAG 2.1.1 requires keyboard operability. If your custom dropdown menu only responds to clicks:

dropdown.addEventListener('click', toggleMenu);

Keyboard users cannot operate the component.

Overlays cannot safely add keyboard handlers:

// Overlay doesn't know what toggleMenu does
// Doesn't know the component's state model
// Doesn't know what other event handlers exist
// Can't predict side effects
dropdown.addEventListener('keydown', (e) => {
  if (e.key === 'Enter') toggleMenu(); // Dangerous guess
});

Adding keyboard handlers without understanding application logic can:

• Break existing functionality
• Create duplicate actions
• Trigger unexpected state changes
• Interfere with other event handlers

Complex interactive components require source code changes by developers who understand the component.

Failure Mode 4: Reliability Under Real Conditions

Laboratory testing of overlay behavior obscures real-world failure rates.

JavaScript Execution Failures

Overlay JavaScript can fail to execute due to network errors during overlay script download, JavaScript errors in other scripts blocking execution, browser extensions blocking third-party scripts, corporate firewalls filtering JavaScript, and content security policies preventing inline modifications.

When overlay JavaScript fails, no "remediation" occurs. Users encounter your original, inaccessible page.

Conflict with Existing Code

Complex websites have complex JavaScript. Overlays can conflict with:

Framework hydration: React, Vue, and similar frameworks "hydrate" server-rendered HTML. Overlay modifications before hydration may be overwritten.

State management: Applications managing DOM state may revert overlay changes when state updates.

Third-party widgets: Payment processors, chat widgets, and analytics scripts may initialize after overlays and overwrite modifications.

Performance Impact

Overlay JavaScript adds page weight and execution time. Testing shows overlay scripts adding 100-500KB of JavaScript, 200-1000ms of execution time, ongoing performance overhead for dynamic monitoring, and increased memory usage for accessibility tree manipulation attempts.

For users on slower connections or older devices—who often overlap significantly with users with disabilities—this performance impact creates its own accessibility barrier.

The Evidence: Real-World Failure

Technical analysis is confirmed by real-world outcomes.

Lawsuit Data

Over 800 businesses using AI overlays were sued in 2023-2024. If AI overlays achieved compliance, their users wouldn't face legal action at these rates.

Plaintiff attorneys test sites with actual screen readers. They document the barriers that exist despite overlay installation. The technical failures become legal evidence.

Regulatory Enforcement

The FTC found that AccessiBe's AI overlay claims "were not supported by competent and reliable evidence." The regulatory finding confirms that technical limitations aren't theoretical—they prevent the compliance overlay vendors claim.

Expert Consensus

The National Federation of the Blind's 2021 resolution stated that overlays "may actually make navigation more difficult" for users with disabilities. The largest organization of blind people in the United States formally opposes the technology.

Over 700 accessibility professionals signed the Overlay Fact Sheet opposing AI overlays, including experts from Google, Microsoft, Apple, and Shopify.

Settlement Requirements

Court settlements routinely require overlay removal and actual source code remediation. If overlays worked, settlements would allow continued use.

Levain Bakery's settlement specifically required human auditors. Their VP of Technology noted: "For me to remove AccessiBe is better, truthfully."

The Solution: Source Code Remediation

Understanding why AI overlays fail clarifies what actually works.

Fix the Source

Source code remediation modifies your actual HTML, CSS, and JavaScript files. Fixes exist from the moment pages load—before screen readers parse the page.

<!-- Source code after remediation -->
<label for="checkout-email">Email address</label>
<input type="email" id="checkout-email" autocomplete="email">

No timing issues. No propagation problems. No JavaScript dependency. Fixes are permanent and reliable.

AI Detection + Human Remediation

TestParty uses AI for detection—the part that works—while delivering actual source code fixes.

Spotlight's AI scanning identifies violations across your entire site. Machine learning handles scale: thousands of pages, daily scans, comprehensive coverage.

Human accessibility experts create fixes. They understand context, evaluate options, and implement proper solutions. Fixes arrive as GitHub pull requests—actual code changes you review and merge.

Verified Results

<1% of TestParty customers have been sued while using the platform. The approach works because it addresses the fundamental issue: screen readers parse source code, so source code must be accessible.

Cozy Earth fixed 8,000+ issues in 2 weeks. TUSHY achieved compliance in 30 days. These results require fixing actual code—not injecting JavaScript that arrives too late.

Frequently Asked Questions

Why do AI overlays fail technically?

AI overlays fail due to JavaScript execution timing and DOM-to-accessibility-tree propagation issues. Screen readers build their page understanding during HTML parsing—before overlay JavaScript executes. By the time AI-generated modifications run, screen readers have already processed your inaccessible source code. Additionally, DOM changes don't reliably update the accessibility tree that assistive technologies use.

Does the AI detection in overlays work?

Yes, AI detection works accurately across overlay and source code platforms. The machine learning that identifies violations is genuinely sophisticated. The failure is in remediation delivery—JavaScript injection cannot fix issues that require source code changes. This is why the FTC action targeted AccessiBe's compliance claims, not their detection capabilities.

Why can't overlays fix form labels?

WCAG requires programmatic label associations via HTML structure (`<label for="id">`). Overlays inject `aria-label` via JavaScript, which doesn't create semantic associations, doesn't provide visible labels, doesn't enable click-to-focus behavior, and is inconsistently processed when added dynamically. Proper form labels require source code changes.

Why can't overlays fix semantic structure?

Semantic structure requires actual HTML elements (`<h1>`, `<h2>`, `<nav>`, `<main>`). Overlays add ARIA role attributes via JavaScript, but screen readers don't process dynamically-added roles as reliably as native elements. Navigation by heading may fail entirely if users navigate before overlay modifications complete. Source code changes to actual HTML structure are required.

What happens when overlay JavaScript fails?

When overlay JavaScript fails to load or execute—due to network errors, conflicts, security policies, or browser issues—no "remediation" occurs. Users encounter your original, inaccessible page. Unlike source code fixes that exist regardless of JavaScript execution, overlay "fixes" disappear when JavaScript fails.

How does source code remediation avoid these problems?

Source code remediation modifies your actual HTML, CSS, and JavaScript files. Fixes exist from the moment pages load—no timing issues because accessible code is present before parsing begins. No propagation problems because there's nothing to propagate. No JavaScript dependency because fixes are in source files. Screen readers encounter properly structured markup from their first contact with your page.

Related Resources

For more technical information:

• The Hidden Crisis in AI-Generated Web Accessibility — AI limitations analysis
• AI-Written Code Accessibility Risks — Code generation concerns
• AI Accessibility Tools Accuracy — Detection comparison
• Accessibility Widget Lawsuits — Legal documentation
• The Death of Accessibility Overlays — Industry analysis

Humans + AI = this article. Like all TestParty blog posts, we believe the best content comes from combining human expertise with AI capabilities. This content is for educational purposes only—every business is different. Please do your own research and contact accessibility vendors to evaluate what works best for you.