WCAG 2.2 Accessibility Audit Checklist Template

The answers on the first task decide whether the document task in Phase 5 and the EU, UK and Title II tasks in Phase 7 appear.

• Record the scope, the audit target and the laws that apply — name the site or app, set WCAG 2.2 AA as the target, and note any law that names 2.1 or 2.0
• Carry forward open issues from the last audit — and the known failures listed in the current accessibility statement
• Explore the site and list its templates and components — page types, shared navigation, forms and dialogs, and the journeys users come to complete
• Select a structured and a random sample — every template, each complete process end to end, plus random pages as a cross-check
• Fix the browser and assistive technology pairs — for example NVDA with Firefox or Chrome, VoiceOver with Safari on macOS and iOS, TalkBack with Chrome on Android

Automated rules cover only part of WCAG. A clean scan is where manual testing starts, not a result.

• Run an automated scan across the sample — include a wider crawl, drop false positives and group repeats caused by one shared component
• Check page titles, page language and heading structure — descriptive titles (2.4.2), a declared language (3.1.1), headings that match the content (1.3.1)
• Measure colour contrast in every state — 4.5:1 for text, 3:1 for large text (1.4.3); 3:1 for control borders, focus indicators and icons (1.4.11)
• Review images and their text alternatives — alternatives serve the same purpose (1.1.1); decorative images are hidden from screen readers

• Complete every sampled journey by keyboard alone — all functions operable (2.1.1), no keyboard traps (2.1.2), a logical focus order (2.4.3) and visible focus (2.4.7)
• Test skip links, menus, dialogs and custom widgets — bypass blocks (2.4.1), focus into and out of dialogs, name, role and state exposed (4.1.2)
• Run each journey with a screen reader — headings, landmarks, link purpose (2.4.4), and labels and instructions announced (3.3.2)
• Check error handling and status messages — errors described in text (3.3.1) with a suggested fix (3.3.3); status messages announced (4.1.3)
• Zoom to 400% and resize text to 200% — content reflows at 320 CSS pixels without two-way scrolling (1.4.10) and nothing is lost (1.4.4)
• Apply text-spacing overrides and rotate the device — no clipped text (1.4.12), and no lock to portrait or landscape (1.3.4)

Six of the nine new criteria are Level A or AA. The other three (2.4.12, 2.4.13 and 3.3.9) are AAA and sit outside an AA audit.

• Check that sticky content never hides the focused element (2.4.11) — cookie banners, sticky headers and chat launchers must not cover it entirely
• Find every drag interaction (2.5.7) — sliders, sortable lists and maps need a single-pointer alternative
• Measure small pointer targets (2.5.8) — at least 24 by 24 CSS pixels or enough spacing; links inside a sentence are exempt
• Confirm help appears in a consistent place (3.2.6) — contact details, chat or help links in the same relative order on every page
• Walk multi-step forms for redundant entry (3.3.7) — details already given are filled in or selectable, unless re-entry is essential or for security
• Test sign-in and verification steps (3.3.8) — paste and password managers allowed; a test such as solving a puzzle needs an alternative or help

The document task appears only when PDFs or other documents are in scope.

• Test the in-scope PDFs and office documents — tags, reading order, headings, text alternatives, form fields and document language
• Check prerecorded video and audio — captions (1.2.2), audio description for video (1.2.5), and a transcript for audio-only content (1.2.1)
• Check live and moving content — captions for live audio (1.2.4), and a way to pause, stop or hide moving or auto-updating content (2.2.2)
• Review third-party components — booking, payment, chat and map widgets; ask suppliers for a conformance report and test what you can
• Record each exception the law allows — such as archived pages or third-party content you do not control, citing the provision

When the first task records at least one failure, the three remediation and retest tasks appear.

• Log each failure against its success criterion — page, component, steps to reproduce, who is affected and a suggested fix
• Rate every finding by its effect on users — a blocker that stops a task outranks many minor failures on a rarely used page
• Fix shared components first — one fix to a template or component clears the failure on every page using it
• Agree an owner and a target date for each finding — and document any disproportionate burden assessment with the reasoning behind it
• Retest each fix the way it was found — same page, browser, assistive technology and steps; close only on a pass
• Write the audit report — scope, sample, method, tools, result per criterion and date: the evidence behind the statement

The EU, UK and Title II tasks appear only when the matching scope answer on the first task is Yes. The approver named in Phase 1 signs off the statement.

• Update the accessibility statement — conformance status, known failures and alternatives, the audit date and a way to report problems
• Publish the EAA service information (Annex V) — in the terms and conditions or equivalent, explaining how the service meets the requirements
• Follow the UK model accessibility statement — with the contact form and enforcement procedure link that regulation 8 requires, kept under regular review
• Record the Title II compliance date and any exceptions relied on — 26 April 2027 or 2028 by population and entity type; WCAG 2.1 AA is the legal benchmark
• Approve and publish the statement — the named approver signs off and the publication date is recorded
• Add accessibility checks to the release process — scans and keyboard checks on changed templates, and a quarterly check of key journeys