DEV Community: Cecilia Olivera

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

Cecilia Olivera — Sun, 25 Jan 2026 18:46:44 +0000

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"

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 overlay 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):

Remove the overlay. It's not helping. It might be hurting.
Get an audit. Hire an accessibility professional to evaluate your site against WCAG 2.1 AA.
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.
Train your team. Designers, developers, and content creators should understand accessibility basics so new features don't introduce new barriers.
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:

Overlay Fact Sheet — The public statement signed by 1000+ professionals
Overlay False Claims — Documented evidence of misleading marketing
FTC v. accessiBe — The $1M fine for deceptive practices
EDF/IAAP Joint Statement — European Disability Forum warning
Adrian Roselli's blog — Extensive documentation of overlay problems
WCAG 2.1 Quick Reference — What actual compliance looks like

¿Qué significa que Javascript está basado en prototipos?

Cecilia Olivera — Sat, 12 Sep 2020 09:21:05 +0000

Cuando empecé a estudiar Javascript y POO escuché muchas veces que a pesar de que Javascript es un lenguaje orientado a objetos no está basado en clases sino en prototipos.
En este artículo intentaremos entender qué significa exactamente esto y por qué es importante saber qué hace un prototipo.

En otros lenguajes orientados a objetos cuando declaramos una clase estamos creando un nuevo tipo de dato compuesto, es decir, un tipo de dato formado por tipos primitivos. Pero esto no es lo que ocurre en Javascript, a pesar de que desde ES2015 usemos la palabra reservada class. Los prototipos son instancias de objetos. Mientras que las clases son modelos, los objetos heredan directamente de otros objetos por defecto en JS.

Entonces, primero que nada tenemos que entender qué es la cadena de prototipos.

La cadena de prototipos es una estructura en forma de árbol que conecta funcionalidades entre objetos y en cuya raíz se encuentra Object.prototype. Object.prototype provee de una serie de métodos que aparecen en todos los objetos, como por ejemplo toString( ), hasOwnProperty( ) o keys( ).

Prácticamente todos los objetos en Javascript son instancias de Object si seguimos la cadena de prototipos. Y como probablemente ya sabes, casi todo es un objeto en Javascript. Incluso algunos tipos de datos primitivos (string, number y boolean específicamente) pueden ser objetos por fracciones muy pequeñas de tiempo. Entonces, los arrays son objetos, las funciones son objetos y, por supuesto, los objetos son objetos.

La cadena prototipal nos permite crear instancias de arrays, por ejemplo, que tengan acceso a todos los métodos definidos en Array.prototype como map, forEach, filter y un gran etc. Pero también obtenemos acceso a todos los métodos disponibles en Object.prototype.

Pero, ¿cómo ocurre esto?
Pues resulta que todos los objetos en Javascript tienen una propiedad oculta llamada __proto__ que guarda una referencia al objeto prototype del constructor. Siguiendo con el ejemplo de los arrays, un array tiene acceso a todos los métodos en Object.prototype porque cada array individual es una instancia del objeto Array, y el objeto Array es una instancia del objeto Object. Y esta cadena continúa hasta que llegamos al prototipo de Object.prototype, que será null.

De esta manera, cuando intentamos ejecutar un método en un objeto, Javascript primero buscará en las propiedades del objeto en cuestión. Si no encuentra una propiedad con ese nombre buscará en su propiedad __proto__, que guarda una referencia al objeto prototype de su constructor. Si no la encuentra ahí buscará en la propiedad __proto__ del objeto constructor. Esto continuará hasta que encuentre esa propiedad o método, o no la encuentre y lance un TypeError.

Por si acaso, ya que estamos usando los arrays como ejemplo, cabe recordar que los arrays son azúcar sintáctico en Javascript. Son objetos con un comportamiento especial, pero bajo la alfombra son algo así:

{
    ‘0’: value,
    ‘1’: value,
    ‘2’: value
}

