Navegación por teclado en los widgets de reserva
Esta comprobación responde a una sola pregunta para cada widget de reserva: ¿puede una persona que usa el teclado llegar realmente a las opciones que hay dentro y elegirlas?
Widget de destino
Qué es capaz de hacer hoy
- Encontrar barreras reales. Cuando una web de reservas muestra una lista de destinos pero no se puede llegar a ellos ni elegirlos solo con el teclado, la herramienta lo detecta y lo reporta. Los casos que al principio se escapaban —listas que solo aparecen al empezar a escribir, listas que aparecen en cuanto el campo recibe el foco, y listas en las que el foco nunca entra en el desplegable— ya están cubiertos.
- Dejar de dar falsas alarmas. El grueso del trabajo fue la precisión. Muchos sitios se marcaban como problemáticos aunque sus opciones de destino sí eran perfectamente usables con teclado. Ronda tras ronda se rastrearon y eliminaron esas falsas alarmas, incluidas varias webs conocidas de viajes y hoteles.
- Distinguir un control real de un texto cualquiera. La herramienta ya no se fía de cómo está etiquetado algo internamente. Busca las señales que usaría una persona —¿el cursor cambia a una mano?, ¿se ilumina al pasar por encima?, ¿ocurre algo?— y solo entonces se pregunta si alguien con teclado puede llegar hasta ahí.
- Reportar con más claridad. Los hallazgos de un mismo widget se agrupan en un único issue con todos los elementos afectados listados juntos, en vez de repartirse en varios reportes sueltos, y se limpió la redacción.
- Comportarse igual dos veces seguidas. Los resultados pasaron a ser mucho más estables entre ejecuciones. Se introdujo una comprobación de consistencia específica (cinco ejecuciones por sitio) y la mayoría de sitios da ahora resultados idénticos cada vez.
En qué punto está
La precisión medida para el widget de destino llegó a cerca del 92 % a finales de julio y siguió mejorando durante agosto y principios de septiembre. En las últimas rondas de revisión, la gran mayoría de los sitios de prueba reportaba los problemas correctos o no reportaba nada correctamente, y no se observaron retrocesos.
Pendiente / próximos pasos: quedan unos pocos sitios por atender — una web de reservas importante cuya página tiene una estructura especial que se tratará por separado, más un puñado de sitios que la herramienta sencillamente no puede cargar porque bloquean a los visitantes automatizados. Ambos casos se siguen aparte de este trabajo.
Limitaciones conocidas
Esto es lo que la comprobación honestamente no puede hacer hoy. Conviene tenerlo presente al revisar sus resultados.
No prueba las cosas: lee las señales. La herramienta nunca hace clic en las opciones de destino que está inspeccionando. Hacerlo seleccionaría un destino, cerraría la lista y destruiría justo lo que se está examinando, podría lanzar una búsqueda real o navegar fuera a mitad de la comprobación, y en listas de decenas de elementos la haría mucho más lenta. Por eso juzga «¿esto es un control de verdad?» a partir de señales de apariencia y comportamiento. Es un compromiso deliberado, y es el origen de los dos puntos siguientes.
Puede pasar por alto un control cuyo comportamiento no se ve desde fuera. En algunos sitios el comportamiento «cliqueable» está montado de una forma que la herramienta no puede ver. Si además ese elemento no tiene cursor de mano ni reacción al pasar por encima, puede colarse sin detectarse.
Ocasionalmente puede reportar de más. Un texto decorativo al que un diseñador le puso cursor de mano y un resaltado al pasar por encima puede parecer un control real. Para las listas que aparecen al escribir, una de las comprobaciones se relaja a propósito (algunos sitios pintan su efecto hover de una forma que no se puede leer), lo que sube ligeramente la probabilidad de falsa alarma ahí.
Elementos que se ven iguales reciben el mismo veredicto. Si dos cosas se ven igual en pantalla y están construidas igual, pero solo una funciona de verdad, la herramienta no puede separarlas. Marcará las dos o ninguna, nunca solo la que funciona. Cuando pasa esto verás un issue con un elemento extra listado, no un reporte falso entero.
«Alcanzable pero invisible» no es asunto de esta comprobación. Algunos sitios dejan que el teclado recorra opciones de destino que nunca se muestran en pantalla. Técnicamente sí son alcanzables, así que esta comprobación las da por buenas — pero quien usa el teclado no tiene ni idea de dónde está. Esa es otra pregunta de accesibilidad («¿dónde estoy?») y se trata en otro sitio.
Hay sitios que no se pueden comprobar en absoluto. Varias webs de viajes detectan y bloquean a los visitantes automatizados, o nunca terminan de cargar. En esos casos la herramienta ve una página en blanco o a medio cargar y no reporta nada — lo que no es lo mismo que «no se encontraron problemas». Entre un 8 % y un 20 % de los sitios de las últimas rondas cayó en esta categoría.
Depende de que se le apunte a la parte correcta de la página. Si el área de reserva se identifica de forma imprecisa —o si el sitio genera una estructura distinta en cada visita— la comprobación puede salirse del área de reserva y reportar cosas que no le corresponden.
Los sitios complejos o lentos pueden ser poco fiables. Los sitios que reconstruyen su widget de destino repetidamente, o que tardan muchísimo en cargar, pueden dar resultados distintos en ejecuciones distintas o agotar el tiempo.
Widget de huéspedes y habitaciones
Qué es capaz de hacer hoy
- Encontrar controles inalcanzables dentro del panel. Abre el panel de Huéspedes y Habitaciones y comprueba si alguien con teclado puede llegar realmente a lo que hay dentro: los botones de más y menos para adultos y niños, los ajustes de habitación, los desplegables y los botones de Aceptar o Confirmar. Los controles que se ven pero a los que nunca se llega con el teclado ahora se reportan.
- Reportar cuando no se puede llegar al área de reserva. En algunos sitios, con teclado no se puede entrar siquiera en el formulario de reserva. En vez de quedarse callada, la herramienta levanta un único reporte claro que cubre toda el área de reserva, con una explicación práctica de cómo arreglarlo.
- Dar reportes más claros y concretos. Al principio los reportes podían decir algo vago como «un desplegable dentro de un widget» en páginas que tenían varios. Ahora identifican qué control y qué parte del formulario están afectados, y usan la terminología correcta para distinguir el control que abre el panel del panel en sí.
- Reportar lo correcto, y solo lo correcto. Buena parte del trabajo fue eliminar falsas alarmas: casos en los que se marcaba un problema que en realidad no existía. Ya no marca controles que nunca llegan a hacerse visibles, ni paneles que funcionan bien con teclado, ni controles que caen fuera del alcance de esta comprobación.
- Seguir funcionando en sitios que bloquean herramientas automatizadas. Algunos sitios muestran una pantalla de seguridad en lugar de la página real. Antes eso hacía que la revisión fallara sin dejar siquiera una captura. Ahora se comporta como cualquier otra comprobación: termina, muestra la captura y no reporta hallazgos, de modo que quien revisa ve inmediatamente qué pasó.
- Manejar páginas más difíciles y dinámicas. Los sitios en los que el formulario de reserva se mueve, cambia de forma o carga tarde a medida que interactúas se manejan ahora de forma mucho más fiable.
Cuánto se probó
Las pruebas crecieron de 3 sitios en la primera ronda a 55 en la última, a lo largo de 13 rondas de revisión más una comprobación previa a producción. En la última ronda completa, todos los sitios utilizables se comportaron como se esperaba —sin errores y sin problemas no detectados—, y por eso la funcionalidad se aprobó para pasar a preproducción. La comprobación puntual posterior confirmó el mismo comportamiento, sin regresiones en el panel de Huéspedes y Habitaciones.
Próximos pasos
Quedan abiertos unos pocos hallazgos que se siguen como trabajos aparte, y hay un comportamiento —el foco aterrizando en controles invisibles para el visitante pero alcanzables con teclado— que aún necesita una decisión sobre cómo debe reportarse.
Limitaciones conocidas
Situaciones en las que la comprobación puede no dar una respuesta completa o fiable hoy.
Sitios que no podemos revisar
- Sitios que bloquean herramientas automatizadas. Muchas webs de viajes muestran una pantalla de «comprobación de seguridad» a cualquier cosa que no parezca un visitante humano. En la muestra más grande (55 sitios), aproximadamente 1 de cada 4 no se pudo revisar por este motivo. La comprobación termina limpiamente y muestra una captura, pero no hay nada que reportar porque la página real nunca llegó a cargarse.
- Sitios que cargan lentamente o se renderizan en blanco. Unos pocos sitios devuelven una página vacía o tardan demasiado, y hay que apartarlos en lugar de revisarlos.
Cosas que la comprobación no cubre
- Paneles que solo se abren con ratón. Si el panel de Huéspedes y Habitaciones no se puede abrir con teclado, esta comprobación no reporta lo que hay dentro: esa situación pertenece a otra comprobación («¿se puede operar este control con el teclado?»).
- Controles ocultos a la vista pero alcanzables con teclado. En algunos sitios el foco entra en campos invisibles en pantalla, y el visitante no puede ver dónde está. La herramienta lo detecta internamente, pero todavía no se convierte en un reporte: falta decidir bajo qué criterio de accesibilidad debe archivarse.
- Contenido que solo aparece más tarde. Los controles que surgen únicamente tras hacer scroll o tras varias interacciones quedan fuera de la revisión, porque la comprobación mira el formulario tal como existe en el momento del análisis.
- Controles agrupados. En unos pocos sitios, todo un grupo de controles se trata como un único elemento enfocable que se maneja con las flechas, en vez de que cada botón de más y menos sea alcanzable por su cuenta. El reporte para ese patrón todavía no está definido.
Cosas que afectan a la consistencia
- El área de reserva tiene que identificarse correctamente. La revisión apunta a una parte concreta de la página. En sitios donde esa parte se desplaza o cambia de nombre mientras carga, un objetivo incorrecto puede hacer que se revise el área equivocada, o la página entera.
- Pop-ups y avisos de consentimiento. Los pop-ups publicitarios, los avisos de cookies y los modales promocionales pueden aparecer a mitad de la revisión y cambiar el resultado, así que el mismo sitio puede dar resultados ligeramente distintos en ejecuciones distintas.
- La redacción y las soluciones sugeridas varían. La explicación y la corrección recomendada que acompañan a un hallazgo se generan en cada ejecución, así que su calidad no es idéntica siempre: el mismo sitio puede recibir una sugerencia muy completa un día y una más pobre al siguiente.
- Todavía no hay una página de pruebas controlada. No existe aún una página hecha a propósito que reproduzca estos patrones a demanda, lo que hace difícil reproducir y confirmar de forma consistente algunos casos poco frecuentes.