It Answered. You Just Couldn't Hear It: The Accessibility of AI Tools

A screen reader user opens the AI assistant your team shipped last quarter. They type a question. They press Enter.

Then nothing.

On screen, the answer is arriving beautifully, one token at a time, a paragraph unfurling in real time in a way that looks alive and expensive. In the user's ears, there is silence. Ten seconds of it. Fifteen. So they do what any reasonable person does when a system gives no feedback: they assume it broke, and they send the question again. Now two responses are streaming into a container nothing is announcing, and the conversation has become unusable.

The model worked perfectly. The interface failed completely.

We spent a lot of time arguing that machines cannot see your website, and that the structure you build for disabled people is the same structure crawlers, answer engines and agents depend on. That argument runs the other way too. The AI tools your organisation is now buying, embedding and building have interfaces of their own, and most of them are worse than the websites they are being bolted onto.

The interface is the product now

Every organisation we speak to is shipping something with a model behind it. A support chatbot. A search box that answers instead of listing. A copilot inside the CRM. A summariser in the document library. An agent that fills in the form on the customer's behalf.

The procurement conversation is all about the model: accuracy, hallucination rates, data residency, token cost. The accessibility conversation is not happening at all, because everyone is treating the model as the product. It is not. The chat window is the product. That is the part your customer actually operates, and it is a dynamic, constantly updating, keyboard-hostile widget of exactly the kind that web accessibility has always found hardest.

Worse, these interfaces are being built fast, often by teams who have never shipped a live region in their lives, and they are being dropped onto sites that were compliant before the widget arrived. A conforming page plus an inaccessible assistant is an inaccessible page. There is no partial credit.

The silence problem: streaming responses

This is the defining accessibility failure of AI interfaces, and it is almost universal.

Text that appears progressively is a status change. Something happened, and the user needs to know. Sighted users get that for free: they watch the words appear, they see the cursor pulse, they know the machine is thinking. Screen reader users get whatever you programmatically announce, which in most implementations is nothing at all.

When it is done badly in the other direction, it is arguably worse. An unbuffered live region wrapped around a streaming response will interrupt itself constantly, announcing fragments, re-reading partial sentences, stuttering through half words as each chunk lands. Users describe it as noise, not information, and they turn it off.

Getting this right is a design decision before it is a code decision:

• Announce the state, not the stream. "Generating response" when it starts, then the response when it is complete or at meaningful segment boundaries. The relevant criterion is 4.1.3 Status Messages, which exists precisely for changes that do not take focus.
• Buffer to something a human can follow. Sentence or paragraph level, not token level. A live region firing sixty times a second is a denial of service on your user's attention.
• Choose the right region and politeness. aria-live="polite" with role="status" for progress, role="log" for the running conversation. Never assertive for content, because interrupting a person mid sentence to read them more content is not urgency, it is rudeness.
• Give an accessible way to stop and to review. Stop generating must be reachable and labelled. So must the finished message, as text, in reading order, after the fact. That is 4.1.2 Name, Role, Value and 1.3.1 Info and Relationships doing ordinary work.
• Say when it is finished. The single most valuable announcement in the whole interaction is the one that tells the user the answer is complete and they can now read it.

Test this with a real screen reader, not a scanner. No automated tool can tell you whether an announcement was useful, timely or maddening. Our comparison of manual versus automated testing covers why, and screen readers compared covers the behavioural differences between JAWS, NVDA, VoiceOver and TalkBack, which are substantial in live region handling specifically.

Keyboard and focus: the widget that swallows people

The second failure is older, better understood, and still everywhere.

Chat widgets are usually launched by a floating button in a corner, rendered in a portal at the bottom of the DOM, positioned visually where it has no structural relationship to anything. The predictable consequences:

