Un overlay de accesibilidad es un widget que se añade a un sitio web con una sola línea de JavaScript, que suele aparecer como un pequeño icono que abre un panel de ajustes de visualización: texto más grande, mayor contraste, una fuente apta para dislexia, ayudas de navegación por teclado y, en versiones más avanzadas, algunos intentos automatizados de añadir texto alternativo o etiquetas ARIA ausentes. Puede ayudar de verdad con algunos problemas, pero no sustituye a un código subyacente accesible, y ningún proveedor creíble afirma que cierre por sí solo todas las carencias de la WCAG.

Cómo funcionan realmente los overlays

Una vez instalado, un overlay se ejecuta como una capa de script sobre su sitio existente, en lugar de cambiar su HTML, CSS o código de aplicación subyacente. Cuando un visitante abre el panel del widget, este aplica ajustes de visualización de forma dinámica: ampliar el texto, aumentar la relación de contraste, cambiar las fuentes, pausar las animaciones o activar un modo de navegación por teclado. Los overlays más sofisticados, incluidos los de proveedores como accessiBe y UserWay, también ejecutan escaneos automatizados que intentan inyectar en tiempo real atributos de accesibilidad ausentes en la página, como generar texto alternativo para las imágenes que no lo tienen o añadir etiquetas ARIA a elementos interactivos sin etiquetar.

Como nada de esto toca su código fuente real, el efecto de un overlay desaparece en cuanto el script no llega a cargarse, un bloqueador de anuncios o un filtro de contenido lo bloquea, o el navegador de un usuario no lo ejecuta por cualquier motivo. Esa es una diferencia arquitectónica relevante frente a una corrección a nivel de código: un campo de formulario correctamente etiquetado está etiquetado correctamente sin importar qué script se cargue o no encima, mientras que una etiqueta aplicada por un overlay solo existe mientras el propio overlay se está ejecutando activamente.

Con qué pueden ayudar realmente los overlays

Para un sitio con restricciones reales de presupuesto o calendario, un overlay no es nada desdeñable. Puede dar rápidamente a los usuarios control sobre el tamaño del texto, el contraste y el movimiento, algo que importa para personas con baja visión, sensibilidad a la luz o afecciones vestibulares. Las mejoras de navegación por teclado pueden ayudar a los usuarios que no usan ratón. Y para propietarios de sitios sin recursos de desarrollo internos, es un punto de partida que se pone en marcha rápido, a menudo el mismo día, en lugar de esperar a un proyecto de corrección a nivel de código.

También hay un beneficio de visibilidad fácil de subestimar: el icono en pantalla de un overlay es una señal visible para los visitantes de que una empresa ha pensado en la accesibilidad, y para algunos usuarios, simplemente tener una forma rápida de aumentar el tamaño del texto o reducir el movimiento es una mejora real frente a un sitio sin ninguna opción de ajuste, aunque no sea una solución completa.

Lo que los overlays normalmente no pueden corregir

Los límites aparecen en todo lo que depende de cómo se construyó realmente el contenido y no de cómo se muestra. Un campo de formulario sin etiqueta programática, un menú desplegable personalizado al que le falta el rol ARIA y el comportamiento de teclado correctos, un vídeo sin subtítulos o una estructura de documento que no expone un orden de lectura lógico a un lector de pantalla: son problemas estructurales que un script superpuesto a la página tiene una capacidad limitada de corregir de forma fiable en todos los casos, sobre todo en sitios complejos o que cambian con frecuencia. La generación automática de texto alternativo es un buen ejemplo de esta carencia: una descripción generada por IA puede ser razonablemente precisa para la foto sencilla de un producto y claramente errónea para un gráfico complejo o una imagen con un significado cultural específico, sin que ninguna persona revise el resultado.

Los documentos PDF enlazados desde una página son otro punto ciego habitual: un widget que se ejecuta en la página HTML donde está instalado en general no tiene forma de acceder a un PDF enlazado y corregir su estructura interna, así que un sitio puede tener una página web totalmente ajustada justo al lado de un PDF inaccesible que el widget nunca toca. Lo mismo suele ocurrir con el contenido incrustado de terceros, como un widget de reservas o un formulario de pago incrustado mediante un iframe de un proveedor distinto, ya que un overlay tampoco puede normalmente cruzar esa frontera.

