WebsightWhat it asks for, in plain English
When the page tells the person something happened without moving them there ('3 items in your basket', 'Saved', 'Showing 12 results', 'Loading'), that message has to be exposed to assistive technology so a screen reader can read it out, without the person having to go looking for it.
The mechanism is a live region: an element with role="status", role="alert" or an aria-live attribute. The region needs to exist in the page before the message is added, and the message goes inside it. The screen reader then announces the new text while the person carries on where they are.
It applies only to messages that do not receive focus. If you open a dialog or move focus to an error summary, that is a change of context and this criterion does not apply; the focus move does the work.
This is an independent explanation. The binding wording is the W3C Recommendation, and the W3C's own Understanding 4.1.3 page has the full intent, techniques and definitions.
Who it affects
A screen reader user clicks Add to basket, hears nothing, clicks again, and ends up with two.
Someone using screen magnification is looking at the button they just pressed and never sees the Saved message that appeared in the corner.
A blind user filtering a list of results types in the filter and has no idea whether anything changed until they move through the whole page.
Example
The count updates in a plain div. Focus stays on the search box, so a screen reader says nothing; the person has to go hunting for the result.
Looks identical. With role="status", the new text is announced when it changes: '3 results for fern'.
Show the markup behind both examples
<style>body{margin:0;padding:16px;font-family:system-ui;font-size:14px}label{font-weight:600;margin-right:6px}input{font:inherit;padding:6px 8px;border:1px solid #9ca3af;border-radius:4px;width:160px}button{font:inherit;padding:6px 12px;margin-left:6px}.count{margin-top:12px;color:#374151}</style>
<form>
<label for="q">Search plants</label>
<input id="q" value="fern">
<button type="button">Search</button>
</form>
<div class="count">3 results for fern</div><style>body{margin:0;padding:16px;font-family:system-ui;font-size:14px}label{font-weight:600;margin-right:6px}input{font:inherit;padding:6px 8px;border:1px solid #9ca3af;border-radius:4px;width:160px}button{font:inherit;padding:6px 12px;margin-left:6px}.count{margin-top:12px;color:#374151}</style>
<form>
<label for="q">Search plants</label>
<input id="q" value="fern">
<button type="button">Search</button>
</form>
<div class="count" role="status">3 results for fern</div>How to check it
- Find the places where the page updates in place: search result counts, basket counts, Saved and Copied messages, loading spinners, form progress.
- With a screen reader running, trigger each one without moving focus. The new message should be read out.
- Inspect the container. It should have role="status" (or role="alert" for urgent errors, or aria-live), and it should be in the page before the message is added.
- Check the message is short and meaningful; '3 results' beats a whole table being read again.
What Websight checks for 4.1.3
Websight has no automated check for this criterion. It lists it in the manual checklist that comes with every report, so it is not forgotten.
A scanner cannot trigger the updates, so it cannot tell whether a message was announced. Websight flags invalid role and aria-live values where it finds them, but whether the right messages land in a live region needs a person. It is in the manual checklist.
Practical tips
- Put one empty role="status" element in the layout at page load and write messages into it.
- Use role="alert" only for things that need to interrupt; everything else should be polite.
- Do not announce every keystroke; announce the result once typing pauses.
Other criteria in guideline 4.1, Compatible
- 4.1.1 Parsing (level A)
- 4.1.2 Name, Role, Value (level A)