Navegación por teclado: cómo comprobarla y corregir errores
Una página puede funcionar perfectamente con el ratón y, aun así, impedir que alguien complete una compra, cierre una ventana o envíe un formulario desde el teclado. Estos obstáculos afectan a personas que utilizan el teclado de forma habitual, incluidos algunos usuarios de tecnologías de asistencia, pero también aparecen cuando el ratón no está disponible.
Comprobar la navegación por teclado consiste en recorrer y utilizar la interfaz sin depender del puntero. En esta guía aprenderás a preparar una prueba, detectar problemas de foco y corregir los fallos más habituales en enlaces, formularios, menús y ventanas modales.
Antes de empezar: qué significa navegar con el teclado
El foco indica qué elemento de la página recibirá la siguiente acción del teclado. Normalmente se identifica mediante un contorno u otra señal visual. Al pulsar Tabulador, el foco avanza por los elementos interactivos; con Mayúsculas + Tabulador retrocede.
Según el elemento, también se utilizan otras teclas:
- Enter: activa enlaces y botones, entre otros controles.
- Espacio: activa botones y cambia el estado de casillas de verificación cuando tienen el foco. En un enlace, no sustituye normalmente a Enter.
- Flechas: permiten operar determinados controles, como botones de opción, listas o pestañas.
- Escape: suele cerrar componentes como cuadros de diálogo y algunos menús desplegables.
El comportamiento exacto depende del control y del componente. Los elementos HTML nativos incorporan gran parte de esta interacción; los componentes personalizados deben implementarla explícitamente.
Antes de probar, consulta la configuración de navegación por teclado de tu navegador y sistema operativo: algunas combinaciones pueden requerir ajustes para que Tabulador alcance todos los controles. Conviene verificar el resultado en los navegadores relevantes para el proyecto.
Cómo hacer una prueba manual paso a paso
Reserva unos minutos para recorrer la página sin tocar el ratón. No te limites a la portada: prueba también formularios, resultados de búsqueda y flujos completos, como iniciar sesión o finalizar una compra.
- Carga la página y pulsa Tabulador. Comprueba dónde aparece el foco y si existe un enlace para saltar al contenido principal.
- Recorre todos los controles. Observa si puedes alcanzar enlaces, botones, campos, casillas y otros elementos interactivos.
- Retrocede con Mayúsculas + Tabulador. Verifica que el recorrido inverso también funciona y no queda bloqueado.
- Activa cada control. Usa Enter, Espacio y las flechas cuando corresponda. Abre menús, marca opciones y envía formularios.
- Prueba los cambios de interfaz. Abre y cierra diálogos, despliega paneles y provoca errores de formulario. Comprueba dónde queda el foco en cada caso.
- Repite tareas reales. Por ejemplo, intenta elegir un producto, añadirlo al carrito y completar los campos necesarios sin usar el puntero.
Durante el recorrido, anota el elemento afectado, los pasos para reproducir el problema y el comportamiento esperado. Una captura o una grabación breve puede ayudar al equipo a localizarlo. Prueba también con distintos tamaños de ventana y niveles de ampliación: un encabezado fijo puede tapar el foco aunque el control siga estando en la página.
Problemas frecuentes y cómo solucionarlos
El foco no se ve
Si al pulsar Tabulador no sabes dónde estás, puede que el estilo de foco se haya eliminado o que su contraste sea insuficiente. Una regla como outline: none sin una alternativa visible deja al usuario sin una referencia esencial.
Mantén el indicador predeterminado del navegador o define uno que destaque sobre el fondo. Por ejemplo:
:focus-visible {
outline: 3px solid #005fcc;
outline-offset: 3px;
}
:focus-visible permite aplicar el estilo cuando el navegador determina que debe mostrarse una indicación visible de foco. Ajusta el color y el grosor al diseño, y comprueba el resultado sobre todos los fondos relevantes. Revisa también que el indicador no quede recortado por un contenedor ni oculto detrás de una barra fija.
El orden de tabulación resulta confuso
El recorrido debe seguir una secuencia que conserve el sentido y permita usar la interfaz. Si el foco salta del menú al pie de página y luego vuelve al formulario, completar la tarea se vuelve difícil.
La solución habitual es ordenar el HTML de forma coherente con la estructura visual y funcional. Ten cuidado con diseños CSS que reorganizan visualmente los elementos sin cambiar su orden en el documento: la secuencia de Tabulador puede seguir siendo la original.
Evita usar valores positivos de tabindex para forzar un orden. Son difíciles de mantener y pueden generar recorridos inesperados. Por el contrario, tabindex="0" incorpora un elemento al orden habitual y tabindex="-1" permite mover el foco a él mediante programación sin añadirlo al recorrido normal. Utilízalos cuando el comportamiento realmente lo requiera.
Un elemento parece un botón, pero no funciona como tal
Un div con un controlador de clic puede parecer un botón y funcionar con el ratón, pero no recibe por defecto el foco ni responde como un botón nativo. La corrección más fiable suele ser sustituirlo por el elemento adecuado:
<button type="button">Abrir filtros</button>
Un botón nativo ya puede recibir el foco y activarse con Enter y Espacio. Usa un enlace con href para navegar a otra ubicación y un botón para ejecutar una acción. Añadir solo un atributo ARIA a un elemento genérico no incorpora automáticamente el comportamiento de teclado.
El contenido oculto sigue recibiendo el foco
Un menú cerrado o un panel fuera de pantalla no debería obligar al usuario a recorrer enlaces que no puede ver. Del mismo modo, un control deshabilitado no debería parecer disponible si no puede utilizarse.
Comprueba cómo se oculta el contenido: desplazarlo visualmente fuera de la pantalla o hacerlo transparente no necesariamente lo elimina del recorrido de teclado. Cuando corresponda, utiliza mecanismos como el atributo hidden o display: none mientras el panel esté cerrado. Al volver a mostrarlo, asegúrate de restaurar su comportamiento y su estado de forma coherente.
No uses aria-hidden="true" como única solución: afecta a la exposición del contenido a tecnologías de asistencia, pero no impide por sí solo que un elemento reciba el foco.
El usuario queda atrapado o pierde el foco en un diálogo
Una ventana modal requiere una gestión deliberada del foco. Al abrirla, mueve el foco a un elemento adecuado dentro del diálogo, por ejemplo su título enfocable o el primer control pertinente. Mientras esté abierta, Tabulador y Mayúsculas + Tabulador deben permanecer dentro de la ventana modal; el contenido de fondo no debe poder utilizarse.
Ofrece una forma clara de cerrarla, como un botón visible, y permite Escape cuando sea apropiado. Al cerrarla, devuelve normalmente el foco al control que la abrió, salvo que otro destino tenga más sentido para la tarea. Comprueba qué sucede si ese control ya no existe.
El elemento nativo <dialog> abierto con showModal() puede facilitar parte de este comportamiento, pero sigue siendo necesario probar la gestión del foco, el nombre accesible y la experiencia de cierre. Una trampa de foco fuera de un contexto modal, o sin salida disponible, impide continuar la navegación.
Los menús y pestañas solo responden al ratón
Un menú que aparece únicamente al pasar el puntero deja fuera a quien navega con teclado. Usa un botón para abrirlo, permite activarlo con Enter o Espacio y comunica su estado mediante aria-expanded cuando corresponda. Comprueba que sus enlaces sean alcanzables y que el usuario pueda cerrarlo sin usar el ratón.
No todos los desplegables son iguales. Para una navegación web convencional, un botón que muestra una lista de enlaces suele ser más sencillo que reproducir un menú de aplicación con roles y controles especiales. Si implementas pestañas u otros patrones complejos, consulta el patrón de accesibilidad correspondiente y programa las teclas esperadas, incluidas las flechas cuando proceda.
Formularios, errores y enlaces de salto
En un formulario, cada campo debe tener una etiqueta asociada y poder utilizarse desde el teclado. Recorre el formulario completo, abre los selectores, marca las casillas y envíalo tanto con datos válidos como con errores.
Cuando falle la validación, presenta mensajes claros asociados a los campos afectados. Según el diseño, puede ser útil mover el foco a un resumen de errores o al primer campo incorrecto; evita hacerlo sin avisar o de una forma que haga perder el contexto. No dependas solo del color para indicar el problema.
También conviene ofrecer un enlace de salto al principio de la página, visible al recibir el foco, que lleve al contenido principal. Un destino con id permite enlazarlo; si necesitas controlar el foco explícitamente tras el salto, puedes hacer que el contenedor principal admita foco programático con tabindex="-1" y verificar el comportamiento en los navegadores objetivo.
<a href="#contenido">Saltar al contenido principal</a>
<main id="contenido" tabindex="-1">
<h1>Contenido de la página</h1>
</main>
Este enlace evita repetir la navegación principal en cada página. Comprueba que el salto desplaza la vista y sitúa al usuario en una posición útil para continuar con el teclado.
Cómo integrar la revisión en el desarrollo
Incorpora la prueba a cada cambio que añada controles o modifique el recorrido. Una lista breve puede servir para revisar si el foco es visible, el orden tiene sentido, todas las funciones se pueden activar y no existen bloqueos sin salida.
Las herramientas automáticas y las pruebas de interfaz pueden detectar algunos fallos, pero no sustituyen el recorrido manual: no siempre determinan si el orden resulta comprensible o si una tarea se puede completar. Complementa estas revisiones con pruebas de tecnologías de asistencia y, cuando sea posible, con personas que utilicen diferentes formas de interacción.
Conclusión
Una buena navegación por teclado exige controles alcanzables, foco visible, orden coherente y respuestas previsibles. Los elementos HTML nativos resuelven parte del trabajo, mientras que los menús, diálogos y formularios requieren pruebas específicas.
Empieza por una tarea importante de tu sitio y complétala sin ratón. Registra cada obstáculo, corrígelo y repite el recorrido: una comprobación sencilla puede revelar problemas que pasarían inadvertidos en una revisión exclusivamente visual.
