Overlays de accesibilidad: el parche de una sola línea que termina en una demanda

Respuesta breve: no. Un overlay de accesibilidad, el script que añade un widget a un sitio ya existente, no lo hace conforme. Las pruebas independientes muestran que los overlays detectan solo una fracción de los problemas de WCAG, una proporción creciente de demandas por accesibilidad señala a sitios que tienen uno instalado, y la FTC ya multó a un proveedor importante de overlays por afirmar lo contrario. El cumplimiento real se construye dentro de los componentes, no se superpone.

¿Qué es un overlay de accesibilidad y por qué se vende como una solución?

Un overlay es una única etiqueta <script> que un proveedor vende como un atajo hacia el cumplimiento. Una vez instalado, añade un widget flotante con controles para el tamaño de fuente, el contraste y un interruptor de "pausar animaciones", y ejecuta scripts automatizados que intentan parchear la página sobre la marcha: adivinando el texto alternativo, ajustando valores de color, reescribiendo atributos ARIA que no escribió.

La propuesta es genuinamente atractiva: sin revisión de código, sin tiempo de diseñador, y una insignia que declara que el sitio está protegido. Lo que omite es la parte que importa: el widget está adivinando sobre un sitio que no construyó, encima de una página que no puede ver por completo.

¿Qué parte de WCAG puede detectar realmente un overlay?

No la mayor parte. Las herramientas automatizadas, incluidos los escáneres integrados en los widgets de overlay, solo pueden evaluar de forma significativa una minoría de los criterios de éxito de WCAG por sí solas.

(Deque, Deque coverage report, por verificar.)

La brecha es estructural, no un error que la próxima actualización resuelva. Un script puede confirmar que una imagen tiene un atributo alt. No puede saber si ese texto describe la imagen, si un widget personalizado responde al teclado, o si el orden de lectura tiene sentido para un lector de pantalla. Esas son decisiones de criterio, y el criterio es justo lo que le falta a un overlay. El WebAIM Million, un análisis anual de un millón de páginas de inicio, encontró fallos detectables de WCAG 2 en el 95,9 por ciento de ellas en 2026, frente al 94,8 por ciento del año anterior (WebAIM, por verificar). La detección automatizada por sí sola no está cerrando esa brecha. La está ampliando.

¿Se menciona realmente a los overlays en demandas por accesibilidad?

Sí, y la tendencia no favorece al widget. El informe de demandas de 2024 de UsableNet encontró que aproximadamente una cuarta parte de todas las demandas por accesibilidad digital presentadas ese año apuntaba a sitios web que ya tenían un overlay instalado, y el propio overlay era citado como una barrera y no como una solución (reportado a través de cobertura secundaria de los datos de UsableNet, Accessibility.Works, por verificar). El propio monitoreo de 2025 de UsableNet muestra que el patrón se mantiene, con demandas que mencionan widgets de accesibilidad registradas todos los meses: 85 en enero, subiendo a 132 en febrero, para luego estabilizarse entre 99 y 119 al mes hasta junio (UsableNet, por verificar).

Que un widget esté presente no prueba que haya causado la demanda, ni que los sitios sin uno sean más seguros. A lo largo de dos años de seguimiento, un overlay no ha sido un sustituto creíble para corregir el código subyacente. Los bufetes de la parte demandante encuentran los problemas de todos modos, y los tribunales no lo han considerado un escudo.

¿Qué ocurrió con la FTC y accessiBe?

Este es el caso que convirtió "los overlays realmente no funcionan" de una queja de la comunidad en ley federal. En enero de 2025, la Comisión Federal de Comercio (FTC) anunció una denuncia y una propuesta de acuerdo contra accessiBe, uno de los proveedores de overlays más conocidos, acuerdo que se formalizó como orden el 21 de abril de 2025. La acusación: accessWidget, el producto de accessiBe, se comercializaba como capaz de hacer que cualquier sitio web fuera conforme con WCAG mediante IA, y eso era falso, ya que no lograba corregir componentes básicos como menús de navegación, campos de formulario y descripciones de imágenes. La denuncia además alegó que accessiBe maquilló testimonios de terceros para que parecieran independientes sin revelar su propia participación. La empresa pagó 1 millón de dólares y tiene prohibido afirmar que su producto puede hacer que un sitio sea conforme con WCAG, o mantenerlo conforme con el tiempo, sin evidencia que lo respalde (FTC, por verificar).

Se trata de uno de los mayores proveedores de la categoría, señalado por un regulador por haber exagerado lo que la categoría puede lograr. Tómese eso como el techo de lo que cualquier overlay puede prometer honestamente, no como el piso.

Entonces, ¿qué funciona realmente en su lugar?

No hay atajos. La solución es la misma disciplina que hace que un sitio sea bueno en todos los demás aspectos.

1. Empezar por el componente, no por la página. Cada botón, campo de formulario, menú y ventana modal se construye con HTML semántico y ARIA correctos desde la primera versión, no se corrige después.
2. Hacer de la navegación por teclado un camino de primera clase. Una función que solo funciona con el ratón no está terminada, sin importar su puntuación.
3. Probar con tecnología de asistencia real. Un lector de pantalla, una revisión exclusivamente con teclado, y una persona que depende de esa tecnología a diario detectan lo que un escáner no puede.
4. Exigir que el contraste y el movimiento cumplan la norma, no la prueba visual. Las relaciones de contraste de WCAG 2.2 AA y el soporte de prefers-reduced-motion se verifican, no se dan por hecho.
5. Volver a probar después de cada cambio. El cumplimiento es una propiedad de la versión actual, no un certificado que se obtiene una sola vez.

Por eso Thabrew Effect trata la accesibilidad como parte del mismo sistema que la visibilidad y la conversión, nunca como una partida delegada a un plugin. Un componente construido de forma accesible desde el principio sirve a la vez a cada visitante y a cada auditoría. Un widget superpuesto después solo sirve para una captura de pantalla.

Una nota clara antes de las preguntas frecuentes: nada de esto es asesoría legal. Resume investigaciones reportadas públicamente y una acción federal de cumplimiento. Cualquiera que enfrente una denuncia activa de accesibilidad necesita un abogado, no una entrada de blog.