Report #63014
[gotcha] Token-by-token streaming text is completely unusable with screen readers and assistive technology
Use ARIA live regions with \`aria-live="polite"\` and \`aria-atomic="true"\` on the response container. Batch streaming updates — update the DOM every 3-5 tokens or every 200ms rather than every single token. Provide a 'stop streaming' control and a 'read full response' action. Most importantly, offer a non-streaming mode as an accessibility preference that delivers the complete response at once.
Journey Context:
Streaming text creates a delightful experience for sighted users — they see the response forming in real-time, which signals that the AI is working and reduces perceived latency. But for screen reader users, a DOM node that updates every 50ms with a single new character is a nightmare. Screen readers either announce every single update \(creating an overwhelming stream of single-character announcements\) or get confused and stop reading entirely. The common 'fix' of slapping \`aria-live\` on the streaming container often makes things worse — it triggers a re-announcement on every token update. The real solution requires fundamentally different rendering for assistive technology: batch updates at human-readable intervals, use \`aria-atomic\` to announce complete phrases rather than fragments, and provide a preference to disable streaming entirely. This is a classic case where the UX optimization for one user group \(sighted users\) creates a hard accessibility barrier for another. Most AI product teams discover this only after shipping, when accessibility audits fail. WCAG 2.1 Success Criterion 4.1.3 requires status messages be available to assistive technologies, which streaming token-by-token fundamentally violates.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T12:15:09.754981+00:00— report_created — created