
Rules and ethics
AI-drafted pages on UK public sector sites: seven draft checks, four WCAG 2.2 AA criteria and the statement
Seven draft checks for AI-written pages under the 2018 accessibility regulations, with WCAG 2.2 AA criteria 2.4.11, 2.5.7, 2.5.8 and 3.3.8, test tools and enforcers.
What to take away
- The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 apply to public sector websites and apps. An AI-drafted page is judged like any other page.
- Current GOV.UK guidance points teams to WCAG 2.2 AA.
- Seven checks at draft stage cost minutes and avoid rewriting live pages later.
- The accessibility statement must be kept up to date after content changes.
- GDS monitors compliance, and the Equality and Human Rights Commission enforces in England.
Which rules apply to AI-drafted pages
The regulations apply to a website or mobile application of a public sector body. They carve out public service broadcasters, non-governmental organisations that do not provide essential services, and schools or nurseries apart from essential online administrative functions. Check your own status before relying on an exemption.
The accessibility requirements guidance on GOV.UK tells teams to check how far a site or app meets WCAG 2.2 and where the problems are. The rule follows the published page, so the tool that drafted it makes no difference.
The Equality Act 2010 sits underneath. All UK service providers must make reasonable adjustments under that Act, or under the Disability Discrimination Act 1995 in Northern Ireland. That duty remains even when an exemption or a disproportionate burden claim applies.
The seven-point check for AI drafts
Run these on the draft before it reaches the CMS. Each point comes from GOV.UK accessibility guidance, so reviewers can cite one standard.
- Test the page against WCAG 2.2 AA, including the four criteria named below, and list the failures.
- Make every link say where it goes. Replace generic link text such as "here" or "more".
- Check headings are a true hierarchyheading 1 for the title, no skipped levels, no bold text standing in for a heading.
- Aim for around 25 words or fewer per sentence.
- Give every image or chart alt text that conveys its meaning.
- Run an automated checker such as Axe, WAVE or ARC Toolkit, then test by hand.
- Update the accessibility statement if the page changes what it says about gaps.
Steps 2 to 4 belong in a written AI content style guide, so every reviewer applies the same rule to every draft.
What each check tests
The table maps each check to the failure it catches and the evidence a reviewer should keep.
| Check | What it catches | Evidence to keep |
|---|---|---|
| WCAG 2.2 AA test | Failures against the standard | Test notes per page |
| Link text | Generic or vague link wording | List of links and destinations |
| Heading hierarchy | Skipped levels, fake headings | Heading outline of the page |
| Sentence length | Sentences over about 25 words | Reviewer sign-off |
| Alt text | Images with no text equivalent | Alt text list |
| Checker run | Faults a tool such as Axe, WAVE or ARC Toolkit can find | Checker report plus manual test notes |
| Accessibility statement | Gaps not disclosed | Dated statement version |
Four WCAG 2.2 AA criteria to name in check 1
A check that only says "meet WCAG 2.2 AA" gives a reviewer nothing to tick. These four AA success criteria give check 1 something concrete to test on a finished page.
Level
- 2.4.11 Focus Not Obscured (Minimum)
- AA
- 2.5.7 Dragging Movements
- AA
- 2.5.8 Target Size (Minimum)
- AA
- 3.3.8 Accessible Authentication (Minimum)
- AA
What it requires
- 2.4.11 Focus Not Obscured (Minimum)
- A component that receives keyboard focus is not entirely hidden by author-created content
- 2.5.7 Dragging Movements
- Anything done by dragging can also be done with a single pointer, unless dragging is essential
- 2.5.8 Target Size (Minimum)
- Pointer targets are at least 24 by 24 CSS pixels, subject to exceptions
- 3.3.8 Accessible Authentication (Minimum)
- No cognitive function test, such as remembering a password, unless an alternative exists
Sticky footers, sticky headers and non-modal dialogs are the usual content that overlaps a focused item. Test them with the keyboard. Link wording, heading order and sentence length come from GOV.UK writing guidance, so they belong in the style guide rather than in this table.
Links, headings and sentences
GOV.UK guidance on publishing accessible documents says link text must clearly describe where the link goes. The same page tells writers to use styles to build a hierarchy of headings. It also asks for sentences of around 25 words or fewer.
Models drift on all three. They write vague link text, add a heading level for visual effect and produce long sentences. Reject those faults at review rather than editing them out of a live page. The reason is practical: some screen reader users list links to find what they need quickly.
Alt text and the checker
Images and charts need alt text. The guidance asks the author to supply alt text for an image or chart to whoever converts or uploads a document. Ask an AI tool for a draft, then have a person confirm it matches the image.
Most office software ships a basic accessibility checker. Run it before upload and keep the report. For web pages, automated tools include Axe, WAVE and ARC Toolkit. Treat a pass as a first filter, because automated testing alone misses some issues. Test by hand as well, with a screen reader and the keyboard.
Who monitors, who enforces and what the statement says
The Government Digital Service monitors public sector bodies' compliance on behalf of the Minister for the Cabinet Office. The Equality and Human Rights Commission enforces the requirement in England, Scotland and Wales. The Equality Commission for Northern Ireland enforces it in Northern Ireland.
An accessibility statement must say whether the site or app is fully, partially or not compliant, and which parts fail and why. It must also say how to report problems, with a link to the website people can use if they are unhappy with the response.
Put the check in the workflow
A checklist applied once fixes one page. Put the same rules into your content brief template so writers and AI tools see them before drafting begins. State the sentence limit and the link wording you will accept.
Accessibility also overlaps with accuracy. A model that invents a fact may invent a link destination too, so run fact-checking for AI content in the same review. Keep sign-off with the publisher, as set out in the governance framework. A wider accessibility law audit tests the process, and the quality checklist covers wider controls.
Before you publish
- Page tested against WCAG 2.2 AA, including 2.4.11, 2.5.7, 2.5.8 and 3.3.8, and failures listed.
- Every link describes its destination.
- Headings form a hierarchy with no skipped levels.
- Images and charts have confirmed alt text.
- Automated checker run, manual test done and report saved.
- Accessibility statement reviewed and updated.
Common questions
Do the accessibility regulations cover AI-generated content?
Yes, if it sits on a public sector website or app. The rules apply to the published page, not to the tool behind it. Unless an exemption applies, the page must meet the standard.
Can we claim a disproportionate burden because AI output is hard to fix?
Only after a legal assessment. Lack of time or knowledge cannot be used in that assessment, and the claim must be stated in the accessibility statement.
Do private businesses have to follow the same regulations?
The 2018 regulations apply to public sector bodies. Every UK service provider still has the reasonable adjustments duty under the Equality Act 2010, or the 1995 Act in Northern Ireland.



