Vi una publicación en LinkedIn sobre cómo la accesibilidad de algunos modales está rota porque atrapan el foco, incumpliendo el criterio de éxito 2.1.2 Sin bloqueo de teclado de las WCAG (Web Content Accessibility Guidelines). Esto es incorrecto, pero es fácil entender cómo alguien puede llegar a esa conclusión.
Cuando hablamos de accesibilidad, solemos citar las WCAG porque presentan los criterios de manera comprensible.
Pero practicar la accesibilidad (ya sea desarrollando sitios web o aplicaciones accesibles, analizando o auditando la accesibilidad en proyectos existentes, o corrigiendo estos problemas) normalmente requiere profundizar más.
Primero, tenemos los documentos Understanding de las WCAG. Ayudan a los desarrolladores a comprender mejor cada criterio con información de contexto y detalles técnicos, incluyendo técnicas suficientes con ejemplos.
Luego, tenemos la suite Accessible Rich Internet Applications (ARIA). Define cómo hacer que el contenido web y las aplicaciones web sean accesibles para personas con discapacidad. La Authoring Practices Guide (APG) explica en detalle cómo se deben implementar los patrones y las prácticas.
También tenemos la EN 301 549, que es la norma europea armonizada para los requisitos de accesibilidad en productos y servicios TIC. Esta norma especifica cómo se aplican las WCAG al contenido web, documentos y aplicaciones.
Tantos materiales pueden ser abrumadores. Pero significa que entran en detalles muy específicos sobre qué hay que conseguir y cómo hacerlo.
Empecemos por el criterio 2.1.2 Sin bloqueo de teclado. La definición de las WCAG es: «Si el foco del teclado puede moverse a un componente de la página mediante una interfaz de teclado, entonces el foco puede alejarse de ese componente usando únicamente una interfaz de teclado, y, si requiere más que las teclas de flecha o tabulación sin modificar u otros métodos de salida estándar, se informa al usuario del método para mover el foco.»
Parece bastante sencillo. Si navegas con el teclado, ningún componente debería atraparte de una manera de la que no puedas salir usando el teclado.
Pero exploremos el patrón ARIA Dialog (Modal). La documentación ARIA aclara: «Un diálogo es una ventana superpuesta sobre la ventana principal o sobre otra ventana de diálogo. Las ventanas bajo un diálogo modal están inactivas. Es decir, los usuarios no pueden interactuar con el contenido fuera de una ventana de diálogo activa. El contenido inactivo fuera de un diálogo activo suele estar visualmente oscurecido o atenuado de modo que es difícil de distinguir, y en algunas implementaciones, los intentos de interactuar con el contenido inactivo provocan que el diálogo se cierre.
Al igual que los diálogos no modales, los diálogos modales contienen su propia secuencia de tabulación. Es decir, Tab y Mayús+Tab no mueven el foco fuera del diálogo. Sin embargo, a diferencia de la mayoría de diálogos no modales, los diálogos modales no proporcionan medios para mover el foco del teclado fuera de la ventana del diálogo sin cerrarlo.»
No hay ambigüedad. Un modal (o diálogo) debe impedir que el usuario salga del modal hasta que se cierre. ¿Contradice esto el criterio de las WCAG?
Si consultamos el documento Understanding sobre el criterio de éxito 2.1.2, en la sección de intención, se explica: «La intención de este criterio de éxito es garantizar que el contenido no «atrape» el foco del teclado dentro de subsecciones del contenido en una página web. Esto es un problema frecuente cuando múltiples formatos se combinan dentro de una página y se muestran mediante complementos o aplicaciones incrustadas.
Puede haber momentos en que la funcionalidad de la página web restrinja el foco a una subsección del contenido, siempre que el usuario sepa cómo abandonar ese estado y 'liberar' el foco.»
Todo parece reducirse a dos consideraciones: si el método de salida es estándar, y si la aplicación del patrón modal es adecuada.
El primero es fácil de resolver, ya que el uso de la tecla Esc o de un botón de cierre se menciona en el patrón ARIA Dialog (Modal).
El segundo es donde reside la decisión importante. ¿Por qué usamos un modal? Este patrón se utiliza para presentar información o una decisión que debe mostrarse y reconocerse antes de que el usuario pueda continuar con su tarea.
Si volvemos a la publicación de LinkedIn, ahora sabemos que un modal en el que el usuario puede saltárselo sin reconocerlo es una implementación incorrecta. Entonces, ¿de dónde viene la confusión? Probablemente la persona que lo publicó estaba pensando en un diálogo no modal donde el usuario debería poder navegar fuera del diálogo. Pero al llamarlo modal y usarlo como ejemplo de incumplimiento del criterio de éxito 2.1.2 de las WCAG, simplemente estaba haciendo una afirmación engañosa.
El problema existe porque modal se usa de forma laxa como concepto amplio que engloba varios tipos de interfaces de usuario con comportamientos e implementaciones diferentes. Sin embargo, en la documentación, la especificación del modal está claramente definida y es diferente de conceptos similares.
La accesibilidad requiere un uso del lenguaje más específico y riguroso que otras disciplinas. Algunos pueden pensar que este rigor es innecesario, pero estamos hablando de estándares. El rigor y la fiabilidad de los diferentes documentos y normas es una gran parte de lo que los hace valiosos.