Componentes complejos con lector de pantalla: probar los patrones de la APG

Los componentes personalizados (pestañas, combos con autocompletado, diálogos, menús desplegables, controles deslizantes) concentran buena parte de los hallazgos graves de una auditoría, y son justo lo que las herramientas automáticas no saben evaluar. En la lección de NVDA y JAWS aprendiste los comandos; en esta aprenderás un método para evaluar cada componente: qué debería anunciar, qué teclas debe aceptar, adónde debe ir el foco y cómo comprobarlo en escritorio y en móvil. La referencia es la APG (se abre en una ventana nueva) (ARIA Authoring Practices Guide, guía de prácticas de autoría ARIA) del W3C, que describe el comportamiento que las personas usuarias esperan y que los lectores están preparados para interpretar.

El método: contrato, teclado, lector y móvil

1. Identifica el patrón por su función. Antes de tocar nada, decide qué es el componente para quien lo usa: ¿un grupo de pestañas, un botón que despliega contenido (disclosure), un combo con sugerencias, un diálogo? El rol que haya elegido el equipo de desarrollo puede estar equivocado; tu referencia es lo que hace el componente, no lo que dice el código.
2. Escribe el contrato esperado. Del patrón de la APG extrae tres cosas: el rol, el nombre y los estados que deben anunciarse; las teclas que deben funcionar; y adónde va el foco al abrir, cerrar o seleccionar.
3. Prueba solo con teclado, sin lector, como viste en la lección de teclado y zoom. Si no se opera con teclado, ya tienes un fallo de 2.1.1 Teclado y el lector solo añadirá matices.
4. Prueba con NVDA en los dos modos. Llega al componente con Tab (el lector suele pasar a modo formulario) y también en modo navegación, con flechas o con las letras de navegación rápida, activándolo con Enter o Espacio. Muchos componentes funcionan en un modo y fallan en el otro.
5. Repite en móvil con VoiceOver o TalkBack: desliza hasta el componente, activa con doble toque y comprueba que los estados también se anuncian allí.

Tabla de referencia: qué debe anunciarse y qué teclas probar

Las palabras exactas cambian entre lectores e idiomas; lo que importa es que la información llegue. Usa esta tabla como guion de prueba y amplíala con los patrones de la APG que aparezcan en tu muestra.

Ejemplo detallado: el combo con autocompletado

Es el componente que más falla y uno de los más usados: buscadores de calles y municipios en sedes electrónicas, origen y destino en webs de transporte, buscadores de tiendas. Según WAI-ARIA 1.2 (se abre en una ventana nueva) y el patrón de la APG, el campo lleva role="combobox", aria-expanded y aria-controls apuntando a una lista con role="listbox"; cada sugerencia es un role="option" y el foco permanece en el campo mientras la opción activa se comunica con aria-activedescendant.

Versión que solo funciona para quien ve la pantalla:

<input type="text" id="calle" placeholder="Calle">
<ul class="sugerencias">
  <li class="activa">Calle Mayor</li>
  <li>Calle Mayor Alta</li>
</ul>

Versión que expone el contrato completo al árbol de accesibilidad:

<label for="calle">Calle</label>
<input id="calle" type="text" role="combobox"
       aria-autocomplete="list" aria-expanded="true"
       aria-controls="lista-calles"
       aria-activedescendant="calle-op1">
<ul id="lista-calles" role="listbox" aria-label="Calles sugeridas">
  <li id="calle-op1" role="option" aria-selected="true">Calle Mayor</li>
  <li id="calle-op2" role="option" aria-selected="false">Calle Mayor Alta</li>
</ul>

Guion de prueba con NVDA y el visor de voz abierto:

1. Tab hasta el campo: debe anunciarse el nombre («Calle»), el rol de cuadro combinado y que es editable.
2. Escribe «May»: ¿se comunica que hay sugerencias, ya sea por el cambio a expandido o por un mensaje con el número de resultados?
3. Flecha abajo: ¿se lee «Calle Mayor» y, según el lector, su posición en la lista?
4. Enter: ¿el valor pasa al campo, la lista se cierra y el lector confirma el valor?
5. Escape: ¿se cierra la lista sin borrar lo escrito?
6. En iOS con VoiceOver: ¿puedes llegar a las sugerencias deslizando y elegir una con doble toque?

Diálogos: lo que solo el lector revela

Con teclado ya habrás comprobado que el foco queda atrapado dentro del diálogo y que Escape lo cierra. Con lector añade cuatro comprobaciones:

• Al abrir: ¿se anuncia que es un diálogo y su título? El nombre suele venir de aria-labelledby apuntando al encabezado del diálogo.
• En modo navegación: ¿puedes salir del diálogo con Flecha abajo o con H y acabar leyendo el contenido de fondo? Con el elemento <dialog> abierto mediante showModal(), el resto de la página queda inerte; con role="dialog" depende de aria-modal, de inert y del soporte de cada combinación, y por eso se prueba en todas las de la línea base.
• Al cerrar: ¿el foco vuelve al botón que lo abrió, o se pierde y el lector empieza a leer desde el principio de la página?
• En móvil: ¿VoiceOver o TalkBack permiten deslizar hacia el contenido de detrás?

Los fallos se registran normalmente en 2.4.3 Orden del foco (foco que se escapa o no vuelve) y en 4.1.2 Nombre, función, valor (diálogo sin rol o sin nombre); si no se puede salir con teclado, en 2.1.2 Sin trampas para el foco del teclado.

Un caso clásico: la navegación del sitio con role="menu"

Los roles menu y menubar están pensados para menús de aplicación, como los de un programa de escritorio. Cuando se aplican a la navegación principal de un sitio, el lector anuncia «barra de menú» y «elemento de menú», suele pasar a modo formulario y la persona usuaria espera moverse con flechas. Si el script no implementa ese modelo de teclado, la experiencia se rompe: las flechas no hacen nada y el comportamiento contradice lo anunciado. Para la navegación de un sitio, la APG recomienda el patrón de botones desplegables con enlaces normales.

Criterio práctico para el informe: si en una combinación de la línea base el componente no se puede operar, es un fallo (2.1.1 o 4.1.2 según la causa). Si se puede operar pero contradice lo que anuncia, regístralo con su criterio cuando el rol o el estado expuestos sean incorrectos, y añade siempre la recomendación del patrón adecuado.

Resumen

• Evalúa cada componente con el mismo método: identificar el patrón por su función, escribir el contrato esperado, probar con teclado, con lector en ambos modos y en móvil.
• La APG describe el comportamiento esperado; no es obligatoria, pero un rol ARIA declarado promete unas teclas y unos anuncios que deben cumplirse.
• En combos, comprueba con el visor de voz que la opción activa se anuncia en cada pulsación; si no, es un fallo de 4.1.2.
• En diálogos, verifica el anuncio de rol y título, que el fondo no sea accesible en modo navegación y que el foco vuelva al disparador.
• role="menu" en la navegación del sitio es una fuente habitual de problemas: recomienda el patrón de botones desplegables.