All articles
WCAGCheck Editorial

Accessibility Overlays Don't Meet UK Legal Requirements: What Developers Need to Know

Accessibility overlays won't protect you under UK law. Here's why outcome-based legal tests mean you need to fix your actual code.

Accessibility Overlays Don't Meet UK Legal Requirements: What Developers Need to Know

Accessibility overlays have been marketed as a quick fix for years. Drop a JavaScript widget on your site, and it'll make everything accessible. That's the pitch, anyway.

Recent legal guidance confirms what accessibility professionals have been saying all along: overlays don't satisfy UK accessibility law. If you're relying on one to protect your business, you're exposed.

What Are Accessibility Overlays?

Accessibility overlays are third-party tools that sit on top of your website. They typically add a toolbar icon that opens options like:

  • Text size adjustments
  • Contrast changes
  • Screen reader "optimisation"
  • Dyslexia-friendly fonts

Companies selling these tools often claim they'll make your site WCAG compliant automatically. Some even guarantee legal protection.

Popular overlay products include AccessiBe, UserWay, and AudioEye. They're attractive because they cost a few hundred pounds per year and take minutes to install. Compare that to properly fixing your codebase, which takes real development time.

Why Overlays Fail Under UK Law

The Equality Act 2010 requires service providers to make "reasonable adjustments" for disabled people. This applies to websites.

Here's the problem for overlay vendors: UK law uses outcome-based tests. It doesn't matter what tools you've installed. What matters is whether disabled users can actually use your service.

Overlays don't change your underlying code. They add a layer on top. This creates several failure points:

Screen readers already have these features. Users who need larger text or different contrast have system-level settings. They don't need your overlay duplicating (and often conflicting with) their existing tools.

Overlays can't fix structural problems. If your form fields lack proper labels, an overlay can't add them. If your images have no alt text, an overlay can only guess (badly) at what they show. If your keyboard navigation is broken, an overlay can't fix the tab order.

They often make things worse. Accessibility overlays frequently interfere with actual assistive technology. Screen reader users report overlays blocking their software, adding confusing announcements, or changing page behaviour unexpectedly.

Real WCAG Failures Overlays Can't Fix

Let's get specific. These common WCAG violations require code changes:

WCAG 1.1.1 (Non-text Content): Every image needs meaningful alt text written by someone who understands the content. An AI guessing "image of people" doesn't cut it.

WCAG 1.3.1 (Info and Relationships): Your heading structure needs to be logical. If you've styled <div> elements to look like headings instead of using proper <h1> through <h6> tags, an overlay can't restructure your DOM.

WCAG 2.1.1 (Keyboard): All functionality must work with a keyboard alone. If your custom dropdown only responds to mouse events, that's a JavaScript fix, not something an overlay can patch.

WCAG 4.1.2 (Name, Role, Value): Custom components need proper ARIA attributes. A date picker built from <div> elements needs role="dialog", aria-label, and keyboard handlers coded in.

The Legal Risk Is Real

In 2019, Beyoncé's website was sued under the ADA despite using an accessibility overlay. The plaintiff's lawyers specifically noted the overlay's presence and argued it didn't provide equivalent access.

UK cases haven't hit the headlines in the same way, but the Equality and Human Rights Commission has enforcement powers. They've previously investigated websites and required changes.

The legal test is simple: can a disabled user complete the same tasks as everyone else? If your checkout process traps keyboard users, no overlay changes that answer.

What Actually Works

There's no shortcut. Accessible websites require:

  1. Semantic HTML. Use the right elements for the job. Buttons should be <button>, not clickable <div> elements.

  2. Proper form labels. Every input needs a <label> with a matching for attribute.

  3. Keyboard testing. Tab through your entire site. Can you reach and operate everything?

  4. Screen reader testing. NVDA is free on Windows. VoiceOver is built into macOS. Use them.

  5. Automated scanning. Tools can catch about 30-40% of WCAG issues automatically. They're a starting point, not a complete solution.

  6. Manual review. Some things require human judgement. Is this alt text actually useful? Does this error message make sense?

The Bottom Line

Accessibility overlays are a liability, not a solution. They cost money, they don't work, and they won't protect you legally.

The only path to compliance is fixing your actual code. Start with automated scanning to identify the obvious issues, then work through them systematically. It takes longer than installing a widget, but it's the only approach that actually works.

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