Rules and ethics
How to audit AI content operations for UK accessibility law
A step by step audit for UK teams: test AI assisted content against WCAG 2.1 AA, repair link text, headings and alt text, and keep a dated evidence log.
What to take away
- Audit the output, not the toolheadings, link text, alt text, contrast, and sentence length are where AI drafts fail.
- UK public sector bodies must meet WCAG 2.1 AA and publish an accessibility statement under the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.
- Free tools such as WAVE, axe DevTools, and Lighthouse find part of the problem, and keyboard plus screen reader testing finds the rest.
- Repair repeat faults in the prompt and the brief, then log every failure with a date and an owner.
Set the standard before you test anything
Public sector bodies in England must publish an accessibility statement and meet WCAG 2.1 AA. The Government Digital Service monitors compliance, and the Equality and Human Rights Commission can act on equality law complaints.
Private companies sit outside those regulations. However, procurement questionnaires and public contracts increasingly ask for the same evidence, so the public standard is a sensible baseline for any UK team.
Two documents define the test. Use the GOV.UK accessibility requirements to confirm what your organisation must publish and review. Test the pages themselves against the WCAG 2.1 quick reference, which lists every success criterion at level A, AA, and AAA.
Where AI drafts usually fail
Repeated faults cluster in four places. This table maps each one to the criterion you are testing.
Four AI draft faults and repairs
Fault in draft
- Link text
- "read more"
- Headings
- H2 jumps to H4
- Alt text
- Repeats the caption
- Status colour
- Colour alone
WCAG criterion
- Link text
- 2.4.4 Link Purpose A
- Headings
- 1.3.1 Info and Relationships A
- Alt text
- 1.1.1 Non-text Content A
- Status colour
- 1.4.1 Use of Colour A
Repair
- Link text
- Name the destination
- Headings
- Rebuild outline in CMS
- Alt text
- Describe image's page role
- Status colour
- Add text label beside
| Fault in the draft | WCAG 2.1 criterion | Repair |
|---|---|---|
| Link text such as "read more" | 2.4.4 Link Purpose, level A | Rewrite so the link names its destination |
| Heading levels that jump from H2 to H4 | 1.3.1 Info and Relationships, level A | Rebuild the outline in the CMS |
| Alt text that repeats the caption | 1.1.1 Non-text Content, level A | Describe what the image does on the page |
| Status shown by colour alone | 1.4.1 Use of Colour, level A | Add a text label beside the colour |
Link text needs its own rule, because a screen reader can list every link on a page out of context. The rules for writing link text give you a pattern to copy into your prompt library.
Five-pass accessibility audit
- Pull 20 live AI-drafted pages
- Run WAVE and axe, export CSV
- Test by hand with Tab, NVDA, VoiceOver
- Grade prose, flag sentences over 25 words
- Log page, criterion, owner, repair date
Run the audit in five passes
- Pull a sample. Choose 20 live pages that began as AI drafts, including two landing pages, one news item, and one PDF.
- Run the automated tools. Test each URL with WAVE and axe DevTools, then export the results as CSV.
- Test by hand. Move through the highest traffic pages with the Tab key, then listen with NVDA on Windows or VoiceOver on macOS.
- Grade the prose. Read each draft aloud and flag every sentence over 25 words.
- Log the faults. Record the page, the criterion, the owner, and the repair date in one shared sheet.
Example: a green score that hides a link failure
An automated scan can pass a page while every link still reads "read more". A screen reader user then hears a list of links with no destination.
The repair is manual. Open the CMS, rewrite each link so it names the target, for example "apply for a parking permit". Then re-run axe DevTools on the same URL and keep the export as evidence.
Before any draft goes live, run the seven-point accessibility checklist as a publishing gate. It takes roughly ten minutes per page and catches the faults that automated scans miss.
Fix the pattern, not just the page
Every fault you repair by hand should become a rule in the prompt and the brief. Add heading order, link text, alt text, and sentence length to the AI brief template. Then add a publish gate so nothing goes live unchecked.
Track the failure log monthly. Remove prompt lines that catch nothing, and add a line for any fault that appears twice in a month.
Audited content is also easier to reuse. The AI content repurposing workflow turns one checked blog post into LinkedIn copy, regional press notes, and newsletter sections without breaking the rules you just set.
Common questions
Does an audit need a screen reader?
Yes, at least for a sample of templates. Automated tools cannot judge whether link text makes sense out of context, so listen with NVDA or VoiceOver.
How often should we re-audit?
Quarterly for templates and landing pages, plus a fresh check after any change to prompts, CMS templates, or the design system.
Who owns the fix?
The content lead owns the page and its accessibility statement. The accessibility lead owns the standard and signs off any exception.
What evidence should we keep?
The dated failure log, the tool exports, the accessibility statement review date, and the prompt version that produced the draft.
