Accessibility is an AI architecture requirement

Watch a screen reader user meet the average AI chat widget. The answer streams in and nothing announces it. A “thinking” indicator spins, silently. The refusal message appears in a color-coded box the screen reader treats as any other text, if it reaches it at all. Focus jumps when the transcript updates. Every one of those failures was designed in, by nobody, because accessibility was scheduled as a test at the end of a project whose interaction model was already frozen.

I spent eleven years as the Web Accessibility Officer for a state agency, holding public digital properties to Section 508, the federal accessibility standard, and the ADA. The lesson from that decade is blunt: accessibility failures are cheapest at the whiteboard and most expensive after launch. AI interfaces have made both ends of that curve steeper.

The obligations did not change. The interface did.

The rules were never about static pages. WCAG 2.2, the Web Content Accessibility Guidelines in their current W3C Recommendation, rests on four principles that read like an AI interface test plan: information must be presentable in ways users “can perceive,” interface components “must be operable,” content must be understandable, and it “must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.” Generated text is still information. A send button is still a component. A screen reader is still a user agent.

For US state and local government entities, the obligations now carry dates. The Department of Justice's Title II web rule adopts WCAG 2.1 AA as the standard for state and local government web content and mobile apps, with compliance deadlines, extended in April 2026, of April 26, 2027 for entities serving 50,000 or more residents and April 26, 2028 for smaller entities and special districts. To be precise about scope: that rule binds Title II entities, and this article is operational guidance rather than legal advice. What matters for architecture is simpler: the deadline for an accessible AI interface is the day you launch it to someone who needs it.

Where AI interfaces break, in WCAG's own terms

The failure modes are specific, and the standard already names them.

• Streaming answers and silent status. Chat output arrives as a live stream, and states like searching or generating change without a page load. WCAG’s status-message criterion requires exactly this to be "identified programmatically, through role or properties" so assistive technology can present it "without receiving focus." In practice that usually means a live region, a marked area of the page whose changes screen readers announce. An interface that streams silently has failed a named criterion, not a nicety.
• Focus that will not sit still. Transcript updates, auto-scroll, and appearing elements can drag or hide keyboard focus. WCAG requires a visible focus indicator and, in 2.2, that the focused element is never entirely hidden by other content. Decide where focus lives during generation and where it lands after, as architecture.
• Errors and refusals nobody perceives. AI systems decline, time out, and fail in ways traditional forms never did. Each of those states needs to be perceivable and understandable: announced, described in text, and recoverable by keyboard.
• Controls without names. Suggestion chips, regenerate buttons, feedback icons: every interactive element needs an accessible name and a keyboard path, the same as any other component.
• Motion without mercy. Typing indicators, shimmer effects, and animated transitions should respect reduced-motion preferences; the strictest WCAG motion criteria sit at the highest conformance level, and good practice honors the preference regardless.

None of this is exotic. It is the ordinary standard applied to a new interaction model, which is why it belongs with the people designing the interaction rather than the team testing it later.

Designed in, then tested anyway

Designed-in does not mean test-free. It means the acceptance criteria exist before the build: how streaming is announced, where focus travels, how failure states present, what the keyboard-only journey is, and who signs off. NIST's AI Risk Management Framework frames trustworthiness as a property carried through design, development, use, and evaluation, and accessibility is exactly that kind of property: unownable at the end, cheap at the start.

Then test with the real thing: a keyboard, a screen reader, and time spent listening to your own interface. And keep testing, because generated interfaces change under your feet. A model update that makes answers longer, a prompt change that adds a new refusal state, a template tweak that reorders the transcript: each one can break an announcement pattern that passed last quarter.

One caution from practice: the failure mode of enthusiasm is over-announcing. A live region wired to every token of a streaming answer shouts at assistive technology users. The pattern that works is deliberate: put a polite live region on the transcript container (aria-live=“polite” with aria-busy while generating), let it announce message arrival and completion rather than every token, and give status and error states a status role so they announce themselves. Announce the events a person needs, and let the stream itself stay quiet.

Accountability has a name or it does not exist

The office I held existed because someone has to own the standard, reviewing the interfaces and answering for the failures. AI interfaces need the same named ownership, and they raise the stakes, because the interface now generates its own content at runtime. Put accessible behavior in the definition of done for every AI surface, give one person the authority to hold it there, and make the AI vendor conversation include the question every procurement should ask: show me how your interface announces itself to a screen reader.

I build to that standard because I spent a decade being the person who had to answer for it. This site practices what it can: the chat transcript announces updates through a live region, and the animations respect reduced-motion preferences. Inspect it with the tools you would use on your own site; that is what the standard should invite.

Questions worth asking next

Sources

1. W3C, Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation, 12 December 2024 edition. https://www.w3.org/TR/WCAG22/
2. U.S. Department of Justice, fact sheet on the Title II web and mobile app accessibility rule (WCAG 2.1 AA; deadlines as extended April 2026). https://www.ada.gov/resources/2024-03-08-web-rule/
3. NIST, AI Risk Management Framework. https://www.nist.gov/itl/ai-risk-management-framework