Short answer: aria-live marks a part of the page whose changes a screen reader should announce without moving the focus. Put the region on the page empty, then change its text. Use polite for almost everything and keep assertive for what can’t wait.
Why changes go unheard
MDN explains that sighted users usually notice when a part of the screen updates. A screen reader focuses on one part of the page at a time, and the update may be somewhere else.
The aria-live attribute fixes that. When the content of the region changes, the screen reader announces it, and the element is not given focus. Our screen reader guide shows how people move through a page.
WCAG asks for this in success criterion 4.1.3, Status Messages, at level AA. A status message has to reach assistive technologies through a role or properties, without receiving focus.
Polite, assertive or off
| Value or role | When it speaks | Use it for |
|---|---|---|
| aria-live="polite" | When the user is idle | Most updates |
| aria-live="assertive" | Right away, interrupting | Time-sensitive, critical notices |
| aria-live="off" | Only with the focus inside it | Updates nobody needs to hear at once |
| role="status" | Like polite | A status, such as a count or a result |
| role="alert" | Like assertive | An error or a warning |
From MDN, read November 5, 2026.
Polite is the most common value, since it waits until the user is idle. MDN reserves assertive for time-sensitive, critical notifications, because it interrupts whatever the screen reader is saying.
Off is easy to misread: it doesn’t silence the region. Its changes are only announced when the focus is on or inside it.
The region has to exist before the message
Assistive technologies generally announce only changes inside a live region, not the region itself. MDN’s advice is to start with an empty region and give it time to be exposed before you update it.
In practice, put the empty element in the page when it loads and write the message into it later. A region added together with its text is often never read.
Read the whole message with aria-atomic
By default a screen reader may read only the part that changed. aria-atomic="true" makes it read the whole region each time, as in MDN’s clock example.
The W3C technique ARIA22 uses role="status" for status messages, such as “5 results returned”. It adds aria-atomic="true" because some environments don’t treat the status role as atomic by default.
Roles that are live regions already
Some roles act as live regions by default: status and log are polite, alert is assertive. MDN suggests a redundant aria-live="polite" on status and log for compatibility.
With alert, though, MDN warns that adding aria-live as well makes VoiceOver on iOS speak twice. Our loading animation guide shows a status region for loading text, and our what is ARIA guide covers roles in general.
How to add a live region
- Add the region to the page when it loads, empty.
- Use aria-live="polite" or role="status" for most messages.
- Keep assertive and role="alert" for what can’t wait.
- Add aria-atomic="true" when the whole message must be read.
- Write short text into the region and leave the focus where it is.
- Don’t combine role="alert" with aria-live on the same element.
- Test with a screen reader that each message is announced once.
The chat message on our pricing page
On November 5, 2026, we watched the chat’s message on our pricing page, in both languages, scrolling half a screen as a visitor would. A status region, polite and atomic, was already on the page, empty, about two seconds after it loaded.
When the message came, its text went into that region with our name in front: “Feedback Studios: Not sure which plan fits?…”. Eight seconds later the region was empty again.
The focus never moved: it stayed where it was before, during and after the message.
Before you publish
- Every live region is on the page before its first message.
- Routine updates are polite; only urgent ones are assertive.
- Each message is short and makes sense on its own.
- aria-atomic is set where the whole text must be read.
- No element has both role="alert" and aria-live.
- Nothing takes the focus just to announce a status.
RememberA live region speaks for the part of the page the screen reader isn’t on. Keep it empty until it has something to say, and keep what it says short.
Our web design service adds these regions where a message has to be heard.
Quick answers about aria-live
What is the difference between aria-live polite and assertive?
Polite waits until the user is idle and doesn’t interrupt the current task. Assertive speaks right away and can clear what the screen reader was about to say. MDN keeps assertive for time-sensitive, critical notifications.
Why isn’t my aria-live region announced?
Usually because the region arrived with its message. MDN says assistive technologies generally announce only changes inside a live region, so add the region empty when the page loads, give it a moment, and then change its text.
Should I use role="status" or aria-live="polite"?
role="status" already acts as a polite live region. MDN suggests adding a redundant aria-live="polite" for compatibility, and the W3C technique ARIA22 adds aria-atomic="true" when the whole message should be read.
Does WCAG require live regions?
It requires status messages to reach screen readers. Success criterion 4.1.3, level AA, asks that they be programmatically determined through a role or properties, so they are presented without receiving focus. A live region is the usual way.
Can I use role="alert" and aria-live="assertive" together?
Better not. MDN notes that some people add the redundant attribute for compatibility, but that using both aria-live and role="alert" makes VoiceOver on iOS speak the message twice.
Sources
Read on November 5, 2026. MDN Web Docs: ARIA: aria-live attribute and ARIA live regions. W3C Web Accessibility Initiative: Understanding Success Criterion 4.1.3: Status Messages and ARIA22: Using role=status to present status messages. Our case: our own pages, read in a browser on November 5, 2026.