Requires that status messages, such as results counts, confirmations and errors, are announced by assistive technology without moving focus.
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.
role="status", so that assistive technology can announce it without taking focus.role="status" (ARIA22), together with success feedback (G199).role="alert" or a live region (ARIA19), with a text description of the error and suggestions.role="log" for sequential updates (ARIA23).role="alert" or aria-live="assertive" for content that is not important and time-sensitive is a failure.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.
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.
| Clause | Type of ICT | What it requires |
|---|---|---|
| 9.4.1.3 | Web pages | Web 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
Add role="status" to a container that is already in the page, and update its text.
<div id="count">12 results</div> <!-- text changes silently --><div id="count" role="status" aria-atomic="true">12 results</div>
<script>
count.textContent = results.length + " results";
</script>A confirmation after an action should be announced without moving focus.
toast.textContent = "Added to cart"; // not exposed<div role="status" id="toast"></div>
<script>
addBtn.addEventListener("click", () => {
toast.textContent = "Added to cart";
});
</script>For an important, time-sensitive error, use role="alert".
<div class="error">Card declined</div><div role="alert">Your card was declined. Check the number or try another card.</div>Announce upload progress through a polite live region, not on every percent.
<progress value="60" max="100"></progress> <!-- nothing announced --><progress value="60" max="100" aria-label="Upload"></progress>
<div role="status" id="up">Upload 60% complete</div>Use role="log" for sequential entries that are added over time.
<div id="chat">…</div> <!-- new messages are silent --><div id="chat" role="log" aria-label="Chat messages">…</div>role="alert" is assertive and interrupts the user. Use it only for important, time-sensitive content.
<div role="alert">Saved</div> <!-- not time-sensitive --><div role="status">Saved</div>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.
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()
}
}
}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 }
)
}status, alert or log, or a live region?alert used only for important and time-sensitive messages?role="alert" on everything: Constant interruptions.