Skip to content
UX Atlas
Plate A11Y·009 · AccessibilityGrid B4 · Rev. 2026-09-14

Status Messages and Live Regions

Telling assistive technology that something changed, when focus did not move to say so.

AccessibilityCraft conventionAdvanced

Definition

WCAG 4.1.3 requires that status messages can be presented to assistive technology without receiving focus. ARIA live regions are the mechanism: content inserted into them is announced automatically.

Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.

On this plate
  1. 1Definition
  2. 2Politeness levels
  3. 3Implementation notes
  4. 4The region exists first, the message arrives second
  5. 5Announcing change
  6. 6Why a correct live region stays silent
  7. 7Local chart
  8. 8Sources
  9. 9Continue from here

Reach for this when

  • Content updates without a page load or focus change.
  • Search results, filters, validation and autosave.

Common mistakes

  • Region added at the same moment as the message.
  • Assertive used for everything.
  • Rapidly changing content in a live region.

Politeness levels

SettingBehaviourUse for
aria-live="polite"Announced at the next pauseSearch result counts, save confirmations, most updates.
aria-live="assertive"Interrupts immediatelyGenuine urgency only, such as a session about to expire.
role="status"Implicitly politeRoutine status updates.
role="alert"Implicitly assertiveErrors requiring immediate attention.

Implementation notes

  • The live region must exist in the DOM before the content changes. Adding the region and the message at the same time frequently announces nothing.
  • Keep messages short. Long announcements are hard to follow and cannot be re-read.
  • Do not use assertive for routine updates. It interrupts whatever the user was listening to.
  • Do not put live regions on content that changes constantly, such as a live counter.
  • Test with a real screen reader. Live region behaviour varies significantly between implementations.

The region exists first, the message arrives second

html
<!-- Rendered once, on page load, and left empty -->
<div id="status" role="status" aria-live="polite" class="visually-hidden"></div>

<script>
  // Later, in response to something the reader did
  function announce(message) {
    const region = document.getElementById("status");
    region.textContent = "";          // clears a repeated message so it announces again
    requestAnimationFrame(() => {
      region.textContent = message;   // "14 results" or "Draft saved"
    });
  }
</script>

<!-- visually-hidden: off-screen but not display: none, which would silence it -->

The container is rendered empty with the page. Writing text into it later is what triggers the announcement. Creating the container and its content together usually announces nothing.

Announcing change

Do

  • Announce anything that changes without focus moving: result counts, autosaves, background completion, validation summaries.
  • Keep the message to what changed, in the words the reader would use.
  • Use role="alert" only for errors that genuinely interrupt, and role="status" for everything else.
  • Announce the outcome of a long operation, since nobody watches a progress bar with a screen reader.

Do not

  • Do not put a live region around content that updates continuously, which produces constant speech.
  • Do not hide a live region with display: none or the hidden attribute, which stops it announcing entirely.
  • Do not announce and move focus for the same event. The reader hears one and loses the other.
  • Do not rely on a toast alone. It disappears, and the announcement is gone with it.

Why a correct live region stays silent

Worksrole="status", emptytext written in later"14 results"announcedSilentregion and message added togethernothing announcedthe change had nowhere to land
The announcement is triggered by a change inside a region the browser is already watching. A region that arrives with its message has nothing to compare against.

Local chart

A11Y·009 · Region V · Grid B4

This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.

Selective AttentionPSY·004 · WHY THIS WORKSAlert and Inline MessageCMP·015 · RELIED ON BYToastCMP·014 · RELIED ON BYLoading StatesPAT·011 · RELIED ON BYNotificationsPAT·015 · RELIED ON BYSearchPAT·002 · RELIED ON BYSettings and PreferencesPAT·025 · RELIED ON BYNVDATOOL·035 · OFTEN USED WITHARIATERM·074 · SHORT DEFINITIONLive RegionTERM·079 · SHORT DEFINITIONToastTERM·049 · SHORT DEFINITIONError Identification and SuggestionA11Y·016 · RELATED CONCEPT

Sources

Where a source establishes something narrower than the popular reading of it, the note says so.

  1. [1]

Continue from here

Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.

Applies when you are designing

A DashboardA Data TableA FormA Search ExperienceAn AI ProductAn Onboarding Flow

Why this works

The reasoning this entry rests on.

  • Selective AttentionPSY·004 · Psychology

    A message outside the area of focus is routinely missed, which is why confirmation belongs where the action happened.

Relied on by

Entries that assume this is already in place.

Often used with

These usually appear in the same screen or the same decision.

  • NVDATOOL·035 · Tool

Short definition

The one-paragraph version, for when that is all you need.

Related concept

Connected closely enough to change how you apply this.