Probar la navegación por teclado: un recorrido sin ratón

¿Por qué es tan importante poder usar una web con el teclado?

Muchas personas no usan ratón: las personas ciegas con lector de pantalla, las personas con limitaciones motoras que usan teclado, conmutadores o control por voz, y todas las que trabajan rápido con el teclado. Muchas ayudas técnicas recurren a la misma interfaz de teclado.

Por eso, en el criterio 2.1.1, de nivel A, las WCAG exigen que todas las funciones se puedan usar con el teclado. Una prueba con teclado no necesita ninguna herramienta y aun así detecta algunas de las barreras con más consecuencias. Los problemas que muestra suelen tener causas técnicas que también afectan a los lectores de pantalla.

¿Qué teclas necesitas para la prueba?

Algunos componentes tienen a propósito una sola parada de tabulación, por ejemplo un grupo de pestañas. Dentro del grupo te mueves entonces con las teclas de flecha. En Mac, según la configuración, Safari solo salta con Tab a los campos de formulario. Activa en los ajustes avanzados que Tab resalte todos los elementos de una página web, o prueba en otro navegador.

1. 1Tab salta al siguiente control; Mayús+Tab, al anterior.
2. 2Intro sigue un enlace o activa un botón.
3. 3La barra espaciadora activa botones, marca casillas de verificación y desplaza la página si no hay ningún elemento con el foco.
4. 4Las teclas de flecha cambian entre botones de opción, elementos de menú, pestañas o valores de un control deslizante.
5. 5Escape cierra diálogos, menús y listas desplegables.

¿Cómo se hace una prueba con teclado?

1. 1Recarga una página importante y no hagas clic en ella, para empezar al principio del documento.
2. 2Pulsa Tab una vez: ¿hay un enlace «Saltar al contenido» que permita omitir la navegación repetida (WCAG 2.4.1)?
3. 3Recorre con Tab todos los elementos interactivos y observa el orden y el foco.
4. 4Abre el menú, la búsqueda y los acordeones y vuelve a cerrarlos.
5. 5Abre un diálogo, úsalo y ciérralo con Escape.
6. 6Rellena un formulario, provoca un error y envíalo.
7. 7Al final de la página, comprueba si se puede llegar a los enlaces del pie de página, los vídeos incrustados o los mapas y volver a salir de ellos.
8. 8Repite el recorrido con un zoom del 200 % y comprueba si el foco se mantiene en la zona visible.

¿Qué es un orden del foco lógico?

El foco debe moverse en un orden que encaje con el contenido y su significado (WCAG 2.4.3). Normalmente eso significa de arriba abajo y de izquierda a derecha, tal como se lee la página.

Causas típicas de saltos son los elementos reordenados visualmente con CSS y los valores positivos de tabindex, como tabindex="3". Un error frecuente son los menús ocultos cuyos enlaces siguen pudiendo recibir el foco. Entonces el foco pasa minutos sobre elementos invisibles.

Comprueba también adónde salta el foco tras una acción. Después de añadir algo al carrito o de cargar más resultados, no debería volver al principio de la página.

¿Cómo debe verse el foco del teclado?

El foco debe ser visible (WCAG 2.4.7, nivel AA). Muchas webs eliminan el contorno estándar del navegador con outline: none sin definir un estilo de foco propio. Entonces nadie sabe dónde está.

Desde las WCAG 2.2, además, el elemento con el foco no puede quedar totalmente tapado por contenidos propios, como una cabecera fija o un banner de cookies (WCAG 2.4.11). Un contorno de foco claro y con buen contraste ayuda a todo el mundo; el criterio AAA 2.4.13 contiene requisitos precisos sobre la apariencia del foco. Prueba el foco también sobre superficies de color e imágenes, porque un contorno en el color corporativo puede desaparecer allí.

¿Qué problemas de teclado son típicos?

Muchos de estos problemas se evitan con elementos HTML nativos: button para las acciones, a con href para los enlaces, select e input para las selecciones y las entradas. Incorporan de serie el manejo con teclado y el foco. Para los componentes propios, las ARIA Authoring Practices describen qué teclas se esperan.

1. 1Foco invisible: no reconoces qué elemento está activo.
2. 2Trampa de teclado: el foco ya no puede salir de una zona, por ejemplo un vídeo incrustado o un mapa (WCAG 2.1.2).
3. 3Acción inaccesible: un botón visible es un div con un evento de clic y solo reacciona al ratón.
4. 4Listas de selección o selectores de fecha propios que solo se abren con el ratón.
5. 5Carruseles que siguen avanzando y se llevan el foco con ellos.
6. 6Diálogo sin camino de vuelta: al cerrarlo, el foco aparece en un lugar inesperado.
7. 7Atajos de teclado de una sola letra que no se pueden desactivar ni cambiar (WCAG 2.1.4).

¿Cómo deben comportarse los diálogos y los menús?

Para los diálogos modales, la colección del W3C ARIA Authoring Practices describe un patrón claro: al abrir el diálogo, el foco salta a él. Tab y Mayús+Tab solo se mueven dentro del diálogo. Escape lo cierra. Después, el foco vuelve al elemento que abrió el diálogo.

Retener el foco en el diálogo abierto es intencionado y no es una trampa de teclado, siempre que se pueda volver a cerrar con el teclado. En los menús desplegables, Escape debería cerrar el menú y devolver el foco al botón que lo abrió. Revisa también el banner de cookies: debería poder alcanzarse pronto con Tab y aceptarse o rechazarse con el teclado.

¿Cómo documentas los problemas de teclado?

Anota la URL, el navegador, el punto de partida, la secuencia de teclas y el comportamiento observado. Describe la tarea bloqueada en lugar de escribir solo «el teclado no funciona». Así, el equipo de desarrollo puede reproducir el problema y volver a comprobarlo tras un cambio. Un ejemplo: «Chrome, página de inicio, siete veces Tab: el foco desaparece detrás del banner de cookies, menú inaccesible».

La prueba con teclado no es una evaluación completa. Compleméntala con pruebas con lector de pantalla, ampliación y hallazgos automáticos. Un escáner como el análisis de Accessonaut detecta, por ejemplo, controles sin nombre, pero no un orden del foco ilógico. En los recorridos centrales ayudan las opiniones de personas que usan estas vías de acceso a diario.