• Opening it does not move focus into it. The user activates the launcher and their focus stays where it was, or worse, is dumped at the start of the document. Sighted keyboard users watch a panel open and cannot get to it without twenty tab presses.
• Closing it does not return focus. Escape dismisses the panel and focus vanishes to the top of the page, losing the user's place entirely. If Escape does nothing at all and the tab cycle never leaves the widget, that is a 2.1.2 No Keyboard Trap failure, and the only way out is a page reload.
• The reading order and the visual order disagree. The panel appears bottom right, but in the tab order it sits after the footer, which breaks 2.4.3 Focus Order.
• Sticky headers, cookie banners and the widget itself obscure the focused element. WCAG 2.2 added 2.4.11 Focus Not Obscured (Minimum) for exactly this, and floating AI assistants are its most enthusiastic new violator.
• Send is a click handler on a div. It works with a mouse and does nothing on Enter or Space, which is 2.1.1 Keyboard. So do the copy, regenerate, thumbs up, thumbs down, attach and stop controls, which are frequently icon only and not in the tab order at all.
• Suggestion chips are not buttons. They look like buttons, they behave like buttons for mouse users, and they are invisible to everything else.

None of this is novel. It is modal and dialog behaviour that has been documented for fifteen years, arriving again inside a new component because the team building it was solving a machine learning problem and treating the interface as packaging. The patterns that survive a refactor are in our accessibility for developers guide, and the framework specific traps are in single page application accessibility.

Nobody labelled anything

The prompt input is the most important field on the page. In a startling number of implementations it has no accessible name whatsoever. It has placeholder text, which disappears the moment you type and was never a label to begin with, and that is it.

The same goes for the send button, which is often a paper plane glyph with no text alternative, the microphone, the attachment control, the model selector, the copy button, the regenerate button, and the little icons that appear on hover and are therefore unreachable by keyboard or touch anyway.

Every one of these is 4.1.2 Name, Role, Value and 3.3.2 Labels or Instructions, and every one is a five minute fix that nobody made because the interface was tested by people who point at things.

The contrast nobody checked, because it looked sleek

AI interfaces have a house style: low contrast grey on white for the assistant's text, thin weights, tinted chat bubbles, muted timestamps, dim sidebars listing previous conversations, status indicators in pale colour, disabled states you cannot distinguish from enabled ones, and a dark mode that was designed first with a light mode generated from it afterwards.

The result fails 1.4.3 Contrast (Minimum) on body text and 1.4.11 Non-text Contrast on the icon controls and the boundaries between message bubbles. Dense conversational layouts also tend to collapse, clip or scroll in two directions when pushed to 200 per cent or given a user stylesheet, which is 1.4.4 Resize Text and 1.4.12 Text Spacing. And colour alone is routinely doing the work of distinguishing your message from the assistant's, which leaves users with colour vision deficiency parsing a transcript with no reliable idea of who said what.

You can check a page against these in a few minutes with our free page checker, and look up any criterion mentioned in this post in the WCAG criteria search.

A conversation with no structure

A chat log is a document. Almost nobody marks it up like one.

There are typically no landmarks, so there is no way to jump to the conversation or back to the input. There are no headings, so there is no way to move between responses, and a screen reader user who wants the third answer from ten minutes ago must arrow through everything in between. There is no way to skip the conversation history to reach the controls, which is 2.4.1 Bypass Blocks. Message boundaries and authorship are conveyed by bubble alignment and colour rather than by anything programmatic, which is 1.3.1 Info and Relationships. And content inserted above the current position, such as a retry or a system notice, breaks 1.3.2 Meaningful Sequence.

Then there is the response content itself, which is generated markdown rendered to HTML, and which is where a lot of otherwise careful teams lose control. If the model emits a heading, does it become a real heading, at what level, and does it collide with the page's existing hierarchy? Do lists become lists? Do tables get header cells? Do code blocks get labelled? Do generated links get meaningful text, or forty instances of "here"? You are shipping user generated content authored by a machine, at volume, into a live document. That needs a sanitising and structuring layer, and it needs testing.

The answer is part of the interface too

Everything above is about the container. The output has access implications of its own, and this is the part that gets waved away as "not an accessibility issue".

