Comprobar con teclado: protocolo de prueba

La prueba con teclado es la más rentable de todas las pruebas de accesibilidad: no requiere instalar nada, cualquier miembro del equipo puede hacerla y detecta una proporción enorme de los problemas graves. Pero para que sea útil tiene que ser sistemática. Esta lección propone un protocolo de prueba reproducible que puedes incorporar a la revisión de cada página o componente antes de darlo por terminado, y que sirve como base para la definición de hecho (definition of done) del equipo.

Preparación

• Usa un navegador actual (Chrome, Edge o Firefox). Si pruebas en Safari para macOS, activa en Ajustes del sistema, Teclado, la opción «Navegación por teclado», y en Safari, Avanzado, «Pulsar Tab para resaltar cada elemento»; de lo contrario, Tab se salta los enlaces.
• Aparta el ratón o desconéctalo físicamente. La tentación de «ayudarse» con un clic invalida la prueba.
• Ten a mano una hoja de registro con columnas: página o componente, paso, tecla, resultado esperado, resultado obtenido, criterio afectado, gravedad.
• Define las tareas a probar: no se trata de tabular por toda la página, sino de completar lo que la persona vendría a hacer (buscar un trámite, rellenar la solicitud, pagar).

Las teclas de la prueba

Protocolo paso a paso

1. Carga la página y pulsa Tab una vez. Debería aparecer el enlace de salto o el primer elemento de la cabecera. Si el foco va a parar a un elemento invisible o al cuerpo de la página sin indicador, anótalo (2.4.7).
2. Activa el enlace de salto. El foco debe llegar al contenido principal y la siguiente pulsación de Tab debe caer dentro de él (2.4.1).
3. Recorre toda la página con Tab. En cada parada comprueba: que ves el foco, que el orden sigue el diseño, que el elemento es realmente interactivo (si paras en un párrafo o una tarjeta inerte, hay un tabindex sobrante) y que ningún elemento fijo lo tapa (2.4.3, 2.4.7, 2.4.11).
4. Haz el recorrido inverso con Mayús+Tab. Debe ser el espejo exacto. Los componentes que cambian de estado al pasar por ellos suelen fallar aquí.
5. Activa cada tipo de control con Intro y con Espacio. Un enlace que no responde a Intro o un botón que no responde a Espacio suele ser un div disfrazado (2.1.1).
6. Entra en cada componente compuesto (menú, pestañas, acordeón, calendario, carrusel, select personalizado): prueba las flechas, Inicio, Fin y Escape. Comprueba que puedes salir con Tab (2.1.2).
7. Abre cada diálogo o panel y comprueba las cinco condiciones del modal: foco dentro, foco retenido, Escape cierra, fondo inerte, foco devuelto al cerrar.
8. Provoca contenido dinámico: errores de validación, resultados de búsqueda, mensajes de confirmación, eliminación de elementos. Observa a dónde va el foco y si lo que aparece se puede alcanzar.
9. Busca funciones solo de ratón: pasa por los elementos que tienen comportamiento al hover (menús, tooltips, botones de fila) y verifica que aparecen con el foco.
10. Pulsa letras sueltas fuera de los campos de texto para detectar atajos de una sola tecla (2.1.4).
11. Cambia el tamaño de la ventana a 320 píxeles de ancho o al 400 % de zoom y repite los pasos 3 y 7: los menús móviles y los paneles responsive tienen a menudo su propia gestión del foco, y suele ser peor.

Clasificar la gravedad

No todos los hallazgos pesan igual. Una clasificación sencilla y útil:

• Bloqueante: impide completar una tarea principal (una trampa de teclado, un paso del formulario inoperable).
• Grave: la tarea se completa con gran dificultad o por caminos alternativos (foco invisible en todo un formulario, orden ilógico en un proceso de pago).
• Moderado: molesta pero no impide (un tabindex sobrante, un tooltip que no se cierra con Escape).
• Leve: mejora recomendable (un indicador de foco de bajo contraste en un enlace secundario).

Integrarlo en el flujo de trabajo

Incluye el protocolo en la revisión de cada pull request que toque la interfaz: quien revisa el código debe poder decir «lo he recorrido con teclado». Para los componentes del sistema de diseño, documenta en su ficha qué teclas soporta cada uno, de modo que la prueba sea también la especificación. Y cuando se corrija un hallazgo, repite exactamente el paso registrado antes de cerrarlo. En el curso de frameworks veremos cómo automatizar parte de estas comprobaciones con pruebas de extremo a extremo que simulan pulsaciones de teclado.

Resumen

• Prueba sin ratón, con tareas reales y una hoja de registro con pasos, teclas, resultado esperado y obtenido.
• El protocolo cubre: primera pulsación, enlace de salto, recorrido completo en ambos sentidos, activación, componentes compuestos, diálogos, contenido dinámico, funciones de hover, atajos y vista móvil.
• Registra cada hallazgo con el criterio WCAG y una gravedad (bloqueante, grave, moderado, leve).
• Haz de la prueba con teclado parte de la revisión de código y de la documentación de los componentes.
• Repite el paso exacto registrado para verificar cada corrección.