Overlays de accesibilidad: las críticas de 2025 explicadas

Actualizado: 2026-05-03

El 28 de junio de 2025 entró en vigor la European Accessibility Act en su aplicación plena al sector privado, y con ella una avalancha de ofertas comerciales prometiendo cumplimiento inmediato a cambio de añadir una línea de JavaScript a una web. Tres meses después, el panorama es revelador: las demandas contra empresas que usan overlays han aumentado, los grupos de usuarios con discapacidad han publicado manifiestos cada vez más contundentes y varios organismos reguladores europeos han emitido guías aclarando que estos productos no cumplen por sí solos.

Puntos clave

• Un overlay de accesibilidad es un script JS que modifica dinámicamente el DOM para supuestamente mejorar la accesibilidad — los más conocidos en Europa son accessiBe, UserWay, EqualWeb y AudioEye.
• La Comisión Europea publicó en julio de 2025 una nota aclaratoria de la EAA indicando que el cumplimiento debe ser sustantivo, no simbólico — las soluciones que enmascaran problemas estructurales modificando el DOM no constituyen cumplimiento.
• Los problemas reportados por usuarios reales son concretos: sobrescriben configuraciones de JAWS/NVDA, generan alt text erróneo en contextos críticos, y el propio panel de usuario a menudo no es accesible.
• El caso Murphy v. Eyebobs en EEUU estableció que accessiBe no sustituye al diseño accesible.
• La alternativa no es mágica pero es conocida: auditoría manual, corrección sustantiva del código, integración de linters (axe-core) en CI, y declaración de accesibilidad honesta.

Qué son los overlays y qué prometen

Un overlay de accesibilidad es un script de JavaScript que se añade a una web y que modifica dinámicamente el contenido para supuestamente mejorar la accesibilidad. Los productos más conocidos en el mercado europeo son accessiBe, UserWay, EqualWeb y AudioEye. Su promesa es atractiva: por una cuota mensual relativamente baja, la herramienta analiza la página, corrige problemas automáticamente, añade un panel de opciones al usuario y declara el cumplimiento con WCAG 2.1 o 2.2 en nivel AA.

La mecánica interna varía entre productos, pero el patrón común es un motor de detección que identifica elementos potencialmente problemáticos y aplica correcciones como añadir atributos ARIA, cambiar contraste, inyectar alt text generado automáticamente, ajustar tamaños de fuente o modificar comportamientos de teclado. El panel de usuario visible permite al visitante ajustar parámetros como ampliación, contrastes predefinidos, perfiles para dislexia o para TDAH, y desactivar animaciones.

El argumento comercial es claro: cumplimiento normativo sin tocar el código de la web ni rediseñar componentes. Para empresas con sitios heredados, con presupuesto limitado y con fecha límite legal aproximándose, la tentación es enorme. Y sin embargo, la evidencia de los últimos años apunta a que la promesa no se sostiene.

Por qué la comunidad afectada los rechaza

La crítica más contundente viene de los usuarios con discapacidad que realmente usan lectores de pantalla, software de ampliación, navegación por teclado u otras tecnologías de apoyo. En 2021 ya se publicó la declaración Overlay Fact Sheet, firmada por cientos de profesionales y activistas, rechazando el modelo. Desde entonces, el rechazo se ha consolidado y ampliado.

Los problemas reportados son concretos:

• Sobrescriben configuraciones de los usuarios: un usuario de NVDA o JAWS con su perfil afinado durante años recibe de repente una capa que cambia tags ARIA de forma impredecible, generando confusión.
• Alt text erróneo en contextos críticos: los atributos alt generados automáticamente con IA, aunque mejorados, siguen produciendo descripciones erróneas en formularios bancarios o información médica.
• El propio panel no es accesible: muchos usuarios con discapacidad reportan que el panel de usuario del overlay tiene controles que no reciben foco, usa contrastes deficientes o impone un flujo de navegación que rompe el del usuario. En palabras de varios activistas publicadas en 2024 y 2025, la frustración es doble: se les vende una solución y luego la solución les añade barreras.
• Privacidad: algunos overlays ejecutan análisis de comportamiento detallado para adaptar el perfil automáticamente, incluyendo datos que pueden revelar la discapacidad del usuario. Esto plantea problemas bajo el RGPD si no hay consentimiento explícito.

El terreno legal se ha endurecido

En Estados Unidos, las demandas bajo la ADA contra empresas que usaban overlays como única medida han ido creciendo. En varios casos conocidos, los tribunales han dictaminado que el uso de un overlay no absuelve a la empresa de responsabilidad si el sitio subyacente sigue siendo inaccesible. La sentencia más citada es Murphy v. Eyebobs, donde el tribunal explicitó que accessiBe no sustituye al diseño accesible.

