Sin trampa de teclado
Si el foco del teclado puede desplazarse hacia un componente, también debe poder alejarse de él utilizando únicamente el teclado. Los diálogos modales, los contenidos embebidos y los widgets personalizados son los principales infractores.
Qué exige
Si una persona usuaria puede acceder con Tab a un componente, debe poder salir de él también con Tab (o con Shift+Tab, o con otra tecla documentada) sin necesidad de usar el ratón. Si para salir se requieren teclas distintas a las habituales de flechas y Tab —por ejemplo, Ctrl+M para abandonar un reproductor de vídeo embebido—, se debe informar al usuario de cómo hacerlo.
Esto no es lo mismo que una trampa de foco dentro de un diálogo modal, que es un patrón deseable: un modal cicla el foco entre sus propios elementos pero lo libera cuando el usuario lo cierra. Una trampa de teclado es aquella situación en la que no existe ninguna vía de salida documentada.
Cómo cumplirlo
- Dentro de un diálogo modal, ciclar el foco entre el primero y el último elemento enfocable con Tab y Shift+Tab, y cerrar el diálogo al pulsar Escape, devolviendo el foco al elemento que lo activó.
- Para contenido embebido de terceros (reproductores de vídeo, mapas, iframes de origen desconocido), comprobar que Tab continúa más allá del contenido embebido. Si no es así, documentar la tecla de salida cerca del elemento.
- Para los widgets personalizados que consumen las teclas de flechas (selectores de fecha, comboboxes, vistas de árbol), conservar Tab como vía de salida universal; nunca bloquearlo.
- Para los manejadores de arrastre o los editores de texto enriquecido que usan Tab para la indentación, ofrecer una alternativa documentada (Escape para liberar, Ctrl+M para salir del modo de edición) y hacerla visible en la interfaz.
Fallos frecuentes
- Diálogos modales que atrapan el foco pero no se cierran al pulsar Escape y no exponen un botón de cierre enfocable.
- Visores de PDF embebidos, reliquias de Flash y algunos paneles de control de Tableau / Power BI que absorben Tab indefinidamente.
- Editores de texto enriquecido (TinyMCE, versiones antiguas de CKEditor) que capturan Tab para indentar y nunca lo liberan.
- Comboboxes personalizados en los que las teclas de flechas recorren las opciones pero Tab no hace nada, dejando al usuario atrapado en el campo de entrada.
- Banners de cookies con gestión de foco que se repiten en bucle sin ofrecer nunca el foco en «Aceptar» / «Rechazar».
Las herramientas automatizadas raramente detectan este problema: axe y Lighthouse solo pueden marcar patrones sospechosos. La prueba manual con teclado es la única comprobación fiable.
Por qué importa
Una trampa de teclado es uno de los fallos de accesibilidad más graves: el usuario queda literalmente imposibilitado para abandonar esa parte de la página. Una persona usuaria ciega podría tener que recargar la página, perdiendo su sesión y cualquier dato de formulario. Para muchas personas usuarias, este es el momento en que abandonan el sitio definitivamente. De todos los criterios WCAG, este es el que con mayor probabilidad convierte una página en indefendible legalmente: los tribunales y los organismos de control consideran la situación de «trampa» como una barrera evidente.