La accesibilidad web es un desafío constante, y entre las problemáticas más comunes se encuentran los diálogos modales. Pero, ¿qué son exactamente y por qué pueden llegar a representar un problema?
Un diálogo modal es una ventana emergente que aparece sobre el contenido principal de una página web, obligando a la persona usuaria a interactuar con él antes de poder volver al contenido subyacente. Se utilizan para formularios, confirmaciones de acción o alertas, avisos de cookies, etc. Aunque son herramientas útiles, desde el punto de vista de la accesibilidad pueden presentar problemas.
## Principales problemas de accesibilidad
————————————–
1. **Foco no gestionado**: Muchas veces, al abrir un diálogo modal, el foco del teclado no se mueve automáticamente a su contenido, lo que deja a quienes navegan mediante teclado o lectores de pantalla perdidos en el contenido que está detrás del modal.
2. **Falta de indicación clara**: Los modales pueden no anunciarse correctamente a las tecnologías de asistencia, dejando a las personas usuarias sin contexto sobre qué ha pasado o qué acción realizar.
3. **Navegación no restringida o confusa**: Cuando el foco del teclado no está restringido al modal, es posible «escapar» involuntariamente hacia el contenido detrás de este, causando confusión.
4. **Cierre inaccesible**: Un modal que no se puede cerrar fácilmente con el teclado (por ejemplo, con la tecla Esc) o que carece de un botón de cierre visible genera frustración y exclusión.
## ¿Cómo diseñar diálogos modales accesibles?
——————————————
Para que un diálogo modal cumpla con los estándares de accesibilidad, debe tener las siguientes características clave:
### 1\. Gestionar correctamente el foco del teclado
Al abrir el modal, el foco del teclado debe moverse automáticamente al primer elemento interactivo dentro de él, como un botón o un campo de formulario. Al cerrarlo, el foco debe volver al elemento que lo activó.
Debido a que puede haber contenido textual antes del primer elemento interactivo, y el usuario de lector de pantalla puede no darse cuenta de ello, es recomendable implementar como primer elemento interactivo un botón de «Cerrar», de esta manera nos aseguramos que nunca se perderá información.
Si el contenido textual antes del elemento interactivo es breve, también puede relacionarse con los atributos aria-labelledby y aria-describedby como se explica más adelante.
**Ejemplo**: Supongamos un botón que activa un modal. Cuando el modal se abre, el foco se debe mover al contenido del modal y, al cerrarlo, volver al botón original.
«`html
Título del modal
Descripción del contenido del modal.
«`
### 2\. Usar roles y atributos de ARIA
Para garantizar que el modal sea accesible a lectores de pantalla, se deben usar atributos como:
– role=»dialog»: Indica que el elemento es un diálogo.
– aria-modal=»true»: Especifica que es un modal y que se debe interactuar con él antes de volver al contenido principal.
– aria-labelledby y aria-describedby: Vinculan el modal con un título y una descripción que las tecnologías de asistencia pueden anunciar.
### 3\. Implementar el bloqueo de foco
Mientras el modal esté abierto, el foco del teclado debe permanecer dentro de él. Esto evita que las personas usuarias naveguen accidentalmente hacia el contenido detrás del modal. La técnica de «bloqueo de foco» se utiliza para este propósito.
Un ejemplo básico en JavaScript sería:
«`js
document.addEventListener(‘keydown’, (e) => {
if (e.key === ‘Tab’ && modalOpen) {
// Asegurarse de que el foco no escape del modal
const focusableElements = modal.querySelectorAll(‘button, input, \[tabindex\]:not(\[tabindex=»-1″\])’);
const firstElement = focusableElements\[0\];
const lastElement = focusableElements\[focusableElements.length – 1\];
if (e.shiftKey && document.activeElement === firstElement) {
lastElement.focus();
e.preventDefault();
} else if (!e.shiftKey && document.activeElement === lastElement) {
firstElement.focus();
e.preventDefault();
}
}
});
«`
### 4\. Ofrecer métodos claros para cerrar el modal
Es fundamental incluir un botón de cierre visible y accesible, así como permitir el cierre mediante la tecla **Esc**.
**Ejemplo con HTML y ARIA**:
«`html
«`
### 5\. Ocultar o hacer inerte el contenido detrás del modal
Cuando el modal está activo, el contenido detrás de él debe quedar inaccesible para las tecnologías de asistencia. Esto se puede lograr con aria-hidden.
«`html
«`
En versiones más recientes, es más recomendable utilizar el atributo inert de HTML, ya que él por sí mismo ya evita que el foco entre en cierto contenido, por lo que si se aplica en lugar de aria-hidden no será necesario gestionar el bloqueo del foco
## Beneficios para todas las personas usuarias
——————————————-
Los diálogos modales bien diseñados no solo benefician a las personas con discapacidad, sino que también mejoran la experiencia de navegación para quienes navegan rápidamente con el teclado, en dispositivos móviles o en situaciones de baja concentración. La navegación se vuelve más clara, intuitiva y coherente.
Implementar estas recomendaciones no solo garantiza el cumplimiento de estándares como las **WCAG**, sino que también fomenta un diseño inclusivo, haciendo la web más accesible y funcional para todas las personas.