Accesibilidad ≠ Overlay: cuando un overlay interfiere con el lector de pantalla

Los lectores de pantalla son programas que presentan en voz o braille la información que una interfaz expone de forma programática. Las personas que los utilizan aprenden sus comandos, configuran sus preferencias y desarrollan estrategias para moverse por encabezados, enlaces, regiones, formularios y controles. W3C incluye los lectores de pantalla entre las tecnologías de asistencia que las personas utilizan para interactuar con la web. Por eso, el punto de partida no debería ser sustituir esa tecnología desde la página, sino ofrecerle una web correctamente construida.

La interoperabilidad depende de la información que proporciona el código: HTML semántico, encabezados reales, enlaces y botones reconocibles, etiquetas asociadas a los campos, nombres accesibles, roles, estados y valores correctos, además de un orden y una gestión del foco coherentes. W3C explica que los lectores de pantalla pueden utilizar la estructura de encabezados para navegar y que los controles HTML estándar facilitan la interoperabilidad con las tecnologías de asistencia. Si esa base falla, el problema está en la implementación de la web.

Algunos overlays insertan JavaScript de terceros que analiza la página y trata de reparar problemas en el front-end. Esto significa que la tecnología de asistencia puede recibir una versión modificada de la interfaz, no necesariamente la misma estructura que generó originalmente el sitio. La Overlay Fact Sheet advierte de que esas reparaciones pueden ralentizar la carga o provocar cambios inesperados para usuarios de tecnologías de asistencia. No significa que cada overlay produzca siempre el mismo fallo, pero sí que añadir una capa de modificación introduce otra variable entre la web y el lector de pantalla.

Para una persona que navega sin visión, el foco no es un detalle visual: determina dónde está y qué elemento va a manejar. Un cambio inesperado de foco, una tecla interceptada o controles cuya semántica cambia pueden desorientar por completo. Lo mismo ocurre si aparecen encabezados artificiales, nombres poco fiables o estados que no se anuncian como corresponde. Las experiencias recopiladas por la Overlay Fact Sheet incluyen usuarios de lectores de pantalla que describen saltos de foco, navegación alterada y sitios que resultan más difíciles de usar con el overlay activo.

La pregunta no debería ser si el usuario ha activado un perfil especial, sino si la web funciona con su tecnología de asistencia habitual desde el primer momento. W3C señala que las personas con discapacidad utilizan configuraciones y herramientas distintas según sus necesidades y preferencias. Una solución accesible debe respetar esa diversidad. Obligar a descubrir un widget, abrirlo y seleccionar un modo adicional introduce pasos que no corrigen necesariamente las barreras originales.

NVDA, JAWS, VoiceOver, TalkBack y otras soluciones tienen comandos, modos y combinaciones diferentes. Además, cada persona configura voz, velocidad, puntuación, braille y preferencias de navegación según sus necesidades. Por eso es arriesgado diseñar una supuesta experiencia universal de «usuario de lector de pantalla». La accesibilidad robusta consiste en exponer información estándar y predecible para que navegadores y tecnologías de asistencia puedan interoperar.

Un buen encabezado no es solo texto grande. Un campo no es accesible solo porque haya una palabra visualmente cerca. Un botón no debería ser un elemento genérico al que después se intenta atribuir comportamiento. Cuando se utiliza HTML apropiado y, cuando hace falta, ARIA correctamente, el lector de pantalla puede comunicar la estructura y el usuario puede saltar entre encabezados, recorrer enlaces, localizar regiones o trabajar con formularios utilizando sus propios comandos. W3C recomienda utilizar elementos nativos siempre que sea posible y define ARIA como un mecanismo para comunicar roles, estados y propiedades a las tecnologías de asistencia.

Que se oiga texto no demuestra que una página sea usable. Hay que comprobar tareas completas: llegar al contenido principal, entender la jerarquía, abrir y cerrar menús, completar formularios, identificar errores, utilizar diálogos, recorrer resultados, controlar componentes dinámicos y recuperar la orientación después de cada interacción. También es importante probar con teclado y, cuando sea posible, involucrar a personas que utilizan estas tecnologías habitualmente.

Primero, identificar las barreras reales. Después, corregirlas en el componente, plantilla, tema o aplicación que las genera. Conviene trabajar con HTML semántico, patrones accesibles, gestión correcta del foco y pruebas con combinaciones representativas de navegador y tecnología de asistencia. La automatización puede ayudar a detectar determinados problemas, pero la experiencia con lector de pantalla requiere comprobaciones funcionales y humanas.

La entrega 06 pone el foco en una idea sencilla: el lector de pantalla pertenece al usuario, no al sitio web. La web debe ofrecer una interfaz sólida y predecible con la que esa tecnología pueda interoperar. Si una capa altera la estructura, el foco o la semántica, puede transformar una barrera conocida en otra diferente y más difícil de diagnosticar. La solución sostenible sigue siendo corregir la accesibilidad en origen y comprobar el resultado con tecnologías de asistencia reales.

W3C Web Accessibility Initiative (WAI)
Tools and Techniques — How People with Disabilities Use the Web
Page Structure Tutorial
WAI-ARIA Overview

Overlay Fact Sheet
Hoja informativa sobre los overlays — experiencias y limitaciones relacionadas con tecnologías de asistencia

Este artículo forma parte de la serie «Accesibilidad ≠ Overlay». Entrega 06 — Overlays y lectores de pantalla.