Ask an AI "is this accessible?" and you already know what you'll get back. A vague, hedging yes. Maybe a "mostly," or a "it looks reasonably accessible." Nothing you can cite, nothing you can hand to an engineer, nothing you can check off against WCAG. It's a useless answer to a useless question.
Now hand the same model one specific, structured prompt instead. Not "is this accessible," but a prompt that names a persona, scopes the review, and forces a strict output format. The difference isn't subtle. The output flips from a shrug into a real, cited, fixable audit, and it does this reliably, on almost any AI you point it at.
That's the whole idea behind this article: one prompt, reused over and over, that turns a chat window into something closer to a junior auditor with a checklist. We didn't just write the prompt and theorize about it. We ran it for real against a real broken component, and we're publishing the exact output below.
The Stat: In our own real test, one structured audit prompt run against one real broken custom dropdown component returned 7 correctly-cited WCAG findings, from missing keyboard support (2.1.1) to a missing live-region announcement (4.1.3), with an accurate minimal fix for each. (Source: our own real, reproducible test, detailed in the article below)
Why "Is This Accessible?" Is the Wrong Question
Vague prompts get vague answers. That's not a knock on any particular AI model, it's just how language models respond to underspecified requests. If you don't tell it what role to play, what to look at, or how to format its answer, it will default to the safest, softest, most hedged response it can generate.
An accessibility audit isn't a vibe check. It's a checklist against a specific standard (WCAG 2.2), with specific success criteria, specific failure conditions, and specific fixes. If you want that kind of output from an AI, you have to ask for that kind of output. That means building the constraints into the prompt itself, not hoping the model infers them.
The Prompt Itself
Here's the actual prompt, word for word, reusable on any component you paste in:
"Act as a WCAG 2.2 AA accessibility auditor. Review this component's HTML/JS ONLY for accessibility defects a screen reader or keyboard-only user would hit. For each defect, name the exact WCAG success criterion it violates, explain in one sentence why it fails, and give the minimal code change that fixes it. Do not comment on visual design, only on programmatic/semantic accessibility. Output a numbered list, most severe first."
Notice what this prompt is actually doing. It isn't asking a question, it's issuing four separate constraints, each one closing off a way the model could wander into a vague, unhelpful answer.
The Four Parts That Make It Work
Persona. "Act as a WCAG 2.2 AA accessibility auditor" tells the model which hat to wear. It's no longer a general assistant guessing at what you want, it's playing a role with a defined job: cite criteria, don't editorialize.
Scope. "HTML/JS ONLY" and "do not comment on visual design" fence the review to programmatic and semantic accessibility. Without this line, most models will happily drift into color contrast opinions or layout critique, which is a different job entirely and dilutes the output.
Output format. "Name the exact WCAG success criterion... explain in one sentence... give the minimal code change" forces every finding into the same three-part shape: citation, reason, fix. That consistency is what makes the output checkable and actionable instead of a wall of prose.
Severity order. "Most severe first" makes the list triage-ready. Your team can start fixing from the top and stop wherever their time runs out, instead of hunting through an unordered pile for the thing that actually blocks users.
We Ran It for Real, Here's What Happened
To see whether this actually holds up, we didn't just write the prompt and move on. We built a real, deliberately broken component, a custom country-dropdown made the way a lot of teams accidentally build one under deadline: a div-based fake select, click handlers instead of real interactivity, no ARIA roles, no keyboard support at all.
We pasted the component's HTML and JS into an AI chat and ran the exact prompt above, with no follow-up questions and no hand-holding. The model returned 7 real, correctly-cited findings, in severity order:
- Missing keyboard support (WCAG 2.1.1)
- Missing role/state on the trigger element (4.1.2)
- Missing role on the individual options (4.1.2)
- No programmatic link between the trigger and the menu (1.3.1)
- No focus movement into the opened menu (2.4.3)
- No Escape-to-close behavior (2.1.1)
- No live-region announcement of the selected value (4.1.3)
Every single WCAG success criterion cited was correct for the defect it was attached to. Every proposed fix was genuinely minimal: adding tabindex and keydown handlers, setting role="listbox" and role="option", wiring up aria-expanded and aria-controls, and adding an aria-live region for the selected value announcement. None of it was a "just rebuild this component" cop-out. Each fix was something a developer could drop in within minutes.
The scope constraint held up too. Because the prompt explicitly said "do not comment on visual design," the output stayed entirely on programmatic and semantic issues. No stray comments about spacing, color, or layout crept in, even though the component had plenty of visual quirks the model could have latched onto.
The Verdict: It's the Prompt, Not the Model
The interesting part isn't that an AI can find accessibility bugs. It's that the specific structure of the prompt, not the underlying model, is what makes the output reliably useful. Naming a persona, scoping strictly to programmatic accessibility, and forcing a WCAG-criterion-per-finding format turns a vague "is this accessible" request into a real, checkable, cited audit, every time you run it.
That's a small but important distinction if you're building AI into your own workflow. You don't need a fancier model, you need a better-constrained prompt. Swap in any AI you already have access to and this same structure should keep producing the same kind of grounded, citable output, because the constraints are doing the work, not the model's raw capability.
How to Use This on Your Own Components
This isn't a one-off trick, it's meant to be reused on every component you ship. A simple workflow looks like this:
- Paste the component's HTML and JS (not screenshots, not descriptions, the actual markup and event handlers) into your AI of choice.
- Run the exact prompt above, unmodified.
- Read the numbered list top to bottom and fix the most severe items first.
- Re-run the same prompt after your fixes to confirm the findings are gone, rather than assuming they are.
- Keep a copy of the prompt somewhere your whole team can grab it, so every audit uses the same structure and the results stay comparable over time.
If you want a wider toolkit beyond this one audit prompt, our earlier piece on 11 Prompts That Turn ChatGPT Into a Real Accessibility Assistant covers a broader library of tasks, from writing alt text to drafting VPATs. And if you're curious what happens on the other side of this process, when an AI is asked to build a component rather than audit one, We Asked ChatGPT to Build an Accessible Form walks through everything it got wrong in that direction.
Beyond the Prompt
A good audit prompt gets you a list of defects and fixes, but it's worth grounding those fixes against the actual standards. The ARIA Authoring Practices Guide has reference patterns for exactly the kind of custom widget we tested here, listbox, combobox, and menu patterns included. And the WCAG 2.2 specification itself is the source of truth for every success criterion number the prompt asks the model to cite, so it's worth keeping open in a tab while you review the output.
An AI prompt is a great first pass. It won't catch everything a real assistive-technology user would hit in practice, and it won't replace a full manual and automated audit across your whole product. If you want that deeper layer of coverage on top of what a prompt like this can surface, that's exactly what AccessRadar is built for.
If you try this prompt on your own components and want a second set of eyes on what it finds (or misses), reach out to a real person on our team at experts@wcag.world, or head straight to AccessRadar to see how a fuller audit builds on top of exactly this kind of test.