Responsive, accesibilidad y rendimiento
Probar una web con teclado permite detectar problemas que se pasan por alto al navegar siempre con el ratón. Un botón puede verse impecable y resultar inaccesible para quien intenta alcanzarlo con Tab.
La prueba no exige empezar por una herramienta compleja. Sí requiere observar el recorrido con atención y registrar lo que ocurre.
Es una primera revisión. No certifica accesibilidad ni sustituye una evaluación completa con otras técnicas, herramientas y personas.
Empezar por una tarea pequeña
Elige una tarea concreta: encontrar una pieza en un catálogo ficticio y abrir su ficha. Empieza desde el principio de la página y evita usar el ratón para resolver los obstáculos.
Tab suele avanzar entre elementos interactivos; Shift+Tab permite volver. Los enlaces se activan normalmente con Enter. Los botones nativos admiten Enter y Espacio.
Otros componentes pueden tener convenciones propias, como flechas en ciertos grupos de controles. Si necesitas una acción distinta, la interfaz debe resultar comprensible y respetar las convenciones del componente. W3C ofrece una introducción en sus comprobaciones iniciales de accesibilidad.
Recorrido ilustrativo: el foco indica qué control recibirá la siguiente acción. No representa una prueba de conformidad. Toca para ampliar.
Saber dónde está el foco
El foco señala el elemento que recibirá la acción del teclado. Puede mostrarse con un contorno, un cambio de fondo u otra diferencia clara.
No lo confundas con el hover, que responde al puntero. Diseñar un hover cuidado no garantiza que el foco sea visible.
En una página con fondo claro y oscuro, comprueba ambos contextos. El indicador no debería desaparecer al cambiar de sección ni quedar tapado por una cabecera fija.
Seguir un orden que tenga sentido
El recorrido debería permitir entender cómo se pasa de navegación a contenido y acciones. Compara ese orden con la disposición visual.
Si el foco salta de forma inesperada a una zona lejana, anota qué elemento precede al salto y cuál viene después. El problema puede estar en la estructura del documento o en cambios de orden hechos solo para la presentación.
No intentes arreglar todo asignando números positivos a tabindex. Puede producir un orden difícil de mantener. Una estructura coherente y controles nativos suelen ser una base más sólida.
Poder entrar y también salir
Abre un menú o un diálogo si lo hay. Comprueba si puedes utilizarlo y cerrarlo con el teclado según su comportamiento esperado. En un diálogo modal, observa dónde queda el foco al cerrar.
Si quedas atrapado, registra la incidencia. El criterio de ausencia de trampas de teclado explica por qué también debe existir una forma de abandonar un componente.
No todas las pruebas necesitan activar una compra, enviar un formulario o modificar información. Puedes revisar el recorrido sin ejecutar esas acciones finales.
Mini tutorial: registrar tres observaciones útiles
Prepara una tabla con cuatro columnas: página, elemento, qué ocurrió y resultado esperado. Sustituye «no funciona bien» por una observación reproducible.
Por ejemplo: «En la ficha, al pulsar Tab después de la imagen, el foco llega al enlace de consulta pero no se distingue del fondo». Ese detalle permite revisar el indicador sin rediseñar toda la ficha.
Si pides ayuda a la IA, proporciona el problema y el alcance. Solicita una explicación antes del cambio y repite la misma prueba después. Puedes apoyarte en cómo comprobar una respuesta de IA.
Comprobar más de una forma de uso
Recorre también la página en orden inverso. Revisa un ancho móvil y prueba el aumento de texto. El teclado no revela por sí solo todos los problemas de contraste, contenido, lectura o compatibilidad con tecnologías de apoyo.
Si necesitas entender por qué la estructura influye en el recorrido, repasa las bases de HTML y CSS.
Diseñar una interacción incluye que pueda encontrarse, entenderse, activarse y abandonarse de una forma previsible.
