Web Design · UX & accessibility
The Best Prompt for an Accessibility Audit
The best prompt for an accessibility audit has the model review the markup you paste against WCAG 2.2 and be explicit about what a code review can and cannot prove. This prompt returns confirmed issues with the success criterion, who is affected and a corrected snippet, a separate list of things that need human testing, and a manual test script for keyboard, screen reader, zoom and contrast. It never declares a page compliant.
Accessibility Audit Prompt
Reviews page markup against WCAG 2.2, separating issues confirmed in the code from those needing manual testing, with fixes and a test script.
- Works with
- ChatGPT, Claude, Gemini
- Difficulty
- Advanced
- Complexity
- Multi-part reply
- Variables
- 6
- Version
- 1.0
Customize this prompt
Fill in what you know. Anything left blank stays as a [bracketed placeholder]. Nothing you type leaves your browser.
6 variables · fields marked * matter most
# Your role You are a web accessibility specialist reviewing a page against WCAG 2.2. You are doing a code-and-content review. You cannot operate the page, hear a screen reader or measure rendered colors, so you must keep what you can confirm separate from what needs a human to test. # Scope Page or component: [Page or component] Conformance target: [Conformance target] Key tasks a user must be able to complete: [Key tasks] Framework or component library: [Framework or component library] Already known issues (do not repeat these): [Already known issues] # Material to review <markup> [Markup to review] </markup> # Procedure 1. Read the markup in source order and build a picture of the page: landmarks, heading outline, interactive elements, forms, images and media, dynamic regions. 2. Report confirmed issues: problems visible in the markup itself. For each give: - Element: the selector or a short quoted snippet - Issue: what is wrong - WCAG: success criterion number, name and level - Impact: who is affected and what they cannot do - Fix: corrected markup or a precise instruction 3. Report needs-manual-check items: things the markup makes likely or possible but that only testing can settle, such as color contrast, focus visibility, focus order after scripts run, behavior of custom widgets, and whether text alternatives are accurate. Say what to test and how. 4. For each key task listed in the scope, state whether anything found would stop a keyboard-only user or a screen reader user from completing it. 5. Write a manual test script for this page: keyboard pass, screen reader pass, zoom to 200 percent and reflow at 320 CSS pixels, contrast checks, and reduced-motion check. Tailor each step to elements that are actually in the markup. # Rules - Review only what is in the markup. If stylesheets, scripts or states are missing, list them under "Not reviewed". - Cite a success criterion only when you are confident of the number and name. If unsure, describe the problem and write [CRITERION TO CONFIRM]. - Do not report 4.1.1 Parsing; it is obsolete in WCAG 2.2. - Prefer native HTML elements over ARIA in fixes. Do not add ARIA that duplicates native semantics. - Never state that the page passes, conforms or is compliant. A review like this can find failures; it cannot establish conformance. - Do not estimate a percentage score. # Output format A. Page picture (short list) B. Confirmed issues (table, most severe impact first) C. Needs manual check (table) D. Task impact E. Manual test script (numbered steps) F. Not reviewed
Use it when you are
- Checking a page template or component before release
- Triaging accessibility work ahead of a formal audit by a specialist
- Reviewing a form, modal or navigation component built in-house
- Producing a manual test script for a team new to accessibility testing
Why this prompt works
Two lists: confirmed and needs manual check
A missing form label can be seen in markup. Insufficient contrast or a keyboard trap usually cannot. Splitting findings by how they can be verified stops the model from asserting things it has no way to observe, and tells you which items a developer can fix immediately and which need a tester.
Findings are written for the person who will fix them
Element, issue, criterion, impact and fix is the shape of a usable accessibility ticket. Including who is affected and what they are prevented from doing keeps the work grounded in people instead of rule numbers, and helps a team decide what to do first.
Guardrails against confident citation errors
Models can attach the wrong success criterion number to a real problem. The prompt allows a [CRITERION TO CONFIRM] marker in place of a guess, and excludes the Parsing criterion that WCAG 2.2 made obsolete, so the report does not send developers to look up requirements that do not apply.
No verdict of compliance
Conformance is a claim about a whole page under real use, and a text review cannot support it. Forbidding pass statements and scores keeps the output honest about being a failure-finding exercise, which is also how it should be described to stakeholders.
The test script is specific to your page
Generic checklists get skipped. Because step five must refer to elements actually present in the markup, the script reads as instructions for this page: tab to this control, open this menu, trigger this error. That makes manual testing approachable for someone doing it for the first time.
How to use it
- Open the page in a browser, inspect the region you want reviewed and copy its outer HTML. Strip out any personal data.
- Name the tasks a user must complete on this page. The task impact section depends on them.
- List issues you already track so the response concentrates on new ones.
- Fix the confirmed issues first, then check each fix against the WCAG text linked in the sources.
- Carry out the manual test script yourself with a keyboard and a screen reader, and add what you find to your backlog.
- Repeat for each distinct template or component instead of pasting an entire site.
AI model compatibility
| Model | Status | Notes |
|---|---|---|
| ChatGPT | Expected to work | Very long pages may not be reviewed evenly. Paste one template region at a time, such as the header and navigation, then the main form, and run the prompt for each. |
| Claude | Expected to work | The markup sits inside a tag already, in line with Anthropic's guidance on separating supplied material from instructions. Keep the tags when you paste long HTML. |
| Gemini | Expected to work | Paste rendered HTML from the browser's element inspector where you can, not framework source, so the review reflects what assistive technology receives. |
“Expected to work” means the prompt uses plain, model-independent structure and has been reviewed for that — not that it has been run on that model. A model is marked Tested only when a test record is published below.
Worked example
Scenario: A dental clinic checking its appointment request form before launch.
# Your role You are a web accessibility specialist reviewing a page against WCAG 2.2. You are doing a code-and-content review. You cannot operate the page, hear a screen reader or measure rendered colors, so you must keep what you can confirm separate from what needs a human to test. # Scope Page or component: Appointment request form on a dental clinic site Conformance target: WCAG 2.2 Level A and AA Key tasks a user must be able to complete: Fill in and submit the form; recover from a validation error Framework or component library: Plain HTML with a custom JavaScript date picker Already known issues (do not repeat these): None logged yet # Material to review <markup> <div class="form"> <div class="title">Request an appointment</div> <input type="text" placeholder="Full name"> <input type="text" placeholder="Phone"> <div class="datepicker" onclick="openCal()">Choose a date</div> <span class="err" style="color:red">Required</span> <img src="/img/tooth.png"> <div class="btn" onclick="send()">Send</div> </div> </markup> # Procedure 1. Read the markup in source order and build a picture of the page: landmarks, heading outline, interactive elements, forms, images and media, dynamic regions. 2. Report confirmed issues: problems visible in the markup itself. For each give: - Element: the selector or a short quoted snippet - Issue: what is wrong - WCAG: success criterion number, name and level - Impact: who is affected and what they cannot do - Fix: corrected markup or a precise instruction 3. Report needs-manual-check items: things the markup makes likely or possible but that only testing can settle, such as color contrast, focus visibility, focus order after scripts run, behavior of custom widgets, and whether text alternatives are accurate. Say what to test and how. 4. For each key task listed in the scope, state whether anything found would stop a keyboard-only user or a screen reader user from completing it. 5. Write a manual test script for this page: keyboard pass, screen reader pass, zoom to 200 percent and reflow at 320 CSS pixels, contrast checks, and reduced-motion check. Tailor each step to elements that are actually in the markup. # Rules - Review only what is in the markup. If stylesheets, scripts or states are missing, list them under "Not reviewed". - Cite a success criterion only when you are confident of the number and name. If unsure, describe the problem and write [CRITERION TO CONFIRM]. - Do not report 4.1.1 Parsing; it is obsolete in WCAG 2.2. - Prefer native HTML elements over ARIA in fixes. Do not add ARIA that duplicates native semantics. - Never state that the page passes, conforms or is compliant. A review like this can find failures; it cannot establish conformance. - Do not estimate a percentage score. # Output format A. Page picture (short list) B. Confirmed issues (table, most severe impact first) C. Needs manual check (table) D. Task impact E. Manual test script (numbered steps) F. Not reviewed
What a good response should contain
- Confirmed issues for inputs that rely on placeholders with no label, a clickable div used as a button, a date picker that cannot receive keyboard focus, and an image with no alt attribute
- Each confirmed issue paired with a success criterion and a corrected snippet that uses native elements such as label and button
- Manual-check items for the red error text contrast, whether the error is announced, and how the calendar behaves once open
- A task impact note that a keyboard-only user is likely blocked at the date picker and the Send control
- A not-reviewed section naming the stylesheet, the calendar script and the page's surrounding landmarks
This is an illustrative scenario showing how to fill in the prompt and what to look for. It is not a recorded model output. Recorded outputs will be published here once this prompt has a test record.
Testing and editorial review
Status: Untested. Reviewed for structure and clarity by the editorial team. No recorded model test yet.
No test record has been published for this prompt yet. When it is tested, this section will show the model and version, the date, the inputs, the actual output and notes against our seven-point rubric. We do not publish numerical scores.
| Author | TheBestPromptFor Editorial Team — The editorial team writes, reviews and maintains the prompts and guides on TheBestPromptFor. Prompts are drafted with AI assistance and reviewed against published editorial standards. |
|---|---|
| Published | November 15, 2026 |
| Last reviewed | November 15, 2026 |
| Last tested | Not yet tested |
| Version history |
|
Limitations and things to check
- This is not a conformance audit. It cannot show that a page meets WCAG, only point to likely failures.
- Contrast, focus visibility, reading order as rendered and custom widget behavior cannot be judged from markup alone.
- Success criterion references can be wrong. Check each against the WCAG 2.2 text before filing or citing it.
- Legal obligations differ by country and sector. For compliance decisions, involve an accessibility specialist and test with disabled users.
Alternative prompts
Web Design
UX Audit Prompt
Runs a heuristic review of one user flow: a step-by-step walkthrough, findings tied to usability heuristics with severity ratings, and fixes.
- ChatGPT
- Claude
- Gemini
Web Design
Design System Prompt
Drafts design-system foundations: tiered design tokens, type and spacing scales, and component specs with variants, states and accessibility notes.
- ChatGPT
- Claude
- Gemini
Web Design
Responsive Design Prompt
Turns one page layout into responsive rules: content order on small screens, fluid techniques, justified breakpoints and a per-component behavior table.
- ChatGPT
- Claude
- Gemini
Web Development
Pull Request Code Review Prompt
Reviews a diff the way a careful senior engineer would: intent first, findings ranked by severity, each tied to a line with a suggested fix.
- ChatGPT
- Claude
- Gemini
- Cursor
Related resources
Guide
How to Improve AI Responses
A diagnostic approach to weak AI answers: name the fault, trace it to the gap in your prompt, then follow up precisely or rewrite and start again.
Technical guide
How to Test AI Prompts
A seven-criterion rubric and a nine-field test record for evaluating prompts, plus why this site describes results in words and publishes no scores.
Frequently asked questions
Can an AI model tell me whether my site is WCAG compliant?
No. Compliance depends on how the rendered page behaves with assistive technology, and many criteria need human judgment. A model reading markup can catch a useful share of structural problems early. Treat the result as preparation for manual testing and, where the stakes are high, a professional audit.
How does this compare with automated checkers?
Automated tools run against the live page and are consistent at detecting machine-testable failures such as missing attributes. This prompt adds explanation, corrected code and a tailored manual test plan, but it does not execute the page. Using a checker and this review together covers more than either alone.
What should I paste: source code or rendered HTML?
Rendered HTML from the browser's inspector is usually better, because it includes content that scripts add and reflects what assistive technology is given. Framework source can hide the real output behind components. If the region is large, paste it in sections and run the prompt for each.
Which WCAG level should I choose?
Level AA is the target most organizations and many regulations refer to, and it includes all Level A criteria. Choose the AAA option only if you have a specific reason, since some AAA criteria cannot be met for all content. If a law applies to you, confirm the required version and level.
Sources and references
Was this prompt useful?
No account needed. Do not include personal information.