Announcing the stream, not the tokens

The review gate now streams. When the extractor finishes a document it writes a plain-language summary into the panel above the fields, a handful of tokens at a time, over about eight seconds. Sighted reviewers like it: they start reading before it finishes. Somebody wrapped the panel in role="status" so screen reader users would get it too, and that change is in production right now.

It made the panel worse than silence. This lesson is about why, what the published guidance actually says, and — the part that matters most for the job you are aiming at — how little of it there is.

role="status" is atomic, and atomic is the bug

MDN states the two defaults plainly. Elements with the status role “have an implicit aria-live value of polite” and “an implicit aria-atomic value of true”.

The first default is the one people know about and it is fine. The second is the one nobody checks and it is fatal here. Atomic means present the whole region, every time. Not the delta — the region. So on a token stream, the region is re-presented once per token, and each re-presentation is longer than the last. Eight seconds of streaming does not produce one announcement of a summary. It produces an announcement of the first word, then of the first two words, then of the first three, each one racing the one before it, none of them ever finishing.

Reach for a bare aria-live="polite" instead and the defaults change but the problem does not go away. MDN’s live regions guide gives aria-atomic a default of false and aria-relevant a default of "additions text", so you now get the added text rather than the accumulated text. That trades one failure for another. Instead of one unfinishable sentence you get a queue of fragments, each announced without the grammar around it, and a screen reader announcing token fragments in isolation is producing noise, not content.

The one W3C sentence that speaks to this

4.1.3 Status Messages, Level AA is the criterion the streaming panel lives under. Its Understanding document defines a status message as one that conveys “the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors”, which covers a generation-in-progress state and its result cleanly.

And then it says the thing you will end up quoting for the rest of your career:

there is a risk of making an application too ‘chatty’ for a screen reader user. User testing should be carried out to ensure the appropriate level of feedback is achieved.

That is from the 4.1.3 Understanding document, it is informative rather than normative, and it is the closest thing in the whole W3C corpus to guidance on this problem. Read it carefully: it identifies the risk and then hands the resolution to user testing. It does not tell you what to build.

The other half of the mechanism is aria-busy. MDN describes it as an attribute added to an element currently being updated “to inform the assistive technology that it should wait until the modifications or changes are complete before exposing the content to the user”. That is a description of an attribute. MDN is not endorsing a streaming pattern, and neither is anybody else.

The shelf is empty, and saying so is the finding

The W3C’s Accessible Platform Architectures Working Group has live work on exactly this subject area: Accessibility of machine learning and generative AI, an Editor’s Draft dated 28 March 2026. It was fetched and read end to end on 5 September 2026, and no newer draft was published in the interval.

It addresses generated alt text, captioning, plain-language conversion, and using machine learning in accessibility testing. It contains nothing on announcing streaming or incrementally generated text, nothing on chat interfaces, and nothing on live regions. Not a weak treatment. Not a stub. The subject is absent.

Two things follow, and they pull in opposite directions, so hold both. The first is that anyone who tells you the W3C has an answer here has not opened the document. The second is that an editor’s draft is a moving target: this is a fact about 5 September 2026, not a permanent property of the field. Re-check the draft before you repeat the claim, and put the date on it when you do.

The pattern — and it is this course’s, not the W3C’s

What follows is this course’s own position, assembled from 4.1.3, aria-busy and the chattiness warning. No source states it. Present it that way when you take it to a team, and the argument you get back will be about the design rather than about whether you made it up.

1. The streamed text is not a live region. Render it as ordinary content in the document. A screen reader user can read it at any point with the virtual cursor, at their own pace, in whatever order they like — which is strictly more control than any announcement gives them.
2. Mark the container aria-busy="true" while it generates, and flip it to false exactly once, on completion. That is the attribute doing the job MDN describes.
3. Announce transitions, not tokens. One separate, polite status region, present at parse time, carrying at most three messages across the whole run: that generation started, that it finished, and where the result is. A count is more useful than an adjective — “Summary complete, four fields flagged” beats “Summary complete.”
4. Never announce the body of the stream. Not on completion either. If the summary is worth reading it is long enough that forcing it through an uninterruptible announcement is a punishment, and the user can already read it under point one.

The honest weakness of this pattern is that it has not been tested against real screen reader users, and 4.1.3’s own guidance is that user testing is how you settle the appropriate level of feedback. Write that limitation into the note rather than leaving it for somebody to discover.

What this does not cover

This lesson is about output: text arriving, and how to say so without saying it four hundred times. It says nothing about how a keyboard user stops the thing producing it, which is a different criterion at a different level and a harder obligation than most teams realise. The keyboard-only-through-a-long-run lesson takes 2.2.2 Pause, Stop, Hide apart and argues that a cancel control on a four-minute run is a Level A requirement rather than a nicety.

It also says nothing about the case where the agent needs an answer rather than an audience. Announcing an interrupt is a harder problem than announcing a result, because the tempting fix — move focus to the question — is a change of context by WCAG’s own definition. That is the interrupting-without-hijacking lesson, and it turns on the sentence in MDN’s status role page that this lesson deliberately left on the table.