An answer grows word by word. For sighted people, this looks like progress. If every fragment is read out immediately, the same output can lead to constant interruptions. The question is therefore not whether a change is technically visible, but what information a person needs at that moment.
In success criterion 4.1.3, WCAG 2.2 covers status messages, which should be programmatically determinable without a change of focus. The W3C explanation also mentions avoiding unnecessary interruptions. This does not imply a general obligation to announce every newly generated word individually. For an AI chat, separating the working state from the content of the answer is particularly helpful.
Three states instead of an endless announcement
Our own demonstration model has three understandable situations: request received, answer being generated, answer complete. They provide orientation about the process. The answer text itself answers the question of substance and should then remain readable at the person’s own pace.
While waiting, a person may go back to their own input field or read other parts of the page. The interface should not push this activity aside just because another chunk of text has arrived. A finished answer does not automatically have to take over the keyboard focus either.
The appropriate feedback depends on the state. A process that is still running is something different from an error that requires a new decision. If all messages are presented as equally urgent, exactly this priority disappears.
A small HTML pattern separates content and status
The following fragment is our own and contains no AI connection. It only shows two areas with different jobs. The answer area holds the text that can be read later. The short status line conveys the current state.
<section aria-labelledby="answer-title">
<h2 id="answer-title">Answer</h2>
<div id="answer"></div>
</section>
<p id="answer-status" role="status" aria-atomic="true"></p>The W3C technique ARIA22 describes role=status with a polite live region and an announcement of the complete status content. Our explicit aria-atomic makes this intention visible in the teaching fragment. It is no reason to put the entire, constantly growing answer text into the same short status message.
An actual implementation would update the status line at meaningful transitions, for example once at the start and once after full completion. How often a progress message in between really helps has to be tested with the specific flow and with assistive technology.
When checking by ear, also consider a person who is already reading somewhere else while the answer is being generated. Do they keep having to start their sentence again? Can they find the finished answer deliberately later on? These observations test how the pattern is used more precisely than merely establishing that an announcement is heard somewhere.
Cancellation and errors need their own words
If the output is interrupted, “done” must not simply mean that no more characters are arriving. A text that was deliberately stopped may be incomplete. A technical error can mean that no usable result was produced at all. These differences belong in the language of the interface.
For a first check, you can use three fixed sample texts and trigger the transitions by hand. Observe what is announced while you keep reading, whether the focus stays where it is and how you get to the finished text. This is an exercise you can carry out, but it is not presented here as a passed screen reader test.
If you prepare your own HTML and JavaScript in a KENJTEC page, the developer mode of KENJTEC WebSiteBuilder ai is available for this, with a sandboxed preview and publishing of your own code. You transfer the component yourself; this does not create an additional, integrated AI chat service.
The actual listening experience decides
A screenshot can prove neither an interruption nor an unexpected announcement. Testing therefore needs a keyboard and real assistive technology. Record the device, browser and screen reader used if you later report on a specific result.
Even a good status pattern does not automatically meet every requirement for an accessible chat. It answers a limited question: how does the working state become understandable without pressing the content on someone word by word? A good solution preserves both: reliable orientation and the person’s control over their own reading pace.
Sources and status
Research and documentation as of 25 October 2026. Understanding SC 4.1.3: Status Messages · ARIA22: Using role=status to present status messages.
