An AI interface can look calm while being exhausting to use with assistive technology. A response that arrives one fragment at a time may create constant announcements. A panel that automatically follows new text may interrupt reading. A newly generated answer may appear without any useful indication that the process finished.
Accessibility is not solved by adding a live region to the entire interface. Designers and developers need to decide what should be announced, when focus should move and how a person remains in control as content changes.
Separate the answer from its status
Consider an illustrative document assistant. It has an input, a Generate button, a changing answer and a status message. The answer is content someone may want to read at their own pace. “Generating” and “Draft ready” describe the process.
W3C's Understanding Status Messages explains WCAG 2.2 success criterion 4.1.3: qualifying status messages should be programmatically determinable so assistive technologies can present them without receiving focus. The guidance does not require every new piece of content to become an announcement, and it explicitly warns against overly chatty interfaces.
That distinction matters for streaming. Do not assume every token belongs in an assertive live region. A separate, concise status channel can communicate progress while the answer remains available for deliberate navigation. The exact announcement strategy should be tested with actual browser and assistive-technology combinations.
Preserve focus unless there is a reason to change it
After someone starts generation, keeping focus on the initiating control may let them continue navigating predictably. Automatically moving focus to each new answer can interrupt their work. On the other hand, a modal dialog requires its own managed focus behaviour; it is not the same case as an inline status update.
Agree on focus rules for completion, cancellation, error and dismissal. If an action removes the focused control, choose a sensible destination. If a new result includes an optional “Read draft” control, make its purpose clear rather than forcing the person into the content.
Designers can annotate these rules alongside visual states. Developers can verify them in the actual DOM and keyboard sequence. A static frame cannot demonstrate whether focus survives an asynchronous update.
Make stopping and reading independent
A visible Stop control should be keyboard reachable and have an unambiguous accessible name. Explain whether stopping preserves a partial answer or discards it. Do not imply that stopping generation cancels an external action that has already happened.
Auto-scroll needs similar care. If a person scrolls back to inspect earlier content, avoid dragging them to the latest text. A clearly labelled way to return to the latest content is preferable to silently taking over the reading position.
These are recommended interaction decisions, not a claim that one implementation guarantees WCAG conformance. Different products and assistive technologies need testing. Accessibility review should cover the whole workflow, including source inspection, editing and error recovery.
Test with awkward but realistic content
Use long answers, lists, tables, links, code and interrupted responses. Check headings and reading order after the content renders. Generated formatting can produce a page that looks structured but has confusing semantics or inaccessible controls.
Test keyboard-only operation, zoom and reflow, visible focus, reduced motion where relevant, and screen-reader announcements. Automated checks are useful for some detectable issues; they do not establish that the timing and reading experience are usable.
AI can propose alternative labels and help enumerate states. It cannot replace testing with people or validate an accessible experience from a screenshot alone.
Accessibility checklist for an AI response
- Separate process announcements from the generated content.
- Avoid announcing every streamed fragment by default.
- Document focus behaviour for each transition.
- Keep Stop, retry and source controls keyboard usable.
- Let people read earlier content without forced scrolling.
- Test interrupted output, long content and generated structure.
- Combine automated checks with manual and user testing.
The goal is not merely to expose everything to assistive technology. It is to provide equivalent information without unnecessary interruption. That requires interaction design and implementation to be reviewed together while the feature is still easy to change.
Sources
Key takeaways
- Separate response content from statusExpose streaming progress without making assistive technology repeatedly announce the entire answer.
- Preserve focus and user controlDo not move focus unexpectedly; let people pause, stop, read and resume at their own pace.
- Test realistic edge casesCheck long responses, rapid updates, errors and keyboard/screen-reader behaviour with real assistive technology.