WCAG 2.1 · Level AA · Robust
4.1.3 Status Messages
Manual verification
How to validate 4.1.3 by hand
Check whether status messages that appear without taking focus are programmatically exposed to assistive technology.
Start with the extension result
Reopen the reported URL and reproduce the same state (for example, after expanding a menu or submitting a form). Use the result’s Highlight action when available, or its affected-element details and CSS selector, to find the reported content. Apply the checks below to that content and its context. If the element or state has changed, rescan and record that difference before deciding whether the finding still applies.
- Trigger messages such as saved, results loaded, item count changed, or an error summary updated.
- Keep focus in its original location and listen with a screen reader or inspect live-region semantics.
- Check that the message and its purpose are announced without requiring the user to move focus to it.
Evidence to record
Record the trigger, focus location, status message, exposed role/live semantics, and whether it is announced once and at the right time.
Scope and exceptions
Not every content change is a status message. A dialog or required focus change is evaluated differently; do not move focus solely to force an announcement when the message should be exposed as status.
Record the review outcome
- Confirmed: the recorded evidence shows the requirement is not met in the tested page state, and no applicable exception explains it.
- Not reproduced: the reported issue is absent in the current state. Record the URL, state, and affected element you checked; this does not prove other pages or states conform.
- Needs more review: evidence is incomplete, the content requires human judgment, or an exception is uncertain. Record what remains to be checked instead of treating it as a pass.