¿Los overlays de accesibilidad son una trampa legal? Lo que dicen la FTC, los tribunales y 800+ expertos

¿Qué es un overlay de accesibilidad?

Un overlay de accesibilidad es un fragmento de JavaScript —un widget, plugin o barra de herramientas— que se carga en tu web e intenta parchear los problemas de accesibilidad al renderizar, normalmente añadiendo un icono flotante (a menudo un símbolo de silla de ruedas) que deja al visitante ajustar contraste, tamaño de texto y espaciado (Compliapoint, 2026). Algunos productos afirman usar IA para detectar y reparar violaciones de WCAG de forma automática. La característica que los define es lo que no hacen: un overlay modifica cómo se ve tu página sin cambiar el código fuente que está debajo.

La categoría es grande y comercial. Los productos más comunes son accessiBe, UserWay, AudioEye y EqualWeb, vendidos como suscripciones recurrentes que van de cerca de 490 a 3.990 dólares al año, y la Overlay Fact Sheet lista más de 30 empresas que venden estas herramientas, muchas de marca blanca, así que un comprador puede ni saber de quién es el código que corre (a11y Collective, 2026). El discurso es el mismo en todos los proveedores —pega una línea de código y cumple— y es justo esa promesa la que persiguió la FTC.

¿Cómo sabes si un sitio ya usa uno?

Dos comprobaciones rápidas. A la vista, busca un botón flotante pequeño —a menudo un círculo con un icono de silla de ruedas o de una persona— por lo general en una esquina inferior, que abre un menú de ajustes de contraste, tamaño de fuente y espaciado. A nivel técnico, mira el código fuente o las solicitudes de red y busca el script del proveedor: nombres de archivo como acsb.js de accessiBe, userway.js de UserWay, o un dominio de AudioEye son exactamente las firmas que buscan los escáneres de los demandantes. Si encuentras uno en tu propio sitio, lo prudente no es arrancarlo con pánico, sino iniciar una auditoría real en el código fuente, porque las barreras que el widget enmascaraba siguen ahí — y ahora sabes que hay que arreglarlas bien.

¿Qué halló la FTC, exactamente?

Halló que la promesa era falsa, y le puso un número. En una orden de 2025, la Comisión Federal de Comercio de EE. UU. multó a accessiBe con un millón de dólares por publicidad engañosa (Hudson Cook, 2026). La afirmación concreta que sancionó era llamativa por su seguridad: accessiBe vendía su accessWidget como capaz de volver un sitio conforme al 30% de WCAG al instante y totalmente conforme al 70% restante en 48 horas, con un re-escaneo cada 24 horas para mantenerlo (Hudson Cook, 2026). La FTC halló esas afirmaciones falsas, engañosas o sin fundamento, y señaló que el widget no logró que componentes básicos —menús, encabezados, tablas, imágenes, grabaciones— fueran accesibles.

Hubo un segundo engaño que abordó la orden: accessiBe había presentado respaldos pagados como si fueran reseñas independientes, sin revelar la conexión (Brickfield, 2026). La orden de consentimiento ahora le prohíbe afirmar que sus productos vuelven cualquier sitio conforme a WCAG o mantienen el cumplimiento con el tiempo. Fue la primera acción federal contra un proveedor de overlays, y desmontó el relato de marketing en el que se apoyaba toda la industria (Kha Creation, 2026).

¿Por qué un overlay no puede volver conforme a un sitio?

Porque la mayor parte de la accesibilidad vive en el código fuente que un overlay nunca toca, y la automatización tiene un techo duro. Ninguna herramienta automática —ni con la IA actual— detecta, y mucho menos repara, más de cerca del 30 al 40% de los criterios WCAG (Accessibility.Works, 2026). WCAG 2.1 tiene 78 criterios de éxito, y muchos exigen decisiones estructurales que un script no puede tomar: si una imagen es decorativa o informativa, si un proceso de pago a medida se opera por teclado, si un texto alternativo tiene sentido (Kha Creation, 2026).

