ARIA Live Regions: Announce Status Messages
Also called: aria-live, Live region, Status message
Definition
An ARIA live region is a part of the page marked with aria-live or a live role such as status or alert. When its content changes, screen readers announce the new text without the user having to move focus to it.
ARIA live regions are areas of a page that tell assistive technology: "announce changes here". When a shop adds an item to the cart, a search returns results or a form shows an error next to a field, sighted visitors notice it at a glance. A screen reader user only hears about it if the message sits in a live region – otherwise the update happens in silence.
What it means
WCAG 4.1.3 Status Messages (Level AA, WCAG 2.2) requires that status messages can be programmatically determined through role or properties, so assistive technology can present them without the message receiving focus. W3C defines a status message as a change in content that is not a change of context and that reports the result of an action, a waiting state, the progress of a process or the existence of errors.
Typical status messages from the W3C examples: "5 results returned" after a search, an updated cart count, an "Invalid entry" note near a field, a busy indicator and a confirmation after a form was sent.
The ARIA specification offers several ways to mark them:
| Markup | Announcement | Use it for |
|---|---|---|
role="status" |
Polite – waits until the screen reader is idle | Results, confirmations, cart counts (W3C technique ARIA22) |
role="alert" |
Assertive – interrupts | Errors and warnings that need attention now (ARIA19) |
role="log" |
Polite, new entries added in order | Chat messages, activity feeds (ARIA23) |
aria-live="polite" / "assertive" |
As above, on any container | Custom widgets without a fitting role |
W3C also lists a failure: using role="alert" or aria-live="assertive" on content that is neither important nor time-sensitive. Constant interruptions make a page tiring to use.
Examples
<!-- Good: the region exists from the start, text is added later -->
<p role="status" id="cart-status"></p>
<script>
document.getElementById('cart-status').textContent = '3 items in your cart';
</script>
<!-- Good: an error that needs attention -->
<p role="alert">Payment failed. Please check your card number.</p>
<!-- Bad: visual-only update, never announced -->
<span class="badge">3</span>Put the live region into the page when it loads and change only its text. Keep messages short ("Saved"), use role="status" for most updates and keep role="alert" for real errors. Give icon-only counters a text the screen reader can say.
Insert the whole live region together with its message – many screen readers miss it. Don't mark large areas such as a full product list as live, don't use assertive for routine updates, and don't rely on a color change or a badge alone.
How to check ARIA live regions
Questions
What is the difference between aria-live polite and assertive?
Polite waits until the screen reader has finished what it is saying, then reads the update. Assertive interrupts immediately. Use polite for almost everything and assertive only for urgent errors or warnings.
Is role="status" the same as aria-live="polite"?
Almost. role="status" gives the region an implicit aria-live value of polite and an aria-atomic value of true, so the whole message is read. It also tells assistive technology that the content is advisory status information.
Why does my screen reader not announce the live region?
Most often the region was added to the page together with its text. Browsers only report changes to regions that already exist. Add an empty container on page load and fill it later. Hidden containers with display: none are not announced either.
Do form error messages need a live region?
Errors shown without moving focus are status messages under WCAG 4.1.3, so they need role="alert" or a live region. If you move focus to an error summary instead, the focus change already makes the screen reader read it. Link each message to its field as well, as described for form labels.
Related terms
ARIA: Roles, States and Properties Explained
ARIA (WAI-ARIA, Accessible Rich Internet Applications) is a W3C specification of HTML attributes – roles, states and properties – that tell assistive technology what a custom element is, what it is called and what state it is in.
Read definition: ARIA: Roles, States and Properties ExplainedScreen Reader: How It Reads Websites and What It Needs
A screen reader is assistive software that reads the content and controls of a screen aloud or outputs them on a braille display. It relies on the names, roles and states that a website exposes through the browser's accessibility tree.
Read definition: Screen Reader: How It Reads Websites and What It NeedsAccessible Name: What It Is and How It Is Computed
The accessible name is the text that browsers pass to assistive technology to identify an element – for example the words a screen reader announces for a button, link or form field. WCAG 4.1.2 requires a programmatically determinable name for every user interface component.
Read definition: Accessible Name: What It Is and How It Is Computedaria-label: How to Name Elements Correctly
aria-label is an ARIA attribute that sets the accessible name of an element as a text string. Screen readers announce this name instead of the element's content, so it is used mainly for controls without visible text, such as icon buttons.
Read definition: aria-label: How to Name Elements Correctly