Accessibility in AI Interfaces: What Most Builders Miss

#ai #ux #webdev #a11y

Most teams think they've handled accessibility once someone adds aria-live to the chat window and closes the ticket. I've watched this happen on three separate AI products now. The screen reader demo works in the sprint review. Then a real blind user opens the product three weeks later and can't tell if the assistant answered at all.

That gap between "we tested it" and "it works" is the whole story of accessibility in AI interfaces right now. Builders are shipping conversational UI faster than they're shipping the plumbing that makes it legible to assistive technology, and the checkbox mentality is making it worse, not better.

The checkbox that doesn't check anything

Here's the belief that's costing teams the most: that screen reader support is a line item you can bolt on after the interface is built. It isn't. A live region only works if the container announcing new content is present in the DOM before the update happens, if the urgency level matches the content, and if the message itself is short enough to be useful when read aloud mid-conversation.

Most AI chat widgets fail at least one of those three. Message containers often lack ARIA live regions entirely, so screen readers announce nothing when the assistant responds, even though the text is fully visible on screen. The response exists. The user just doesn't know it happened.

This isn't a hypothetical gap. Across the top million homepages, the vast majority still carry detectable WCAG 2.2 failures, and automated scanners, the tools most teams lean on to feel compliant, only catch a slice of the real problems. Screen reader compatibility, cognitive load, and complex interactive components need a human tester with a screen reader, not a lint rule.

Streaming broke the one thing that used to work

Static text was never the hard problem. Screen readers have handled static pages fine for two decades. What's new, and what most teams haven't adjusted for, is token-by-token streaming: the thing every AI product does now to feel responsive.

Streaming is a screen reader's worst case. NVDA and JAWS are built to read stable content, not text that's rewriting itself multiple times a second. When a response streams in, screen readers can mispronounce partial tokens, freeze mid-read, or stop responding to the user's commands entirely until the stream finishes. There's an open GitHub issue on Claude Code asking for a dedicated screen-reader mode specifically because NVDA locks up during token streaming, forcing users to restart their screen reader mid-session just to regain control.

Notice who found the workaround. Not the vendor. A developer built claude-a11y, a browser extension and CLI wrapper that reformats AI chat output into something a screen reader can actually parse, layered on top of tools that shipped without that consideration built in. Blind engineers are patching accessibility gaps in AI products faster than the companies that own those gaps are fixing them. That's not a compliment to the ecosystem. It's an indictment of it.

Agentic UI adds a layer nobody accounted for

It gets worse once the product isn't just chatting, it's reasoning. Agentic interfaces show their work now: a "thinking" indicator, a tool call, a status line that says it's searching, then reading, then writing. Sighted users get a lightweight animation they can glance at and ignore. Screen reader users get every one of those transient states read aloud, in sequence, competing for the same live region as the actual answer.

That's a cognitive load problem most teams never budget for. A blind user trying to follow a multi-step agent has to track state changes that a sighted user processes peripherally in half a second. If every intermediate step fires an announcement, the meaningful content, the actual answer, gets buried under process narration. If nothing announces, the user has no idea whether the agent is still working or has silently failed. Neither default is acceptable, and I haven't seen a mainstream agentic product pick a deliberate middle ground yet.

The fix here isn't exotic engineering. It's editorial judgment applied to live regions: decide which state changes matter enough to announce, suppress the rest, and give users a way to check status on demand instead of narrating every micro-step at them. Nobody's shipping this because it requires someone to actually sit down and decide what's worth saying out loud, which is slower than just wiring up aria-live and calling the ticket done.

What screen readers actually hear

Set streaming aside for a second. Even a fully rendered, static AI response usually fails on structure. Screen readers don't read pixels, they read the DOM: headings, lists, landmarks, labeled buttons. That's how a blind user skips to the third point in a numbered list instead of listening to the whole response top to bottom.

Generated AI content routinely skips all of it. No heading tags to distinguish a section title from a sentence. No list semantics around what's visually a bulleted list. No labels on the buttons rendered inline in a response. What a sighted user sees as a clean, skimmable answer, a screen reader user hears as one unbroken wall of text, no way to tell where an idea starts or a new one begins.

Six recurring problems account for the overwhelming majority of detected accessibility errors industry-wide: low contrast, missing alt text, empty links, unlabeled inputs, missing buttons, missing language tags. None of these are exotic. They're the basics, and AI-generated interfaces are reproducing them at scale because the models generating the markup were never scored against whether a screen reader could parse the output.

The fix nobody wants to build

WCAG 2.2's Success Criterion 4.1.3, Status Messages, already covers exactly this case: users need to be informed when content updates without their focus moving to it. That's precisely what happens every time an AI assistant finishes a response while the user's focus sits in the input box. The standard isn't missing. The implementation discipline is.

Fixing this for real means a few unglamorous things. Message containers need aria-live="polite" present in the DOM from page load, not injected after the fact. Streaming needs a throttled or chunked announcement strategy instead of firing an update on every token. Generated responses need semantic structure, actual heading and list tags, not visual formatting that only sighted users benefit from. And someone with a real screen reader needs to sit with the product before launch, because automated tools are only catching a fraction of what's actually broken.

There's also a widening legal backdrop pushing this from "nice to have" to "required." California's AB-331, in effect since the start of this year, mandates algorithmic accessibility assessments for public-facing AI systems, and regulators are increasingly citing WCAG directly in settlements involving AI interfaces. Roughly one in four adults in the US lives with a disability. Treating their access to your product as a post-launch patch isn't just a UX failure, it's a growing compliance one too.

The teams that get this right won't be the ones with the most accessibility statements on their marketing page. They'll be the ones who tested with a screen reader before the demo, not after the complaint.