Your AI assistant just shipped a component in eleven seconds. It looks great. It compiles. Nobody on the team has time to run a full audit on every pull request, so it merges.
Here is the part nobody says out loud: the same assistant that wrote the component can also review it, if you ask the right way. It will not replace a real audit and it will not catch everything a trained human eye or assistive tech user would catch. But it will catch the obvious stuff, the stuff that repeats across almost every AI-generated interface, before a human has to say "this div should be a button" for the hundredth time this quarter.
We built a single prompt for exactly this. Not a plugin, not a tool, just text you paste into whatever assistant you are already using, right after it hands you a component. Here is what is actually in it, why each line exists, and where its limits are.
The Stat: A feedback-driven review step (the FeedA11y method) was found to significantly improve the accessibility of AI-generated code compared to trusting a single, unreviewed prompt. (Source: arXiv 2503.15885)
Why a second prompt actually helps
The instinct to distrust "ask the AI to check its own work" is a healthy one. Most of the time, if you just say "is this accessible?" the assistant will say yes and move on, because that is the path of least resistance in a chat.
But that is not what a structured review prompt does. It does not ask a vague question. It asks a fixed list of specific, checkable things, one at a time, and asks the assistant to point at the actual line of code that answers each one. That distinction, a single open-ended pass versus a structured, feedback-driven second look, is exactly what the arXiv study this prompt strategy is based on tested. Their finding was straightforward: a feedback-driven review step measurably improved the accessibility of AI-generated code compared to code that only went through a single, unreviewed generation prompt. The improvement came from the review step existing at all, not from the first prompt being smarter.
That is the whole theory behind what we are sharing here. Not "AI can audit accessibility." Just: a second, structured pass beats no second pass.
The prompt
Paste this immediately after your assistant generates or edits a UI component, before you accept the diff:
"Review the component you just wrote against these six checks, one by one. For each one, quote the specific line of code involved, then answer pass or fail, then explain why in one sentence. Do not summarize at the top, go through all six in order:
- Does every form input have a label that is programmatically linked to it (not just visually near it)?
- Does every icon-only button or link have an accessible name, via visible text, aria-label, or aria-labelledby?
- Is there anywhere color alone (red text, a colored dot, a colored border) is the only way a user would know something is an error, a status, or a required field?
- Does the DOM order and tabindex match what a sighted user would visually expect when tabbing through?
- Is every clickable element a real button or anchor tag, or is it a div or span with an onClick and no semantic role?
- Does the text-to-background contrast meet at least 4.5:1 for normal text and 3:1 for large text? For any fail, rewrite just that piece of code."
That is it. No tooling, no plugin, no account required. It works in whatever assistant already wrote the code.
Why these six and not others
We picked these six because they map to the failures we see AI generate over and over, and because two of them map directly to named WCAG success criteria, which makes them checkable rather than a matter of opinion.
The clickable-div problem is the single most common thing an AI coding assistant gets wrong when speed-generating UI. It reaches for a div with an onClick handler because it is faster to style than a native button, and it looks identical on screen. But a screen reader user gets nothing: no role, no indication it is interactive, no keyboard focus by default. This is squarely WCAG 4.1.2 Name, Role, Value, the criterion most directly violated by that pattern.
The color-only problem shows up constantly in generated form errors and status badges: a red border with no text, a colored dot with no label. That is exactly what WCAG 1.4.1 Use of Color exists to catch, and it is an easy thing for an assistant to self-verify once it is asked the direct question, because the code either includes text/icon/pattern alongside the color or it does not.
| Check | Common AI failure pattern | WCAG reference |
|---|---|---|
| Real buttons vs. styled divs | <div onClick> instead of <button> |
4.1.2 Name, Role, Value |
| Color not the only signal | Red border / colored dot with no text | 1.4.1 Use of Color |
| Linked labels | Placeholder text used instead of a real <label> |
Labels or Instructions (3.3.2) |
| Icon-only button names | SVG icon button with no aria-label | 4.1.2 Name, Role, Value |
| Focus order | Visual grid reordered with CSS, DOM order untouched | Focus Order (2.4.3) |
| Contrast | Light-gray-on-white text for "subtlety" | Contrast (Minimum) (1.4.3) |
What this prompt will not catch
Be honest with your team about the ceiling here. This prompt catches pattern-level, code-visible issues. It will not catch:
- Whether the reading order actually makes sense to a real screen reader user navigating live
- Whether your custom widget's keyboard behavior matches the ARIA Authoring Practices for that widget type
- Cognitive load, plain-language issues, or whether an error message is actually helpful
- Anything about video captions, audio descriptions, or non-text content review
- Real assistive technology testing with an actual screen reader or switch device
That is why this is a first pass, not a final one. If you want a sense of how badly this can go without any review at all, read what we found asking an AI to build a form directly: almost every failure in that piece is one this six-question prompt would have flagged before the code ever reached a human.
Where it fits in your workflow
Run it right after generation, before your own eyes even look at the diff. It costs you one extra message in a chat you are already having. Then, before anything ships to production, run your generated page through our free tools too for the checks a self-review prompt structurally cannot do: real contrast measurement, real DOM inspection, real automated scanning against the fuller rule set.
Neither step alone is an audit. Together, they catch most of what would otherwise reach a human reviewer, or a user, first. If you want the fuller check alongside this prompt, that is exactly what our free tools are built for.