Hay además toda una categoría de contenido que los overlays simplemente ignoran. No hacen nada por la accesibilidad de los PDF, las presentaciones, los archivos de audio y de video — y la FTC señaló que los términos de servicio de un proveedor importante no revelaban de forma adecuada que esos formatos no se volverían accesibles sin contratar servicios adicionales (Brickfield, 2026). Un widget que pinta por encima de la portada no cambia nada del documento inaccesible que un cliente de verdad necesita leer.

¿Por qué tener un overlay vuelve más probable una demanda?

Porque para el abogado de un demandante el widget es una bandera, no un escudo — y los datos lo muestran. En la primera mitad de 2025, cerca del 22,6% de las demandas de accesibilidad web apuntaron a sitios que ya tenían un overlay instalado, con casi 500 de esas demandas; dado que los overlays corren en una minoría de los sitios, eso es una sobre-representación enorme (Compliapoint, 2026; Charles Jones, 2026). En 2024, más de 1.000 empresas que corrían widgets de accesibilidad fueron demandadas (a11y Collective, 2026).

El mecanismo es específico. Los bufetes corren escáneres automáticos que buscan firmas de código como userway.js o acsb.js, fáciles de detectar, y la presencia de un overlay señala dos cosas útiles: una empresa con presupuesto que está al tanto de la accesibilidad, y un sitio cuyo código de base probablemente está lleno de violaciones que el widget enmascara (Kha Creation, 2026). Peor: instalar el widget documenta que sabías que la accesibilidad era obligatoria y elegiste un parche superficial — lo que un tribunal lee como elegir la opción más barata que sabías que no funcionaba, lo contrario de un esfuerzo de buena fe (a11y Collective, 2026).

¿Qué han dicho los tribunales?

Han rechazado la defensa del overlay una y otra vez, y con claridad. En LightHouse contra ADP, el acuerdo estableció que las soluciones de overlay como las de AudioEye y accessiBe no bastarían para lograr la accesibilidad — una línea llamativa porque nombraba proveedores directamente (Kha Creation, 2026). En Murphy contra Eyebobs, un demandante ciego demandó a un minorista que usaba el widget de accessiBe, el tribunal se negó a desestimar el caso apoyándose en el overlay, y el acuerdo obligó a Eyebobs a quitarlo y hacer una remediación manual real hasta WCAG 2.1 AA, contratar a un coordinador de accesibilidad y correr pruebas con usuarios (Kha Creation, 2026).

Las promesas de los proveedores han salido igual de mal. En una demanda colectiva de 2024, la empresa de envío de flores Bloomsybox demandó a UserWay tras recibir una demanda de accesibilidad seis meses después de instalar el widget que había comprado en parte por una “garantía de litigio” de un millón de dólares anunciada; cuando Bloomsybox buscó esa protección, según se reporta le dijeron que su plan mensual no calificaba, le entregaron una guía genérica, y la dejaron arreglárselas sola tras 4.000 dólares en honorarios (AccessiTree, 2026). El tribunal permitió que el caso de marketing engañoso contra UserWay avanzara.

¿Los overlays ayudan de verdad a los usuarios con discapacidad?

Con frecuencia empeoran la experiencia, que es la parte que el marketing nunca menciona. Los overlays suelen interferir con la tecnología asistiva que la persona ya usa —JAWS, NVDA, VoiceOver— cambiando atajos de teclado y manejando mal el árbol de accesibilidad, a veces ignorando aria-hidden para que un lector de pantalla anuncie cosas que debería saltar (DEV Community, 2026). La respuesta de los usuarios con discapacidad es elocuente: muchos han instalado extensiones de navegador específicamente para bloquear los overlays, un miembro de la comunidad los llamó sin rodeos “malware”, y la Federación Nacional de Ciegos devolvió un patrocinio de accessiBe y aprobó una resolución en contra del producto (AccessiTree, 2026; a11y Collective, 2026).

