Cuadros de diálogo modales accesibles

Un cuadro de diálogo modal accesible es una ventana emergente que mantiene el foco del teclado en su interior para que no interactúes por accidente con la página que queda detrás. Cuando abres un diálogo modal, el foco pasa automáticamente a su interior, permanece dentro mientras navegas con la tecla Tab y vuelve al botón en el que hiciste clic cuando lo cierras. Así, quienes usan el teclado o un lector de pantalla pueden completar sus tareas sin perderse ni quedarse atrapados. Por ejemplo, cuando haces clic en «Eliminar cuenta» y aparece un diálogo modal de confirmación, una implementación accesible lleva el foco del teclado a ese diálogo, te permite moverte con Tab entre los botones «Cancelar» y «Confirmar», y te devuelve al punto donde estabas cuando terminas.

Prueba esto: abre cualquier diálogo modal de tu sitio e intenta recorrerlo usando solo la tecla Tab: ¿puedes llegar a todos los botones sin salir del diálogo?

Los cuadros de diálogo modales accesibles funcionan mediante una secuencia que coordina la gestión del foco y los atributos de accesibilidad. Primero, cuando se abre un diálogo modal, JavaScript lleva el foco del teclado a un elemento de su interior. Suele ser el primer elemento interactivo, el título del diálogo si contiene mucho contenido o el botón que se usa con más frecuencia. Esto indica a las tecnologías de asistencia que el diálogo modal es ahora el contexto activo. A partir de ahí, el foco queda contenido: Tab y Mayús+Tab recorren únicamente los elementos interactivos del diálogo, sin pasar nunca a la página del fondo.

El propio diálogo necesita atributos ARIA específicos: role="dialog" (o el elemento nativo dialog de HTML), aria-labelledby que apunte al título del diálogo y aria-modal="true" para indicar a los lectores de pantalla que el contenido exterior no está disponible temporalmente. Estos atributos, junto con el código JavaScript que mantiene el foco dentro del diálogo, ofrecen una experiencia completa a quienes usan tecnologías de asistencia. Por ejemplo, un diálogo modal de consentimiento de cookies que contiene el foco obliga a quienes usan el teclado a responder antes de recorrer el resto del sitio. Al mismo tiempo, informa a quienes usan lectores de pantalla de que la página del fondo está temporalmente inactiva.

Al cerrar el diálogo, el proceso se invierte: el foco vuelve al elemento que lo abrió, o a una alternativa lógica, para que conserves tu lugar en el documento. La tecla Escape debe cerrar siempre el diálogo modal y ofrecer una forma estándar de salir. Este ciclo completo es esencial en distintos contextos: el diálogo de confirmación de compra de una tienda en línea, el panel de ajustes de una aplicación de productividad o el diálogo de verificación de seguridad de una aplicación bancaria. Todos dependen de este patrón para que puedas completar tareas importantes independientemente de cómo navegues.

La complejidad aumenta con los diálogos modales anidados, el contenido dinámico o las particularidades de los dispositivos móviles. Por ejemplo, cuando un diálogo modal abre otro, como un formulario de dirección que se abre desde un diálogo de opciones de envío, cada nivel debe mantener su propio contexto de foco y gestionar correctamente la pila de diálogos. Los lectores de pantalla móviles plantean retos adicionales, ya que pueden usar distintos gestos táctiles para navegar. Sigue siendo esencial probar con tecnologías de asistencia reales, porque las especificaciones no garantizan un comportamiento uniforme en todas las combinaciones de navegador y lector de pantalla.

Los cuadros de diálogo modales accesibles son un patrón bien documentado de accesibilidad web, con especificaciones formales que establecen su comportamiento esperado. La Guía de prácticas de autoría de WAI-ARIA (APG) proporciona la especificación de referencia para implementar diálogos modales. Define la interacción con el teclado, la gestión del foco y los atributos ARIA necesarios, incluido aria-modal="true", que informa a las tecnologías de asistencia de que el contenido del fondo está inactivo [1]. El elemento <dialog> de HTML ofrece compatibilidad nativa con diálogos modales e incorpora la contención del foco, aunque las diferencias de compatibilidad entre navegadores requieren una evaluación cuidadosa antes de usarlo en producción [2].

• El criterio de conformidad 2.4.3 de las WCAG 2.1 del W3C (Orden del foco) exige que la navegación con el teclado siga una secuencia lógica. En los diálogos modales, esto significa mantener el foco dentro del diálogo y devolverlo al lugar adecuado cuando se cierra [1].
• Las investigaciones de TPGi, una consultora de accesibilidad, documentan que la compatibilidad con el atributo aria-modal varía entre lectores de pantalla, especialmente en la combinación de Safari y VoiceOver. Esto exige técnicas complementarias, como combinar el atributo inert con aria-hidden en el contenido del fondo [3].
• La APG especifica estrategias para situar el foco inicial según el tipo de contenido del diálogo: el primer elemento interactivo en diálogos sencillos, un elemento de texto estático cuando el contenido requiere una lectura estructurada o la acción menos destructiva en diálogos de confirmación con consecuencias irreversibles [1].
• La compatibilidad de los navegadores con el elemento nativo <dialog> sigue siendo desigual. Safari y los navegadores antiguos carecen de compatibilidad completa, por lo que hacen falta implementaciones alternativas basadas en ARIA en entornos de producción [2].

La implementación se vuelve más compleja al abordar las diferencias entre las especificaciones y el comportamiento real de las tecnologías de asistencia. Por ejemplo, aunque aria-modal="true" debería impedir en teoría que los cursores virtuales de los lectores de pantalla accedan al contenido del fondo, las pruebas reales revelan carencias de compatibilidad, especialmente con VoiceOver en iOS y macOS. Esta diferencia entre la especificación y la implementación exige estrategias de defensa en profundidad, es decir, varias capas de protección que combinen atributos ARIA, contención del foco con JavaScript y el atributo inert de HTML.

El patrón de diálogo modal tiene limitaciones y dificultades de implementación bien documentadas. La compatibilidad de los lectores de pantalla con aria-modal varía considerablemente: VoiceOver en Safari presenta problemas conocidos por los que aria-modal hace que el contenido estático resulte inaccesible, y algunas combinaciones de navegador y lector de pantalla no respetan correctamente aria-modal="false". El elemento nativo <dialog> no tiene una compatibilidad uniforme entre navegadores, especialmente en Safari y navegadores antiguos, lo que exige usar polyfills, código que suple funciones no disponibles, o alternativas basadas en ARIA. La accesibilidad móvil añade complejidad, ya que los gestos táctiles y los lectores de pantalla móviles interactúan con la gestión del foco de forma distinta a la navegación con teclado en computadoras. Los diálogos modales apilados unos sobre otros, o anidados, agravan estos problemas y exigen gestionar con cuidado varios contextos de foco y capas de z-index. Algunas implementaciones dependen demasiado de JavaScript sin tener en cuenta la mejora progresiva, lo que crea experiencias inaccesibles cuando falla la ejecución de los scripts. Por último, el uso de diálogos modales sigue siendo controvertido en el diseño de la experiencia de usuario: las investigaciones sugieren que interrumpen el flujo del usuario y pueden desorientarlo. Por eso, la solución más accesible suele ser evitarlos por completo cuando basta con una alternativa no modal.