DEV Community

Cecilia Olivera
Cecilia Olivera

Posted on

Your Accessibility Overlay Is a Scam (And Here's the Proof)

You've probably seen them: that little wheelchair icon floating in the corner of websites, promising "accessibility" with one click. Maybe your company even pays for one. Products like accessiBe, UserWay, EqualWeb, and AudioEye promise to make your website accessible and legally compliant by just adding a single line of JavaScript.

It sounds too good to be true. Because it is.

Let me be clear from the start: I'm not being hyperbolic when I say "scam." In January 2025, the Federal Trade Commission fined accessiBe $1 million for deceptive marketing claims. The FTC determined that accessiBe was falsely claiming their product made websites "WCAG compliant" when it simply couldn't deliver on that promise.

And accessiBe isn't an outlier—it's the industry leader. The others make the same claims.

What accessibility overlays actually are

An accessibility overlay is a JavaScript widget that sits on top of your website. When users click on it, they get a panel with options like:

  • Change colors/contrast
  • Increase font size
  • Enable a "screen reader"
  • Activate "profiles" for blindness, dyslexia, ADHD, etc.
  • A magical toggle to "make the site WCAG compliant"

View of an open accessibility overlay showing its features

The pitch to businesses is irresistible: instead of spending money on actual accessibility work, just pay us $500-2000/year and we'll handle everything. Avoid lawsuits! Be compliant! One line of code!

Why they can't work (technically)

Here's the thing: web accessibility isn't about surface-level appearance. It's about the underlying structure of your HTML.

WCAG (Web Content Accessibility Guidelines) is the international standard that accessibility laws reference. It has specific technical requirements like:

  • Semantic HTML structure: headings (<h1>, <h2>), lists, landmarks
  • Properly labeled form fields: <label> elements correctly associated with inputs
  • Keyboard navigation: logical tab order, focus management
  • ARIA attributes: proper roles, states, and properties for dynamic content
  • Text alternatives: meaningful alt text for images (not auto-generated garbage)

An overlay is JavaScript that runs on top of your existing code. It cannot change your source code.

If your HTML uses <div> where it should use <button>, the overlay can't fix that. If your form fields don't have proper labels, the overlay can't create that association. If your modal doesn't trap focus correctly, the overlay can't restructure your DOM.

It's like putting a cardboard on a staircase and calling it a wheelchair ramp.

The features are either fake, redundant, or irrelevant

Let's break down what these overlays actually offer:

Fake: "Make site WCAG compliant" toggle

EqualWeb literally has an ON/OFF switch labeled "Make the site comply with WCAG."

This is the exact claim the FTC sanctioned. WCAG 2.1 has 78 success criteria. Many require structural changes to your codebase. No JavaScript widget can magically fix all of them with a toggle. This feature is, to put it plainly, a lie.

Fake: "Blindness profile"

Blind users already have screen readers. Professional ones. JAWS, NVDA (free), VoiceOver (built into Apple devices), TalkBack (Android). They've spent years learning these tools and configuring them to their needs.

An overlay that "adapts the site for blindness" can actually interfere with their existing screen reader, change keyboard shortcuts they rely on, and create an inconsistent experience across websites.

Moreover, I've checked that some of these screenreaders ignore aria-hidden, the standard for removing a node from the accessibility tree (AOM), which is the data structure that dependable screen readers use to know what they are allowed to read.

Fake: "AI-powered image descriptions"

Overlays claim to automatically generate alt text for images using AI. The problems:

  • The descriptions are generic ("a person smiling") instead of contextual ("CEO presenting Q3 results")
  • Decorative images should have alt="" (empty), but AI adds unnecessary descriptions
  • WCAG requires alt text to be functionally equivalent, which requires human judgment about purpose

Redundant: Everything else

Most overlay features already exist at the operating system level:

Overlay feature Already exists in...
Zoom/Magnification Windows Magnifier, macOS Zoom, browser Ctrl+/-
High contrast Windows High Contrast, macOS Increase Contrast
Color filters (colorblindness) Windows, macOS, iOS, Android color filters
Screen reader NVDA (free), VoiceOver (free), TalkBack (free), Narrator (free)
Large cursor System accessibility settings on all OS
Voice control Dragon, Windows Voice Control, macOS Voice Control
Text-to-speech Built into every modern OS and browser
On-screen keyboard Built into every OS
Dictionary Built into every OS (Ctrl+Cmd+D on Mac, right-click on Windows)

People who need these features already have them configured system-wide, working across all apps and websites. They don't need each website to provide its own inferior version. Also, none of them are WCAG requirements and therefore, not a web dev responsibility.

Irrelevant: "Profiles" for ADHD, Dyslexia, Epilepsy, etc.

WCAG doesn't have success criteria for "ADHD profile" or "dyslexia mode." These aren't legal requirements.

What WCAG does require is specific things like not having content that flashes more than 3 times per second (for seizure safety), proper text spacing, ability to pause moving content, etc. An overlay can't stop a video from flashing. An overlay can't fix your auto-playing carousel.

These "profiles" are marketing theater — they sound inclusive but don't address actual legal compliance.

They don't protect you from lawsuits

The whole pitch is "avoid lawsuits." But the data shows the opposite:

25% of accessibility lawsuits in 2024 were against websites with overlays installed.

The legal precedent is clear. In the Murphy v. Eyebobs case, the court explicitly rejected the argument that an overlay provided adequate accessibility. In the LightHouse v. ADP settlement, the agreement explicitly stated that "overlay solutions such as those provided by AudioEye and accessiBe will not be sufficient to achieve accessibility."

Plaintiff attorneys know about overlays. Finding an overlay on a website doesn't make them go away—it shows them you tried to take a shortcut instead of doing the actual work.

Over 1000 accessibility professionals have signed against them

The Overlay Fact Sheet is a public document signed by more than 1000 accessibility professionals worldwide, including:

  • Contributors to WCAG, ARIA, and HTML standards
  • Employees at Google, Microsoft, Apple, BBC
  • Independent accessibility consultants
  • Disability advocates

The statement is clear: overlays don't work, they often make things worse, and they represent a misallocation of resources that should go toward real accessibility.

accessiBe, UserWay, EqualWeb, and AudioEye are all explicitly named.

The European Disability Forum has warned against them

In May 2023, the European Disability Forum (EDF) and the International Association of Accessibility Professionals (IAAP) issued a joint statement:

"Overlays do not make the website accessible or compliant with European accessibility legislation. They do not constitute an acceptable alternative or a substitute for fixing the website itself."

This is particularly relevant now that the European Accessibility Act (EAA) is in effect as of June 2025.

They also introduce security risks

In November 2022, Imperva's security research team discovered a DOM XSS vulnerability in EqualWeb's widget. The vulnerability affected major clients including Fiverr, Bosch, Playtika, and Avis.

When you add a third-party JavaScript widget to your site, you're trusting that vendor with your users' security. These overlays load external scripts on every page load, expanding your attack surface.

What you should do instead

If you actually care about accessibility (and avoiding lawsuits):

  1. Remove the overlay. It's not helping. It might be hurting.

  2. Get an audit. Hire an accessibility professional to evaluate your site against WCAG 2.1 AA.

  3. Fix the actual issues. Work with your development team to address problems in the source code. This means semantic HTML, proper ARIA, keyboard navigation, color contrast, alt text, etc.

  4. Train your team. Designers, developers, and content creators should understand accessibility basics so new features don't introduce new barriers.

  5. Test with real users. Include people with disabilities in your QA process. They'll find issues automated tools miss.

Yes, this costs more than a few bucks a month. But it actually works. And it won't get you sued.

The bottom line

Accessibility overlays are selling you a lie: that you can buy compliance without doing the work. The FTC has called it deceptive. The disability community has rejected it. The data shows they don't prevent lawsuits.

If your company uses one, share this article with your manager. If you're a developer being asked to implement one, push back with this evidence. If you're evaluating accessibility solutions, run away from anyone promising a one-line JavaScript fix.

Real accessibility requires real work. There are no shortcuts.


Further reading:

Top comments (0)