Using AI for accessibility checks.

Goal

Use AI for a fast first-pass accessibility review, with each issue mapped to a WCAG 2.2 success criterion and a list of what still needs manual testing.

Who it is for

Website owners, marketers, content editors and developers in New Zealand organisations, including suppliers to government.

Time

30 minutes.

You need

ChatGPT, Claude, Copilot or Gemini and the fictional page code below. Later, a page from your own site.

You will produce

An issue list with success criteria, fixes and confidence, plus a manual test list.

What standard should you check against?

Check against WCAG 2.2 Level AA. The W3C’s Web Content Accessibility Guidelines 2.2 is the current recommendation, and New Zealand’s Web Accessibility Standard 1.2 requires that every web page of a covered agency “must conform to the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA”, subject to listed exceptions. It took effect on 17 March 2025, replaced version 1.1, and applies to both publicly facing and internally facing pages of public service departments and non-public service departments in the Executive branch.

WCAG 2.2 added criteria such as 2.4.11 Focus Not Obscured (Minimum), 2.5.8 Target Size (Minimum) and 3.3.8 Accessible Authentication (Minimum) at Level AA, and 3.2.6 Consistent Help and 3.3.7 Redundant Entry at Level A.

What can AI check, and what can it not?

AI reads code and text well. It cannot use your site the way a person does.

Where does AI fit in an accessibility process?

AI is one layer of three. An automated checker gives broad coverage of code-level problems across many pages. AI explains what those findings mean in plain English, drafts fixes, writes alt text options and simplifies dense copy. People do the rest: keyboard and screen reader testing, judging whether the page makes sense, and, wherever possible, testing with disabled users.

Keep one issue log for all three, with the success criterion, the fix, who fixed it and when it was re-tested. That log, not the AI conversation, is your evidence.

Exercise: review a booking page

The clinic and page below are fictional, and the code contains deliberate problems.

Illustrative page code. Fictional physiotherapy clinic, Whangārei.

<h1>Book an appointment</h1>
<img src="team-photo.jpg">
<img src="map.png" alt="map.png">
<h4>Opening hours</h4>
<!-- hours text below is grey #999999 on a white background -->
<p class="hours">Mon to Fri 7am to 6pm. Sat 8am to 12pm.</p>
<p>Fields in red are required.</p>
<input type="text" placeholder="Full name">
<input type="text" placeholder="Phone">
<select><option>Choose a physio</option></select>
<button>Go</button>
<p class="error">Invalid input</p>
<a href="/forms/intake.pdf">Click here</a> for the intake form.
<a href="https://video.example/welcome">Watch our welcome video</a>

1. Run the review prompt in the worked example below with the page code.
2. Check the criteria numbers. Open WCAG 2.2 and confirm two of the success criteria the tool cited actually say what it claims.
3. Verify the contrast claim. Put #999999 on white into a contrast checker. It should come out at about 2.85:1, below the 4.5:1 that 1.4.3 requires for normal text.
4. Draft the fixes. Ask for corrected HTML for the form, and alt text options for the two images, then choose the alt text yourself.
5. List the manual tests. Keyboard order, visible focus, screen reader announcement of errors, zoom to 200%, and the video’s captions.
6. Repeat on a real page from your own site, pasting the page source or the visible text.

Worked example: the review prompt

Review the HTML below for accessibility against WCAG 2.2 Level AA.
For each issue give: element, success criterion (number and name),
why it fails, a specific fix, and your confidence (high / medium /
low). Then list what cannot be assessed from code alone and must
be tested manually. Do not invent issues you cannot see in the
code. If unsure whether something fails, say so.

[paste HTML]

Example output (illustrative and abridged; your tool’s wording will differ):

img team-photo.jpg | 1.1.1 Non-text Content | no alt attribute |
add alt describing the team, or alt="" if decorative | high

img map.png | 1.1.1 Non-text Content | alt is a file name | describe
the location and include the street address in text | high

inputs | 1.3.1 Info and Relationships; 3.3.2 Labels or Instructions
| placeholder is not a label | add visible <label> elements | high

"Fields in red are required" | 1.4.1 (use of colour) | colour is
the only cue | mark required fields in text, e.g. "(required)" | high

hours text #999999 | 1.4.3 Contrast (Minimum) | about 2.85:1 on white
| use #767676 or darker (about 4.54:1) | high

"Click here" | 2.4.4 Link Purpose (In Context) | link text gives no
purpose | "Download the intake form (PDF)" | high

Cannot assess from code: keyboard order, focus visibility, how
the error is announced, video captions.

Every finding names a criterion, which makes it checkable. That matters more than the length of the list.

Where this goes wrong

• AI audit treated as compliance. A clean AI review does not mean a page conforms. Only testing against each criterion, including manual tests, can show that.
• Invented failures. Models sometimes cite the wrong criterion or flag problems that are not there. Check each against the WCAG text.
• Alt text without purpose. “A photo of people smiling” rarely helps. Write what the image means on that page; images are covered more broadly in working with images in business AI.
• Contrast from screenshots. Compression changes colours; use exact values.
• Fixing once. New content brings new problems. Add the review prompt to your AI prompt library and run it on every new page.

Check your work

• Every issue on my list cites a WCAG 2.2 success criterion I have read.
• I verified at least one contrast result with exact colour values.
• I chose the final alt text for each image based on its purpose.
• My manual test list covers keyboard, focus, screen reader, zoom and captions.
• I know whether the Web Accessibility Standard 1.2 applies to my organisation or my clients.

Where to go next

Next in the pathway: planning human review for AI output, which turns checks like this into a routine. Plain, unambiguous English also helps translation, as covered in evaluating translation quality with AI. Developers can turn the review into structured issue lists using structured outputs and validation. To run checks on every new page automatically, see AI workflow automation. MOGGED, Levy Street’s AI-native digital agency, builds websites for New Zealand businesses.

Written by the Levy Street team in Wellington. Last updated 19 October 2026.