El consenso profesional está documentado y es amplio. La Overlay Fact Sheet, una declaración pública firmada por más de 800 profesionales de la accesibilidad —entre ellos el presidente del grupo de tareas de prácticas de autoría de ARIA del W3C, colaboradores del lector de pantalla NVDA, y responsables de accesibilidad de empresas como Microsoft, Google y Amazon— afirma que ningún overlay puede volver un sitio totalmente conforme a ningún estándar y, por tanto, no puede eliminar el riesgo legal (a11y Collective, 2026). Hay también una dimensión de privacidad: un overlay que detecta el uso de tecnología asistiva sin consentimiento maneja datos sensibles sobre la condición de discapacidad, lo que abre sus propias preguntas de cumplimiento bajo regímenes como el RGPD (Brickfield, 2026).

¿Qué dice la ley europea sobre los overlays?

El mismo veredicto, desde el otro lado del Atlántico. La European Accessibility Act entró en vigor el 28 de junio de 2025, y exige que los servicios digitales privados de la UE cumplan EN 301 549, que incorpora WCAG 2.1 AA, con sanciones que llegan hasta 3 millones de euros en algunos Estados miembros y, en la implementación de Irlanda, la posibilidad de prisión (Brickfield, 2026). Un overlay no la satisface, y los organismos europeos lo han dicho directamente: una declaración conjunta del Foro Europeo de la Discapacidad y la Asociación Internacional de Profesionales de la Accesibilidad concluyó que los overlays no logran el cumplimiento (Accessibility.Works, 2026).

Para un negocio que atiende a EE. UU. y a la UE, esto cierra el último escondite del atajo. Un widget que falla la ADA en los tribunales estadounidenses también falla la EAA en los europeos. Y hay un detalle propio del marco español: la ley exige una Declaración de Accesibilidad veraz, con el nivel real de cumplimiento — algo que un overlay no puede generar con honestidad, porque no sabe qué se arregló de verdad en tu código. Estés donde estés, el overlay es el mismo pasivo en otra jurisdicción — y la remediación en el código fuente es la respuesta en todas.

¿Qué funciona de verdad en su lugar?

La remediación en el código fuente — arreglar el HTML real para que el sitio sea accesible por construcción en vez de disfrazado al renderizar. Eso implica una auditoría manual contra WCAG 2.1 o 2.2 AA, idealmente con pruebas de personas que de verdad usan tecnología asistiva, y luego corregir el código: usar el elemento correcto para cada cosa, de modo que un menú de navegación sea un <nav>, un encabezado sea un <h1> y no un <div> con estilo, y un botón sea un <button> real y no un div con clic (Charles Jones, 2026). La versión más rentable es desplazar la accesibilidad al inicio —integrarla en el diseño y el desarrollo— para que los problemas nunca lleguen a producción.

El cálculo legal también la favorece. A diferencia de un overlay, la remediación en el código puede cubrir el 100% de los criterios WCAG, y una auditoría fechada más una Declaración de Accesibilidad veraz te dan evidencia documentada de buena fe — la posición más fuerte posible en una disputa o una revisión de compras (Compliapoint, 2026). Es la misma conclusión a la que llega, desde el lado regulatorio, nuestro pilar sobre si la accesibilidad web es obligatoria: la accesibilidad se construye, no se compra, porque la versión construida es la única que es real.

Por qué no vendemos overlays

Porque no podemos recomendar un producto que la FTC sancionó y que los tribunales rechazan, y no estamos en el negocio de venderlo. No revendemos ningún overlay ni widget de cumplimiento, que es justo por lo que esta valoración no nos cuesta nada darla derecha: si la promesa central de un proveedor es cumplimiento de un clic o en 48 horas, trátalo como la señal de alarma, no como la función. La versión honesta de la accesibilidad es más lenta, vive en tu código real, y produce un sitio que funciona para quien usa un lector de pantalla esté o no mirando alguien.

Ese es el punto de construir la accesibilidad en vez de pegarla encima. Para el panorama completo —qué leyes aplican, cómo funcionan las demandas, y por qué la respuesta que dura es la construcción y no un widget— esta guía vive bajo nuestro pilar sobre si la accesibilidad web es obligatoria.