Sí, correcto, como señaló @simonk, una de las formas en que estábamos fallando era no cambiar el foco a las superposiciones. El foco debe estar en un lugar lógico mientras navegas por la aplicación.
Creo que podríamos querer cambiar de :focus a :focus-visible en nuestro CSS. Aún no es compatible con Safari, pero en ese caso es fácil hacer un fallback a :focus.
Si el elemento activo coincide con :focus-visible y un script hace que el enfoque se mueva a otro lugar, el elemento recién enfocado debería coincidir con :focus-visible.
Esto significa que si abres el menú hamburguesa usando la tecla Tab (lo que activa el estilo :focus-visible), al abrirse el menú, el estilo :focus-visible aparecerá. Sin embargo, si abres el menú con un puntero, el estilo :focus-visible no aparecerá:
Hay una desventaja: en un escenario de entrada mixta donde abres el menú hamburguesa con un puntero y luego intentas navegar con la tecla Tab… el estilo :focus-visible no es visible en el primer enlace (aunque técnicamente esté enfocado), por lo que parece que se salta. No estoy seguro de si existe una solución alternativa para esto…
Dado que soy (principalmente) un usuario de ratón, eso es exactamente lo que esperaría que ocurra.
Por otro lado, a veces uso mi teléfono inteligente con pantalla táctil: el mismo problema allí; “Admin” está resaltado, lo que indica que podría haber algo importante en la sección de administración que requiera atención.
De la discusión relacionada sobre lectores de pantalla, veo que parece necesario establecer el foco de alguna manera.
Me conformaría con el comportamiento mencionado anteriormente para los punteros.
No creo que este elemento tenga actualmente el valor de UX que ustedes pretendían: inmediatamente recibimos informes de errores sobre esto en nuestro foro. El foco desaparece al hacer clic con el botón derecho en cualquier parte de la ventana y hay un doble foco al pasar el cursor sobre los botones. En general, los usuarios lo perciben como defectuoso, especialmente porque Discourse no impone esta selección en ninguna otra vista.
Sería mejor mostrar el foco del teclado solo cuando el usuario presione por primera vez Tab, o solo cuando el usuario navegue para abrir el menú hamburguesa con una acción de teclado.
Veo lo mismo en Safari y Firefox (macOS); esto también se menciona en la publicación anterior:
Si entiendo correctamente esta función, debería poder abrir ese menú haciendo clic o presionando = y luego navegar con algo (¿flechas?) y presionar algo (¿Intro?) para ir al elemento resaltado.
En Safari y Firefox en macOS, ya sea que abra el menú con un clic o con =, no parece ser posible navegar dentro de ese menú. Las flechas arriba/abajo mueven la página hacia arriba y abajo, y las flechas izquierda/derecha no parecen hacer nada visible.
La tecla Tab cambia el enfoque a otro elemento, como el botón de “Me gusta” en una publicación, y elimina el resaltado amarillo del menú. En Firefox, Tab sí recorría los elementos del menú antes de que empezara a escribir esta respuesta, pero ahora ya no lo hace; se cerró una ventana privada entre esos intentos.
Observo estos comportamientos tanto aquí en Meta como en mi propia instancia actualizada a efbc2481d8 (excepto que en Firefox Tab funciona correctamente, algo que solo he visto aquí).
Las teclas de flecha no deberían hacer nada, pero Tab y Intro ¡sí!
Entonces, cuando abres el menú con = y pulsas Tab, ¿no estás recorriendo los elementos del menú? Estoy en macOS y funciona como se espera en Safari, Firefox y Chrome, así que esto es un poco desconcertante.
He revisado más de cerca lo que está ocurriendo en general y la idea de usar focus-visible que mencioné anteriormente no funcionará.
El problema es que el menú hamburguesa aparece en nuestro HTML fuera del contenedor del botón del menú (el contenedor que alberga los botones de búsqueda, hamburguesa y usuario). Esto significa que el menú no está a continuación en el orden natural de tabulación. Para compensarlo, establecemos focus en el primer elemento del menú mediante JavaScript. Esto tiene el efecto secundario de resaltar el elemento (porque también necesitamos tener estilos :focus).
No creo que podamos depender necesariamente de detectar una pulsación de Tab, ya que no es la única tecla que usan los lectores de pantalla para navegar, y si capturáramos todas las pulsaciones de teclas, interferiríamos con otros atajos…
Se me ocurren dos soluciones posibles:
Mover el menú en el HTML para que aparezca inmediatamente después del botón que lo activa. Esto podría tener algunos efectos secundarios en la disposición.
Atrapar el foco dentro del menú cuando está abierto, pero no establecer el foco en ningún elemento en particular. Esto significa que, cuando el menú está abierto, solo puedes navegar por su contenido con Tab y no por nada más en la página. Creo que esta es probablemente la solución preferible…
Correcto. Para mayor especificidad, esto es macOS 11.4 y Safari 14.1.1. Estoy viendo meta en una ventana privada y mi propia instancia en una ventana no privada.
Debo haber cometido un error en mi prueba inicial de Firefox; funciona como describes si la preferencia del sistema para «Usar la navegación por teclado para mover el enfoque entre controles» está habilitada, y salta a un botón de «Me gusta» de la manera que describí anteriormente si está deshabilitada.
Puedo cambiar de forma fiable entre comportamientos alternando esa preferencia del sistema sin necesidad de recargar la página en Firefox.
En Safari, veo que salta a un botón de «Me gusta» independientemente de esa preferencia del sistema, incluso después de recargar la página. Aún no he probado reiniciar Safari después de habilitarla.
Ahora también he revisado Chrome; funciona como describes independientemente de la preferencia del sistema.
He encontrado la causa de mi problema en Safari. Noté que, a diferencia de Chrome y Firefox, si hacía clic en algún lugar de la barra de encabezado y pulsaba Tab, no se seleccionaba ningún elemento de la cabecera.
Esto me llevó a descubrir esta preferencia en Safari, en la sección Avanzado:
Estoy casi seguro de que esa es la configuración predeterminada en una instalación limpia de Big Sur; no creo que la haya cambiado yo. Con esa preferencia activada, el comportamiento empieza a funcionar como describes. Además, como sugiere el texto anterior, también funciona así al usar Option+Tab cuando la preferencia está desactivada.