a11y tips #6: ventanas modales, alertas y otros mensajes accesibles
Las ventanas modales, las alertas y los mensajes de estado son componentes habituales en aplicaciones y sitios web. Se utilizan para solicitar datos, confirmar acciones, advertir sobre errores o comunicar el resultado de una operación.
A pesar de que visualmente pueden adoptar una apariencia similar –un cuadro superpuesto, una notificación o un mensaje destacado–, su propósito y comportamiento son diferentes. Una ventana modal interrumpe temporalmente la interacción con el resto de la página, mientras que una alerta o un mensaje de estado puede anunciar información sin modificar el foco ni impedir que el usuario continúe con su tarea.
Una implementación incorrecta puede provocar que los usuarios de teclado queden atrapados, que el foco permanezca detrás de la ventana, que los lectores de pantalla no anuncien el mensaje o que sea posible interactuar con contenido que visualmente parece desactivado.
Qué son las ventanas modales, las alertas y los mensajes de estado
Una ventana modal es un cuadro de diálogo que se muestra sobre el contenido principal de la página. Mientras permanece abierto, el contenido situado detrás debe quedar inactivo. El usuario debe completar, cancelar o cerrar la interacción antes de volver a la interfaz principal.
Algunos ejemplos habituales son:
- Formularios para editar datos.
- Selectores de fechas.
- Ventanas de configuración.
- Información complementaria que requiere una interacción.
- Procesos compuestos por varios pasos.
Un diálogo de alerta (alert box) es un tipo específico de ventana modal que interrumpe la tarea para comunicar un mensaje importante y solicitar una respuesta. Se utiliza, por ejemplo, para confirmar una operación irreversible o advertir de las consecuencias de una acción.
Una alerta es un mensaje breve e importante que debe anunciarse inmediatamente, pero que no requiere trasladar el foco ni interrumpir la interacción. Puede utilizarse para comunicar un error, una advertencia o una situación que requiere atención.
Finalmente, un mensaje de estado informa sobre el resultado o la evolución de una acción sin interrumpir al usuario. Algunos ejemplos de mensajes son «Cambios guardados», «Cinco resultados encontrados», «Producto añadido a la cesta» o «Cargando resultados».
Cuándo utilizar cada patrón
Utiliza una ventana modal cuando:
- El usuario debe completar una tarea delimitada antes de continuar.
- Es necesario solicitar varios datos relacionados.
- La interacción requiere controles como campos, enlaces o botones.
- El contenido principal no debe permanecer disponible mientras se completa la tarea.
Utiliza un diálogo de alerta cuando:
- La acción tiene consecuencias importantes o difíciles de revertir.
- Es necesario solicitar una confirmación explícita.
- El usuario debe elegir entre varias opciones antes de continuar.
- El mensaje debe interrumpir necesariamente el flujo de trabajo.
Utiliza una alerta no modal cuando:
- El mensaje es importante o urgente.
- No se requiere ninguna respuesta.
- No es necesario mover el foco.
- El usuario puede continuar con su tarea.
Utiliza un mensaje de estado cuando:
- Se comunica el éxito o resultado de una operación.
- Se informa del número de resultados obtenidos.
- Se actualiza el estado de una cesta, un proceso o una aplicación.
- El mensaje no requiere una interrupción inmediata.
No todas las notificaciones visuales deben implementarse como alertas. El uso excesivo de anuncios urgentes puede interrumpir continuamente a los usuarios de lectores de pantalla y dificultar la realización de la tarea.
Consideraciones de diseño
- Utiliza las ventanas modales únicamente cuando sea necesario interrumpir temporalmente el flujo de trabajo.
- Proporciona un título visible que describa claramente su propósito.
- Incluye un botón visible para cerrar o cancelar la ventana.
- No dependas únicamente de un icono con forma de aspa para identificar el botón de cierre. Debe contar con un nombre accesible como «Cerrar ventana».
- Oscurece o diferencia visualmente el contenido situado detrás de la ventana modal.
- Impide que los usuarios interactúen mediante teclado, ratón o dispositivos táctiles con el contenido exterior.
- Asegura que la ventana sea legible y operable en pantallas pequeñas.
- Cuando el contenido sea extenso, permite que la propia ventana se desplace sin ocultar su inicio ni el indicador del foco.
- Evita mensajes que desaparezcan automáticamente antes de que puedan ser leídos.
- No utilices el color como único medio para diferenciar mensajes de error, advertencia o confirmación.
- En acciones destructivas, como eliminar información, destaca claramente las consecuencias y coloca inicialmente el foco sobre la opción menos peligrosa.
- No conviertas el contenedor completo de la ventana modal en un elemento enfocable. El foco debe situarse sobre un control o sobre un elemento estático concreto con
tabindex="-1".
Requisitos de accesibilidad de las ventanas modales
- El contenedor debe contar con
role="dialog". - Debe incluir
aria-modal="true"cuando el contenido exterior sea realmente inerte. - La ventana debe tener un nombre accesible mediante
aria-labelledbyoaria-label. - Siempre que exista un título visible, es preferible utilizar
aria-labelledbypara relacionarlo con la ventana. aria-describedbypuede relacionar la ventana modal con un mensaje o descripción breve.- No conviene utilizar
aria-describedbycuando el contenido incluye varios párrafos, listas, tablas u otras estructuras que deben recorrerse de forma independiente. - Al abrir la ventana, el foco debe desplazarse hasta un elemento situado en su interior.
- La tabulación debe permanecer dentro de la ventana modal.
- Cuando el foco alcanza el último control, la tecla
Tabdebe devolverlo al primero. - Cuando el foco se encuentra en el primer control,
Mayús+Tabdebe llevarlo al último. - La tecla
Escapedebe cerrar la ventana. - Debe existir un botón visible que permita cerrarla.
- Al cerrar la ventana, el foco debe volver normalmente al elemento que la abrió.
- El contenido exterior debe permanecer inerte mientras la modal está abierta.
- El foco debe resultar claramente visible en todos los controles.
- Deben evitarse valores de
tabindexsuperiores a0.
El atributo aria-modal="true" no convierte por sí solo un elemento en una ventana modal. El código también debe impedir que cualquier usuario interactúe con el contenido exterior.
Requisitos de accesibilidad de los diálogos de alerta
Los diálogos de alerta comparten el comportamiento de las ventanas modales, pero utilizan role="alertdialog".
- El contenedor debe contar con
role="alertdialog". - Debe incluir
aria-modal="true". - Debe tener un nombre accesible mediante
aria-labelledbyoaria-label. - El mensaje principal debe asociarse mediante
aria-describedby. - El foco debe desplazarse hasta un control situado dentro del diálogo.
- En acciones destructivas, el foco inicial debería colocarse sobre la opción menos peligrosa.
- La navegación con
TabyMayús+Tabdebe permanecer dentro del diálogo. Escapedebe permitir cerrarlo.- Al cerrarlo, el foco debe regresar al elemento que lo activó.
Requisitos de accesibilidad de las alertas y mensajes de estado
Las alertas y los mensajes de estado no deben recibir el foco automáticamente.
Para los mensajes urgentes puede utilizarse:
<div role="alert" aria-atomic="true"></div>
El rol alert indica que el contenido debe anunciarse inmediatamente. No es necesario añadir aria-live="assertive", puesto que este comportamiento está implícito en el rol.
Para los mensajes no urgentes puede utilizarse:
<div role="status" aria-atomic="true"></div>
El rol status dispone de un comportamiento equivalente a una región activa con aria-live="polite". El lector de pantalla anuncia el mensaje cuando finaliza la información que estaba leyendo, sin interrumpirla.
Ten en cuenta que:
- El contenedor de la región activa debe estar presente antes de que se produzca el mensaje.
- El texto debe insertarse o actualizarse después de la acción del usuario.
- No debe trasladarse el foco hasta el mensaje.
- El mensaje debe mostrarse también visualmente.
aria-atomic="true"permite anunciar el contenido completo cuando se actualiza una parte de la región.role="alert"debe reservarse para información importante.- Los mensajes no deben desaparecer demasiado rápido.
- Las alertas no deben producirse con una frecuencia que interfiera constantemente con la tarea.
Código HTML, CSS y JavaScript
Ejemplo de ventana modal
En el siguiente ejemplo, el contenido principal se encuentra dentro de #page-content. La ventana modal se sitúa fuera de este contenedor para evitar que quede afectada cuando se aplica la propiedad inert. Los estilos permiten diferenciar la ventana del resto de la página, mantener el foco visible y adaptar el componente a pantallas pequeñas. El JavaScript se encarga de abrir y cerrar la ventana, mantener la tabulación en su interior y devolver el foco al botón que la activó. El atributo inert evita que el contenido principal reciba el foco o responda a la interacción mientras la ventana permanece abierta. El diálogo se encuentra fuera de #page-content, por lo que continúa siendo operativo.
Ejemplo de diálogo de alerta
En este ejemplo, el diálogo se sitúa fuera de #page-content para que siga siendo operativo al aplicar inert al contenido principal. El JavaScript gestiona la apertura y el cierre, mantiene el foco dentro del diálogo y lo devuelve al botón activador. El foco inicial se coloca en «Cancelar», la opción menos destructiva.
Ejemplo de alerta urgente
El contenedor con role="alert" está presente desde la carga de la página y su contenido se actualiza al activar el botón. El lector de pantalla anuncia el mensaje inmediatamente sin desplazar el foco, mientras que los estilos permiten diferenciar visualmente la alerta.
Ejemplo de mensaje no urgente
El elemento con role="status" comunica el resultado de la operación sin interrumpir al usuario ni modificar el foco. El JavaScript actualiza el contenido después de pulsar el botón y los estilos presentan el mensaje de confirmación de forma visible.
Criterios de conformidad WCAG relacionados
- 1.3.1: Información y relaciones (nivel A).
- 1.4.3: Contraste mínimo (nivel AA).
- 1.4.11: Contraste no textual (nivel AA).
- 2.1.1: Teclado (nivel A).
- 2.1.2: Sin trampas para el foco del teclado (nivel A).
- 2.4.3: Orden del foco (nivel A).
- 2.4.7: Foco visible (nivel AA).
- 2.4.11: Foco no oculto —mínimo— (nivel AA).
- 3.2.2: Al recibir entradas (nivel A).
- 4.1.2: Nombre, función, valor (nivel A).
- 4.1.3: Mensajes de estado (nivel AA).
Referencias
W3C (2026). Alert Pattern. ARIA Authoring Practices Guide. https://www.w3.org/WAI/ARIA/apg/patterns/alert
W3C (2025). Alert and Message Dialogs Pattern. ARIA Authoring Practices Guide. https://www.w3.org/WAI/ARIA/apg/patterns/alertdialog
W3C (2026). Alert Dialog Example. ARIA Authoring Practices Guide. https://www.w3.org/WAI/ARIA/apg/patterns/alertdialog/examples/alertdialog
W3C (2026). Dialog (Modal). ARIA Authoring Practices Guide. https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal
W3C (2026). Modal Dialog Example. ARIA Authoring Practices Guide. https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/examples/dialog
W3C (2026). Understanding Success Criterion 4.1.3: Status Messages. https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html
W3C (2026). Using ‘role=status’ to present status messages. WCAG 2.2 Techniques. https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA22
Deja una respuesta