--- title: "Status Messages" url: "https://barrierefreihochzwei.de/en/wcag/4-1-3-status-messages" language: "en" description: "WCAG 4.1.3 requires status messages like “Item added” to be announced without moving focus – learn how to use live regions correctly in your interfaces." published: "2025-01-01T08:00:00+01:00" updated: "2026-10-15T09:42:01+02:00" --- # Status Messages When updates need to learn to speak. - **Erfolgskriterium:** 4.1.3 - **Prinzip:** Robust - **Konformitätsstufe:** Level AA - **Erklärung beim W3C:** [www.w3.org/WAI/WCAG22/Understanding/stat...](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html) Success criterion 4.1.3 # 4.1.3 Status Messages Level AARobust When updates need to learn to speak. ## 1. What is the goal of this criterion? You know the drill: you fill in an online form, click “Send” – and suddenly “Submitted successfully!” appears at the top of the page. Or you search for a product and see “5 results found”. For sighted people, feedback like this is a given. But what about people who use a screen reader? The goal of WCAG Success Criterion 4.1.3 is clear: important status messages must also be perceivable for people using assistive technologies – without the message having to receive focus and interrupt what they’re doing. In short: when an application’s status changes, everyone should find out – not just those who can see it. ## 2. What exactly does it require? Specifically, it’s about status messages – content that informs people about results, waiting states, progress or errors without changing the context. **Status messages must be programmatically determinable** – through appropriate roles or properties, so screen readers can read them out automatically without focus jumping to them. **Two characteristics define a status message:** - The message informs about the success or result of an action, a waiting state, the progress of a process or the existence of errors - The message appears without changing the context (no new window, no focus change) **Typical examples of status messages:** - “5 search results found” - “Item added to basket” - “Form submitted successfully” - “Please enter a valid postcode”, when the message appears without a focus change - “Loading …” - “Upload 75% complete” **Not status messages:** - The search results themselves (only the number is a status message) - Dialogs or pop-ups that receive focus - Expandable menus or accordion sections - New content that appears through a change of context **Level AA:** this criterion is part of conformance level AA. It was added in WCAG 2.1. ## 3. Why does it matter for accessibility? Imagine sitting at your computer, only hearing what the screen reader reads out through your headphones. You search for a product, press Enter – and then? Silence. You don’t know whether the search is running, whether results were found or whether an error occurred. Status messages support accessibility because they: - give blind and visually impaired people the same information as sighted people - provide feedback on actions without interrupting current work - help people with cognitive disabilities understand an application’s current state - make it clear whether an action succeeded or failed - improve the workflow because it’s clear when you can carry on And last but not least: they build trust in the application because you always know what’s going on. ## 4. How to meet the criterion The good news: the technical side is usually simple – ARIA makes it possible. Here are the most proven tips: **For success and result messages:** - Use `role="status"` for polite, non-interrupting messages - Ideal for: confirmations, number of search results, basket updates - Example: `
Item added
` **For warnings and errors:** - Use `role="alert"` for important, time-sensitive messages - Ideal for: form errors, critical system messages - Example: `
Invalid email address
` **For progress and ongoing messages:** - Use `role="log"` for sequential entries such as chat histories or activity logs - `role="progressbar"` with `aria-valuenow` represents progress; to announce key milestones, add a message with `role="status"` - Ideal for: upload status, multi-step processes **More practical tips:** - The live region must already be in the document before its content changes – so insert the text into an existing element rather than creating the element and its role from scratch - Use `aria-atomic="true"` if the entire text should always be read out - `aria-live="polite"` or `aria-live="assertive"` are an alternative to the roles - Keep status messages short and to the point - Always test with real screen readers (NVDA, JAWS, VoiceOver) **What to avoid:** - Showing status messages visually only, without an appropriate role or property - Using `role="alert"` for unimportant messages – it makes applications “chatty” and keeps interrupting - Inserting live regions together with the message – many screen readers won’t pick that up Related criteria are [Name, Role, Value](https://barrierefreihochzwei.de/en/wcag/4-1-2-name-role-value) for the states of controls and [Error Identification](https://barrierefreihochzwei.de/en/wcag/3-3-1-error-identification) for error messages in forms. ## 5. Why this criterion matters for businesses With Success Criterion 4.1.3, too, accessibility isn’t an end in itself – it brings tangible benefits for your business. **1. Better experience for everyone** Good status messages make your application more usable for everyone. Sighted people benefit from clear, unambiguous feedback too – it reduces confusion and uncertainty. **2. Fewer drop-offs, happier customers** Clear feedback on whether actions succeeded or failed prevents abandonment. People who know where they stand and what to do next are more likely to complete processes successfully. **3. Fewer support requests** Clear status messages answer questions before they arise. “Did my order really go through?” “Is the upload still running?” – uncertainties like these lead to unnecessary support requests that good status messages prevent. And then there’s the legal side: since 28 June 2025, the European Accessibility Act (Directive (EU) 2019/882) has applied to many consumer-facing digital services, such as online shops and banking services. Germany implements it through the Barrierefreiheitsstärkungsgesetz (BFSG). The technical benchmark is the harmonised standard EN 301 549, which refers to WCAG 2.1 Level AA for web content – and 4.1.3 is part of that. Public sector bodies are covered separately by the Web Accessibility Directive (EU) 2016/2102. This section is general information, not legal advice. ## 6. The success criterion in the W3C’s words > **Success Criterion 4.1.3 Status Messages (Level AA)** > > In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus. In short: status messages are marked up via role or properties so assistive technologies can announce them without them receiving focus. **Official explanation from the W3C** The W3C explains every success criterion in depth – with intent, examples and techniques. [Understanding 4.1.3](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html) ## More criteria from “Robust” [ 4.1.1 Obsolete ### Parsing (Obsolete and removed) When a criterion goes into retirement. ](https://barrierefreihochzwei.de/en/wcag/4-1-1-parsing-obsolete) [ 4.1.2 Level A ### Name, Role, Value When your code talks to assistive technology. ](https://barrierefreihochzwei.de/en/wcag/4-1-2-name-role-value)