The feedback loop

Accessibility for a static page is, in principle, a finite job. You author the content, structure it correctly, test it once, and it stays accessible until someone edits it. AI breaks that model in two places, and both are loops. Understanding them is the conceptual hinge for the rest of this site, because almost every pattern and testing recommendation here follows from one fact. An AI product’s accessibility is a runtime property that has to be maintained, not a fixed attribute you can certify and forget.

There are two distinct loops worth keeping separate.

Key points

An AI product’s accessibility is a runtime property you maintain, not a fixed attribute you certify once.
The interaction loop is the per-use cycle of perceive, interpret, act, and repeat, and AI adds an uncertainty step and self-acting agents to it.
The evaluation loop matters because generated output drifts over time through model updates, prompt changes, and real user input, any of which can regress accessibility silently.
No single tier is enough. Automated tools catch about half of issues, so the loop also needs manual testing, real assistive technology, and human judgment.
AI will not dissolve this work. A system that generates the interface still has to generate an accessible one, and it does not do that by default.

The interaction loop

Every use of an interactive product is a loop. The person perceives the current state, interprets it, acts, and then perceives the result of that action, and round again. Accessibility means none of those steps is broken for anyone. For a button the loop is tight and obvious. You see the label, understand it, click, and see what changed.

AI stretches this loop and inserts unfamiliar states into it.

Perceive. The user has to take in output that may be streaming and changing token by token, or long, or non-textual such as a generated image, a chart, or a proposed action. A screen-reader user cannot glance at it. They need it announced in a controlled way, with structure they can navigate.
Interpret. The user has to judge not just what the system said but how much to trust it. AI output can be confidently wrong, so the loop now includes an uncertainty step that static content never had. If confidence is shown only through visual hedging, such as faint text or a phrase like “this might be,” it is invisible to many users.
Act. The user responds, corrects, interrupts, or approves. With agents, the system may also act without waiting, so the user needs a way to perceive and step into actions they did not directly trigger.
Now do it again. Then the loop repeats, often many times in a single session, far more than a traditional form.

Each AI interaction pattern in this reference is, at bottom, a way of keeping this loop closed for everyone.

Conversational interfaces keep the perceive and act turn-taking navigable.
Dynamic and streaming output make the perceive step survivable when output never stops changing.
Uncertainty and confidence make the interpret step honest for non-visual users.
Agentic actions keep the user inside the loop when the system acts on its own.

Audience: Engineer

The interaction loop maps directly onto a handful of implementation responsibilities.

Perceive means a live-region strategy and semantic structure for generated output.
Interpret means exposing confidence and provenance in the accessibility tree, not only in CSS.
Act means keyboard-operable stop, regenerate, and approve controls with proper names and focus management.
Now do it again means moving or announcing focus when new content arrives, without yanking it away from what the user is reading.

If you can point to the code that closes each of these four steps for a non-visual user, the pattern is probably sound.

The evaluation loop

The second loop is about the product over time, and it is the reason AI accessibility cannot be a one-time sign-off.

Because the output is generated, the thing you tested yesterday is not the thing the next user will see. Several forces change it without anyone touching the UI.

Non-determinism. The same prompt produces different structure and length across runs.
Model updates. Swapping or upgrading the underlying model changes how output is formatted, how it hedges, and how long it runs.
Prompt and system-message changes. A small tweak to a system prompt can quietly start producing tables, emoji, or unstructured walls of text.
Fine-tuning and retrieval changes. New training or retrieval data shifts tone, structure, and bias.
Real user inputs. Production prompts are wilder than anything in a test suite, and they surface output shapes you never sampled.

Any of these can regress accessibility, turning a screen-reader-navigable answer into an unstructured blob or a calm announcement into a flood, with zero changes to the code you would normally re-audit. So the evaluation has to become a loop too. You sample real output, test it with automated checks, manual testing, and real assistive technology and real users, feed the findings back into prompts, guardrails, and rendering, and then repeat. This is the through-line of the Testing section. It mirrors the governance loops in frameworks like the NIST AI RMF, which runs Govern, Map, Measure, and Manage, and the data and output loops covered in Inclusive development.

Two findings explain why no single point in the loop is enough.

Accessibility is not the default state of generated output. A Microsoft evaluation found unguided LLM HTML passed automated checks just 12 percent of the time, climbing to 86 percent only with explicit instruction, so the loop has to keep pushing output toward accessibility rather than assume it.
No single tier closes the loop on its own. Automated tooling catches only part of the picture, since Deque’s own figures put automated coverage at around half of issues, and one study of AI-driven remediation found problems in 52 percent of its fixes, including adding new issues, leaving old ones, and missing context.

The loop needs automated checks and manual testing and real assistive technology and human judgment, run repeatedly.

Audience: Accessibility Specialist

In practice this means an accessibility conformance statement for an AI product needs a sampling methodology and a date, not just a pass or fail. Saying “we audited the chat UI” tests one surface, while the generated output is a population you can only sample. Define how you sample, covering representative prompts, edge cases, long and short outputs, and error and refusal states. Test the rendering pipeline rather than a frozen transcript, and set a re-test trigger on model and prompt changes. A VPAT for a generative feature that does not say how output was sampled is describing the shell, not the contents. See Methodology.

Audience: Product Manager

The one-sentence version for planning is that a model or prompt change is an accessibility-relevant change. Wire accessibility re-testing into the same release gate you already use for those changes, and treat shipping a new model version as a trigger to re-sample output rather than a pure backend swap. The cost of not doing this is invisible regression, where the product quietly stops working for screen-reader users between releases and you find out from a complaint rather than a test.

Governance, not just tooling

The loops above describe what to test and when. They do not by themselves say who is accountable for what a model ships, and that gap is where accessibility quietly erodes. Anna E. Cook frames AI accessibility as a governance problem rather than a tooling one, because a model that generates part of the interface is, in her words, a fourth team that ships without a manager. A few governance choices keep that team accountable.

Put AI output through the same review as human work. Generated artifacts need an owner with the authority to block output that fails, not a separate and lighter path.
Name what is protected. Decide up front which properties are non-negotiable, such as keyboard operability, semantic hierarchy, programmatic labels, and focus order, so the model is free to vary presentation but never these.
Never override an explicit user choice. Honor signals the user has already declared, such as prefers-reduced-motion or a high-contrast setting, rather than letting AI inference quietly replace them. Cook draws the line that personalization built on declared signals is adaptive, while personalization built on unauthorized inference is imposition.

Without this, AI amplifies whatever structure it is given, including the failures, across every output at once.

The shortcut that isn’t

It is tempting to believe AI will dissolve this work, and that models will simply generate a perfectly personalized, accessible interface for each user, retiring standards and audits altogether. Jakob Nielsen has argued exactly this, calling accessibility “a miserable failure” and betting on per-user generative UI instead. The accessibility community has pushed back hard. Most fixes are a few lines of well-understood HTML and ARIA, so the bottleneck is organizational will and not technology. A system that generates the interface still has to generate an accessible one, which, going by the evidence above, it does not do by default. The shortcut does not remove the loop. It just moves the loop inside the model, where it is harder to inspect. Both loops still have to be closed, and they have to be closed by people.

Why this framing matters

If you take one idea from Foundations into the rest of the site, make it this. Accessibility for AI is something you keep true, not something you make true once. The patterns tell you how to close the interaction loop for a given feature. The testing tiers tell you how to close the evaluation loop over time. Everything else is detail hung on those two loops.