We spent two days last month testing our AI interface prototypes with a screen reader. Not as an afterthought. We'd built what we thought was a solid chat-based AI tool for document analysis, and we wanted to see how it held up. It didn't. The streaming responses created a wall of noise. The confidence indicators were invisible. The suggested follow-up questions were announced as a flat list with no context. We went back and rebuilt the interaction model from scratch.
What You Need to Know
- AI chat interfaces are being deployed across enterprises at speed, and most have significant accessibility gaps
- Streaming text output is fundamentally hostile to screen readers unless handled with deliberate ARIA patterns
- Confidence scores, status indicators, and inline citations are almost always visual-only
- Markdown-to-HTML rendering inside AI responses often produces broken heading hierarchies and unlabelled elements
- The patterns to fix these problems exist. They're just not being applied because teams ship fast and test with sighted users
The Scale of the Problem
Enterprise AI adoption is accelerating. Every vendor is adding an AI assistant, a chat interface, a "copilot" experience. These interfaces look different from traditional enterprise software, but they're being deployed into the same organisations with the same legal obligations around accessibility.
24%
of New Zealand adults live with a disability
Source: Stats NZ, Disability Survey, 2013
That's roughly one in four of your users. And the 2013 figure almost certainly understates the current reality. These aren't edge cases. When you ship an AI tool to 500 enterprise users, around 120 of them have some form of disability. Some use screen readers. Some rely on keyboard navigation. Some need high contrast. Some have cognitive disabilities that mean dense, rapidly updating interfaces are genuinely difficult to process.
The AI industry is moving so fast that accessibility is being deferred almost everywhere. "We'll fix it later." "It's a beta." "Screen reader support is on the roadmap." These are the same excuses the web industry made in 2005, and many of those gaps still haven't been closed.
Problem 1: Streaming Text
The signature feature of modern AI interfaces is streaming, where tokens appear word by word as the model generates them. It looks impressive. For screen reader users, it's a disaster.
A screen reader using
aria-live="polite" will try to announce each update to the live region. If the content changes every 50 milliseconds as new tokens arrive, the screen reader either queues up dozens of announcements (creating a delayed, overlapping mess) or drops updates to keep up (so the user hears fragments).Using
aria-live="assertive" is worse. It interrupts whatever the user was doing to announce each token. Imagine trying to read an email while your screen reader interrupts every 50ms to say "The," "key," "findings," "from," "the," "document," "are."What works: Don't announce streaming tokens individually. Let the response stream visually for sighted users, but only announce completed chunks to screen readers. We use a pattern where the live region updates once the full response is complete, or at natural paragraph breaks for long responses. The screen reader user gets the same information, just delivered in a way that's actually usable.
// Simplified pattern
<div aria-live="polite" aria-atomic="true">
{isStreaming ? (
<span className="sr-only">Generating response, please wait...</span>
) : (
<div>{completedResponse}</div>
)}
</div>
// Visual streaming happens in a separate, non-live region
<div aria-hidden={isStreaming}>
{streamingTokens}
</div>
The visual streaming element is hidden from screen readers during generation. The live region shows a "generating" status, then the complete response when it's ready. Simple. Effective.
Problem 2: Confidence and Status Indicators
AI interfaces love to show confidence. A coloured bar, a percentage, a traffic light icon, a subtle background tint that indicates the model's certainty about its output. These are visual signals with no text equivalent.
A screen reader user gets: "The contract expiry date is 15 March 2025." A sighted user gets the same text with an amber confidence indicator suggesting the model isn't fully certain. That's a meaningful information gap. The sighted user knows to verify. The screen reader user trusts the output.
What works: Include confidence as text. Not buried in a tooltip. Directly associated with the content.
<p>
The contract expiry date is 15 March 2025.
<span className="confidence-badge" role="status">
<span className="sr-only">Model confidence:</span>
Medium confidence
</span>
</p>
Same pattern for status indicators. "Processing," "Complete," "Error" need to be announced, not just shown as a spinner or a green tick. Use
role="status" for non-urgent updates and role="alert" for errors.Problem 3: Chat Interface Structure
Most AI chat interfaces are built as a vertical list of messages with minimal semantic structure. Visually, the conversation flow is obvious. The user's messages are on the right, the AI's responses are on the left, each has a timestamp and an avatar.
Through a screen reader, it's a flat sequence of text blocks with no indication of who said what, when, or where one message ends and the next begins.
What works: Use proper list markup. Each message is a list item with a clear label.
<ol role="log" aria-label="Conversation with AI assistant">
<li aria-label="You, 2:34 PM">
Summarise the key risks in this contract.
</li>
<li aria-label="AI assistant, 2:35 PM">
The contract contains three significant risk areas...
</li>
</ol>
The
role="log" tells assistive technology that this is a chronological sequence. New messages appended to the log will be announced. The aria-label on each item gives context about who sent it and when.Problem 4: Markdown Rendering
AI models output markdown. Applications render that markdown to HTML. The quality of that rendering varies enormously, and it directly affects accessibility.
Common failures:
Broken heading hierarchy. The AI outputs
## Key Findings and ### Risk Areas inside a response that sits below an h2 on the page. Now you have heading level jumps. The page structure breaks for screen reader navigation.Code blocks without language labels. Rendered
<pre> and <code> elements with no indication of what language the code is in, or that it's code at all if the visual styling is subtle.Tables without headers. AI-generated comparison tables often render as visual grids without
<th> elements, making them useless for screen readers.Links without context. "See this article" becomes a link with the text "this article," which is meaningless when listed alongside other links on the page.
What works: Post-process the rendered markdown. Adjust heading levels to fit the page hierarchy (if the response starts with h2, bump all headings down to fit below the current page context). Add
scope attributes to table headers. Process links to include more context when possible.This is extra engineering work. Most teams skip it because the visual output looks fine and the deadline is tomorrow.
AI interfaces threw us because the content is dynamic and unpredictable - you can't template your way through it. You have to build systems that make any response accessible, regardless of structure.
Mak Khan
Chief AI Officer
Problem 5: Suggested Actions and Follow-ups
AI interfaces often present suggested next steps: "Ask a follow-up," "Export as PDF," "Refine this analysis." These are buttons or links rendered after the AI response.
The accessibility failure is usually context. The actions appear visually below the response they relate to. A screen reader user navigating by links or buttons hears "Ask a follow-up" but has no idea which response this follows up on, especially in a long conversation.
What works: Group the actions with their response and label the group.
<div role="group" aria-label="Actions for AI response at 2:35 PM">
<button>Ask a follow-up question</button>
<button>Export response as PDF</button>
<button>Flag for review</button>
</div>
The Responsibility Gap
The AI model providers don't ship accessible interfaces. They ship APIs. The application developers building on those APIs are responsible for accessibility. But most of them are frontend engineers who've built standard web forms and dashboards, not streaming real-time conversational interfaces.
The patterns are new. The WCAG specification doesn't have specific guidance for AI chat interfaces. The WAI-ARIA authoring practices don't cover streaming content. Teams are figuring it out as they go, and most are figuring it out by shipping inaccessible software first and fixing it later. If they fix it at all.
We're documenting these patterns because we've had to solve them ourselves. The AI tools we're building for enterprise clients need to work for every user, including the ones using assistive technology. That's not a nice-to-have. For our government and enterprise clients, it's a contractual requirement.
The AI industry is repeating the mistakes the web industry made 20 years ago. Shipping fast, optimising for the majority, and treating accessibility as a future problem. The difference is that enterprise AI tools are being mandated for daily use right now. The people being excluded don't have the option to wait.