Planteamiento y alcance
Esta pregunta de frontend evalúa el modelo de teclado y la accesibilidad de una interacción compleja. No te limites a adjuntar unos pocos controladores de keydown; define la máquina de estados completa de apertura, búsqueda, selección, ejecución, cierre y restauración del foco, y expone los roles, nombres y estados correctos a los lectores de pantalla.
Qué evalúa el entrevistador
- Si distingues la semántica de dialog, combobox, listbox y menu.
- Si Tab, las flechas, Enter, Escape, Home y End tienen un comportamiento consistente.
- Si se manejan la visibilidad del foco, la restauración, los resultados dinámicos, la carga y los errores.
- Si los atajos globales evitan apropiarse de entradas de texto, tecnologías de asistencia o valores predeterminados del navegador.
Preguntas de aclaración para hacer primero
Confirma si los comandos están agrupados, son recientes o se buscan de forma asíncrona, si el móvil tiene otro punto de entrada, si los atajos son configurables y si la ejecución navega, abre un diálogo o cambia el estado de la página. Aclara también el soporte para ratón y pantalla táctil, los límites de resultados y el retraso de carga aceptable.
Estructura de respuesta en 30 segundos
Utiliza un diálogo modal con nombre alrededor de una entrada y resultados con una relación explícita combobox/listbox. Guarda el activador y enfoca la entrada al abrir; las flechas mueven el elemento activo, Enter ejecuta y Escape cierra y restaura el foco. Anuncia los cambios de estado de los resultados, activa atajos solo en contextos seguros y prueba cada transición con el teclado, un lector de pantalla y automatización.
Respuesta a fondo
1. Elegir el límite semántico
Utiliza un dialog con nombre en el exterior, semántica combobox para la entrada cuando la interacción lo requiera, listbox para los resultados y option para las opciones. Para comandos jerárquicos, sigue un patrón de menú en lugar de añadir role="menuitem" en todas partes. ARIA debe describir el comportamiento real, no enmascarar una estructura DOM incorrecta.
2. Diseñar la máquina de estados del foco y del teclado
Registra el activador y enfoca la entrada al abrir. Las teclas de flecha se desplazan por los resultados, Home y End saltan a los límites, Enter ejecuta el elemento actual y Escape cierra. El comportamiento de Tab debe coincidir con el patrón elegido y nunca permitir que el foco caiga detrás del diálogo. Al cerrar, fallar o navegar, restaura el foco al activador o a un objetivo razonable.
3. Manejar resultados dinámicos y anuncios
Mantén el foco en la entrada mientras la búsqueda asíncrona actualiza los resultados, actualiza aria-activedescendant o el foco real, y expone los estados de carga, vacío, error y recuento de resultados. No leas toda la lista con cada carácter; utiliza una región de estado concisa y haz perceptibles el nombre seleccionado, el atajo y el estado deshabilitado.
4. Controlar los atajos y el comportamiento predeterminado
Comprueba el foco actual, la combinación de modificadores y la plataforma antes de abrir. Evita apropiarte de atajos de entradas de texto, editores o modos de lector de pantalla. Llama a preventDefault solo cuando reemplazar un comportamiento del navegador sea intencional; preserva copiar, pegar, buscar y las operaciones de asistencia. Proporciona un botón visible para que un atajo nunca sea la única entrada.
5. Hacer observables la ejecución, los fallos y las pruebas
Muestra el comando seleccionado antes de la ejecución, expone el progreso o evita envíos duplicados para el trabajo asíncrono, y mantén el contexto con una ruta de reintento en caso de fallo. Prueba rutas solo con teclado, foco visible, trampas de foco, restauración con Escape, resultados dinámicos, zoom, redes lentas y al menos un lector de pantalla. Registra aperturas, búsquedas, fallos y cancelaciones sin registrar entradas sensibles.
Ejemplo de una respuesta sólida
Envolvería la entrada y los resultados en un diálogo con nombre. Al abrir, guardaría el activador y enfocaría la entrada; conectaría la entrada y el listbox con aria-controls y aria-activedescendant para que la opción activa quede clara. Las flechas y Home/End mueven la selección, Enter ejecuta, Escape cierra y restaura el foco, y Tab nunca llega al fondo. La búsqueda asíncrona anuncia los estados de carga, vacío y error de forma concisa. Los atajos verifican el foco y la plataforma, preservan los valores predeterminados del navegador y tienen una alternativa de botón visible. Las pruebas cubren teclado, lector de pantalla, zoom, red lenta, reintento y foco visible, y la telemetría excluye consultas sensibles.
Errores comunes
- Manejar keydown sin definir los estados de apertura, cierre y restauración del foco.
- Añadir roles menu, menuitem o combobox a contenedores arbitrarios.
- Perder el foco tras actualizaciones dinámicas de modo que los lectores de pantalla no puedan identificar la opción activa.
- Interceptar atajos globales y romper la entrada de texto, copiar/pegar o el comportamiento de asistencia.
- No ofrecer ningún punto de entrada visible y exigir a los usuarios que memoricen un atajo.
- Probar solo clics del ratón y automatización en lugar de teclado, zoom, lector de pantalla y red lenta.
Preguntas de seguimiento
¿Se debe mover el foco real o usar aria-activedescendant?
Ambos pueden funcionar según la estructura y el soporte del lector de pantalla. El foco real es directo pero requiere gestionar la interacción entre la entrada y las opciones; aria-activedescendant mantiene el foco en la entrada y requiere referencias estables, opciones perceptibles y pruebas en dispositivos reales.
¿Cómo se evita una trampa de foco cuando no hay resultados?
Mantén el foco en la entrada, muestra un estado vacío explícito y permite Escape, la edición de consultas y botones visibles. Nunca muevas el foco a un marcador de posición no interactivo.
¿A dónde va el foco tras la navegación?
El destino debe elegir un objetivo razonable, como su encabezado o contenido principal. Si el usuario permanece en la página, restaura el activador o el contexto. En caso de fallo, mantén la paleta abierta con la consulta y el error.
¿Cómo se verifica que los atajos no entren en conflicto con el navegador?
Enumera las plataformas y combinaciones admitidas y realiza pruebas en entradas, editores, formularios y entornos de lectores de pantalla. Evita el comportamiento predeterminado solo cuando se reemplace intencionalmente y proporciona ajustes o una alternativa de botón.