El teclado y las tecnologías de apoyo: lectores de pantalla, voz, conmutadores y ampliadores

Decíamos al empezar el curso que, si una interfaz funciona con teclado, funciona con la mayoría de las tecnologías de apoyo. Es cierto como punto de partida, pero no basta: un lector de pantalla, un programa de control por voz o un conmutador no se comportan exactamente como una persona que pulsa Tab. Usan el foco, sí, pero también interceptan teclas, activan los controles por su cuenta y dependen de los nombres y roles que expone tu código. Esta lección explica cómo interactúan con el teclado y el foco las principales tecnologías de apoyo y qué consecuencias tiene eso para quien desarrolla. Su manejo para auditar lo verás en el nivel de auditoría.

Qué entienden las WCAG por «interfaz de teclado»

Las WCAG definen la interfaz de teclado como la que usa el software para recibir pulsaciones de teclas, y aclaran que también la utilizan otros dispositivos que las emulan: teclados en pantalla, sistemas de reconocimiento de voz o dispositivos de soplido y aspiración. Por eso 2.1.1 Teclado protege a mucha más gente que a quien usa un teclado físico. Pero esas tecnologías no solo envían teclas: también leen el árbol de accesibilidad y piden al navegador que ejecute acciones sobre los elementos. Una interfaz que solo responde a eventos de teclado concretos puede pasar la prueba con teclado y fallar con ellas.

Lectores de pantalla en el ordenador: dos modos y dos cursores

NVDA y JAWS en Windows trabajan con dos modos:

• Modo exploración (o modo virtual): el lector presenta la página como un documento que se recorre con las flechas, línea a línea, y usa letras sueltas para saltar por elementos. En NVDA, H va al siguiente encabezado, K al siguiente enlace, B al siguiente botón, F al siguiente campo de formulario y D a la siguiente región. Estas teclas no llegan a la página: las consume el lector.
• Modo foco (o modo formulario): al entrar en un campo de texto o en muchos componentes con rol compuesto, el lector deja pasar las teclas a la página. Solo entonces tu manejador de keydown recibe las flechas y las letras. En NVDA se puede alternar manualmente con Insert+Espacio.

De aquí salen tres consecuencias prácticas:

1. La activación debe estar en el evento click. En modo exploración, cuando la persona pulsa Intro o Espacio sobre un elemento, el lector no reenvía la tecla: pide al navegador que active el elemento, lo que normalmente genera un click. Un control personalizado que solo escucha keydown funciona con teclado y no funciona con el lector.
2. El cursor del lector no es el foco. Leer con las flechas en modo exploración no siempre mueve document.activeElement. Si una información o un botón solo existe en el DOM cuando algo recibe el foco, quien lee con las flechas puede no encontrarlo nunca.
3. Los roles deciden el modo. El rol que pones a un componente influye en si el lector cambia a modo foco. Por eso un rol equivocado (un role="menu" en la navegación del sitio, por ejemplo) cambia las teclas que funcionan.

<div role="button" tabindex="0" id="favorito">Añadir a favoritos</div>
<script>
favorito.addEventListener('keydown', (e) => {
  if (e.key === 'Enter') marcarFavorito();
});
</script>

Existe un rol que desactiva el modo exploración en toda una región: role="application". Con él, el lector deja de ofrecer la navegación por encabezados y enlaces y pasa todas las teclas a tu código. Solo tiene sentido en interfaces que funcionan como una aplicación de escritorio y tienen un modelo de teclado completo y documentado, como un editor gráfico. En una web de contenidos o en un formulario, casi nunca es la respuesta.

Móviles y tabletas

Con VoiceOver en iOS y TalkBack en Android, los gestos mueven el foco del lector de elemento en elemento y el doble toque activa el elemento enfocado. No hay ningún keydown: otra razón para que la activación esté siempre en click. Cuando tu código llama a focus() (al abrir un modal o cambiar de vista), los lectores móviles suelen llevar su foco a ese elemento, así que la gestión del foco que vimos en lecciones anteriores también protege a quien usa el móvil.

Además, cada vez más personas usan un teclado físico con la tableta o el móvil. iOS y iPadOS incluyen la opción «Acceso total con el teclado» (en Ajustes, Accesibilidad, Teclados), y Android permite recorrer la interfaz con Tab y las flechas desde un teclado externo. Los criterios de teclado se aplican igual en la versión móvil de tu web.

Control por voz

Dragon en Windows, Control por voz en macOS e iOS, Acceso por voz en Windows 11 y Voice Access en Android permiten manejar la interfaz hablando. La persona tiene tres formas de actuar:

• Decir el nombre del control: «pulsa Enviar solicitud». El programa busca un elemento interactivo cuyo nombre accesible coincida con lo dicho.
• Pedir números o etiquetas: «muestra los números» superpone un número a cada elemento interactivo y la persona dice «pulsa 12». Solo se numeran los elementos que el navegador expone como interactivos.
• Dictar teclas: «pulsa Tab», «pulsa flecha abajo». Aquí vuelve el teclado y, con él, el riesgo de los atajos de una sola tecla que vimos en 2.1.4.

Para que lo primero funcione está el criterio 2.5.3 Etiqueta en el nombre (nivel A): cuando un control tiene una etiqueta visible con texto, su nombre accesible debe contener ese texto, preferiblemente al principio. Para que funcione lo segundo, los elementos clicables deben ser nativos o tener un rol interactivo; un div con onclick a menudo no recibe número.

<!-- Incorrecto: dice «Continuar», pero su nombre es «Botón principal» -->
<button type="button" aria-label="Botón principal">Continuar</button>

<!-- Correcto: el nombre empieza por el texto visible -->
<button type="button" aria-label="Continuar al paso 3, fecha y hora">Continuar</button>

Conmutadores y ampliadores de pantalla

Quien usa uno o dos conmutadores (pulsadores que se accionan con la mano, la cabeza o el pie) suele trabajar por barrido: el sistema resalta los elementos interactivos uno a uno, o por grupos, y la persona pulsa cuando llega al que quiere. Cada parada innecesaria (un tabindex="0" en una tarjeta, 31 días de un calendario sin roving tabindex) cuesta segundos por pulsación, y los límites de tiempo que no se pueden ampliar pueden hacer imposible la tarea (2.2.1 Tiempo ajustable).

Los ampliadores de pantalla (Lupa de Windows, Zoom de macOS, ZoomText) muestran solo una parte de la pantalla muy aumentada y siguen el foco del teclado y el cursor de texto. Si el foco salta a un lugar imprevisto, si un modal se abre sin recibir el foco o si un mensaje aparece en la otra esquina, la persona simplemente no se entera: lo que ocurre fuera de su ventana de aumento no existe para ella.

Resumen

• Para las WCAG, la interfaz de teclado incluye a los dispositivos que emulan pulsaciones, pero las tecnologías de apoyo también activan controles mediante acciones del navegador.
• En modo exploración, los lectores de pantalla consumen las flechas y las letras y convierten Intro en un click: la activación debe estar en el evento click.
• El cursor del lector no siempre mueve el foco: no hagas depender del foco la existencia de contenido; reserva role="application" para casos excepcionales.
• El control por voz necesita nombres que contengan el texto visible (2.5.3) y controles con rol interactivo.
• Conmutadores y ampliadores castigan las paradas sobrantes y los movimientos de foco imprevistos.