Lo que esto significa es que, por ejemplo, cada vez que declaramos un array estamos creando una instancia del objeto Array que viene con el lenguaje. Si lo miramos en consola veremos que la propiedad __proto__ está vinculada al objeto Array:

Y si seguimos metiéndonos en la madriguera veremos que el objeto __proto__ tiene también una propiedad __proto__ que guarda una referencia a Object.prototype (es una referencia aunque nos salga en consola todo, porque ya sabes, DRY).

Entonces, ¿hay alguna forma de crear un objeto sin prototipo en Javascript?
Pues sí, la hay. Resulta que una de las formas que tenemos de crear objetos es con Object.create( ), a la cual podemos pasarle como argumento el objeto que queremos que sea el prototipo del nuevo objeto que queremos crear. Si le pasamos null estaremos creando un objeto que sea solo eso, una hash table:

const objetoSinPrototipo = Object.create(null);

What does it mean that Javascript is prototype based?

Cecilia Olivera — Fri, 11 Sep 2020 19:10:01 +0000

When I first started learning Javascript and OOP I heard over and over that Javascript is an object-oriented language though it is not based on classes but prototypes.
In this article we are going to try to understand what this means and why it is important to know what a prototype is to acknowledge what we are doing.

In other object-oriented languages when you declare a class you are creating a new complex data type, that is to say, a data type composed of primitive data types. But this is not what happens in Javascript even though we use the keyword class since ES2015. Prototypes are object instances. While a class is a blueprint, objects inherit directly from other objects by default in Javascript.

To understand what this means, we need to understand what the prototype chain is.

The prototype chain is a tree-shaped structure that connects objects functionality and at the root of this tree is where Object.prototype lays.
Object.prototype provides a few methods that show up in all objects, such as toString( ), hasOwnProperty( ) or keys( ).

Almost every object in Javascript is an instance of Object if we follow the prototype chain. And as you probably know, almost everything in Javascript is an object, even some primitive data types (string, boolean and number specifically) can be objects for a tiny fraction of time. So, arrays are objects, functions are objects and, of course, objects are objects.

The prototype chain allows us to create instances of, for example, arrays that have access to all the methods that are available for arrays, like map, forEach, reduce, filter, and a big etc. But arrays also have access to all the Object.prototype functionalities.

How does this happen?
Just to be clear because we are using arrays for the example, arrays are syntactic sugar in Javascript. They are objects with a special behavior to make them look and feel like an array, but under the hood, they are something like this:

{
  '0': value,
  '1': value,
  '2': value
}

It turns out that every object has a property called __proto__ which holds a reference to the prototype object of the constructor. So following the array example, an array has access to all the methods in Object.prototype because every array is an instance of the Array object and the Array object is an instance of the Object object. And this chain goes on until we hit the prototype of Object.prototype which will be null.

This way, when we try to execute a method on an object, first JS will lookup in the properties of the object itself. If it doesn’t find a property with that name, it will look in its __proto__ property, which holds a reference to the prototype object of its constructor. If it doesn’t find it there it will look in the __proto__ property of the constructor object. This will go on until it finds it or it doesn’t find it and throws a TypeError.

What this means is that, for example, every time we declare an array we are creating an instance of the Array object that comes with the language. if we look at it in the console we will see that its __proto__ property is linked to the Array object:

And if we keep looking down the rabbit hole we’ll see that the __proto__ object has a __proto__ property itself that holds a reference to Object.prototype (it’s a reference even though you see all the properties in the console because you know, DRY).

So, is there a way to create an object without a prototype in Javascript?

Well, yes there is. One of the ways of creating an object is with Object.create( ), to which we can pass as an argument the prototype we want that object to have, which by default is Object.prototype. If we pass it null as an argument we will get an object that is just that, a hash table.

const objectWithoutPrototype = Object.create(null);

Share if you liked it and let's connect! Follow me on Twitter and LinkedIn 😊