Accessibility Overlays: Why They Don't Fix WCAG Compliance (And What to Do Instead)

WCAG Repair Team

If you've been approached by a vendor promising instant ADA compliance through a single JavaScript snippet, you're not alone. Accessibility overlays are marketed aggressively to small business owners and developers who need a fast solution to a real legal problem. The pitch sounds reasonable: install one widget, check the compliance box, move on. The reality is that accessibility overlays don't deliver WCAG compliance—and relying on one could leave you more exposed to lawsuits than if you'd done nothing at all.

What Accessibility Overlays Actually Are

Accessibility overlays are third-party JavaScript tools (UserWay, accessiBe, AudioEye, and others) that inject a toolbar onto your website. Users can theoretically adjust font sizes, contrast, and other visual settings. Some vendors claim their AI automatically remediates barriers in real time.

These tools typically run client-side, layering modifications on top of your existing HTML. They don't touch your source code. When the script loads, it attempts to fix what it can detect—but detection is the fundamental problem.

What Overlays Can (Sometimes) Do

  • Increase font size via CSS
  • Toggle high-contrast color schemes
  • Add a "pause animations" button
  • Provide a basic screen reader mode

What Overlays Cannot Do

  • Fix missing or incorrect ARIA landmark structure
  • Repair keyboard navigation traps baked into JavaScript components
  • Correct meaningless alt text (or add alt text that accurately describes an image's content)
  • Remediate PDF and document accessibility
  • Fix form labels that are visually present but not programmatically associated
  • Fix custom dropdown menus, date pickers, or modals that block screen reader access

The last category is where lawsuits happen.

ADA Title III web accessibility lawsuits exceeded 4,600 federal filings in 2023, and that number has remained elevated. Small and mid-sized businesses are the most common targets—large enterprises have legal teams; plaintiffs' firms know it's cheaper for an SMB to settle.

Overlay vendors have been named as co-defendants in litigation. More importantly, courts have not accepted "we installed an overlay" as a defense. In Robles v. Domino's Pizza and subsequent rulings, the standard that has emerged is whether a disabled user can actually access the content—not whether you installed a tool that claims to help them.

The National Federation of the Blind, Disability Rights Advocates, and hundreds of individual plaintiffs have filed cases specifically against companies using overlays, arguing the tools sometimes create additional barriers by interfering with native assistive technology like JAWS and NVDA.

Using an overlay for accessibility overlays WCAG compliance purposes is not a legal shield. It's a liability with a monthly subscription fee.

What WCAG 2.1 AA Actually Requires

WCAG 2.1 Level AA is the current enforceable standard for most U.S. businesses under the ADA, and for public sector entities under Section 508. It's organized around four principles—Perceivable, Operable, Understandable, Robust—with 50 success criteria at Level AA.

An overlay cannot programmatically verify whether your content meets these criteria. It cannot rewrite your DOM to fix structural issues. Here's a concrete example:

Broken form label (common failure):

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

WCAG 2.1 SC 1.3.1 compliant form label:

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

One attribute. An overlay will not add for="email" to your label. A screen reader user will hear an unlabeled input field and have no idea what to type. The fix takes ten seconds in your source code—but only if you know it's broken.

Another common failure—image alt text:

<!-- What overlays might generate (useless) -->
<img src="team-photo.jpg" alt="image">

<!-- What WCAG 1.1.1 requires (meaningful) -->
<img src="team-photo.jpg" alt="The WCAGRepair development team at their office in Austin, Texas">

No AI overlay can write accurate, contextual alt text for your images. It doesn't know what's in the photo.

The Keyboard Navigation Problem

Overlays are particularly weak on keyboard accessibility—one of the most litigated issues. WCAG 2.1 SC 2.1.1 requires that all functionality be operable via keyboard alone. Many custom UI components fail this test entirely.

A modal dialog that traps keyboard focus (common failure):

// User tabs into modal, but focus escapes to background content
document.getElementById('modal').addEventListener('click', openModal);
// No focus management, no focus trap, no Escape key handler

Remediated with proper focus management:

function openModal() {
  const modal = document.getElementById('modal');
  const focusableElements = modal.querySelectorAll(
    'a, button, input, select, textarea, [tabindex]:not([tabindex="-1"])'
  );
  const firstFocusable = focusableElements[0];
  const lastFocusable = focusableElements[focusableElements.length - 1];

  modal.setAttribute('aria-modal', 'true');
  firstFocusable.focus();

  modal.addEventListener('keydown', function(e) {
    if (e.key === 'Tab') {
      if (e.shiftKey && document.activeElement === firstFocusable) {
        e.preventDefault();
        lastFocusable.focus();
      } else if (!e.shiftKey && document.activeElement === lastFocusable) {
        e.preventDefault();
        firstFocusable.focus();
      }
    }
    if (e.key === 'Escape') closeModal();
  });
}

This is source-level code. An overlay runs after the DOM loads—it cannot inject this kind of logic reliably into every component on every page.

What to Do Instead

Genuine accessibility overlays WCAG compliance is a contradiction in terms. Here's the approach that actually works:

1. Audit your actual codebase. Use automated tools to catch the roughly 30–40% of WCAG failures that are machine-detectable. Axe DevTools, WAVE, and Lighthouse are free starting points. Automated tools alone won't find everything—keyboard testing and screen reader testing are necessary for the rest.

2. Fix at the source. Every accessibility issue has a code-level fix. Form labels, alt text, color contrast, heading structure, ARIA roles—all of these live in your HTML, CSS, and JavaScript. Patching them there is permanent. Patching them with an overlay is fragile and often ineffective.

3. Prioritize by lawsuit risk. Images without alt text, unlabeled form fields, missing skip navigation links, and inaccessible PDFs are the most commonly cited issues in ADA demand letters. Fix those first.

4. Document your remediation work. Maintain an accessibility statement on your site. Courts and plaintiffs' attorneys look for good-faith effort. An overlay doesn't demonstrate effort—it demonstrates that you paid someone else to not solve the problem.

5. Treat accessibility as ongoing maintenance. Every new page, feature, and content update needs to meet the standard. Build accessibility checks into your development workflow, not onto the end of it.

The Bottom Line on Accessibility Overlays and WCAG Compliance

Overlays are not compliant solutions. They are marketed compliantly, but they don't produce accessibility overlays WCAG compliance in any meaningful legal or technical sense. The companies selling them have faced regulatory scrutiny and ongoing litigation. The disabled users they claim to serve have publicly stated these tools often make sites harder to use, not easier.

The good news: most WCAG failures are fixable with straightforward code changes. You don't need a $500/month widget. You need to know what's broken and how to fix it.

Scan your site for free at wcagrepair.com and get a remediation guide with exact code fixes for $8.99. You'll see every failure, which WCAG success criterion it violates, and the specific code change required to fix it—no subscription, no overlay, no hand-waving.

Ready to scan your site?

Find and fix WCAG accessibility issues with our AI-powered scanner.

Scan Now