These 13 accessibility prompts help ChatGPT, Claude, Claude Code and Codex audit and fix web interfaces against WCAG 2.2: a full page audit, the criteria that are new in 2.2, color contrast, forms, ARIA misuse, keyboard support for custom widgets, live regions, alt text, data tables, zoom and reflow, and test plans you can run yourself. Each prompt asks the model to name the success criterion behind every finding so you can check it.
For React-specific fixes, such as an accessible modal component, see the React prompts. For styling-level fixes like focus rings and reduced motion in utility classes, see the Tailwind CSS prompts.
How to use these prompts
Copy a prompt and fill the blanks in double braces. A blank with a colon has a default: {{level:AA}} means Level AA unless you change it.
Paste rendered HTML when you can. Component source hides what the browser actually gets, such as the label a design system adds or the div a library wraps around your button. In your browser's dev tools, copy the outer HTML of the section you care about.
Ask for the success criterion and the evidence. The current standard is WCAG 2.2, and every finding should point at a numbered criterion and the exact element. Findings without evidence are often guesses. If the model isn't sure which criterion applies, it should say so.
Treat the result as a first pass. AI review is good at spotting patterns in code and weak at judging real assistive technology behavior. Confirm the important findings with a keyboard, a screen reader and an automated checker.
How do you audit a page against WCAG 2.2?
1. WCAG 2.2 audit of a page
Audit this page against WCAG 2.2 Level {{level:AA}}.
Page purpose: {{purpose:checkout step where users enter shipping details}}
Rendered HTML: {{html}}
CSS or design tokens (for contrast): {{css}}
For each issue give: the success criterion number and name, the element
(quote the HTML), why it fails, who it affects, and the fix as corrected
HTML. Group by severity: blocks a task, makes a task hard, minor. Mark
anything you can't judge from code alone, such as reading order or
screen reader output, as "Needs manual check".
2. Check the criteria that are new in WCAG 2.2
The What's New in WCAG 2.2 page lists nine new success criteria. Six of them are at Level A or AA, so they apply to most audits.
Check this {{scope:sign-in and account settings flow}} against the WCAG 2.2
criteria added in 2.2:
{{html}}
- 2.4.11 Focus Not Obscured (Minimum): can sticky headers, cookie banners
or chat widgets fully cover a focused element?
- 2.5.7 Dragging Movements: does every drag action have a single-pointer
alternative?
- 2.5.8 Target Size (Minimum): are pointer targets at least 24 by 24 CSS
pixels or spaced enough to qualify for an exception?
- 3.2.6 Consistent Help: do help links appear in the same relative order
across pages?
- 3.3.7 Redundant Entry: are users asked to retype information they
already gave in this process?
- 3.3.8 Accessible Authentication (Minimum): does sign-in require a
cognitive function test, such as remembering or transcribing a code,
without an allowed alternative like paste support or a password manager?
Report pass, fail or needs manual check for each, with evidence and a fix.
3. Check color contrast for a palette
Success criterion 1.4.3 asks for at least 4.5:1 for normal text, and 1.4.11 asks for 3:1 for user interface components and meaningful graphics against adjacent colors.
Check the contrast of these color pairs used in my UI:
{{pairs}}
For each pair, calculate the contrast ratio and say which use it passes at
WCAG 2.2 AA: normal text (4.5:1), large text (3:1), or non-text UI parts
like borders, focus rings and icons (3:1). For each failing pair, suggest
the smallest change to one color that passes while keeping the hue. Show
your ratios so I can verify them with a contrast checker.
How do you fix common accessibility bugs?
4. Make form errors accessible
Forms touch several criteria at once: 3.3.1 Error Identification, 3.3.2 Labels or Instructions, and 4.1.3 Status Messages.
Fix the accessibility of this form and its validation:
{{form}}
Requirements: every input has a visible, programmatically linked label;
required fields are marked in text, not only with color or an asterisk;
hints and errors are linked with aria-describedby; invalid fields get
aria-invalid; on submit, show an error summary at the top that links to
each field and move focus to it; inline errors describe how to fix the
problem. Show the corrected HTML and the JavaScript for focus handling.
5. Replace fake buttons and bad ARIA
The ARIA Authoring Practices warn: "Unlike HTML input elements, ARIA roles do not cause browsers to provide keyboard behaviors or styling."
Find elements in this code that fake native controls or misuse ARIA:
{{code}}
Look for: div or span with click handlers, links used as buttons and
buttons used as links, role attributes that conflict with the element,
aria-label hiding visible text, aria-hidden on focusable elements, and
ARIA states that never update. For each, replace it with the native
element where possible. Only keep ARIA where no native element fits, and
explain what keyboard behavior I must then add myself.
6. Add keyboard support to a custom widget
The APG patterns page documents the expected keyboard behavior for widgets such as Tabs, Combobox, Menu Button, Listbox and Tree View.
Make this custom {{widget:tabs}} component fully keyboard accessible,
following the WAI-ARIA Authoring Practices pattern for it:
{{code}}
List the keyboard interactions the pattern expects, the roles and states
it needs, and how focus should move (roving tabindex or
aria-activedescendant, and why). Then show the updated code and a short
manual test script I can run with only a keyboard.
7. Announce dynamic updates with live regions
These parts of my app update without a page load, and screen reader users
don't hear the change:
{{updates:toast after saving, search result count, cart total}}
Code: {{code}}
For each update, decide: a polite live region, an assertive alert, moving
focus, or nothing. Explain the choice under WCAG 2.2 4.1.3 Status Messages.
Make sure live regions exist in the page before their content changes.
Show the code and warn me about any update that would be announced too
often.
8. Write alt text for images
Success criterion 1.1.1 asks for text alternatives that serve the equivalent purpose, which depends on why the image is there.
Write alt text for these images on a {{page_type:product page}}:
{{images}}
For each image, first decide its role: informative, decorative, functional
(inside a link or button), or complex (chart or diagram). Decorative images
get alt="". Functional images describe the action, not the picture. Complex
images get a short alt plus a longer description nearby. Keep alt text
short and specific to the page's purpose. Don't start with "image of".
9. Mark up a data table
Turn this data into an accessible HTML table:
{{data}}
Use caption, thead, tbody and th with the right scope. If there are
multi-level headers, use headers and id only where scope isn't enough. Keep
it a real table, not a div grid. If it must scroll sideways on small
screens, make the scroll container keyboard focusable with a visible label.
Show the HTML and the CSS for the scroll wrapper.
10. Make a layout survive zoom and reflow
The Understanding Reflow note says 320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels at 400% zoom.
This layout breaks when zoomed:
{{html_and_css}}
Make it meet WCAG 2.2 1.4.10 Reflow and 1.4.12 Text Spacing: no
two-dimensional scrolling at 320 CSS pixels wide (except content that needs
it, like data tables or maps), no clipped text when line height, letter
spacing and word spacing increase, and no fixed heights on text
containers. Keep sticky headers from covering focused elements. Show the
CSS changes and explain each one.
How do you test accessibility?
11. Write a manual keyboard test script
Write a manual keyboard test script for this flow: {{flow:sign up, confirm email, set up profile}}
HTML for each step: {{html}}
For each step, list what to press (Tab, Shift+Tab, Enter, Space, Escape,
arrow keys), what should happen, and what counts as a failure, such as a
lost focus indicator, a focus trap, focus hidden behind a sticky bar, or an
action only reachable by mouse. Reference the WCAG 2.2 criterion for each
check. Format it as a checklist a tester can follow.
12. Write automated accessibility tests
Write automated accessibility tests for {{pages:the home, pricing and checkout pages}} using {{tools:Playwright with axe-core}}.
Scan each page in its main states (default, menu open, form with errors,
dark mode). Fail the test on serious and critical violations, and print
each violation with its rule, element and help link. Add one keyboard test
per page that tabs through and checks focus lands on the main controls in
order. Explain what these automated checks cannot catch so we keep manual
testing.
13. Draft an accessibility statement
W3C's guide to developing an accessibility statement recommends including at least a commitment, the standard applied (such as WCAG 2.2) and contact information.
Draft an accessibility statement for {{product}}.
Standard we target: WCAG 2.2 Level {{level:AA}}
Known issues: {{known_issues}}
How we test: {{testing:automated checks in CI and a manual audit each quarter}}
Contact: {{contact}}
Include: our commitment, the standard, the conformance status in honest
terms (don't claim full conformance if there are known issues), known
limitations with workarounds and planned fix dates, how we test, and how
to report a problem with an expected response time. Plain language, no
legal claims.
How do you make accessibility checks routine?
Accessibility fixes are cheapest before a component spreads across the app. Add the fake buttons prompt and the form errors prompt to your review of any new shared component, so one fix reaches every screen that uses it. When a finding needs a design change, such as a color that fails contrast, fix the token rather than the single screen.
Run the audit prompt on every new page and the new-criteria prompt on every flow that involves sign-in, drag and drop or multi-step forms. Keep the test scripts next to the feature so they get rerun when the code changes. The accessibility skill and web design guidelines skill pages cover ready-made skills that bring these checks into an agent, and the code review prompts include broader review passes. To turn your own audit prompt into a skill, paste it into the SKILL.md generator.
Kipt keeps prompts like these as Markdown in a private GitHub repo you own, with {{level:AA}} style blanks, tags and Cmd+K search, so your audit checklist is one search away. Skills you save there install into Claude Code or Codex with one command.