El parche que promete solucionar todo sin resolver nada
El argumento de venta es tentador: añade una línea de JavaScript a tu sitio web y obtén cumplimiento WCAG inmediato. Sin auditorías, sin refactorización de código, sin contratar especialistas en accesibilidad. Productos como UserWay, AccessiBe y AudioEye prometen exactamente eso: un overlay que se ejecuta sobre tu web existente y la "convierte" en accesible de forma automática.
El problema es que no funciona. Y con el European Accessibility Act (EAA) en aplicación desde junio de 2025, confiar en un overlay no solo es técnicamente insuficiente — es una exposición legal activa.
Qué son los overlays de accesibilidad
Un overlay de accesibilidad es una capa de JavaScript que se inyecta en una web existente y muestra, típicamente en una esquina de la pantalla, una barra de herramientas con controles como ajuste de tamaño de fuente, aumento de contraste, "modo lectores de pantalla" o simplificación de la interfaz.
Los proveedores más conocidos son:
- AccessiBe: el más agresivo en marketing, con precios desde 490 USD/año para sitios pequeños
- UserWay: posicionado como la alternativa más "empresarial"
- AudioEye: cotizada en bolsa, con contratos activos en administraciones públicas estadounidenses
- EqualWeb, Recite Me, MaxAccess: variantes del mismo modelo
Todos comparten la misma premisa: el problema de accesibilidad está en la presentación, no en el código. Un cambio visual al vuelo basta.
Esta premisa es falsa.
Por qué los overlays no funcionan
No tocan el HTML subyacente
La accesibilidad web no es un problema de apariencia. Un botón sin etiqueta aria-label, un formulario sin <label> correctamente asociado, una imagen sin alt, una estructura de encabezados incoherente, o un componente de fecha construido con <div> en lugar de los elementos HTML semánticos apropiados — ninguno de estos problemas se corrige añadiendo CSS o JavaScript encima.
Los overlays intentan inferir el propósito de los elementos y añadir atributos ARIA a posteriori. El resultado es impredecible y con frecuencia incorrecto. Añadir aria-label="botón" a un elemento que no comunica su función real no es accesibilidad: es ruido adicional para el usuario de lector de pantalla.
El OverlayFactSheet.com: 800+ profesionales en contra
En 2021, Karl Groves — investigador de accesibilidad y fundador de Tenon.io — creó OverlayFactSheet.com, un documento público que refuta las afirmaciones de los vendedores de overlays con evidencia técnica. A fecha de 2025, más de 800 profesionales de accesibilidad, desarrolladores y académicos lo han firmado, incluyendo figuras reconocidas como Lainey Feingold, Léonie Watson y Adrian Roselli.
El documento concluye que los overlays "no pueden lograr accesibilidad completa, automáticamente, para todos los usuarios", que presentan nuevos problemas de accesibilidad al código existente, y que ningún overlay puede identificar todos los problemas de una página.
La posición del European Disability Forum
El European Disability Forum (EDF), la organización paraguas que representa a 100 millones de personas con discapacidad en Europa, ha publicado posiciones explícitas contra los overlays. Su argumento es directo: los overlays desplazan el trabajo de accesibilidad desde los desarrolladores hacia los propios usuarios con discapacidad, que deben activar herramientas adicionales para acceder a contenido que debería ser accesible por defecto.
El EDF señala que esta carga adicional contradice el principio de igualdad de acceso que sustenta tanto la CRPD (Convención de la ONU sobre los Derechos de las Personas con Discapacidad) como el EAA.
La posición de la National Federation of the Blind
La National Federation of the Blind (NFB), la mayor organización de personas ciegas en Estados Unidos, adoptó en 2021 una resolución que condena explícitamente el uso de overlays. La resolución afirma que los overlays "no han demostrado lograr cumplimiento legal" y que "interfieren con las tecnologías asistivas que utilizan las personas ciegas".
La NFB insta a las organizaciones a no usar overlays y a invertir en accesibilidad nativa del código fuente.
Demandas contra AccessiBe
El fracaso de los overlays no es solo teórico. AccessiBe ha sido demandada en múltiples ocasiones en Estados Unidos bajo el Americans with Disabilities Act (ADA). En 2021, Newsweek publicó una investigación que documentó que cientos de sitios web que usaban AccessiBe seguían siendo inaccesibles para usuarios de lectores de pantalla, a pesar de mostrar el distintivo "AccessiBe Certified".
El modelo de negocio completo se basa en una promesa que no puede cumplirse: que un script automático puede resolver un problema que requiere decisiones de diseño humanas, revisión técnica y pruebas con usuarios reales.
Pueden empeorar las cosas para usuarios de lectores de pantalla
Quizá el problema más grave es que los overlays pueden activamente perjudicar a los usuarios que supuestamente ayudan. Los lectores de pantalla como JAWS, NVDA o VoiceOver procesan el DOM directamente. Cuando un overlay modifica el DOM en tiempo de ejecución — añadiendo, eliminando o alterando atributos ARIA — puede crear conflictos con la tecnología asistiva del usuario.
Usuarios de lectores de pantalla han documentado públicamente sitios donde el overlay hacía el contenido menos accesible que sin él: elementos que antes eran navegables por teclado dejaban de serlo, o el lector de pantalla anunciaba información incorrecta generada por la capa del overlay.
Qué exige realmente el EAA
La Directiva (UE) 2019/882 — el European Accessibility Act — establece requisitos de accesibilidad para productos y servicios digitales dirigidos al mercado europeo. No es una recomendación ni un estándar voluntario: es legislación vinculante.
El estándar técnico de referencia es EN 301 549
La norma técnica que operacionaliza el EAA es la EN 301 549 v3.2.1, que mapea directamente a WCAG 2.1 nivel AA. Esto incluye los cuatro principios: perceptible, operable, comprensible y robusto. Un overlay que modifica la presentación visual sin garantizar que el código subyacente cumple estos criterios no satisface la norma.
Sectores afectados desde junio de 2025
El EAA se aplica a servicios digitales en sectores específicos:
- E-commerce: tiendas online que venden a consumidores en la UE
- Banca y servicios financieros: banca online, aplicaciones de pago, contratos digitales
- Transporte: reservas online, información de viaje, check-in digital
- Telecomunicaciones: interfaces de gestión de servicios de comunicaciones
- Atención al cliente digital: chat, formularios, portales de soporte
Para todos estos sectores, el servicio digital completo debe ser accesible. No partes de él. No con ayuda de herramientas adicionales. Por defecto.
Sanciones por estado miembro
Las sanciones varían según la transposición nacional de la directiva, pero los marcos son significativos:
- España: hasta 1.000.000 € por infracción grave (Ley General de derechos de las personas con discapacidad, modificada para transposición del EAA)
- Alemania: hasta 100.000 € por infracción, con posibilidad de prohibición de comercialización
- Francia: hasta 50.000 € iniciales, con sanciones periódicas por incumplimiento continuado
Las autoridades de supervisión nacionales tienen capacidad para iniciar investigaciones de oficio, no solo a instancia de parte. Un overlay no constituye defensa válida frente a una inspección técnica.
Qué funciona realmente
Accesibilidad integrada desde el diseño
La accesibilidad efectiva no se añade al final: se diseña desde el principio. Esto implica que los equipos de producto incluyen criterios de accesibilidad en los criterios de aceptación de cada funcionalidad, los diseñadores trabajan con sistemas de color que superan los ratios de contraste WCAG, y los desarrolladores usan HTML semántico como primera opción en lugar de recurrir a <div> para todo.
HTML semántico, ARIA correcto, navegación por teclado
Las bases técnicas son conocidas y no requieren librerías complejas:
- Usar
<button>para acciones,<a>para navegación,<input type="...">para formularios - Asociar
<label>con<input>mediantefor/ido anidamiento - Proporcionar texto alternativo descriptivo en imágenes funcionales
- Garantizar que todos los flujos de usuario son completables solo con teclado
- Gestionar el foco correctamente en modales, dropdowns y widgets dinámicos
- Usar ARIA únicamente para aumentar semántica que HTML no puede expresar, nunca para sustituir HTML semántico
Auditorías regulares con tecnología asistiva
Las herramientas automatizadas como axe, Lighthouse o WAVE detectan entre el 30% y el 40% de los problemas de accesibilidad. El resto requiere revisión manual con lectores de pantalla reales (NVDA en Windows, VoiceOver en macOS/iOS, TalkBack en Android) y, cuando es posible, pruebas con usuarios con discapacidad.
Una auditoría anual no es suficiente en servicios que se actualizan frecuentemente. Lo ideal es integrar pruebas automatizadas en el pipeline de CI/CD y realizar auditorías manuales en cada lanzamiento mayor.
Para chat y soporte: construido desde cero con WCAG
El canal de atención al cliente digital merece atención especial. Los chatbots y widgets de chat son componentes interactivos complejos: mensajes que aparecen dinámicamente, botones de respuesta rápida, adjuntos de archivos, transcripciones. Un overlay no puede hacer accesible un componente de chat que no fue diseñado para serlo.
La solución correcta es elegir herramientas que implementen WCAG desde su arquitectura base. AISWise construye su widget de chat con accesibilidad nativa: navegación completa por teclado, anuncios ARIA para mensajes nuevos, roles semánticos en la interfaz de conversación y compatibilidad verificada con JAWS, NVDA y VoiceOver. Las empresas que necesitan cumplir el EAA en su canal de soporte pueden registrarse en aiswise.ai para ver cómo funciona en práctica.
El futuro: accesibilidad potenciada por IA más allá de los overlays
La inteligencia artificial tiene un papel legítimo en la accesibilidad — pero ese papel no es el que prometen los overlays.
Corrección estructural, no cosmética
La diferencia entre un overlay y un sistema de IA bien aplicado a la accesibilidad es la diferencia entre pintar encima de una pared con grietas y reconstruir los cimientos. La IA puede analizar el código fuente de un componente, identificar ausencias de semántica, sugerir la estructura ARIA correcta y generar tests de accesibilidad automatizados. Esto complementa el trabajo de los desarrolladores en lugar de intentar sustituirlo con una capa superficial.
Agentes IA que adaptan experiencias completas
El siguiente paso no es un widget de barra de herramientas que ajusta el tamaño de fuente. Son agentes IA capaces de entender el contexto de una interacción — qué está intentando hacer el usuario, qué tecnología asistiva está usando, qué restricciones cognitivas o motoras pueden estar presentes — y adaptar la experiencia de forma coherente y no invasiva.
Esto requiere que la web subyacente sea accesible. Un agente no puede adaptar lo que no puede leer. La accesibilidad estructural del código fuente es el prerequisito, no el objetivo final.
La visión de AISWise: del chat accesible a la accesibilidad web completa
En AISWise, empezamos por el canal donde la accesibilidad es más urgente para el EAA: la atención al cliente digital. Un chat de soporte accesible no es solo un requisito legal — es la diferencia entre un usuario con discapacidad que puede resolver su problema de forma autónoma y uno que tiene que llamar por teléfono porque la web no funciona con su lector de pantalla.
La accesibilidad nativa en el canal de chat es el punto de partida. Las empresas que quieran entender cómo construir soporte digital accesible que cumpla con el EAA pueden explorar AISWise y ver cómo se integra con sus herramientas existentes.
Conclusión
Los overlays de accesibilidad son, en el mejor caso, ineficaces. En el peor, activamente perjudiciales para los usuarios que supuestamente protegen. Y frente al EAA, son una defensa legal inexistente.
El European Accessibility Act exige accesibilidad real: código semántico, navegación funcional, compatibilidad verificada con tecnología asistiva. No píxeles recoloreados ni menús flotantes.
Las organizaciones que han invertido en overlays esperando cumplimiento automático tienen hasta junio de 2025 para corregir el rumbo. La pregunta no es si los overlays son suficientes — la evidencia técnica, académica y legal es unánime en que no lo son. La pregunta es cuánto tiempo queda para construir accesibilidad real.