En Europa, la situación en septiembre de 2025 apunta en la misma dirección. La Comisión Europea publicó en julio de 2025 una nota aclaratoria sobre la EAA subrayando que el cumplimiento debe ser sustantivo, no simbólico, y que las soluciones que modifican dinámicamente el DOM para enmascarar problemas estructurales no constituyen cumplimiento. Varios organismos nacionales, como el español Centro de Referencia Estatal de Autonomía Personal, han publicado guías desaconsejando explícitamente los overlays como única medida.

La consecuencia práctica es que una empresa que confíe exclusivamente en un overlay para cumplir la EAA se expone a multas y a demandas civiles con pocas defensas.

Por qué las empresas siguen comprándolos

A pesar de todo lo anterior, los overlays siguen vendiéndose. Las razones son comprensibles aunque no justificadas:

• Asimetría de información: el equipo directivo que decide comprar rara vez tiene contacto directo con usuarios con discapacidad ni con auditores de accesibilidad, y la página de marketing del proveedor parece convincente.
• Presión de plazo: con la EAA vigente desde junio de 2025, muchas empresas descubrieron tarde que no cumplían y buscaron soluciones rápidas.
• Aparente bajo coste: una suscripción mensual parece barata frente a una auditoría, una reestructuración de código y formación interna.

El problema es que las tres razones se disuelven con un examen cuidadoso. La asimetría de información se resuelve consultando con asociaciones como la ONCE, CERMI u organizaciones equivalentes en otros países, que publican posicionamientos claros. La presión de plazo no se alivia con un overlay que legalmente no cumple: solo se pospone el problema. Y el coste real de un overlay, sumando años de suscripción más la inevitable auditoría que termina llegando, suele superar al coste de hacer las cosas bien desde el principio.

Esta dinámica de solución aparente es análoga a la que ocurre con los overlays en la cadena de cumplimiento de la Ley de IA: la tentación de marcar una casilla sin hacer el trabajo sustantivo siempre termina siendo más cara que hacerlo bien desde el inicio.

Qué hacer en lugar de un overlay

La alternativa no es mágica, pero es conocida y funciona:

Primer paso: auditoría manual hecha por profesionales de accesibilidad, idealmente con participación de usuarios con discapacidad en las pruebas. Esto identifica problemas reales, priorizados por impacto. No es barato, pero es la base de cualquier plan serio.

Segundo paso: corrección sustantiva del código. Contrastes adecuados en el CSS, estructura semántica HTML correcta, atributos ARIA solo donde realmente aporten, foco visible, orden de tabulación coherente, formularios con etiquetas asociadas, y tests de teclado sistemáticos. Este trabajo se hace sobre la web, no encima de ella. Es el único que produce cumplimiento real.

Tercer paso: integrar accesibilidad en el flujo de desarrollo continuo. Linters como axe-core integrados en el pipeline de CI, revisiones de accesibilidad en los pull requests, formación periódica al equipo, pruebas con tecnologías de apoyo como parte de QA. Esto evita regresión y convierte la accesibilidad de proyecto puntual a práctica sostenida. Para proyectos construidos con Astro 5, la integración de axe-core en el CI de construcción es directa y detecta problemas antes de que lleguen a producción.

Cuarto paso (opcional pero valioso): publicar una declaración de accesibilidad honesta. Admitir los problemas conocidos que aún no se han resuelto, indicar un calendario, ofrecer un canal de contacto para usuarios que se encuentren con barreras. Esta transparencia es legalmente útil en la EAA y genera confianza en la comunidad.

Mi lectura

Después de varios años viendo este debate, mi lectura es que los overlays de accesibilidad son un caso ejemplar de solución aparente que empeora el problema. Se venden a quienes no saben lo suficiente para distinguir, dan la falsa sensación de cumplimiento, desincentivan las correcciones reales y dañan activamente a los usuarios que supuestamente protegen. El hecho de que sigan siendo un negocio rentable dice más sobre el vacío de información en el mercado que sobre su eficacia.

Mi recomendación práctica, para cualquiera que esté considerando contratar un overlay, es muy clara: no lo hagas. Invierte ese dinero en una auditoría real, en formación interna y en un plan de corrección a un horizonte razonable. Es más trabajo, cuesta más al principio y no produce una solución en una semana. Pero es lo único que cumple la ley, lo único que mejora la vida de los usuarios y lo único que sostiene a largo plazo.

Si ya contrataste un overlay antes de que esta información te llegara, no pasa nada: aprovecha la suscripción actual como ventana temporal mientras preparas la transición al trabajo real. Pero empieza la transición ya, porque cuando llegue la primera demanda o la primera inspección, ninguna página de marketing del proveedor te va a defender.