Por qué es importante la navegación por teclado
La navegación por teclado es un requisito de accesibilidad que afecta a múltiples grupos de usuarios: personas con movilidad reducida en manos o brazos, usuarios de lectores de pantalla, personas que utilizan dispositivos de acceso alternativo (como interruptores o sistemas de seguimiento ocular), y usuarios avanzados que prefieren el teclado al ratón por eficiencia.
Un sitio que no funcione completamente con el teclado excluye a estos usuarios de forma efectiva, independientemente de que el contenido sea visualmente accesible. La operabilidad completa por teclado es el segundo principio de las pautas WCAG (principio POUR: Perceptible, Operable, Comprensible, Robusto).
Criterios de éxito WCAG 2.1 relacionados con el teclado
Las WCAG 2.1 incluyen varios criterios directamente relacionados con la accesibilidad por teclado:
Criterio 2.1.1 — Teclado (Nivel AA)
Toda la funcionalidad del contenido es operable a través de una interfaz de teclado, sin requerir sincronización temporal específica de cada pulsación de tecla, excepto cuando la función subyacente requiere de una entrada que depende de la trayectoria del movimiento del usuario y no únicamente de los puntos de inicio y final.
Criterio 2.1.2 — Sin trampa de teclado (Nivel AA)
Si el foco del teclado puede desplazarse a un componente de la página, el foco puede salir de ese componente usando solo el teclado. Si requiere más que las teclas de cursor, Tab, Shift+Tab o Retorno, se informa al usuario de cómo mover el foco.
Criterio 2.4.3 — Orden del foco (Nivel AA)
Si se puede navegar secuencialmente por una página Web y la secuencia de navegación afecta al significado o a la operación, los componentes que pueden recibir el foco lo hacen en un orden que preserva el significado y la operabilidad.
Criterio 2.4.7 — Foco visible (Nivel AA)
Cualquier interfaz de usuario operable por teclado tiene un modo de operación donde el indicador del foco del teclado es visible.
Elementos nativamente enfocables
Los elementos HTML que reciben el foco de teclado de forma nativa son:
- Hipervínculos con atributo
href - Botones (
<button>) - Campos de formulario:
<input>,<textarea>,<select> - Elementos con
tabindex="0"
Los elementos con tabindex="-1" pueden recibir foco mediante programación (JavaScript) pero quedan fuera del orden de tabulación natural. Los valores positivos de tabindex (mayor que 0) están desaconsejados porque alteran el orden natural de tabulación y dificultan el mantenimiento.
Indicadores visuales de enfoque
El indicador de foco es la señal visual que muestra qué elemento está actualmente activo cuando el usuario navega con el teclado. Los navegadores modernos incluyen un indicador por defecto (generalmente un contorno azul o punteado), pero este puede haber sido eliminado mediante la regla CSS outline: none o outline: 0, práctica que elimina la accesibilidad del teclado para usuarios con visión.
Requisitos del indicador de foco en WCAG 2.2
WCAG 2.2 (2023) introduce el criterio 2.4.11 (Foco visible mejorado, nivel AA) que exige que el indicador de foco tenga un área mínima y un contraste mínimo de 3:1 respecto al estado sin foco. Los indicadores deben:
- Rodear el componente completo o tener un área de al menos el perímetro del componente multiplicado por 2 píxeles CSS.
- Tener un ratio de contraste de al menos 3:1 entre los píxeles del indicador en estado de foco y en estado sin foco.
La recomendación práctica es utilizar contornos visibles mediante outline con suficiente grosor (mínimo 2px) y contraste, o implementar un estilo personalizado que resulte claramente visible.
Gestión del foco en componentes dinámicos
Las interfaces de usuario modernas incluyen componentes que modifican el DOM de forma dinámica: modales, desplegables, tooltips, acordeones, notificaciones. La gestión correcta del foco en estos elementos es esencial para la accesibilidad por teclado.
Diálogos modales
Cuando se abre un diálogo modal:
- El foco debe desplazarse al primer elemento enfocable dentro del modal o al propio contenedor del modal.
- El foco debe quedar atrapado dentro del modal mientras esté abierto (trampa de foco intencional y controlable por teclado).
- Al cerrar el modal, el foco debe volver al elemento que lo activó.
Menús desplegables
Los menús de navegación con submenús deben permitir que el usuario abra y cierre los submenús con el teclado, y navegue entre sus elementos. El patrón ARIA para menús de navegación no requiere necesariamente el uso de las teclas de cursor: un menú simple puede abrirse con Enter/Espacio y navegarse con Tab y Shift+Tab.
Omisión de bloques de contenido (skip links)
El criterio 2.4.1 de WCAG (Nivel A) exige proporcionar un mecanismo para omitir los bloques de contenido que se repiten en múltiples páginas. La solución más habitual es incluir un enlace oculto al inicio del HTML, visible solo cuando recibe el foco, que lleva directamente al contenido principal:
<a href="#main-content" class="skip-link">Ir al contenido principal</a>
Teclado y lectores de pantalla
Los lectores de pantalla (NVDA, JAWS, VoiceOver) utilizan el teclado como principal método de interacción. Sin embargo, su modo de navegación no siempre coincide con el orden de tabulación estándar: disponen de comandos propios para navegar por encabezados, listas, tablas y regiones de página (landmarks ARIA).
La accesibilidad por teclado y la accesibilidad para lectores de pantalla son complementarias pero distintas. Un sitio puede ser navegable por teclado sin que los lectores de pantalla transmitan correctamente la semántica del contenido, y viceversa.
Referencias y fuentes
- W3C: WCAG 2.1 — Pauta 2.1 Teclado
- W3C: WCAG 2.2 — Criterio 2.4.11 Foco visible mejorado
- W3C WAI: ARIA Authoring Practices Guide — Patrones
- WebAIM: Keyboard Accessibility
Actualizado: 19 de junio de 2026