Trampas de teclado dentro de los paneles de reserva
Esta página es la compañera de trampas de teclado en la fila de reserva. Aquella comprobación juzga la fila de campos que se recorre con Tab antes de que se abra nada; esta juzga lo que ocurre una vez el panel está abierto.
Qué hace esta comprobación y por qué
Hay personas que no pueden usar el ratón. Se mueven por una web con el teclado: pulsando Tab para pasar de un control al siguiente, Shift+Tab para volver atrás, las flechas para moverse dentro de una lista o un calendario, Enter o Espacio para elegir algo, y Escape para cerrar.
Para que eso funcione, tiene que haber una salida de cada parte de la página. Si el teclado llega a un sitio del que no puede salir, la persona se queda atascada: no puede ir atrás, ni adelante, ni terminar lo que venía a hacer. Normalmente no le queda más remedio que cerrar la pestaña y empezar de nuevo. La norma de accesibilidad que lo prohíbe es WCAG 2.1.2 — Sin trampas de teclado.
Esta comprobación busca exactamente ese problema dentro de los paneles de un formulario de búsqueda de reserva: la lista de destinos que se despliega, el calendario que se abre al hacer clic en las fechas, el panel de «Huéspedes y habitaciones» con sus botones de más y menos, y el panel de vuelos donde lo hay.
El propósito es simple: asegurar que, una vez alguien abre uno de esos paneles con el teclado, todavía puede salir de él.
Cómo se comporta, paso a paso
Para cada panel que encuentra, la herramienta hace lo mismo que haría una persona probando con cuidado a mano:
- Se asegura de que el panel está realmente abierto y visible en pantalla. Si el panel no está ahí, no hay nada que probar.
- Mete el teclado dentro del panel, en el primer control que puede recibirlo.
- Pulsa Tab una y otra vez, anotando en qué control aterriza el teclado cada vez. Sigue hasta que el teclado sale del panel, el panel se cierra, o detecta que el teclado está dando vueltas en círculo.
- Si el teclado vuelve siempre al mismo control, la herramienta sospecha — pero todavía no reporta nada.
- Entonces prueba todas las salidas normales, una tras otra:
- Escape (varias veces; ver más abajo).
- Shift+Tab, para salir del panel hacia atrás.
- Más pulsaciones de Tab, para salir del panel hacia delante.
- Elegir una opción: pulsar Enter o Espacio, moviendo antes la opción resaltada con las flechas, para ver si seleccionar algo cierra el panel.
Basta con una salida que funcione. Si cualquiera de ellas libera el teclado, el panel pasa y no se reporta nada. El problema solo se reporta cuando fallan todas y cada una.
Después, la herramienta vuelve a abrir el panel si sus pruebas lo cerraron, para que el resto de comprobaciones sobre ese formulario continúen con normalidad.
Por qué se prueba Escape más de una vez: en algunos sitios hay un tooltip o burbuja de ayuda encima del panel, y el primer Escape solo cierra esa burbuja. Una persona real simplemente pulsaría Escape otra vez. La herramienta hace lo mismo, en vez de declarar erróneamente una trampa en un panel que se puede cerrar perfectamente.
Qué tiene en cuenta
Antes siquiera de plantearse reportar, la herramienta comprueba varias condiciones:
- ¿El panel está genuinamente abierto y visible? Un panel que no está realmente en pantalla no se prueba.
- ¿Puede el teclado entrar en el panel? Si nada dentro del panel puede recibir el teclado, eso es un problema distinto —no poder llegar a algo— y ya lo reporta otra comprobación. Esta se queda callada para no reportar dos veces lo mismo.
- ¿Se puede llegar con el teclado al botón que abre el panel? Si no, mismo razonamiento: ese hallazgo es de otra comprobación, no de esta.
- ¿El panel siguió abierto durante toda la prueba? Si desapareció a mitad, la observación no es fiable y se descarta en lugar de reportarse.
Y estos comportamientos se reconocen todos como correctos, así que nunca se reportan:
| Situación | Por qué está bien |
|---|---|
| El teclado sale del panel en cualquier momento de la prueba | Hay una salida, que es todo el requisito |
| Escape cierra el panel, o devuelve el teclado al botón que lo abrió | Una salida estándar que funciona |
| Shift+Tab o seguir pulsando Tab saca el teclado | Una salida estándar que funciona |
| Elegir una opción cierra el panel — escoger un destino, confirmar una fecha | Eso es una salida exitosa, no una trampa |
| Un diálogo abierto retiene el teclado dentro a propósito, pero Escape funciona | Es la forma recomendada de construir un diálogo |
| El teclado da la vuelta pasando por la barra del navegador (barra de direcciones, etc.) | Comportamiento normal del navegador, no cosa de la web |
| El teclado se mueve entre dos o más controles | Un «bucle», deliberadamente fuera de esta comprobación (ver limitaciones) |
Qué reporta cuando encuentra algo
Se levanta un hallazgo solo en una situación precisa: el teclado está atascado en un único control dentro del panel y ninguna de las salidas funciona.
Un ejemplo concreto: entras con Tab en una lista de destinos, el teclado aterriza en el campo de búsqueda, y a partir de ahí Tab no hace nada, Shift+Tab no hace nada, las flechas no hacen nada, Escape no hace nada, y pulsar Enter tampoco cierra la lista. Ves la lista de ciudades en pantalla, pero nunca puedes llegar a ninguna, y nunca puedes volver al resto del formulario.
El reporte te dice:
- Qué panel está afectado: Destino, Calendario, Huéspedes y habitaciones, etc.
- Qué control concreto tiene atascado el teclado, por su nombre, siempre que se pueda identificar — y lo resalta en la página para encontrarlo fácilmente.
- Cómo reproducirlo, paso a paso con el teclado.
- Qué ocurre realmente, descrito como lo que experimenta la persona: el foco se queda en ese control, así que no puede moverse a las otras opciones del panel ni hacer una selección.
Limitaciones: qué no cubre
- Solo se reporta «atascado en un único control». Si el teclado rebota entre varios controles —por ejemplo entre los botones
+y−de Huéspedes y habitaciones— eso es un bucle, y queda intencionadamente fuera de esta comprobación. Esa decisión se tomó durante la revisión y se sigue por separado. - Solo el interior de los paneles. Los problemas de la página que los rodea, o de los botones que abren los paneles, pertenecen a otras comprobaciones — la fila de reserva la cubre su propia comprobación.
- Solo se prueban las salidas estándar: Escape, Tab, Shift+Tab y elegir una opción. Si un sitio usa alguna otra tecla poco habitual para salir y nunca se lo cuenta a la persona, la herramienta no la encontrará. (Lo que discutiblemente ya es un problema en sí: una salida que nadie te explica no es gran salida.)
- Los desplegables dibujados por el sistema operativo se omiten. Cuando un sitio usa un desplegable normal del navegador, la lista de opciones la dibuja el propio navegador, fuera de la página web: no hay nada en la página que pudiera atrapar el teclado.
- Hay un límite de pulsaciones. Los paneles muy grandes se prueban hasta un presupuesto fijo. Ese presupuesto cubre dar dos vueltas completas a cualquier panel realista, pero no es ilimitado.
- En caso de duda, no dice nada. Si algo sale mal a mitad de la prueba —la página navega a otro sitio, el panel desaparece, hay un problema de temporización— la herramienta no reporta nada en vez de arriesgar una falsa alarma. Eso significa que algún problema real puede colarse de vez en cuando. Es un compromiso elegido a propósito: un reporte equivocado cuesta más tiempo que uno que falta.
- No juzga cuán buena es la navegación. Si el orden de los controles tiene sentido, o si las flechas se comportan como esperarías dentro de un calendario, son temas de accesibilidad aparte que cubren otras comprobaciones. Esta responde una sola pregunta de sí o no: ¿puede el teclado salir?