The direct answer
Give ordinary background task status its own trusted, coherent notification plan while preserving the user’s current focus. Establish the supported live region before updates, select appropriate polite and whole-summary behavior, and separate meaningful current-task status changes from streamed draft tokens. Actual browser and assistive-technology evidence is required; a declaration alone is insufficient.
A visible completion label can miss the person waiting
A fictional console prepares an ordinary text draft in the background while the user continues editing another field. A small label changes from waiting to ready. A sighted user may notice it, but moving keyboard focus to that label would interrupt the current task. Making every streamed token an announcement would create a different kind of interruption.
This original worksheet selects one nonurgent draft-status summary in an existing console view. It excludes alerts, modal dialogs, chat-log narration, progress bars and business effects. The draft remains separately inspectable under the existing rendering policy. Every teaching card is PROPOSED_UNRUN; no browser or assistive technology was exercised.
Classify the status before choosing its presentation
The W3C Understanding document for SC 4.1.3 describes status messages as information about results, waiting, progress or errors without a change of context. Its goal is programmatic presentation without giving the message focus. The returned draft itself is not equivalent to its brief completion summary.
The page also warns about excessive announcements and explains why an isolated changed number can lose its context. Removing a busy indicator can communicate something visually that another user misses. This is informative WCAG 2.2 guidance, updated 11 May 2026, not a conformance certificate for this console.
Our proposed channel carries a small trusted account of the current draft’s phase, not its generated prose. “Draft A is ready for review” describes a different event from the next word appearing in that draft. The choice to keep token updates outside this status channel is application policy, not a claim that all streaming interfaces must be silent.
Choose a coherent region plan and keep focus where it belongs
MDN’s live-region guide, modified 11 September 2026, describes polite updates as waiting for an idle opportunity, while assertive updates can interrupt. It advises establishing the region before changing its content and notes that browser and assistive-technology behavior varies. Its status-role table describes an updated status area; aria-atomic controls whether the complete region is presented.
For this ordinary summary, select an application-owned status region with explicit polite behavior and explicit whole-summary atomicity. Keep its contents short enough to give the task and phase together. Those choices form this proposed profile; they are not tested declarations or a universal guarantee that an announcement will be heard.
The region must already be independently established through the actual supported rendering path before the status update. This worksheet supplies no DOM construction, timeout recipe or claim that adding an attribute alongside a message reliably registers it. Nor does it move focus, open a dialog or silently upgrade an ordinary draft notice into an urgent alert.
Only trusted application code may choose the region, semantics and status template. Model output cannot supply markup, an assertive priority or a command disguised as notification content. Preserve the current user’s ability to continue the activity that already has focus.
Bind the summary to the current attempt
Invent draft attempt D-A in view V-A and application status revision S-2. These are paper references, not browser objects or a real request. The controller needs independently supported evidence for the phase it announces. It must not infer ready merely because generation stopped or an old callback arrived.
| Association | Decision supported |
|---|---|
| Attempt and active view | Which current task may this summary describe? |
| Authoritative phase and revision | What actual application evidence permits waiting, incomplete or ready? |
| Coherent visible summary | Does the text include useful task and outcome context? |
| Selected region and update path | Are preestablishment, semantics and complete-summary changes supported? |
| Repeated and stale updates | Which application notifications are suppressed or routed to separate history? |
| Supported environment | What browser, assistive technology and user-facing results were actually inspected? |
Under this original policy, an unchanged status revision does not create another application notification. A late D-A result cannot be relabeled as a new D-B result after the view changes. These controller rules establish no speech-queue deduplication or recall of an announcement already presented.
When waiting ends, provide a supported explicit next-state summary rather than relying solely on the disappearance of a spinner. If the outcome remains unknown, preserve that uncertainty in the text. The stream-completion contract still owns whether a draft is actually complete.
Review eight independent status cards
| Condition | Proposed disposition |
|---|---|
| Current D-A changes from waiting to supported ready, with all actual prerequisites established | Update one coherent summary under the declared region plan; preserve current focus |
| Only another generated token arrives | Update the separate preview policy, not this status channel |
| D-A finishes after another attempt or view becomes current | Keep the original association; no current-task substitution |
| Output is partial or the outcome is unknown | Announce only the supported incomplete or unresolved status |
| The same unchanged revision arrives again | No duplicate application notification under this policy |
| The interaction needs a modal, urgent warning or focus transition | Outside this ordinary nonfocus profile; require its own interaction plan |
| Attributes exist but effective region or browser/AT behavior is unknown | Block the real positive and conformance claim |
| A ready summary is presented but content or action rights are absent | Withhold disclosure or action independently |
Keep delivery evidence and authority separate
The useful positive is a user learning that the current permitted draft is ready while continuing their existing activity. Actual attempt/view coordination, truthful phase evidence, content permissions, safe rendering, region registration, update ordering, supported browser/assistive-technology behavior and user-facing usability are unknown and unimplemented here. Any missing prerequisite blocks that positive.
A future review needs actual supported environments and users’ interaction evidence, not just a screenshot or a declaration in markup. No exact announcement latency, uninterrupted speech, universal compatibility, understanding or consent is established. Notification is neither approval nor an application-effect result.
No DOM, ARIA attribute, event, keyboard action, focus transition, screen reader, speech, browser, task, API/model or runtime fixture was constructed or executed. Boundary is prelaunch and does not ship this accessible-status controller. Its synthetic policy, export and approval-status checks establish different behavior.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.