Cómo probar una miniapp usando solo el teclado

Elige una tarea completa. Prepara un entorno de prueba y selecciona un objetivo concreto, como buscar un elemento, abrir sus detalles y guardar una modificación ficticia. Desconecta cualquier consecuencia externa que no quieras ejecutar. La referencia de W3C WAI sobre funcionamiento por teclado establece que las funciones deben poder operarse mediante una interfaz de teclado, con excepciones específicas para movimientos cuyo recorrido es esencial. Esta revisión propone llevar ese principio a una tarea cotidiana. No sustituye una evaluación completa de accesibilidad ni demuestra conformidad general con WCAG por el hecho de terminar un único recorrido.

Empieza sin ayuda del puntero. Coloca el ratón a un lado y recorre la página con Tab y Mayús más Tab, según el comportamiento del navegador y del sistema operativo. Observa si puedes llegar a las acciones necesarias y si el orden tiene sentido respecto del contenido. Anota saltos inesperados y componentes que parecen desaparecer de la navegación. No todos los elementos de texto deben recibir foco; la pregunta es si las funciones requeridas tienen una vía operable. Si tu navegador necesita una configuración particular para navegar controles, regístrala antes de atribuir el comportamiento a la aplicación.

Mira dónde está el foco. W3C WAI explica el criterio de foco visible para que una persona sepa sobre qué elemento actuará el teclado. Durante el recorrido, detente en botones, enlaces y campos y comprueba que puedas identificar su posición sin adivinarla. Un cambio apenas perceptible puede resultar difícil de seguir. Guarda ejemplos de estados donde el indicador se pierde por el fondo o por un panel superpuesto. Esta observación complementa, pero no reemplaza, las comprobaciones específicas de contraste y otros criterios que necesitan métodos adicionales para evaluarse correctamente.

Activa cada control de la tarea. Prueba enlaces, botones, selecciones y campos con las teclas que correspondan a su tipo. Enter suele activar enlaces; los botones normalmente responden a Enter o espacio, y ciertos componentes utilizan flechas para desplazarse internamente. No impongas una única combinación a todos los controles. Comprueba el patrón de interacción que implementan y si resulta descubrible. Para el registro del ensayo, separa no puedo llegar de llego pero no puedo activar. Son fallos diferentes y esa distinción ayuda a corregirlos sin modificar innecesariamente el resto de la interfaz.

Entra y sal de las ventanas. Revisa menús, selectores y diálogos sin recurrir al ratón. El criterio de ausencia de trampas de teclado de W3C exige una forma de abandonar componentes; una restricción de foco dentro de un diálogo puede ser apropiada si existe una salida utilizable. La guía de patrones ARIA para diálogos modales describe comportamientos como cerrar con Escape y devolver el foco a una posición lógica. Comprueba el patrón aplicable y registra dónde terminas al cerrar. No confundas un foco contenido correctamente con quedar atrapado sin posibilidad de continuar la tarea.

Incluye un error controlado. Introduce un dato inválido de prueba y observa si puedes identificar el problema, volver al campo y corregirlo sin perder lo que ya habías completado. Después recorre la confirmación y regresa a la vista principal. Este ejercicio evalúa más que la pantalla inicial: descubre qué ocurre cuando el proceso cambia de estado. Anota navegador, sistema operativo, versión de la app, teclas utilizadas y resultado esperado. Un reporte como el foco desaparece después de cerrar el selector es mucho más útil si contiene los pasos mínimos que permiten reproducir exactamente ese comportamiento.

Corrige y repite desde el inicio. Prioriza bloqueos que impiden completar la tarea y vuelve a ejecutar el mismo recorrido después de cada ajuste relevante. Conserva un pequeño conjunto de tareas de regresión para formularios, navegación y diálogos. La prueba por teclado debería convivir con otras revisiones, incluidas tecnologías de asistencia y participación de usuarios cuando corresponda. Su valor inmediato es hacer visibles obstáculos que una demostración con ratón puede pasar por alto. El resultado responsable es una lista de hallazgos corregidos y pendientes, no una etiqueta de accesibilidad perfecta que el ensayo no puede sostener.