Feedback loops

This page is about the loops in how an AI product is built and how it learns. It is the practical companion to the feedback loop in Foundations, which sets out why accessibility for AI is continuous. Here the focus is on the loops you can act on, in development and in the data.

Key points

This page is about the loops you can act on, in development and in the data.
AI tools default to inaccessible markup, so constrain and check the generation with enforcement prompts, native HTML first, and CI checks.
The data loop can amplify bias when a model trains on its own output or on majority feedback signals.
A curated knowledge base is a feedback loop you control, and often more reliable than retraining.
Close the loop with disabled users by making reports easy and routing them to someone who can act.

Why generated UI starts inaccessible

An AI coding tool optimizes for output that looks right on screen, not for the accessibility tree that assistive technology actually reads. So it tends to produce a clickable <div> where a <button> belongs, skip labels and ARIA, and leave out keyboard handling, even when the rendered result looks correct. A Frontend Masters analysis of AI-generated React names a few reasons this is the default. A plain <div onClick> is fewer tokens than a real button with a label and key handling, so the cheaper pattern is favored. The model has no internal picture of how its markup maps to a screen reader, so semantics are easy to drop. And the human ratings that tune these models are usually made by looking at the rendered result, which means accessibility rarely enters the reward signal at all. The takeaway is that the default will not improve on its own, so the generation has to be constrained and checked.

Build accessibility into the development loop

The cheapest place to catch an accessibility problem is while the code is being written, including when an AI tool writes it. A reusable enforcement prompt can make an AI coding assistant check keyboard access, focus, and labeling as it generates, and report what it changed. In continuous integration, a scanner can file issues, and a workflow can track remediation over time. None of this replaces human and user testing, but it stops obvious regressions early. See Automated tools.

Two moves do most of the work. The first is to default to native HTML, and have the AI reach for a component library only for the small set of widgets HTML has no native equivalent for, such as a combobox or a tab panel. Treat that choice the same way you would treat ARIA, as a last resort you evaluate rather than a name you trust, since quality varies widely between libraries and a library’s accessibility can be undone by the styling or customization built on top of solid primitives. See WCAG Robust for why. Some generators already default to a specific component library, which is a reason to test the generated result rather than assume it is accessible. The second move is to set eslint-plugin-jsx-a11y to error in CI so a broken pattern cannot merge. Doing this work up front is cheap. Preventing a defect while a component is generated takes a few minutes, but finding and fixing the same defect later takes closer to an hour, so the enforcement pays for itself.

The data loop can amplify bias

AI systems learn from feedback, and that loop can make bias worse. If a model is retrained on its own output, or on a web increasingly full of AI-generated content, it can reinforce existing patterns and erase the variety that disabled users depend on, tending toward the monoculture the W3C warned about. User feedback signals can do the same, because the loudest signals come from the majority. Watch what the loop is optimizing for, and make sure disabled users’ input is weighted in rather than averaged out. The roots of this are in the training data.

Curated knowledge as a feedback mechanism

One practical loop is to feed the system the right knowledge rather than hope it learned it. Teams build a trusted knowledge base of accessibility policies, design-system rules, and standards for an AI assistant to draw on, so its output reflects the organization’s decisions. Updating that knowledge is a feedback loop you control directly, and it is often more reliable than retraining for keeping output accessible.

Close the loop with disabled users

The most important loop runs through people. Reports from disabled users are signal, not noise, and they should feed back into prompts, guardrails, data, and design. Make it easy to report an accessibility problem, route those reports to someone who can act, and treat a model or prompt change as a trigger to re-test, as in Output auditing. The European Disability Forum’s work on AI literacy is about putting disabled people inside these loops as participants who shape the system.

Audience: Engineer

Tie the accessibility re-test to the things that change generation behavior, so a prompt or model change cannot ship without a check. In CI that can be as simple as gating on the paths that matter.

# Re-run accessibility checks whenever generation behavior can change
on:
  push:
    paths:
      - 'prompts/**'
      - 'src/model/**'
jobs:
  a11y:
    steps:
      - run: npm run test:a11y   # axe across a fixed set of sampled prompts

The same native-HTML-first rule applies to whatever component library the model reaches for. One accessibility audit found that shadcn’s copy-paste styling undoes some of what its underlying Radix primitives get right, shipping low-contrast focus rings and at least one chart component with no accessible alternative for screen readers, so audit the components you actually ship rather than trusting the primitive underneath them. Feed the AI assistant a reusable enforcement prompt, instructions that make it check keyboard access, focus, and labeling as it writes code, the same way a human reviewer would. Add keyboard-only and screen-reader interaction tests to the CI suite alongside standard conformance checks, so a regression that only breaks for those interaction patterns still fails the build.

Audience: Product Manager

Give these loops a named owner, someone who watches for drift, decides where user reports go, and knows what triggers a re-test. Write that down rather than leaving it implicit. Prevention is cheaper than remediation, so budget for enforcement during generation rather than fixing defects after release. Watch for majority feedback signals that deprioritize disabled users without anyone noticing, since they are a minority of the signal but a group you have duties toward. Treat a model or prompt change as a trigger to re-test, the same way you would treat a UI redesign.

Audience: Self-advocate

Your reports are how these systems are supposed to improve, so a tool that makes it hard to report a problem, or that never seems to act on one, is failing at the loop that matters most. The teams getting this right bring disabled people in as participants who shape the product, not just as testers at the end. Specific reports, naming the assistive technology and the exact failure, are the ones that move through the loop fastest.