Una pantalla puede parecer terminada y dejar indefinido su comportamiento con teclado. El archivo de diseño muestra un campo enfocado y un menú abierto, pero quizá no explica cómo llegó el foco a ese campo, qué abre el menú o adónde va el foco al cerrarlo. Estas lagunas aparecen cuando alguien intenta utilizar la interfaz sin un puntero.
Una revisión de teclado no sustituye una auditoría de accesibilidad. Ofrece al equipo una forma concreta de encontrar decisiones de interacción pendientes. Elige una tarea real, como guardar una referencia en una carpeta, y sigue el recorrido desde la entrada hasta la confirmación.
Empieza por los controles habituales
Recorre la página con el teclado y anota el orden en que los controles reciben el foco. Comprueba si ese orden sigue el significado del contenido, si el control enfocado está visible y si su etiqueta explica su función. Incluye los controles que solo aparecen al pasar el ratón en el diseño visual: también necesitan una ruta de interacción deliberada.
Utiliza el control adecuado para cada acción. Un destino debe representarse mediante un enlace. Una operación como guardar o abrir un diálogo debe utilizar un botón. Los controles nativos ofrecen comportamientos conocidos que los elementos personalizados deben reproducir de manera intencional. La guía del W3C sobre interfaces de teclado sirve de referencia para revisar el movimiento del foco y los componentes compuestos.
Sigue el foco en las superficies temporales
Para cada diálogo, popover o menú, anota el control que lo abre y la primera interacción relevante dentro. Decide cómo se cierra y adónde regresa la persona. Un diseño claro con ratón puede resultar confuso si cerrar un diálogo deja el foco en algún lugar ajeno al trabajo.
No supongas que todas las superficies temporales deben comportarse igual. Un diálogo modal, un menú de navegación y una ayuda contextual tienen finalidades diferentes. Consulta el patrón apropiado en vez de copiar el comportamiento del componente que resulte más fácil encontrar.
Revisa los cambios posteriores a una acción
Guardar un elemento puede actualizar un contador, cambiar la etiqueta de un botón o mostrar un mensaje breve. Piensa en cómo sabrá lo ocurrido alguien que no está observando esa zona de la pantalla. La interfaz debe confirmar la acción sin mover el foco innecesariamente ni interrumpir repetidamente la tarea.
Prueba una acción fallida además de una exitosa. Si falla la creación de una carpeta, ¿puede la persona acceder a la explicación y reintentar sin volver a rellenarlo todo? Si el elemento que utilizaba desaparece después de eliminarlo, ¿qué control restante permite continuar de forma coherente?
Haz que la entrega se pueda comprobar
Añade notas breves de comportamiento junto a los estados visuales: acción de apertura, destino del foco, acción de cierre y destino de regreso. Incluye un ejemplo de una tarea completa realizada con teclado. Estas notas ofrecen a implementación y revisión una secuencia compartida que comprobar.
Al estudiar referencias en Refcat, utiliza las capturas para identificar posibles patrones y después inspecciona el producto real cuando tengas acceso. Una captura no demuestra el comportamiento con teclado. Registra esa limitación en tus notas. La referencia más útil combina estructura visual e interacción real para apoyar la tarea que necesitas construir.