One good prompt catches a lot. It does not cover everything an accessibility workflow actually needs.
A single review prompt is great for a quick gut-check on a UI you just built. But a real workflow has more moving parts: alt text that needs drafting, ARIA that needs sanity-checking, contrast pairs that need a fast estimate before you open a dedicated tool, a keyboard test that needs a script, an accessibility statement that needs a first draft, and an executive summary that needs to land without jargon.
Here are 11 more prompts, each built for one specific task, ready to copy straight into whichever AI assistant you already use.
The Stat: A 2025 arXiv study (2503.15885) found that adding a feedback-driven review step, the study's own FeedA11y method, significantly improves the accessibility of AI-generated code compared to relying on a single, unreviewed prompt. (Source: arXiv 2503.15885)
Why one prompt was never going to be enough
If you start with our single featured review prompt if you only need one, you already have a fast way to catch obvious issues in AI-generated UI. That prompt is a single pass: paste markup, get a list of likely violations back.
But a real accessibility workflow is not one task. It is alt text, ARIA, contrast, headings, keyboard behavior, form errors, statements, and reporting, all happening on different days for different reasons. Treating an AI assistant as a one-trick reviewer wastes most of what it can actually do.
This is also where the research lines up with practice. The arXiv study this prompt strategy is based on found that a feedback-driven review step meaningfully improves the accessibility of AI-generated code compared to a single, unreviewed prompt. In other words: the value is not in asking an AI to get everything right in one shot. It is in using AI for structured, repeatable second-pass review across many specific categories, each one narrow enough that the model can actually stay focused on it.
That is what the 11 prompts below are built for. Each targets one job. None of them replaces a human decision. All of them save you time getting to that decision.
The 11 prompts
Copy any of these as-is, then fill in the bracketed part with your own content.
1. Draft alt text for review
Use this when you need a first-pass alt text draft, not a finished answer. WCAG's 1.1.1 Non-text Content requires alt text to serve an equivalent purpose to the image, and that judgment call still needs a person who has actually looked at the image.
Here is a description of an image and its context on the page: [describe the image, its
surroundings, and what it's meant to communicate]. Draft a single, concise alt text that conveys
the same information or function a sighted user would get. Do not describe visual style unless
it affects meaning.
2. Review ARIA roles
Here is a chunk of HTML: [paste]. List every ARIA role, state, and property present. Flag any
role duplicating a native HTML element's built-in semantics, any required child role that's
missing, and any aria-* attribute that isn't a real WAI-ARIA attribute.
3. Check color contrast pairs
Here are text and background hex codes: [list pairs, e.g. #241A17 on #F5EEE4]. Calculate the
contrast ratio for each pair and tell me whether it meets 4.5:1 for normal text or 3:1 for large
text and UI components.
Treat this as a fast pre-check, not the final word. Confirm the actual result with a dedicated contrast tool before you ship.
4. Audit heading order
WCAG's 2.4.6 Headings and Labels requires headings and labels to describe topic or purpose, and that is exactly the kind of pattern an assistant can scan across a whole page in one pass.
Here is every heading on this page in order, with its level: [paste, e.g. H1: ..., H2: ..., H3:
...]. Identify any skipped heading levels, any heading that doesn't describe the content that
follows it, and any heading used purely for visual styling rather than structure.
5. Write a keyboard test script
Here are this page's interactive elements: [list buttons, links, form fields, custom widgets].
Write a step-by-step keyboard-only test script covering tab order, visible focus at each stop,
and whether every action available by mouse is also reachable by keyboard.
6. Draft an accessibility statement
We test against WCAG 2.2 Level AA. Our current known issues are: [list]. Draft an accessibility
statement including our conformance target, how someone can report an accessibility issue, and
where to note the last review date.
7. Explain a WCAG criterion in plain language
Explain WCAG [criterion number and name] in plain language a non-technical stakeholder would
understand. Include one concrete example that would pass and one that would fail.
8. Suggest a focus order fix
Here is our DOM order and our visual layout: [describe both]. The visual order and the DOM order
don't match in [location]. Suggest how to reorder the markup, or where to use tabindex, to fix
the mismatch without changing the visual layout.
9. Review error message wording
Here are our form validation error messages: [list them]. Rewrite any that describe only what's
wrong without saying how to fix it, and flag any that rely on color or an icon alone to indicate
an error.
10. Draft skip-link copy
This page has these landmark regions in order: [list, e.g. navigation, main content, search,
footer]. Draft skip-link text for each one, written so it's clear exactly where each link goes
before it's activated.
11. Summarize an audit report for execs
Here is our full accessibility audit report: [paste]. Summarize it for a non-technical executive
audience: what's broken, a plain-language severity ranking, and roughly what it will take to fix
the top three issues.
What each prompt is actually good for
| # | Prompt | Best used for | Still needs a human |
|---|---|---|---|
| 1 | Alt text draft | First-pass wording, faster than a blank page | Yes, confirm accuracy against the real image |
| 2 | ARIA review | Catching redundant or invalid attributes | Yes, confirm actual behavior in a screen reader |
| 3 | Contrast check | Fast estimate before a real tool | Yes, verify with a dedicated contrast checker |
| 4 | Heading audit | Spotting skipped levels and vague labels | Yes, confirm labels match user intent |
| 5 | Keyboard test script | Structuring what to test and in what order | Yes, someone has to run it by hand |
| 6 | Accessibility statement | First draft of structure and wording | Yes, legal/policy review before publishing |
| 7 | Plain-language WCAG explainer | Briefing non-technical stakeholders | Rarely, good for internal education |
| 8 | Focus order fix | Suggesting a markup or tabindex approach | Yes, test the fix in a real browser |
| 9 | Error message review | Rewriting vague or color-only messages | Yes, confirm tone matches your product voice |
| 10 | Skip-link copy | Drafting clear, specific link text | Rarely, mostly a wording check |
| 11 | Exec summary | Translating a technical report for leadership | Yes, confirm severity ranking against your own priorities |
- Pick the prompt that matches today's task, not the whole list at once
- Fill in the bracketed context with real, specific detail
- Read the output against the linked WCAG criterion where one applies
- Run anything visual, like contrast pairs or focus order, through a dedicated tool
- Keep a human sign-off step before anything ships
The one rule that applies to all 11
None of these prompts is a substitute for review. That is the actual finding behind the arXiv study cited above: a feedback-driven second pass beats a single unreviewed prompt, and that holds whether the "pass" is code generation or a wording check on an error message. The prompts above exist to make that second pass fast and specific, not to skip it.
If you only have time for one thing today, our single featured review prompt is still the right place to start on a freshly built UI. Come back here when you need the rest of the workflow: alt text, ARIA, contrast, statements, and everything else that a one-shot review prompt was never designed to cover.
Put it into practice
Pick the prompt for the task in front of you, fill in the details, and treat the output as a strong first draft, not a final answer. Then run the output through our free tools before you ship it to confirm what the AI flagged actually holds up.
Pair these prompts with our free tools for a fuller check, starting with our free accessibility tools. If you would rather have a person walk through the results with you, the team at experts@wcag.world is a message away.