Del código al lector: árbol de accesibilidad, API y modos del lector

En la lección anterior vimos que ARIA actúa exclusivamente sobre el árbol de accesibilidad, que ya conociste en el curso N3-C1. Ahora lo miramos desde ARIA: qué camino recorre un atributo desde tu código hasta el oído (o los dedos, con una línea braille) de quien navega, por qué el mismo marcado suena distinto en NVDA, JAWS, VoiceOver o TalkBack y cómo los modos del lector de pantalla cambian lo que significa cada rol.

La cadena completa: del DOM a la persona

Entre tu HTML y la persona usuaria hay cuatro eslabones, y cuando algo «no se anuncia» el fallo puede estar en cualquiera de ellos.

1. El DOM. El documento tal y como está en memoria: tu HTML y todo lo que JavaScript haya cambiado después. Es lo único que controlas directamente.
2. El árbol de accesibilidad. El navegador recorre el DOM y, para cada nodo relevante, calcula su rol, su nombre, su descripción, sus estados, sus propiedades y sus relaciones. Descarta lo que no aporta significado (buena parte de los <div> y <span> genéricos) y lo que está oculto. ARIA interviene exactamente aquí: sobrescribe o completa lo que el navegador habría deducido del HTML.
3. La API de accesibilidad de la plataforma. El navegador no habla directamente con el lector de pantalla: publica el árbol a través de la interfaz de accesibilidad del sistema operativo. En Windows, UI Automation e IAccessible2 (además de la antigua MSAA); en macOS, la API de accesibilidad de Cocoa (NSAccessibility); en iOS, UIAccessibility; en Linux, ATK y AT-SPI; en Android, la API de accesibilidad del sistema. Las especificaciones de correspondencia del W3C (Core-AAM para los roles y atributos ARIA, HTML-AAM para los elementos HTML) indican cómo debe traducirse cada rol y cada estado a cada una de esas API.
4. La tecnología de apoyo. El lector de pantalla, el magnificador o el control por voz consultan esa API, reciben sus eventos y deciden cómo presentar la información: qué palabra usan para el rol, en qué orden, qué muestran en la línea braille.

Qué decide ARIA y qué decide el navegador

Cuando un elemento lleva el atributo role, el navegador expone ese rol en lugar del implícito. Hay matices que explican muchos comportamientos aparentemente extraños:

• El atributo role admite una lista de valores. El navegador usa el primero que reconozca y descarta el resto. role="switch checkbox" se expone como interruptor donde se conozca switch y como casilla donde no. Si ningún valor es válido (role="boton"), el elemento conserva su rol implícito, como si no hubieras escrito nada.
• Algunos roles tienen hijos presentacionales. En roles como button, checkbox, img, tab, switch, slider, progressbar u option, la especificación indica que el contenido se aplana: el navegador expone su texto, pero cualquier semántica interior (un encabezado, una lista, una tabla) desaparece del árbol. Por eso un encabezado dentro de un botón deja de ser encabezado y la forma correcta es la inversa: el botón dentro del encabezado.
• Los cambios generan eventos. Cuando JavaScript modifica aria-expanded, aria-checked o el texto de una región activa, el navegador actualiza el árbol y lanza un evento de accesibilidad («ha cambiado el estado», «ha cambiado el nombre», «ha aparecido contenido»). La tecnología de apoyo escucha esos eventos. Así se cumple, en la práctica, la parte de 4.1.2 Nombre, función, valor que exige notificar los cambios.
• El navegador también repara el marcado contradictorio con reglas de resolución de conflictos (las veremos en la lección sobre ocultar y anular semántica). No confíes en esas reparaciones.

<div role="button" tabindex="0" class="tarjeta">
  <h3>Empadronamiento</h3>
  <p>Alta, baja y cambio de domicilio</p>
</div>

No busques la misma frase en todos los lectores

