WCAG 4.1.3 · Level AA · EN 301 549 9.4.1.3

Status Messages

Requires that status messages, such as results counts, confirmations and errors, are announced by assistive technology without moving focus.

In brief

A page says "3 results found", "Added to cart" or "Upload 60% complete". Sighted users see it. A screen reader user hears nothing, because focus did not move, and cannot tell whether the action worked.

This criterion requires that, in content implemented using markup languages, status messages can be programmatically determined through role or properties so that they can be presented to the user by assistive technologies without receiving focus.

What does it cover?

  • What is a status message: A change in content that is not a change of context, giving information about the success or results of an action, a waiting state, the progress of a process, or the existence of errors.
  • No focus needed: The message is exposed through a role or a property, such as role="status", so that assistive technology can announce it without taking focus.
  • Success and results: Use role="status" (ARIA22), together with success feedback (G199).
  • Errors and warnings: Use role="alert" or a live region (ARIA19), with a text description of the error and suggestions.
  • Progress: Use a live region for a progress bar (ARIA25), or role="log" for sequential updates (ARIA23).
  • Not a change of context: If a message moves focus, opens a dialog or loads a new page, assistive technology already announces it, so it is outside this criterion.
  • Do not over-announce: Using role="alert" or aria-live="assertive" for content that is not important and time-sensitive is a failure.
  • Out of scope: Identifying input errors in forms is 3.3.1. Changes of context are 3.2.1 and 3.2.2.

Who does it affect?

Screen reader users, who would otherwise miss new important text without losing their place. People with low vision who use screen readers and do not see peripheral text. People with cognitive disabilities, for whom marked-up messages allow assistive technology to delay, suppress or highlight them. Sighted users who notice the message get the same information in another form.

In the EAA and EN 301 549

The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Status messages that assistive technology can present are part of "robust".

The technical counterpart is the standard EN 301 549, which incorporates WCAG 4.1.3 by reference and turns it into separate clauses for each kind of ICT.

Where WCAG 4.1.3 appears in EN 301 549
ClauseType of ICTWhat it requires
9.4.1.3Web pagesWeb content must satisfy WCAG success criterion 4.1.3.

The criterion text applies to content implemented using markup languages. Check how EN 301 549 V4.1.1 treats documents and software. Whether and how the criterion applies to non-web documents is stated in clause 10 of the standard. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.

Standard version: EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2 and is the first version prepared specifically for the EAA. It has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. The text of criterion 4.1.3 is the same in WCAG 2.1 and 2.2. It is a Level AA criterion.

A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.

Directive (EU) 2019/882, EUR-Lex, opens in a new tab

Code examples for the web

1. A search result count (ARIA22)

Add role="status" to a container that is already in the page, and update its text.

Incorrect
<div id="count">12 results</div> <!-- text changes silently -->
Correct
<div id="count" role="status" aria-atomic="true">12 results</div>
<script>
count.textContent = results.length + " results";
</script>

2. Success feedback (G199)

A confirmation after an action should be announced without moving focus.

Incorrect
toast.textContent = "Added to cart"; // not exposed
Correct
<div role="status" id="toast"></div>
<script>
addBtn.addEventListener("click", () => {
  toast.textContent = "Added to cart";
});
</script>

3. An error alert (ARIA19)

For an important, time-sensitive error, use role="alert".

Incorrect
<div class="error">Card declined</div>
Correct
<div role="alert">Your card was declined. Check the number or try another card.</div>

4. A progress update (ARIA25)

Announce upload progress through a polite live region, not on every percent.

Incorrect
<progress value="60" max="100"></progress> <!-- nothing announced -->
Correct
<progress value="60" max="100" aria-label="Upload"></progress>
<div role="status" id="up">Upload 60% complete</div>

5. A chat or event log (ARIA23)

Use role="log" for sequential entries that are added over time.

Incorrect
<div id="chat">…</div> <!-- new messages are silent -->
Correct
<div id="chat" role="log" aria-label="Chat messages">…</div>

6. Do not use alert for everything

role="alert" is assertive and interrupts the user. Use it only for important, time-sensitive content.

Incorrect
<div role="alert">Saved</div> <!-- not time-sensitive -->
Correct
<div role="status">Saved</div>

Code examples for mobile

This criterion is written for markup languages, but the idea applies to apps. On iOS and Android, post an announcement or mark a region as live so screen readers speak the update.

iOS (SwiftUI)

import SwiftUI

struct CartButton: View {
    @State private var count = 0

    var body: some View {
        Button("Add to cart") {
            count += 1
            // Announced by VoiceOver without moving focus
            AccessibilityNotification.Announcement("Added to cart. \(count) items").post()
        }
    }
}

Android (Jetpack Compose)

import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.semantics.LiveRegionMode
import androidx.compose.ui.semantics.liveRegion
import androidx.compose.ui.semantics.semantics

@Composable
fun ResultCount(count: Int) {
    // TalkBack announces changes to a live region without moving focus
    Text(
        text = "$count results",
        modifier = Modifier.semantics { liveRegion = LiveRegionMode.Polite }
    )
}

How to test

  • List the status messages: Find results counts, confirmations, warnings, progress indicators, chat updates and other messages that appear without moving focus.
  • Check the markup: Does each message sit in an element with an appropriate role, such as status, alert or log, or a live region?
  • Use a screen reader: Trigger each message. Is it announced without focus moving?
  • Check timing: Is the container in the page before the text is added? Is the message announced once, not repeated?
  • Check the level: Is alert used only for important and time-sensitive messages?
  • Check what is not a status message: If focus moves or a dialog opens, the criterion does not apply.
  • Use a checker as a starting point: Automated tools cannot see messages that appear after an action. A person must use the interface and listen.

Common mistakes

  • Silent updates: Messages that appear with no role or live region (F103).
  • Moving focus to every message: Interrupts the user.
  • role="alert" on everything: Constant interruptions.
  • A live region created at the same time as its text: The text is often not announced.
  • A message that disappears too fast: Before users can read or hear it.
  • Repeating the same announcement: The message is read again and again.
  • Progress announced on every step: It floods the user with messages.
  • Only visual cues: A spinner or a colour change with no text.

Sources

Standard version: EN 301 549 V4.1.1 (2026-09), WCAG 2.2. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official texts of the European Accessibility Act (Directive (EU) 2019/882) and EN 301 549.

Corpowid is recognized by Gartner

Corpowid has been recognized by Gartner, a leading global research and advisory firm, for our innovation and performance in digital accessibility. These badges reflect our commitment to creating inclusive, AI-powered web experiences.

Have questions about Corpowid?

Let’s connect.

We will get back to you as soon as possible.