Status Messages
When a user clicks a button, presses Enter, or types in a field, a page often updates in place: a spinner appears, a toast slides in, a result count changes, a form shows "Saved!". Sighted users see these updates immediately. Screen reader users only hear them if the page is coded to announce them. When it is not announced, that is a WCAG 4.1.3 violation.
This check watches what changes on the page after an interaction and reports updates that happen silently.
The three kinds of update that get checked
| Area | Examples |
|---|---|
| Loading indicators | A spinner, a progress bar or a skeleton placeholder while something is pending — "Uploading…", "Fetching transactions…" |
| Search results | Result counts updating, "No results found", a pagination page change, facet filter counts, type-ahead suggestions |
| Action and form feedback | An "Item added to cart" toast, a "Password is weak" meter, form validation errors, success banners, like-count updates |
If a page produces one of these three kinds of update silently, the tool reports it. If the page announces it properly, the tool stays quiet.
How the tool decides whether something was announced
After each interaction, the tool records what changed on the page and then asks a single question: would a screen reader user have been told?
It counts an update as announced when any of these is true:
- The changed content sits in a live region — an area the page has marked as one that should be read out when it changes.
- Focus moved into the new or updated content, so the screen reader reads it as the user arrives.
- The control the user activated changed its expanded state, which screen readers announce.
- A progress bar updated its value, which is announced as it advances.
If none of those happened, the update was silent, and it is reported.
When it stays quiet
- The update was announced by any of the means above.
- The update was too brief to matter. A spinner that flashes for a couple of hundred milliseconds and disappears is ignored — announcing it would be noise, not help.
- Several similar things update at once. When four widgets refresh and three of them are silent, the tool reports one issue for the most prominent case rather than three near-identical ones.
Known limitations
Two areas are known to behave imperfectly today. If a case falls into one of them, it is expected behaviour, not a new bug.
Spinners inside carousels and galleries
Many sites show a small spinner every time the user clicks Next on an image carousel, or lazy-loads the next batch of gallery thumbnails. Those spinners are decorative — they do not represent a real task the user is waiting on — and they do not need to be announced.
Until this is addressed, the tool may flag them as violations. Expect false positives on:
- Carousels where Next briefly shows a loading indicator before the next slide renders.
- Photo galleries with lazy-loaded thumbnails.
Guessing where a status message appeared
The tool currently works out whether an update happened above, below, inside, or on top of the control the user clicked by looking at the structure of the page rather than at actual screen positions. That guess is right most of the time, but it fails on pages that place a toast far away in the page structure from where it visually appears.
Two kinds of page can therefore behave off-spec:
- A toast that overlays the screen but lives at the very end of the page structure. It may not be recognised as an overlay, so it can be filtered out when it should not be, or reported when it should not be.
- A cart badge sitting visually right next to the button that the current logic labels as below the trigger, which can cause it to be filtered out.
How to verify it by hand
Use a screen reader — NVDA with Firefox, or VoiceOver with Safari on macOS.
- Load the page and move focus to the control you want to test.
- Perform the action: click the button, submit the form, type in the field.
- Listen. Without looking at the screen, could you tell what happened?
If the page visibly changed and the screen reader said nothing, that is the violation this check is looking for.
WCAG reference
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."