All articles
WCAGCheck Editorial

38.5% of Accessibility Lawsuits Hit Sites That Thought They Were Compliant

Nearly 40% of web accessibility lawsuits in 2025 targeted sites with existing solutions. Here's why overlays fail and what actually works.

38.5% of Accessibility Lawsuits Hit Sites That Thought They Were Compliant

AudioEye's 2026 Web Accessibility Litigation Report contains a statistic that should concern every developer and agency: 38.5% of businesses sued for accessibility violations in 2025 already had an accessibility solution installed.

Read that again. These weren't sites that ignored accessibility. These were sites where someone had actively tried to address it. They installed a tool, ticked a box, and assumed the problem was solved.

It wasn't.

The Overlay Problem

Most of these "solutions" are accessibility overlays—JavaScript widgets that add a toolbar to your site with options like "increase text size" or "high contrast mode". You've seen them. A small icon in the corner that expands into a panel of accessibility controls.

The pitch is appealing: install one line of code, and your site becomes accessible. No redesign needed. No code changes. Just plug and play.

Here's why that doesn't work.

Overlays Don't Fix the Underlying Code

WCAG compliance isn't about adding features on top of a broken foundation. It's about the foundation itself.

Take WCAG 1.3.1 (Info and Relationships). This criterion requires that your HTML structure conveys meaning programmatically. If your form labels aren't properly associated with their inputs using for and id attributes, a screen reader can't tell users what information goes where.

An overlay can't fix that. It sits on top of your page. It doesn't rewrite your HTML. The broken form is still broken.

Or consider WCAG 2.1.1 (Keyboard). If your custom dropdown menu only works with mouse clicks because you've used <div> elements instead of proper <select> or ARIA-enabled components, keyboard users can't operate it.

An overlay adding a "keyboard navigation" toggle doesn't suddenly make your divs focusable and operable. The underlying component is still inaccessible.

Screen Reader Users Often Disable Overlays

People who use assistive technology daily have their own tools configured exactly how they need them. JAWS, NVDA, VoiceOver—these are sophisticated applications with extensive customisation options.

When an overlay tries to "help" by modifying page behaviour, it often conflicts with these existing setups. Many experienced screen reader users have written about disabling overlays immediately because they interfere with their preferred workflow.

You've added code that annoys your target users and doesn't help them navigate your actual content.

Automated Overlays Make Mistakes

Some overlays claim to use AI to automatically fix accessibility issues. They might attempt to generate alt text for images or adjust colour contrast on the fly.

Automated alt text is frequently wrong. An AI looking at a product image might describe "a blue rectangle" when what matters is "Nike Air Max 90 in navy, size selector showing UK 8-12". Context matters. Product details matter. The AI doesn't know your content.

Automatic contrast adjustments can break your brand, confuse users, and still fail to meet the 4.5:1 ratio required by WCAG 1.4.3 for normal text.

What Actually Achieves Compliance

WCAG compliance requires fixing your actual website, not layering workarounds on top.

Semantic HTML: Use the right elements for the right purpose. Headings (<h1> through <h6>) for document structure. <button> for buttons. <nav> for navigation. <main> for main content. This handles a significant portion of WCAG requirements automatically.

Proper Form Labels: Every input needs a label. The label needs a for attribute matching the input's id. This is WCAG 1.3.1 and 3.3.2.

Keyboard Operability: Every interactive element must be reachable and usable with keyboard alone. Tab order should be logical. Focus states should be visible (WCAG 2.4.7 requires this).

Sufficient Contrast: 4.5:1 for normal text, 3:1 for large text (WCAG 1.4.3). Test your actual colour combinations, not just your primary palette.

Alt Text Written by Humans: Someone who understands the content and context needs to write alt text. "Photo of team" is useless. "Sarah Chen, Lead Developer, presenting the new dashboard design at our Manchester office" is useful.

Captions and Transcripts: Video content needs accurate captions (WCAG 1.2.2). Audio content needs transcripts (WCAG 1.2.1).

The Real Fix Takes Work

There's no shortcut. Accessibility requires understanding your codebase, identifying issues, and fixing them properly. It means building accessibility into your development process, not bolting it on after launch.

The 38.5% of sued businesses learned this the expensive way. They paid for an overlay, then paid again for lawyers, settlements, and the remediation they should have done from the start.

Don't be in that statistic.

WCAGCheck scans your website for WCAG compliance issues and tells you exactly what to fix. Try it free at wcagcheck.co.uk