Updates that happen without navigation must be announced to AT

What it is

Sighted users notice a list swap, filter results, a cart badge, from a motion transient. A screen reader’s virtual cursor stays put: no full load, no focus move, so the update never happened for assistive technology. A live region, or moving focus onto the new content, is an active notify pipe. Without at least one, an update that did not navigate exists only in paint.

This is not a stale buffer. Even if the user arrows now, that is not the system having said “something just happened.” Notify is push; rebuild is pull.

Why it happens

Readers follow focus and the virtual cursor. Single-page routing, Ajax replacement, and in-place filtering do not emit a “new document” signal, so the cursor does not jump to the new block on its own. Vision has transients; speech has no equivalent of “the picture flickered.” The change therefore has to be encoded as an accessibility event: text changing inside a live region, or focus landing on a new heading. With neither, the user treats the old context as still valid and builds the next action on a stale premise.

The second layer is what deserves a push. Not every pixel change — that is grading and rate. The mechanism here only requires: if the update changes a fact the next step depends on (result count, submit success, which filter is in force), assistive technology must be brought to that fact, not left to stumble onto it.

Studying it

A task with no full reload: apply a filter, watch the list replace. One cell with no notify; one that moves focus to a results heading; one that only updates “N results found” in a live region. Complete the task with the screen covered. Record whether the user knows the list changed and whether they keep acting on old results. Run NVDA+Firefox and VoiceOver+Safari; reliability of live versus focus-move differs.

Independent variables: notify method (none / move focus / live), whether the update changes the next decision. Dependent variables: whether “an update happened” is reported, error actions, keystrokes until the update is found.

Where it stops holding

Echo from the user’s own input (typing, a slider’s live value) usually should not be pushed; focus is already on that control. Full-page navigation and opening a dialog already move focus; a live recap then double-speaks. Decorative motion and carousels carry no “fact for the next step”; announcing them is noise. On a slow network the announcement can arrive after the user has left the page, becoming a stale message that needs to be ignorable or timestamped.

Applying it

• For filters, route changes, and submit success that change the current view, either move focus to a new heading or push one-sentence summary into a status region — at least one of the two.
• The summary must state the fact (“12 results”), not only “updated.”
• Do not mark the whole result list live as a substitute for notify; notify is one sentence, the list is for the user to walk.
• How to check: cover the display and complete a filter. If the operator still talks about old results or asks whether anything changed, there was no notify. Also watch whether focus was yanked to the top — that is a different interrupt, not a success.

Related

• Same group: J5.12.2 Announcement urgency is graded; non-critical updates must not interrupt · J5.12.3 Transient loading and error feedback is skipped unless it enters a live region · J5.12.4 Too-frequent announcements become noise
• Nearby: J5.09 How screen readers work · J5.11 Correct use of ARIA
• Search terms: live region · status message · dynamic announcement