Live regions and announcements

AI interfaces change after the page has loaded. A reply arrives, a status moves from generating to ready, a suggestion appears, or an answer streams in a piece at a time. A sighted user sees these changes. A screen reader user only learns about them if you announce them, and the announcement must not drag their focus away from what they were doing. A live region is the mechanism for that, and this page is the shared recipe the other patterns build on.

Key points

A live region announces a change to assistive technology without moving the user’s focus.
Put one region in the DOM ahead of time and update its contents, rather than inserting a region at the moment its content appears.
Reach for role="status" on a plain element by default, since it is polite, atomic, and widely supported.
Announce meaningful units, not every change, and remember that repeating the exact same text will not re-announce.
Keep announcements polite, and never move focus just to make something heard.

Put one region in the DOM ahead of time

Scott O’Hara’s guidance on live regions is the place to start. Put a single live region in the page before you have anything to announce, then update its contents when something changes. A region that is inserted at the same moment as its content is announced unreliably, because assistive technology may not have registered it yet. One stable region that you write into is far more predictable than a fresh node per message.

Choose the right element

A live region can be a plain element with role="status" or the native output element, and the choice is worth making on purpose.

Use role="status" on a plain element, such as a p or a div, for a short status notice or a one-shot announcement. It is polite and atomic by default and is the most reliably announced across screen readers.
Use the native output element for content that is the result of a calculation or a user action, such as a generated answer, since that is what the element means.

Both are polite live regions, because output carries an implicit role="status". The catch is that screen reader support for the output element’s built-in live region is uneven, so add an explicit role="status" to an output rather than trusting the default.

Keep announcements polite

With a polite region an announcement waits until the screen reader is idle. With an assertive one it interrupts whatever is being read. Most generated output should be polite, since it is not urgent enough to justify cutting the user off. Reserve assertive for the rare message that is both urgent and infrequent, such as a session about to expire or an action that failed. The glossary defines the polite and assertive settings.

Announce meaningful changes, not every change

A region that updates on every small change floods the screen reader with a barrage no one can follow. Announce in units a person can take in, such as a full status or a complete sentence, rather than every intermediate state. Two things trip people up. Setting the region to the exact same string it already holds will not re-announce, so a repeated message needs genuinely different text. And clearing then refilling a region rapidly can talk over itself. Decide what the user should hear, and update the region only when that changes.

Do not reach for role=“log” without testing

role="log" looks like the right role for a running list of messages, such as a chat transcript or an agent’s activity, but its live behavior varies across screen readers. James Scholes argues that you should design the screen reader experience deliberately rather than delegating it to a role whose behavior you have not confirmed. If you use log, test it with real assistive technology rather than assuming it announces the way you expect.

Never move focus just to make something heard

Announcing a change and moving focus to it are different things. A live region lets the user hear the change while their focus stays where they put it. Moving focus to force an announcement pulls the user out of what they were doing, which is its own failure. Announce through the region, and move focus only when the user has asked to go somewhere, such as jumping to a new reply. This is the status-message behavior required under criterion 4.1.3.

Audience: Engineer

Keep one pre-existing region and write to it. A plain element with role="status" is the safe default, and an output with an explicit role="status" suits generated result content. Update it with whole units rather than every change, and never set it to a string it already holds, since that will not re-announce. Do not move focus to trigger the announcement.

<!-- One pre-existing polite region, present before there is anything to say -->
<p id="announce" class="visually-hidden" role="status"></p>

// Announce a settled unit, resetting first so a repeated message still speaks
function announce(message) {
  const region = document.getElementById('announce');
  if (region.textContent === message) region.textContent = '';
  region.textContent = message;
}

Audience: Accessibility Specialist

Automated tools tell you almost nothing here, so test with a real screen reader. Confirm that a change is announced once, that it does not repeat or talk over itself, and that focus does not move when something is announced. Live regions are the mechanism behind status-message conformance under 4.1.3, so tie your check to real output rather than to the presence of an aria-live attribute.

Where this pattern shows up

Dynamic and streaming output applies it to text that arrives token by token, where the region has to be debounced into chunks.
Conversational interfaces uses it to announce a new reply without pulling focus from the composer.
AI-assisted inputs uses it to announce that a suggestion is available.
Agentic actions uses it for an activity log of meaningful steps.