Design Live Regions for Dynamic Content

Accessibility · accessibility, status, errors

Updated 2026-07-28

Announce anything that changes without a page load. Search result counts, form errors, toast messages, and background job results are invisible to a screen reader user unless the interface says them out loud.
Match the urgency to the interruption. A polite announcement waits for the user to finish what they are saying or reading. An assertive one cuts in immediately, so reserve it for problems that block progress.
Put the live region in the DOM before you fill it. A region that appears at the same moment as its text is usually missed, because assistive technology never had a chance to start watching it.
Announce the outcome, not the mechanics. "Saved" and "12 results" are useful. "Component updated" and "State changed" are noise.
Keep announcements short and free of markup. Long regions get read in full every time any part of them changes, which turns a small update into a paragraph.
Do not announce everything. A live region on a fast-updating counter or a streaming log will talk over the user continuously and make the page unusable.
Give every announcement a visible equivalent. If sighted users get a toast, screen reader users should get the same message at the same moment, not a different one.

Dynamic interfaces are only accessible when the change itself is communicated, not just the result.