# 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](https://artificia11y.ds.house/foundations/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, accessible component primitives, 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](https://frontendmasters.com/blog/ai-generated-ui-is-inaccessible-by-default/) 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](https://github.com/nadav-senseit/ai-accessibility-enforcement) 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](https://github.com/github/accessibility-scanner) can file issues, and a workflow can [track remediation](https://github.blog/ai-and-ml/github-copilot/how-we-automated-accessibility-compliance-in-five-hours-with-github-copilot/) over time. None of this replaces human and user testing, but it stops obvious regressions early. See [Automated tools](https://artificia11y.ds.house/testing/automated-tools/).

Two moves do most of the work. The first is to have the AI build on accessible component primitives, such as Radix UI, React Aria, or Headless UI, which encode the roles, ARIA, and keyboard behavior into the component so the model does not have to get them right from scratch. Some generators already default to this, and Vercel's v0 produces Radix-based output. The second 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](https://frontendmasters.com/blog/ai-generated-ui-is-inaccessible-by-default/).

## 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](https://www.technologyreview.com/2023/06/26/1075504/junk-websites-filled-with-ai-generated-text-are-pulling-in-money-from-programmatic-ads/), it can reinforce existing patterns and erase the variety that disabled users depend on, tending toward the monoculture the [W3C warned about](https://www.w3.org/WAI/research/ai2023/). 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](https://artificia11y.ds.house/inclusive-development/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](https://www.last-child.com/build-ai-brain-a11y.html) 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](https://artificia11y.ds.house/inclusive-development/output-auditing/). The European Disability Forum's [work on AI literacy](https://www.edf-feph.org/projects/empowered-by-ai/) is about putting disabled people inside these loops as participants who shape the system.

> [!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.
>
> ```yaml
> # 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
> ```
>
> Have generated components build on accessible primitives like Radix or React Aria so the roles and keyboard behavior come for free rather than being reinvented per component. Pair this with an enforcement prompt for any AI-generated code, and keep a standing set of disability-related cases in the suite so a regression that only hits those users still fails the build.

> [!PRODUCT-MANAGER]
>
> Own the loops on purpose. Decide who watches for drift, where user reports go, and what triggers a re-test, and write those down rather than leaving them implicit. The economics favor prevention, because catching an accessibility defect during generation costs a few minutes while remediating it after release costs closer to an hour per component, which is the case for funding enforcement rather than cleanup. Be careful that majority feedback signals do not quietly optimize the product away from disabled users, since they are a minority of the signal but a group you have duties toward. A model or prompt change is a release event, not a silent backend swap.

> [!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.

## Further reading

- The Frontend Masters analysis of [why AI-generated UI is inaccessible by default](https://frontendmasters.com/blog/ai-generated-ui-is-inaccessible-by-default/) and how to enforce accessibility.
- The open [AI accessibility enforcement prompt](https://github.com/nadav-senseit/ai-accessibility-enforcement) for shift-left checks.
- Last Child on [building a trusted accessibility knowledge base](https://www.last-child.com/build-ai-brain-a11y.html) for an AI assistant.
- The European Disability Forum's [Empowered by AI](https://www.edf-feph.org/projects/empowered-by-ai/) project.