4.1.3 Status Messages: what it requires and how to test it

What 4.1.3 requires

Status messages must be programmatically determinable through role or properties, so assistive technology can present them without moving focus. A status message is new information about the result of an action, the state of an app, progress, or an error, that appears without a change of context. In HTML that usually means a live region: role="status", role="alert", role="log" or aria-live. This is a plain-language summary. The normative text, including every exception, is in the W3C Recommendation, with the W3C's explanation in Understanding 4.1.3 (opens in a new tab) [1][2].

Exceptions and scope:

• Changes of context are out of scope. W3C's Understanding document says messages that come with a change of context, such as moving focus to a new page or dialog, already interrupt the user and aren't status messages.
• Applies to content implemented with markup languages, which covers ordinary web pages and apps.

Why it matters

Visual feedback is everywhere in modern interfaces: a toast after saving, a cart counter that ticks up, a results count after filtering, a spinner. A screen-reader user gets none of it unless the message is exposed. They press "Add to cart" and hear nothing, so they press it again. They filter a product list and have no idea whether anything changed. Our single-page-app guide calls this out as a failure that only exists while the app is being used.

Common failures

Toast with no live region

A confirmation slides in visually but is never announced.

<!-- Fails -->
<div class="toast">Added to cart</div>

<!-- Better -->
<div role="status" class="toast">Added to cart</div>

Results updated with no announcement

Filtering replaces the list silently.

<!-- Fails -->
<p class="count">24 results</p>

<!-- Better -->
<p role="status" class="count">24 results</p>

Live region added at the same time as its text

Many screen readers don't announce a region that's inserted already filled. Render the empty region first, then update its text.

/* Fails */
container.innerHTML = '<div role="status">Saved</div>';

/* Better */
// present in the page from the start: <div role="status" id="msg"></div>
document.getElementById('msg').textContent = 'Saved';

Errors summarised without being announced

A form-level error banner appears but focus stays on the submit button and nothing is spoken.

<!-- Fails -->
<div class="banner">3 fields need attention</div>

<!-- Better -->
<div role="alert">3 fields need attention</div>
<!-- or move focus to the summary: then it is a change of focus, not a status message -->

Can automated testing check 4.1.3?

No. axe-core maps no rules to 4.1.3. Whether a message is announced depends on how and when it was inserted, which only shows up while someone uses the page.

What automation can't decide: Which pieces of text are status messages, whether they're exposed through a live region or role, and whether they are actually announced when they appear. (axe-core does validate ARIA roles and attributes on live regions under 4.1.2, but that doesn't prove an announcement happens.)

A clean automated result is never proof that 4.1.3 is met. See why sites pass axe-core but fail real screen reader users.

How to test it by hand

1. List every action on the page that produces feedback without moving focus: add to cart, save, filter, search, upload, copy, form submit with errors.
2. Turn on a screen reader, perform each action from the keyboard, and listen. Is the message announced, once, in full?
3. Check timing: is the message announced after the change, not before or never? Loading states should say when loading is finished.
4. Inspect the message's container. Does it have role="status", role="alert", role="log" or aria-live, and was it already in the page before the text changed?
5. Use alert only for urgent messages. Most confirmations should be polite (status).

New to screen readers? Start with how to test a website with a screen reader and how to test keyboard-only navigation.

How Accessible helps (and where it stops)

Status messages are a journey's job. Journeys check, after every click or keystroke, whether a status message was spoken, so "added to cart" that's never announced, or results replaced with no status message, are reported at the step where they happened, filed against 4.1.3 (journey testing). Our ARIA live region testing guide covers the manual side.

Where it stops: Journeys simulate a screen-reader user in Chromium. Live-region support differs between screen readers and browsers, so test important messages with NVDA, JAWS and VoiceOver too. No automated tool, ours included, can certify that a criterion is met.

Related criteria

• 4.1.2 Name, Role, Value
• 3.3.1 Error Identification
• 2.4.3 Focus Order
• WCAG 2.2 success criteria checklist

Sources

1. Understanding Success Criterion 4.1.3: Status Messages (opens in a new tab). W3C Web Accessibility Initiative. Accessed October 18, 2026.
2. Web Content Accessibility Guidelines (WCAG) 2.2, Success Criterion 4.1.3 (opens in a new tab). W3C Recommendation. Accessed October 18, 2026.
3. axe-core rule descriptions (opens in a new tab). Deque Systems, axe-core 4.13.0. Accessed October 18, 2026.
4. WAI-ARIA 1.2: status role (opens in a new tab). W3C Recommendation. Accessed October 18, 2026.

Meeting a success criterion is not the same as legal compliance, which depends on the rules that apply to you. No automated tool can certify conformance.