Operable Teclado accesible Nivel A WCAG 2.0, 2.1, 2.2

2.1.2 Sin trampa de teclado

Meta Los usuarios del teclado no se quedan atascados en ningún componente.
Qué hacer Asegurar que los usuarios siempre sepan cómo navegar fuera de cualquier componente.
Por qué importa Las personas que dependen del teclado a menudo no tienen otros medios para navegar.

Criterio de éxito oficial

2.1.2 Sin trampa de teclado Nivel A

Si el foco del teclado se puede mover a un componente de la página usando una interfaz de teclado, entonces el foco se puede mover desde ese componente usando solo una interfaz de teclado y, si requiere más que teclas de flecha o tabulación sin modificar u otros métodos de salida estándar, se le informa al usuario el método para mover el foco.

Requisito de no interferencia

Cualquier contenido que no cumpla este criterio puede interferir con la capacidad del usuario para usar la página completa. Por ello, todo el contenido de la página debe cumplir con este requisito, incluyendo el contenido de terceros incrustado.

¿Qué es?

Este criterio garantiza que un usuario que navega con teclado nunca quede atrapado dentro de un subconjunto del contenido. Si el foco del teclado puede entrar en un componente, siempre debe existir una forma de salir de él usando solo el teclado.

Las trampas de teclado suelen producirse cuando se combinan varios formatos en una página (plugins, widgets integrados, iframes). Si un componente captura el foco sin proporcionar un mecanismo de salida, el usuario queda bloqueado — obligado a cerrar o actualizar el navegador.

Fuentes comunes de trampas

Modales

Cuadros de diálogo sin botones de cierre accesibles.

Calendarios

Selectores de fecha que no gestionan el foco.

Reproductores

Vídeos con controles que capturan el foco sin salida.

Scroll infinito

Contenido con elementos enfocables que se cargan continuamente.

¿Por qué es importante?

Cuando un usuario se queda atascado en un componente, probablemente tendrá que cerrar o actualizar el navegador, o incluso reiniciar su sistema. Esto es extremadamente frustrante cuando el contenido es importante o crucial, y puede ser imposible de resolver para alguien que no pueda usar un ratón.

Es fundamental probar que se puede usar solo el teclado para navegar por todo el contenido de la página sin trabarse. De lo contrario, la navegación completa es imposible sin recurrir al ratón.

¿Quién se ve afectado?

Personas ciegas o con baja visión: Cuando un componente atrapa el foco, se pierden todo el contenido posterior al componente problemático.

Personas con discapacidades motoras: Una trampa de foco les obliga a buscar ayuda o recurrir al ratón, algo que puede ser imposible para ellos.

Todos los usuarios de teclado: Incluye usuarios avanzados que prefieren el teclado, usuarios de tecnologías de asistencia, y cualquier persona con un ratón averiado.

Cómo implementar 2.1.2

Prueba con Tab de inicio a fin

Usa la tecla Tab para recorrer el contenido de la página de principio a fin. Si el foco se atasca, la página debe proporcionar un método de salida — generalmente Esc o Tab. Las instrucciones deben presentarse antes del componente problemático.

Gestión del foco en modales

Los diálogos modales pueden restringir el foco intencionalmente al contenido del modal — esto es aceptable siempre que el usuario pueda cerrar el modal con un botón «Cerrar», «Cancelar» o la tecla Esc, y que al cerrar el modal el foco vuelva al elemento que lo activó. El contenido fuera del modal debe marcarse como inerte con el atributo inert o aria-hidden="true".

Proporciona instrucciones

Si un componente requiere un método no estándar para mover el foco (distinto a Tab, Shift+Tab o teclas de flecha), informa al usuario antes de que entre en el componente con texto visible o aria-describedby.

Ejemplos prácticos

Ejemplo 1 Widget de calendario accesible

Un widget de calendario permite navegar por sus controles internos y luego continuar con los elementos que siguen al widget mediante Tab o Esc. Al salir, el foco vuelve al campo de fecha o al botón que activó el calendario.

Ejemplo 2 Cuadro de diálogo modal

Un diálogo con botones «Cancelar» y «Aceptar». El foco queda restringido al modal (correcto), pero el usuario puede cerrarlo con cualquiera de los botones o presionando Esc. Al cerrarse, el foco vuelve al botón que abrió el diálogo.

Fallo Selector de fecha sin salida

Un selector de fecha integrado captura el foco en un bucle infinito de fechas. No hay forma de salir con Tab ni con Esc. El usuario debe cerrar el navegador para continuar.

Técnicas recomendadas

Técnicas suficientes para CE 2.1.2
CódigoTécnicaTipo
G21Garantizar que los usuarios no queden atrapados en el contenidoSuficiente

Errores comunes

F10: Combinación de múltiples formatos de contenido de una manera que atrapa a los usuarios dentro de un tipo de formato, impidiéndoles salir con el teclado.

Otros casos de fallo frecuentes: modales que no pueden cerrarse con Esc y cuyo botón de cierre no es enfocable; iframes que capturan el foco sin permitir que Tab salga; menús desplegables que no se cierran con Esc; y no proporcionar instrucciones sobre cómo salir cuando el método no es estándar.

Criterios de éxito relacionados