Ask AI to review a draft page for accessibility problems
Someone asks whether the new page is accessible, and an AI assistant says it "looks accessible overall". That's a mood, not a review. Ask for specific barriers you can find in the code and check with a keyboard.
What you'll make
a short list of specific accessibility barriers, each tied to the code, with a fix and a keyboard check you have done yourself.
What you'll need
the page’s HTML or source code (a screenshot alone can’t show structure or behaviour), an AI assistant that reads code — ChatGPT, Claude, or Copilot in VS Code — and the page running in a browser. Chrome’s built-in Lighthouse panel is a useful automated first pass. About twenty minutes.
Example result.
| Barrier | Evidence | Your check |
|---|---|---|
| Close button has no name | <button type="button">×</button> |
A screen reader says “Close”, not “times” |
| “Saved” shown only as a green dot | No text beside the dot | The word “Saved” is visible |
1. Ask for barriers, not a pass mark
Paste or attach the code and name the tasks that matter on the page, then ask:
Review this draft page for specific accessibility barriers in these tasks: [tasks].
Tie each finding to the markup, a visible element or keyboard behaviour. For each, give who it affects, a small specific fix and how to check it.
Separate what you can see in the code from what needs the running page. Do not give an overall pass or say the page is compliant.[tasks] is what people do there, such as “close the settings panel and save a change”.
Why this works: “is this accessible?” invites a verdict. Asking for evidence and a check for each finding gives you a list you can test, and the last line stops a short review turning into a certificate.
What you should see: a numbered list of findings, each quoting a bit of code or naming an element, with “needs the running page” against anything code can’t prove.
2. Do the keyboard check yourself
Code can show a missing label, but not whether a button works or where focus goes afterwards. Open the running page and, for each task:
- Press Tab until the control is focused. Can you see where focus is?
- Press Enter or Space. Does it do what it should?
- If it opened something, press Escape. Does it close, and does focus return to a sensible place?
- With a screen reader on (VoiceOver on a Mac, Narrator on Windows), does the control announce its purpose, such as “Close”, rather than a symbol?
Why this works: these four presses catch the barriers people meet most often, and you can do them without being an accessibility specialist. W3C’s Easy Checks cover more, as a first review rather than a full audit.
What you should see: a tick or a cross against each step, which tells you which AI findings were real.
3. Fix one issue at a time and check it again
Fix one issue at a time and check it on the running page before moving on. Ask for the change like this:
For issue [number], [control] causes this barrier: [barrier]. Make this change only: [fix]. Keep the page's content and other behaviour as they are.
Tell me how to recheck this control with the keyboard and what else nearby might be affected.[number] and [barrier] come from the review. [control] is the element, such as “the close button”. [fix] is the change, such as “add aria-label="Close"”.
Why this works: one fix at a time means one thing to recheck, and you’ll know which change broke something if it does.
What you should see: a small change to the code, and the same keyboard steps from step 2 now passing for that control.
Check the result
- Every finding points to specific code or a specific element.
- Anything that needs the running page is marked as such, and you’ve done that check.
- Each fix changed only the control it was about.
- Nothing in the final answer claims the page is fully accessible or compliant.
The usual failure: a general verdict instead of findings. “The page looks accessible overall; consider adding ARIA labels where appropriate” sounds thorough and names nothing. Spot it by looking for a quoted line of code or a named element in each sentence. If there isn’t one, ask again:
That answer doesn't name a specific barrier. List each problem you can see, quote the markup or name the element for each, and say what a keyboard or screen-reader user would experience. If the code isn't enough to tell, say what you'd need.Worked example: the unlabelled close button
Fictional example. A draft settings page for a fictional app, Draftspace, has a close button written as <button type="button">×</button> and a status that shows a green dot when changes are saved.
- The first review was a verdict. It said the page “looks accessible overall”. The repair prompt produced two findings, matching the example result: the close button’s name is the symbol ×, which a screen reader may read as “times”; and “Saved” is shown only by colour.
- The keyboard check confirmed one and added a detail. Tab reached the close button with a visible focus ring, and Enter closed the panel — but focus jumped to the top of the page, which the code review couldn’t have seen.
- One fix at a time. Adding
aria-label="Close"fixed the name; adding the visible word “Saved” beside the dot fixed the status. The focus jump is the next issue, and it’s a real one, not a pass.
Try it
Make AI’s review specific enough to act on
See what a screenshot leaves unknown. Add the markup, request a bounded repair, then check the actual change.
A useful finding names the element and the evidence. Code shows a missing name; only the running page shows what the keyboard does.
The example in text
- The fictional button source is <button type="button">×</button>. Its name comes from the symbol, rather than the action.
- The fictional status requirement says Saved. The original markup provides a green dot without that word.
- A screenshot, the markup and a keyboard check on the running page each show different problems.
Task kit for this job: Download (ZIP) · Reusable instructions
Go deeper
Keep each kind of check separate
Reading the code, looking at the page, the keyboard check, an automated tool like Lighthouse, and testing with disabled users each find different things. Write down which you did. “Code reviewed, keyboard checked, no screen-reader or user testing” is an honest status; “accessible” is not.
Charts and complex images
A chart whose data matters needs more than a decorative alt text: a sentence with the main point and the table behind it. See accessible AI charts.