WCAG 2.2 - Success Criterion
4.1.3 Status Messages
Description
In content implemented using markup languages, status messages must be programmatically determinable through role or properties so that they can be presented to the user by assistive technologies without receiving focus. A status message is any update that informs the user of the success or result of an action, a waiting state, the progress of a process, or the existence of errors - where that message does not take focus. Examples include "Your form has been submitted successfully", "3 items added to cart", "Loading, please wait…", or "5 search results found." These messages must reach screen reader users even though keyboard focus remains elsewhere on the page.
How To Test
- Identify all actions on the page that produce status messages without moving keyboard focus: form submissions, cart additions, search result counts, loading indicators, and process progress updates.
- Trigger each action and observe whether a status message appears visually.
- Inspect the DOM to confirm the message container has an appropriate role:
role="status",role="alert",aria-live="polite", oraria-live="assertive". - Verify the container element was present in the DOM before the message was injected (not inserted into the DOM at the same time as the message).
- Test with a screen reader (e.g., NVDA + Firefox): trigger the action and confirm the status message is announced without focus being moved to it.
- Check that
role="alert"is used sparingly and only for truly urgent messages, not for routine status updates, to avoid over-interrupting the user. - Confirm that error summaries that do receive focus (e.g., after form submission) do not also need a live region, as they rely on focus management instead.
Testing Tools
- NVDA — Free screen reader for Windows. Download, install, and open Firefox to test the demo. Navigate using Tab and arrow keys, and listen to role, name, and state announcements from the page.
- VoiceOver (macOS) — Built into macOS. Enable with Cmd+F5, then open Safari or Chrome to test the demo. Use VO+arrow keys to navigate and hear semantic structure announcements.
- Lighthouse — Browser accessibility audit in Chrome DevTools. Open DevTools (F12), go to Lighthouse, run the audit to identify semantic and labeling issues.
Demo 1: Shopping Cart Update
Click Add to cart. The cart count updates visually but has no role="status" or live region - screen reader users receive no announcement.
Screen readers will not announce the cart update. No role or aria-live on the count.
Click Add to cart. The cart count is in a role="status" container - screen readers announce the change politely without moving focus.
role="status" (equivalent to aria-live="polite") announces the update automatically.
Code
Demo 2: Form Validation Error Announcement
Type an invalid email and click Validate. The error message appears visually but has no live region — screen readers stay silent.
No role="alert" or aria-live — screen readers do not announce the error.
Type an invalid email and click Validate. The error message uses role="alert" — screen readers immediately announce the validation error.
role="alert" (equivalent to aria-live="assertive") announces the error immediately.
Code
Demo 3: Search Results Count
Type a query and click Search. Results appear visually but the count has no live region — screen reader users don't know results loaded. This was found in 8 real-world audits.
No role="status" — screen readers do not announce when results appear.
Type a query and click Search. The results count is in a role="status" container — screen readers announce "5 results found" automatically.
role="status" announces the results count without moving focus.
Code
Demo 4: Success Toast Notification
Click Delete Item. A success toast appears visually but has no live region — screen reader users get no feedback that the action succeeded. Found in 6 real-world audits (delete confirmations, clipboard copies, feedback submissions).
No live region on the toast — screen readers stay silent.
Click Delete Item. The success toast uses role="status" — screen readers announce "Item deleted successfully" without moving focus.
role="status" announces the toast content. Text is injected dynamically into a pre-existing container.
Code
Fail Explanation
A dynamic success message that appears visually on screen after a form submission but is injected into the DOM without an appropriate ARIA live region role will not be announced by screen readers, because the user's focus has not moved to the message. Screen reader users will complete an action - such as adding an item to their cart or submitting a search query - and receive no feedback that the action succeeded or produced results. This is a significant usability barrier for blind users who depend entirely on audio output to understand the result of their interactions.
Pass Explanation
Status messages pass when they are inserted into a container element that carries an appropriate ARIA live region role or property. For success and completion messages, role="status" (which maps to aria-live="polite") is appropriate; for urgent alerts, role="alert" (which maps to aria-live="assertive") can be used when the message requires immediate attention. The container element should ideally be present in the DOM on page load (even if empty), and the message text should be injected into it dynamically so that assistive technologies can detect and announce the change.
Notes
This criterion applies to status messages that do not receive focus; messages that are displayed in a dialog or by moving focus to the notification do not need a live region, as the focus management itself informs the screen reader. The pre-existing container pattern is important because some browsers do not announce live region content if the element itself is inserted dynamically into the DOM.
Techniques
WCAG techniques used in this demo: ARIA22, ARIA23, ARIA19
Suggested Solutions & References
Curated from 38 real-world audit findings and official WCAG guidance.
Official W3C / WAI
- Understanding SC 4.1.3: Status Messages
- Technique ARIA22: Using role="status" for status messages
- Technique ARIA19: Using role="alert" for error identification
- Technique ARIA23: Using role="log"
- WAI Tutorial: Form Notifications