El mismo <button aria-expanded="false">Menú</button> no suena igual en todas partes: cada lector ordena a su manera nombre, rol y estado, usa sus propias palabras y aplica la verbosidad que haya elegido la persona. Es normal. Lo que debe coincidir es la información (se llama «Menú», es un botón, está contraído), no la frase. Si en algún lector falta una de esas piezas, entonces sí hay un problema.

Los modos del lector de pantalla

Los lectores de Windows más usados, NVDA y JAWS, trabajan sobre una representación virtual de la página y tienen dos formas de funcionar que cambian por completo qué hace cada tecla:

• Modo exploración (NVDA) o cursor virtual (JAWS): las pulsaciones no llegan a la página. Las flechas leen línea a línea y las letras son atajos de navegación rápida; por ejemplo, en NVDA H salta al siguiente encabezado y D al siguiente landmark (región de referencia como main o nav).
• Modo foco (NVDA) o modo formulario (JAWS): las pulsaciones pasan a la página para que puedas escribir en un campo o manejar un control con flechas. El lector cambia de modo automáticamente al entrar en un campo de texto y en muchos widgets compuestos, como listas de opciones, árboles o rejillas; la persona también puede cambiarlo a mano (en NVDA, con NVDA + Espacio).

VoiceOver en macOS no tiene esta dualidad: las teclas llegan a la página salvo que se combinen con Control + Opción, y la navegación por tipo de elemento se hace con el rotor. En móvil, VoiceOver y TalkBack se manejan con gestos.

La consecuencia para ARIA es directa: el rol influye en el modo. Si programas un componente que responde a las flechas (unas pestañas, una lista de opciones, un árbol de carpetas) pero no le das un rol de widget, en modo exploración las flechas nunca llegan a tus manejadores: el lector las consume para leer la siguiente línea. El componente funciona con el teclado sin lector y falla con él. Los roles de widget son la señal que el lector necesita para ceder el teclado.

role="application": el interruptor que casi nunca debes pulsar

role="application" indica a la tecnología de apoyo que esa zona es una aplicación que gestiona todas las pulsaciones por sí misma. Muchos lectores dejan entonces de interceptar el teclado: dentro de esa zona la persona pierde la lectura con flechas, los saltos por encabezados y los atajos de navegación. Solo tiene sentido en superficies con un modelo de teclado propio y completo para las que no existe rol de widget adecuado (un editor gráfico, un mapa con controles propios), acotado al mínimo elemento posible.

<!-- Incorrecto: toda la intranet se convierte en «aplicación» -->
<body role="application">
  …
</body>

Cómo ver lo que ve el lector

No hace falta adivinar qué hay en el árbol. Estas herramientas lo muestran:

• Chrome y Edge: panel Elementos, pestaña Accesibilidad. Muestra rol, nombre calculado y su origen, estados y propiedades, y permite ver el árbol completo.
• Firefox: el Inspector de accesibilidad enseña el árbol, las propiedades de cada nodo y avisos de problemas habituales. En Safari, el inspector web muestra las propiedades de accesibilidad del nodo.
• Nivel de plataforma: Accessibility Insights for Windows y el Inspector de Accesibilidad de Xcode en macOS enseñan lo que recibe el sistema operativo, útil cuando el navegador muestra algo correcto y el lector se comporta de otra forma.
• El propio lector: el Visor de voz de NVDA (menú de NVDA, Herramientas) muestra por escrito lo que dice; sirve para comparar y guardar evidencias.

Resumen

• La información viaja del DOM al árbol de accesibilidad, de ahí a la API de la plataforma y de ahí a la tecnología de apoyo; ARIA actúa en el paso del DOM al árbol.
• El navegador usa el primer rol válido de la lista, aplana el contenido de los roles con hijos presentacionales y lanza eventos cuando cambian estados y textos.
• Cada lector verbaliza a su manera: exige que llegue la misma información, no la misma frase.
• En NVDA y JAWS el rol influye en el paso a modo foco; un componente con flechas sin rol de widget falla con lector, y role="application" desactiva la lectura normal, así que casi nunca está justificado.
• Inspecciona el árbol con las herramientas del navegador y escucha con el Visor de voz antes de dar nada por bueno.