Respuesta corta: aria-live marca una parte de la página cuyos cambios debe anunciar el lector de pantalla sin mover el foco. Pon la región en la página vacía y después cambia su texto. Usa polite casi siempre y deja assertive para lo que no puede esperar.
Por qué no se oyen los cambios
MDN explica que quien ve la pantalla suele notar cuando una parte se actualiza. El lector de pantalla se centra en una parte de la página cada vez, y el cambio puede estar en otra.
El atributo aria-live lo resuelve. Cuando cambia el contenido de la región, el lector de pantalla lo anuncia, y el elemento no recibe el foco. Nuestra guía del lector de pantalla muestra cómo se recorre una página.
Las WCAG lo piden en el criterio 4.1.3, Mensajes de estado, de nivel AA. Un mensaje de estado tiene que llegar a las tecnologías de apoyo mediante un rol o propiedades, sin recibir el foco.
Polite, assertive u off
| Valor o rol | Cuándo habla | Para qué sirve |
|---|---|---|
| aria-live="polite" | Cuando la persona hace una pausa | La mayoría de los cambios |
| aria-live="assertive" | Enseguida, interrumpiendo | Avisos urgentes y críticos |
| aria-live="off" | Solo con el foco dentro | Cambios que nadie necesita oír al momento |
| role="status" | Como polite | Un estado, como un contador o un resultado |
| role="alert" | Como assertive | Un error o una advertencia |
De MDN, en inglés, consultado el 5 de noviembre de 2026.
Polite es el valor más usado, porque espera a que la persona haga una pausa. MDN reserva assertive para avisos urgentes y críticos, porque interrumpe lo que esté diciendo el lector de pantalla.
Off se presta a confusión: no silencia la región. Sus cambios solo se anuncian cuando el foco está en ella o dentro de ella.
La región tiene que existir antes del mensaje
Las tecnologías de apoyo suelen anunciar solo los cambios dentro de una región viva, no la región en sí. MDN aconseja empezar con una región vacía y darle tiempo a quedar expuesta antes de actualizarla.
En la práctica, pon el elemento vacío en la página al cargarla y escribe el mensaje en él más tarde. Una región que llega junto con su texto muchas veces no se lee nunca.
Leer el mensaje entero con aria-atomic
Por defecto, el lector de pantalla puede leer solo la parte que cambió. aria-atomic="true" hace que lea la región entera cada vez, como en el ejemplo del reloj de MDN.
La técnica ARIA22 del W3C usa role="status" para los mensajes de estado, como «5 results returned». Añade aria-atomic="true" porque algunos entornos no tratan el rol status como atómico por defecto.
Roles que ya son regiones vivas
Algunos roles funcionan como regiones vivas por defecto: status y log son polite, alert es assertive. MDN propone añadir aria-live="polite" de más a status y log por compatibilidad.
Con alert, en cambio, MDN avisa de que añadir también aria-live hace que VoiceOver en iOS hable dos veces. Nuestra guía de animaciones de carga muestra una región de estado para el texto de carga, y nuestra guía de qué es ARIA trata los roles en general.
Cómo añadir una región viva
- Añade la región a la página al cargarla, vacía.
- Usa aria-live="polite" o role="status" para la mayoría de los mensajes.
- Deja assertive y role="alert" para lo que no puede esperar.
- Añade aria-atomic="true" cuando haya que leer el mensaje entero.
- Escribe un texto corto en la región y deja el foco donde está.
- No juntes role="alert" y aria-live en el mismo elemento.
- Comprueba con un lector de pantalla que cada mensaje se anuncia una vez.
El mensaje del chat en nuestra página de precios
El 5 de noviembre de 2026 observamos el mensaje del chat en nuestra página de precios, en los dos idiomas, bajando media pantalla como haría un visitante. Una región de estado, polite y atómica, ya estaba en la página, vacía, unos dos segundos después de cargar.
Cuando llegó el mensaje, su texto entró en esa región con nuestro nombre delante: «Feedback Studios: ¿No sabes qué plan te conviene?…». Ocho segundos después la región volvía a estar vacía.
El foco no se movió en ningún momento: siguió donde estaba antes, durante y después del mensaje.
Antes de publicar
- Cada región viva está en la página antes de su primer mensaje.
- Los cambios de rutina son polite; solo los urgentes son assertive.
- Cada mensaje es corto y se entiende solo.
- aria-atomic está puesto donde hay que leer el texto entero.
- Ningún elemento tiene a la vez role="alert" y aria-live.
- Nada toma el foco solo para anunciar un estado.
RecuerdaUna región viva habla por la parte de la página en la que no está el lector de pantalla. Mantenla vacía hasta que tenga algo que decir, y que lo que diga sea corto.
Nuestro servicio de diseño web añade estas regiones donde un mensaje se tiene que oír.
Respuestas rápidas sobre aria-live
¿Qué diferencia hay entre aria-live polite y assertive?
Polite espera a que la persona haga una pausa y no interrumpe lo que está haciendo. Assertive habla enseguida y puede cortar lo que el lector de pantalla iba a decir. MDN reserva assertive para avisos urgentes y críticos.
¿Por qué no se anuncia mi región aria-live?
Casi siempre porque la región llegó junto con su mensaje. MDN dice que las tecnologías de apoyo suelen anunciar solo los cambios dentro de una región viva. Añádela vacía al cargar la página, deja pasar un momento y luego cambia su texto.
¿Uso role="status" o aria-live="polite"?
role="status" ya funciona como una región viva polite. MDN propone añadir además aria-live="polite" por compatibilidad, y la técnica ARIA22 del W3C suma aria-atomic="true" cuando hay que leer el mensaje entero.
¿Las WCAG exigen regiones vivas?
Exigen que los mensajes de estado lleguen al lector de pantalla. El criterio 4.1.3, de nivel AA, pide que se puedan determinar por programa mediante un rol o propiedades, para que se presenten sin recibir el foco. Una región viva es la forma habitual.
¿Puedo usar role="alert" y aria-live="assertive" a la vez?
Mejor no. MDN cuenta que hay quien añade el atributo de más por compatibilidad. Pero usar a la vez aria-live y role="alert" hace que VoiceOver en iOS lea el mensaje dos veces.
Fuentes
Consultadas el 5 de noviembre de 2026. En inglés: MDN Web Docs, ARIA: aria-live attribute y ARIA live regions; Iniciativa de Accesibilidad Web del W3C, Understanding Success Criterion 4.1.3: Status Messages y ARIA22: Using role=status to present status messages. Nuestro caso: nuestras propias páginas, leídas en un navegador el 5 de noviembre de 2026.