← Insights

Mental Models for the AI EconomyAccessibility

Your AI Chat Box Is Probably Unusable With a Screen Reader

Streaming replies, focus jumps and silent errors lock out the users chat could help most. What breaks, the eight checks that fix it, and a five-minute test.

By George MoreasAugust 6, 20269 min read · interactive

Almost every product now has a chat box. Most of them were built in a sprint, by copying the look of ChatGPT, and tested by people who can see the screen. That is how a feature meant to make software easier ends up being the one part of the product a blind customer cannot use.

The good news is that chat is not a new kind of interface. It is a text field, a button and a list of messages that change. The web has had rules for each of those for years, written down in WCAG. What is new is streaming: the answer arrives a few characters at a time, and that one design choice breaks most implementations.

The streaming problem

Sighted users watch text appear and find it reassuring. A screen reader user hears what the page tells their software to announce. If the reply area is a live region that updates on every token, the reader starts speaking, gets interrupted by the next update, starts again, and so on. Depending on the screen reader, people hear a stutter of fragments, only the last word, or nothing at all. WCAG's status messages criterion (4.1.3) asks that changes like “a reply has arrived” be announced without stealing focus. It does not ask that every character be read as it lands.

01 / What a screen reader hears

One reply, three ways to announce it

“I found three flights under $400. The cheapest leaves at 6:10 a.m. Do you want me to hold a seat?”

Every token
25×
Each sentence
4×
When finished
1×
25 interruptionsEach update cuts off the last one. Many users hear fragments, or nothing usable.
Token count estimated at about four characters per token. Real behaviour depends on the screen reader and how the live region is built; the point is the order of magnitude.

The fix is small: keep the visual stream, but announce in sentences or once at the end, with a short status such as “Assistant is replying” while it works. Put the finished reply in a polite live region, never an assertive one, so it waits for the user to finish what they were doing.

The four failures I see most

Focus jumps. After sending, focus moves to the new message or the top of the page. Keyboard users lose their place. Keep focus in the message box.

No way to stop. A long answer that cannot be paused by keyboard fails the user who needs to read slowly and the user whose screen reader is mid-sentence. A real Stop button fixes both.

Structure flattened. Models return headings, lists, tables and code. Rendering them as one block of text throws that structure away. Render the Markdown into real HTML elements, the same point I make about formats in HTML or Markdown for AI Agents?.

Silent errors. “Something went wrong” in red text, announced to nobody. Errors need to be announced and need to say what to do next.

02 / Ship check

Eight checks for a chat interface

38%5 barriers left. Fix the live region and keyboard items first.
Drawn from WCAG 2.2 success criteria (status messages, keyboard, focus, reflow, error identification). Passing all eight is not a full audit; failing any is a real barrier.

Why this is a product decision

If your support is moving into a chat assistant, an inaccessible assistant is an inaccessible support channel. In the EU that can fall under the European Accessibility Act, which covers customer service for in-scope services. In the US, chat widgets already appear in accessibility lawsuits. But the stronger reason is the one from Accessibility Is a Product Decision: the people who rely on a screen reader, voice control or zoom are also the people for whom a conversational interface could be the biggest improvement. Getting it wrong wastes the best use case you had.

Test it the cheap way first: unplug the mouse, turn on VoiceOver or NVDA, and ask your assistant three questions. You will know within five minutes.

Sources

Across the series

Share
Mental Models for the AI Economy

Get the next essay the day it publishes.

A few a month, written from real builds. Unsubscribe in one click.

George Moreas
About the author
George Moreas

Performance marketing and search leader who builds — 15+ years in digital growth and product (AT&T/DirecTV, Microsoft, Employbridge, Site Impact), now running his own properties with AI. These essays are field notes from that loop: what AI actually changes about work, product, and the economics underneath. Based in South Florida.

Keep reading