Desde junio de 2025, la Ley Europea de Accesibilidad ha convertido WCAG AA en un requisito legal para muchos sitios web de la UE. La navegación por teclado es una de las áreas que cubre, y también es una de las pocas que cualquiera puede comprobar en unos pocos pasos, sin software especial. Eso la convierte en un lugar práctico por donde empezar: el requisito es claro, los errores son reconocibles y las soluciones están bien definidas.
Navegación sin ratón
La navegación por teclado es usar un sitio web sin ratón: moverse entre enlaces, botones y campos de formulario, y activarlos, sólo con el teclado. Muchas personas dependen de ella: usuarios con discapacidad motriz, visitantes con una lesión temporal, usuarios de lectores de pantalla o quienes simplemente prefieren el teclado.
El navegador mantiene el foco únicamente en un elemento, normalmente marcado con un contorno que lo destaca. El teclado mueve ese foco de un elemento interactivo al siguiente, siguiendo el orden del HTML (el código que estructura la página), y actúa sobre el elemento enfocado. Unas pocas teclas sirven para navegar:
- Tabulador / Shift+tabulador: siguiente / anterior elemento interactivo
- Enter: seguir un enlace o pulsar un botón
- Espacio: pulsar un botón, marcar una casilla de verificación
- Flechas: moverse dentro de menús, selectores, grupos de radio y pestañas
- Escape: cerrar menús, desplegables y modales
El siguiente vídeo muestra un ejemplo de un sitio web usado solo con el teclado.
Para las personas que dependen del teclado, un sitio que falla aquí es difícil o imposible de usar. Para muchos sitios, también es una cuestión legal.
El requisito legal detrás del acceso por teclado
Desde que la Ley Europea de Accesibilidad entró en vigor en junio de 2025, cumplir WCAG AA ha sido un requisito legal para muchos sitios. La EAA se aplica a servicios específicos, como comercio electrónico, banca, transporte y libros electrónicos, y exime a las microempresas. Hace referencia a la norma europea EN 301 549, que se corresponde con WCAG 2.1 AA.
WCAG cubre el uso del teclado en varios criterios, los principales son:
- 2.1.1 Teclado (A): todo funciona con el teclado.
- 2.1.2 Sin trampa de teclado (A): el foco siempre puede salir de cualquier elemento.
- 2.4.1 Evitar bloques (A): existe una forma de saltar bloques repetidos como la cabecera.
- 2.4.3 Orden del foco (A): el foco se mueve en un orden lógico.
- 2.4.7 Foco visible (AA): el elemento enfocado siempre es visible.
- 2.4.11 Foco no oscurecido (AA): las cabeceras fijas, los banners de cookies o los widgets de chat nunca ocultan por completo el elemento enfocado. Este criterio se añadió en WCAG 2.2.
Otros criterios también tocan el uso del teclado, como descartar contenido mostrado al recibir el foco o exponer el estado de controles personalizados. La lista completa está en la referencia rápida de WCAG enlazada abajo. En la práctica, estos criterios fallan por un conjunto de errores recurrentes.
Errores comunes que bloquean a los usuarios de teclado
Una fuente común de problemas de teclado es algo que funciona bien con ratón pero que no se prueba con el teclado. El resultado son pulsaciones extra del tabulador, el foco que se pierde o un elemento que no al que no hay forma de llegar.
- Menú de cabecera: los submenús se abren en cuanto el elemento padre recibe el foco, o permanecen ocultos solo visualmente pero siguen en el orden de tabulación. Cada tabulador recorre cada enlace hijo, en cada página, antes de llegar al contenido principal.
- Contorno de foco eliminado: una regla de estilo como
outline: nonesin un reemplazo no deja forma de saber dónde está el foco. - Modales: el foco no se mueve al modal cuando se abre, o no puede salir de él.
- Sin enlace de salto: sin un enlace "Saltar al contenido principal", la cabecera se repite en cada página.
- Botones falsos: un
<div>o<span>con un clic no es enfocable y no responde a Enter o Espacio.
Cada uno de estos errores es solucionable.
La solución técnica detrás de cada error
Cada solución es un cambio en el HTML, CSS o JavaScript del sitio.
El menú de cabecera necesita cuatro cambios:
- Los submenús permanecen cerrados hasta que se abren con Enter, Espacio o la flecha hacia abajo.
- Un submenú cerrado queda fuera del orden de tabulación (
hiddenodisplay: none), así que el tabulador salta al siguiente elemento de nivel superior. - El conmutador contiene
aria-expanded="true|false", un atributo que permite a los lectores de pantalla anunciar si el submenú está abierto. - Escape cierra el submenú abierto y devuelve el foco a su conmutador.
Para el contorno de foco, el selector CSS :focus-visible da estilo al contorno en lugar de eliminarlo.
Para los modales, el foco va dentro al abrirse, permanece dentro mientras está abierto y vuelve al disparador al cerrarse. Escape lo cierra.
El enlace de salto es un enlace "Saltar al contenido principal" colocado como el primer elemento enfocable de la página.
Los botones falsos se sustituyen por los elementos nativos <button> y <a>, ya que son enfocables y responden al teclado por defecto.
Saber cuáles de estos errores afectan a un sitio no requiere herramientas especiales.
Una comprobación manual del teclado con el ratón
La navegación por teclado es una de las comprobaciones de accesibilidad más fáciles de realizar. No necesita herramientas, solo el ratón fuera de alcance.
- Deja a un lado el ratón y pulsa Tab empezando desde la barra de direcciones.
- La primera parada debería ser el enlace de saltar al contenido.
- El foco debería ser visible en cada momento.
- Tab por la cabecera: los submenús cerrados deberían saltarse. Abre uno con Enter, ciérralo con Escape.
- Abre un modal, ciérralo con Escape y comprueba que el foco vuelve al botón que lo abrió.
- Rellena y envía un formulario.
Las herramientas automatizadas como Lighthouse solo detectan parte de esto, la comprobación manual es más fiable.
Conclusión
La navegación por teclado es un requisito, tanto para las personas que dependen de ella como para el cumplimiento de WCAG. Un sitio que falla en esto excluye a usuarios y no alcanza el estándar legal.
Esta comprobación de accesibilidad merece la pena realizar primero. No necesita herramientas, y cada problema que encuentra se corresponde con una de las soluciones anteriores. La revisión manual muestra en qué punto se encuentra un sitio, y las correcciones hacen que sea más rápido de usar para todas las personas que navegan con el teclado, sea cual sea el motivo.
