Accesibilidad de teclado

La accesibilidad de teclado implica que toda acción que un usuario puede realizar en una página puede ejecutarse usando únicamente el teclado. Es el requisito de accesibilidad más innegociable: sin él, ninguna otra tecnología de apoyo funciona.

La interfaz de teclado es la interfaz universal

Los lectores de pantalla, los pulsadores, el control por voz, el seguimiento ocular — toda tecnología de apoyo utilizada en la web termina enrutándose a través de la capa de teclado. Un usuario sin ninguna discapacidad motriz puede que jamás pulse Tab, pero ese mismo sitio tiene que ser totalmente operable de ese modo para que los usuarios con discapacidad puedan utilizarlo.

Por eso 2.1.1 Teclado es un criterio de nivel A: no cumplirlo no hace el sitio más difícil, lo hace inutilizable para poblaciones enteras de usuarios.

Qué exige realmente «operable con teclado»

• Tab y Mayús+Tab desplazan el foco hacia adelante y hacia atrás entre los elementos interactivos.
• Intro activa enlaces y la mayoría de los botones.
• Espacio activa botones y alterna casillas de verificación y botones de opción.
• Las teclas de flecha navegan dentro de componentes compuestos (paneles de pestañas, menús, grupos de botones de opción, listboxes, controles deslizantes).
• Escape cierra diálogos modales, ventanas emergentes y menús desplegables.
• Re Pág/Av Pág, Inicio/Fin navegan por el contenido largo cuando lo establece la convención de la plataforma.

Un componente que no implementa el contrato de teclado que los usuarios de lectores de pantalla esperan según su rol — por ejemplo, un combobox ARIA que responde a los clics pero no a las teclas de flecha — es técnicamente enfocable pero funcionalmente está roto.

La auditoría manual más rápida

Recorra la página con Tab desde el principio (foco en la barra de dirección, luego Tab) hasta el pie de página. El orden de foco debe coincidir con el orden visual. Cada elemento interactivo debe recibir el foco exactamente una vez. Al pulsar Intro o Espacio sobre un elemento enfocado, el resultado debe ser el mismo que al hacer clic. Al pulsar Escape dentro de un modal, este debe cerrarse. Si algo resulta inalcanzable, se alcanza fuera de orden o atrapa el foco, se han encontrado errores.

Cinco minutos de navegación disciplinada con Tab detectan más problemas de accesibilidad que quince minutos de análisis con axe-core.

Patrones de fallo más comunes

• <div onclick> para tarjetas interactivas. No es enfocable, no se activa con el teclado y es completamente invisible para los lectores de pantalla como elemento interactivo. Utilice <button> (para acciones) o <a href> (para navegación).
• Menús desplegables personalizados que no se abren con Intro/Espacio. Construidos solo con manejadores de clic; los usuarios de teclado pueden enfocar el activador pero no abrir la lista.
• Diálogos modales que no atrapan el foco. Tab desplaza el foco fuera del modal hacia la página (visualmente oculta) que hay detrás. Los usuarios no pueden saber dónde están.
• Diálogos modales que sobre-atrapan el foco. Escape no cierra el modal. El usuario queda atrapado.
• Destino del enlace para saltar no enfocable. El enlace para saltar apunta a #main pero <main id="main"> carece de tabindex="-1", por lo que el foco no se desplaza realmente y el siguiente Tab vuelve a comenzar desde la parte superior de la página.

Dos bibliotecas son especialmente útiles: focus-trap para gestionar el foco dentro de modales, y tabbable para localizar los elementos enfocables dentro de un contenedor. Ambas son pequeñas y sin opiniones.