Por qué esta categoría recibe críticas reales

Este mismo patrón arquitectónico también explica por qué los overlays tienden a funcionar de forma inconsistente entre navegadores y dispositivos, de un modo en que no lo hacen las correcciones estructurales. Un ajuste basado en script puede comportarse de forma ligeramente distinta según la versión del navegador, otras extensiones activas en la página o el propio JavaScript del sitio, mientras que un marcado genuinamente accesible se comporta igual para todos los visitantes, sin importar qué más esté ocurriendo en su navegador.

Los profesionales de la accesibilidad han sido críticos abiertos de los enfoques basados solo en overlays durante años, y los datos respaldan que no es una opinión marginal. Una encuesta de WebAIM recogida por el Overlay Fact Sheet encontró que el 67% de los profesionales de la accesibilidad calificaba los overlays como “nada” o “poco” eficaces, y esa cifra subía al 72% entre los profesionales que tienen ellos mismos alguna discapacidad. Solo el 2,4% calificó los overlays como muy eficaces. Parte de la crítica tiene que ver con el marketing más que con la tecnología en sí: cuando un widget se vende como una solución completa y de una sola línea para el cumplimiento legal, crea una expectativa que la herramienta subyacente normalmente no puede cumplir, y en el caso de accessiBe esa brecha entre las afirmaciones de marketing y la capacidad real llevó a la FTC a ordenar un acuerdo de 1.000.000 de dólares en 2025 por afirmaciones engañosas sobre la corrección automatizada de accessWidget.

También existe una crítica más técnica: algunos comportamientos de los overlays pueden interferir con la tecnología de asistencia que un usuario ya ha configurado en su propio dispositivo o navegador, anulando de hecho preferencias que el usuario estableció de forma deliberada, lo cual resulta frustrante precisamente para las personas a las que se supone que sirve la herramienta. WebYes, una herramienta de pruebas centrada en WordPress, es uno de los proveedores que se posiciona explícitamente en contra de la corrección basada únicamente en overlays por esta razón, defendiendo en su lugar las correcciones a nivel de código.

Overlay, plugin, barra de herramientas: lo mismo con distintos nombres

Los proveedores usan varios términos distintos para esencialmente la misma categoría de producto. “Widget de accesibilidad”, “overlay de accesibilidad”, “plugin de accesibilidad” y “barra de herramientas de accesibilidad” describen todos, en general, la misma arquitectura: una capa de script que añade controles de visualización y, en productos más avanzados, algunos intentos de corrección automatizada sobre un sitio existente. La variación en el nombre es sobre todo cuestión de marketing, no una distinción técnica relevante, así que vale la pena evaluar cualquiera de estos productos con los mismos criterios, sin importar cómo lo llame el proveedor.

Dónde encajan los overlays en una estrategia realista

El planteamiento de “overlay frente a nada” pasa por alto la pregunta más útil, que es con qué se combina un overlay. Proveedores como Wawsome y EqualWeb venden el widget junto con corrección manual, auditorías revisadas por personas o monitorización continua, en lugar de como producto independiente, lo cual cambia de forma relevante lo que la oferta combinada puede lograr en comparación con un widget vendido solo. Un widget combinado con una revisión humana genuina cierra más carencias que la automatización funcionando sin supervisión, aunque ambos entren técnicamente bajo la misma etiqueta de “overlay”.

Antes de adoptar uno, vale la pena preguntar directamente a un proveedor: ¿hay algo en este producto que implique revisión humana en algún momento, o es totalmente automatizado de principio a fin? ¿Existe una declaración clara y por escrito de lo que la herramienta no cubre? ¿Y son transparentes el precio y la funcionalidad, o el marketing da a entender una cobertura más amplia de la que realmente respalda la documentación del producto? Esas preguntas hacen más por distinguir una herramienta genuinamente útil de una sobrevalorada que el planteamiento simple de “overlay sí o no”.

Si está evaluando si un overlay encaja con su sitio, nuestra guía que compara los widgets con las auditorías manuales y nuestro artículo sobre si los overlays realmente funcionan profundizan más en esas disyuntivas.