Responses are frequently long, unstructured, written well above the reading level of the audience, and wildly inconsistent in length and shape from one question to the next. For users with cognitive and learning disabilities, that inconsistency is not a style preference. It is the difference between a usable tool and an exhausting one, because unpredictability is a cognitive load multiplier. 3.1.5 Reading Level sits at Level AAA and most organisations ignore it, but the broader principle that content must be understandable is not optional.

There is a more uncomfortable finding in the research too. Model behaviour is not neutral across users. Studies of how models respond to non standard English, to users with lower English proficiency and to users writing with less formal education have found answers that are measurably less accurate, and sometimes patronising in tone. If your assistant is the front door to a government service, that is not a quirk. That is differential service quality delivered to the people least equipped to escalate it, and it will not appear in any automated accessibility report.

Then there is generated media. Images produced by your AI feature arrive with no alternative text at all, or with a caption of the prompt that produced them, which describes what someone asked for rather than what the image contains. That is 1.1.1 Non-text Content failing at scale and at speed, in a pipeline that will keep producing content long after the audit is filed. Generative outputs also under represent disability, and when they do represent it they lean on a narrow set of tired visual shorthands, which matters if you are using them in public communications.

The tools we build with have the same problem

One more, because it is rarely said out loud. The AI coding assistants, chat panels, diff viewers and streaming status indicators inside modern developer tooling are frequently unusable with a screen reader or a magnifier, and lean heavily on colour to convey meaning in diffs.

If the tools used to build software are inaccessible, disabled developers get pushed out of the profession, and the number of people in the room who would have noticed any of the problems above goes down. It is a compounding failure, and it is the one nobody is auditing.

Why your scan came back clean

Because automated testing was never going to catch this.

A scanner loads a page, waits, and evaluates a snapshot. An AI interface spends most of its life in states the scanner never reaches: the widget unopened, the response mid stream, the error after a timeout, the focus behaviour after a dialog closes, the announcement that either happened or did not. The whole failure mode lives in the gap between one snapshot and the next.

That is why we keep saying automation covers around a third of the criteria and none of the judgement. An AI chat panel can pass every automated check on your dashboard and still be completely unusable with assistive technology. The longer version of that argument is in anyone can buy an ice chisel, and the same logic that condemns overlay widgets applies to any AI product sold as instant compliance.

What to do about it

• Treat the assistant as a component under audit, not a vendor feature. If it renders in your page, it is your conformance obligation and your legal risk, whatever the contract says. Ask any vendor for a VPAT or ACR and verify it rather than file it.
• Test the states, not the page. Closed, opening, empty, typing, streaming, complete, stopped, errored, retried, closed again. Check focus and announcements at every transition.
• Buffer and announce deliberately. Progress at the start, content at sensible boundaries, an explicit completion announcement, and a stop control anyone can reach.
• Fix the boring things first. Names on the input and every icon control, real buttons, contrast on text and non text elements, landmarks and headings in the transcript.
• Sanitise and structure generated output. Headings at the right level, real lists and tables, meaningful link text, alternative text on generated images or a considered decision that they are decorative.
• Set output standards. Consistent structure, plain language, predictable length. Write them into the system prompt and test them like any other requirement.
• Test with real users. Screen reader, keyboard only, voice control, switch, low vision, and users with cognitive disabilities, on the actual assistant. That is what assistive technology user testing is for, and there is no substitute.
• Put it in procurement. The next AI product your organisation buys should have accessibility requirements in the evaluation criteria, not in the risk register afterwards. Government suppliers can start with our WCAG 2.2 compliance checklist.

The bottom line

The industry has spent three years obsessing over whether the answer is correct and almost no time on whether the answer can be received.

An assistant that produces a perfect response nobody can hear has produced nothing. An agent that cannot be operated from a keyboard has excluded every user who does not use a mouse. A summariser that emits unstructured walls of text above the reading level of its audience has made the document harder to use, not easier, for the people who most needed the help.

None of this requires new standards. Every failure described in this post maps to a success criterion that has existed for years, in some cases since 2008. The technology is new. The accessibility work is not. It is the same work, on a component that updates itself.

It answered. Make sure they can hear it.

Get Your AI Interface Audited