No es necesario centrarse en el elemento de diálogo.

Estaba construyendo un Modal componentes utilizados <dialog> elemental showModal método. Mientras probaba el componente descubrí que podía saltar <dialog> (en modo modal) y en la barra de direcciones.

Me sorprende: los consejos de accesibilidad sobre los modales a menudo nos enseñan a mantener el enfoque dentro del modal. Entonces esto me parece incorrecto.

Después de más Investigaciónparece que ya no necesitamos limitar el enfoque a <dialog> (incluso en modo modal). Entonces, si está utilizando la captura de enfoque, no se recomienda esta sugerencia. <dialog>.

Darte algunas notas

En lugar de pedirle que lea el texto completo Problemas de GitHub Para ampliar la discusión, he resumido algunos puntos clave de figuras notables a continuación.

aquí hay algunos Comentario Scott O’Hara nos brinda la historia y los antecedentes de las recomendaciones de captura de enfoque:

WCAG es No Especifica que el foco debe restringirse al cuadro de diálogo. Por el contrario, la especificación canónica WCAG no menciona los requisitos para el comportamiento del enfoque en los cuadros de diálogo.

informativo 2.4.3 Comprender el documento en orden de enfoque Hacer Hable sobre limitar el comportamiento de enfoque dentro de un diálogo, pero nuevamente, esto está en el contexto de un diálogo personalizado con script y se escribió hace mucho tiempo. inert o <dialog> es ampliamente utilizado.

El propósito de APG es demostrar cómo utilizar ARIA. Además, sin utilizar funciones HTML nativas, p. <dialog> o inertcapturar el foco en un cuadro de diálogo personalizado es mucho más fácil que implementar ese comportamiento <dialog> Los elementos están ahí.

Los cuadros de diálogo modales APG y la documentación de comprensión WCAG se remontan a inert atributo o <dialog> Los elementos cuentan con un amplio apoyo. Y otra forma de indicar a los desarrolladores que capturen el foco en los diálogos es decirles que deben asegurarse de que todos los elementos enfocables en la página web fuera del diálogo modal reciban un tabindex=-1.

Leonie Watson peso Y explica por qué los usuarios de lectores de pantalla pueden mover el foco a la barra de direcciones:

En el contexto de la página puedes elegir pestaña En la parte inferior y alrededor del navegador Chrome, puede usar comandos de teclado para moverse directamente a la barra de direcciones o abrir menús específicos, puede cerrar pestañas y más. Esto permite a las personas elegir cómo, por qué y qué hacer para escapar de su entorno.

Parece lógico (al menos para mí) que se puedan usar las mismas opciones en un contexto de diálogo en lugar de en un contexto de página.

por fin, matak Compartió las conclusiones del Grupo de Trabajo sobre Arquitectura de Plataforma Accesible (APA) del W3C, que coincidió con lo siguiente: <dialog>de showModal Los métodos no necesitan captar el foco.

Discutimos este tema en varias reuniones de la APA y concluimos que el comportamiento actual de los elementos de diálogo nativos debería permanecer sin cambios. Para que pueda cambiar del cuadro de diálogo a la funcionalidad del navegador.

En particular, vemos el beneficio de que los usuarios del teclado puedan abrir una nueva pestaña para encontrar contenido importante o cambiar la configuración del navegador de esta manera. Al mismo tiempo, el elemento de diálogo proporciona un mecanismo de escape natural adicional (es decir, movimiento a la barra de direcciones), por ejemplo, en situaciones de quiosco donde el usuario no puede usar otros atajos de teclado estándar.

Por lo que he leído, si utilizamos correctamente la API Dialog, no tenemos que preocuparnos por problemas de captura de enfoque. showModal ¡método!

Esperamos que esta noticia le facilite la construcción de componentes. 😉