¿Qué es un overlay de accesibilidad?

Un overlay de accesibilidad es una capa de software que se añade a un sitio web ya terminado. Normalmente llega como una línea de JavaScript que se pega en el código de la página, o como un plugin que se activa desde el gestor de contenidos. Al cargar la página, ese script inserta un botón flotante, casi siempre en una esquina, que abre un menú con ajustes visuales: tamaño de letra, contraste, tipo de cursor, pausa de animaciones, a veces lectura por voz.

La diferencia con la accesibilidad real está en dónde ocurre el cambio. Una implementación de accesibilidad trabaja en el código fuente: etiquetas HTML correctas, atributos ARIA en los componentes interactivos, navegación por teclado probada con usuarios reales, contraste calculado en el diseño. El overlay, en cambio, actúa después, desde fuera, sobre una página que puede seguir teniendo los mismos problemas estructurales debajo del menú de ajustes.

Este artículo no evalúa si los overlays son legales o ilegales, porque ninguna norma lo dice de forma explícita. Lo que sí existe es una base técnica y una postura documentada de organizaciones de accesibilidad en contra de tratarlos como solución completa. Esa base se desarrolla en el siguiente apartado.

El mecanismo es casi siempre el mismo. Un fragmento de JavaScript se ejecuta en el navegador del visitante, recorre el DOM de la página y aplica cambios sobre la marcha: agranda el texto, sube el contraste, añade o modifica atributos ARIA que faltan, intenta describir imágenes sin texto alternativo mediante reconocimiento automático.

El problema aparece en lo que ese script no puede hacer. Las WCAG 2.2, la norma técnica de referencia del W3C para contenido web accesible, exigen por ejemplo que toda la funcionalidad se pueda operar con teclado (criterio 2.1.1) y que cada componente de interfaz comunique su nombre, su rol y su estado a las tecnologías de asistencia (criterio 4.1.2). Un menú desplegable programado sin gestión de eventos de teclado no adquiere esa gestión porque un overlay le añada un contorno visual de foco: el evento que falta sigue faltando. Y un componente personalizado que nunca definió su rol no lo obtiene de forma fiable porque un script externo intente adivinarlo por patrones. Puede acertar en botones simples y fallar en un carrusel o en un formulario con validación propia.

El reconocimiento automático de imágenes tiene el mismo límite. Puede etiquetar una fotografía genérica con una palabra plausible, pero no sabe qué información concreta necesitaba transmitir esa imagen dentro del contenido: un gráfico con datos, un botón disfrazado de icono, una captura de pantalla con texto incrustado. Las WCAG 2.2 piden un texto alternativo que cumpla la función de la imagen (criterio 1.1.1), no una descripción aproximada generada sin contexto.

Por eso la crítica técnica no dice que los overlays no hagan nada. Dice que actúan sobre la capa visible y dejan intacta la capa de comportamiento que un lector de pantalla o un usuario de teclado necesita. En algunos casos añaden un problema nuevo: si el overlay reescribe atributos que el usuario ya había configurado en su propio lector de pantalla o en su navegador, esas dos capas pueden chocar entre sí, y la página queda menos accesible que antes de instalarlo.

El overlay se vende con frecuencia como solución de una sola línea de código para cumplir la Ley Europea de Accesibilidad o el resto de normativa de accesibilidad digital. Esa promesa es el problema: convierte una decisión técnica en una compra rápida y desplaza el presupuesto que debería ir a corregir el código fuente hacia una suscripción mensual que no llega a la raíz.

Sergio Luján Mora, profesor y especialista en accesibilidad web de la Universidad de Alicante, lo resume así en su blog: «El problema con los overlays es que, en lugar de hacer que los sitios web sean lo suficientemente flexibles para acomodar herramientas de accesibilidad, a menudo hacen que las páginas sean más rígidas, menos adaptables e incluso a veces anulan las preferencias del usuario» (2021). Es la valoración de un especialista reconocido en el sector, no una resolución oficial: ninguna norma menciona los overlays por su nombre.

La parte cara del error llega después. Si una empresa se apoya en el overlay para cerrar el asunto y más adelante recibe una reclamación o una inspección, no puede alegar que ya resolvió el problema. La base técnica sigue sin cumplir, y el gasto en el overlay se suma al coste de la corrección real que tarde o temprano hay que hacer.

Hay además una diferencia de fondo entre las dos partidas de gasto. La suscripción al overlay se paga mes a mes mientras la web exista, sin que el código mejore por ello. La corrección en el código fuente es un coste que se paga una vez y queda incorporado a la web: no depende de seguir pagando una cuota para no perderla.

• Antes de instalar nada, pedir una auditoría real con las WCAG 2.2 como referencia, hecha por una persona; un escáner automático no basta.
• Probar la web con teclado, sin ratón: tabular por todos los enlaces, botones y formularios y comprobar que el foco se ve y que nada queda atrapado.
• Probar con un lector de pantalla real (NVDA, VoiceOver): la portada no es suficiente, hay que cubrir también las páginas de mayor tráfico.
• Corregir en el código fuente lo que falte: etiquetas alt, roles ARIA, contraste de color, orden de encabezados, formularios con etiquetas asociadas.
• Documentar cada corrección con fecha, para poder demostrar el trabajo realizado si llega una reclamación.
• Si se usa un overlay, tratarlo como ayuda visual complementaria para el usuario final, nunca como sustituto del trabajo anterior.

• Instalar el overlay y dar por cerrado el proyecto de accesibilidad sin tocar el código.
• Confundir la ausencia de una norma que prohíba los overlays con una garantía de que cumplen la normativa de accesibilidad.
• No probar la web con teclado ni con lector de pantalla después de instalar el overlay, y asumir que funciona porque aparece el menú visual.
• Dejar que el overlay sea la única medida ante una Ley Europea de Accesibilidad con plazos y sanciones reales.
• No revisar si el overlay entra en conflicto con las herramientas de accesibilidad que el propio usuario ya tenía configuradas en su dispositivo, y descubrirlo solo cuando llega una reclamación.