What is AI accessibility?

AI accessibility is the practice of making sure products built on artificial intelligence can be used by people with disabilities. That includes chat assistants, generative tools, recommendation systems, and autonomous agents. It applies the same goal that drives all digital accessibility, which is that everyone can perceive, operate, and understand the product regardless of ability. The difference is that an AI system’s behavior is generated at runtime rather than authored in advance.

That last difference is the whole reason this reference exists. Most accessibility guidance assumes a designer or developer controls what appears on screen. With AI, a model decides instead. It often decides differently every time, sometimes incorrectly, frequently in a continuous stream, and increasingly by taking actions on the user’s behalf. The principles do not change. What changes is where and when you can apply them.

Key points

AI accessibility means people with disabilities can use AI products, the same goal that drives all digital accessibility.
The hard part is the output a model generates at runtime, not just the interface around it.
Generated output is not accessible by default, and an unguided model rarely produces accessible markup unless you ask it to.
Standards like WCAG still apply, but they do not yet cover probabilistic, streaming, and agentic output.
AI accessibility is not the same as AI for accessibility, which means using AI as an assistive tool.

Two surfaces, not one

When people say “make the AI accessible,” they usually mean one of two things, and a complete product has to handle both.

The interface to the AI. This is the input field, the send button, the message list, the settings, and the loading states. It is conventional UI, and conventional accessibility standards apply directly. A chat box that traps keyboard focus or has unlabelled controls fails for the same reasons any other interface would.
The output the AI generates. This is the text it writes, the images it produces, the decisions it returns, and the actions it proposes. No human authored this content, and it is delivered at runtime. You cannot hand-write its alt text or check its heading order in advance. Accessibility here is a property of the system that produces and presents the output, not of a fixed artifact.

The second surface is what makes AI accessibility a distinct discipline. A flawlessly accessible chat interface can still be unusable with a screen reader if it streams unstructured, unlabelled, or unbounded generated content into a live region. This is not hypothetical. In a Microsoft evaluation of LLM-generated HTML, unguided model output passed automated accessibility checks only 12 percent of the time. That rose to 86 percent only when the model was given explicit accessibility instructions. Generated output is not accessible by default. It has to be made so.

The reason is structural. A model generates by reproducing the patterns in its training data, and the web it learned from is overwhelmingly inaccessible. So the markup it returns by default tends to repeat the missing labels, flat heading structure, and non-semantic elements that are already common online. As accessibility practitioner Anna E. Cook argues, AI does not repair a broken structure. It inherits that structure and reproduces it at scale. Accessible, well-structured systems are the foundation it depends on, not something it can reliably generate from nothing.

What AI changes about the usual assumptions

Traditional accessibility leans on a set of assumptions that generative and agentic systems quietly break.

Content is authored and static. AI content is generated and varies between sessions, so you have to build accessibility into the generation and rendering pipeline rather than the artifact.
Output is deterministic. The same prompt can produce different structure each time, so you cannot rely on a fixed DOM that you tested once.
Output arrives all at once. Streaming output changes constantly, token by token, and announcing every update naively will flood a screen reader. See Dynamic and streaming output.
The system is correct, or it fails loudly. Models are probabilistic and can be confidently wrong, so communicating uncertainty becomes an accessibility concern and not just a nicety. See Uncertainty and confidence.
The user starts an action and the UI responds. Agents act on their own, so users need to perceive, interrupt, and review actions taken on their behalf. See Agentic actions.

These shifts run through the whole Patterns section. The feedback loop page explains why they push accessibility from a one-time audit toward continuous evaluation.

Not the same as AI for accessibility

Two phrases get used interchangeably and should not be.

AI accessibility is the subject of this site. It means making AI products usable by disabled people.
AI for accessibility means using AI to assist disabled people, such as automatic captions, generated alt text, real-time sign-language avatars, and voice control.

They do intersect. An AI-generated alt-text feature is both an accessibility tool and an AI product that must itself be accessible. The focus here is the first one. Where assistive uses of AI are relevant we will flag them, but “the model wrote the alt text, so we are covered” is a category error. A generated description still has to be correct, and the feature delivering it still has to be operable. As accessibility practitioner Joe Dolson puts it, AI in this space is best treated as a helper, not the end product. The assistive side is genuinely powerful, though. AI is now letting disabled people build their own assistive tools from a plain-language description of what they need.

Existing standards still apply

AI accessibility is not a replacement for established accessibility standards. It is those standards carried into a harder setting. WCAG 2.2, the W3C Web Content Accessibility Guidelines and a Recommendation since October 2023, governs the interface and most of the rendered output. Its four principles, perceivable, operable, understandable, and robust, organize much of this site. Regional law layers on top, including the EU’s European Accessibility Act, the AI-specific obligations of the EU AI Act, the US ADA and Section 508, and the harmonized standard EN 301 549.

What WCAG does not yet fully cover is the generated, probabilistic, and agentic nature of the output. There is no success criterion for communicating model uncertainty accessibly. That gap is the subject of WCAG applicability. The W3C is working on it. Its AI Accessibility draft maps AI’s impact across authoring tools, user interfaces, evaluation, and assistive technology. Its research symposium on AI and accessibility opened with the warning that because statistical models marginalize outliers, disabled people are “most vulnerable to both existing and emerging harms.”

Audience: Engineer

AI accessibility usually shows up in your code as four recurring problems.

Announcing streamed output without spamming assistive technology, which means debouncing updates and choosing aria-live="polite" over assertive for non-urgent content.
Giving generated content a stable, parseable structure, with real headings, lists, and landmarks rather than a wall of <div> elements.
Surfacing state such as thinking, generating, and stopped through role="status" so it is perceivable without sight.
Making any action an agent takes reviewable and reversible.

None of these need exotic ARIA. They are the disciplined application of the basics to non-deterministic content.

The Patterns section works through each of these with concrete markup. See Dynamic and streaming output for announcing updates, Generated content for parseable structure, and Agentic actions for reviewable and reversible actions.

Audience: Product Manager

The framing that lands with stakeholders is that an AI feature’s accessibility is a property of the system at runtime, so it cannot be signed off once and forgotten. The output changes after launch through new prompts, model updates, and fine-tuning, which means accessibility can regress without a single line of UI code changing. Budget for ongoing evaluation rather than a one-time audit, and treat model or prompt changes as triggers for re-testing, the same way you would re-test after a UI redesign.

Audience: Self-advocate

A useful test of whether a team understands AI accessibility is to ask what happens when the model is wrong and you are using a screen reader. Can you tell the answer is uncertain? Can you tell when it is still generating versus finished? Can you stop it? Products that only ever imagined a sighted user watching text appear tend to fail exactly here, because the information a non-disabled user picks up from visual motion and styling is simply missing for everyone else.

The failures are often mundane and total at the same time. One blind user documented that an AI tool rendered the download link for files it generated as plain text rather than a real, focusable link, so the files simply could not be retrieved with a screen reader. As they put it, “If a blind user cannot access a file, it does not exist for them.”