WCAG 2.2 checklist work is the part of a website project that gets promised in the kick-off meeting and quietly dropped before launch. Everyone agrees accessibility matters. Nobody owns it, nobody schedules it, and it becomes a line item that gets traded away the week the deadline slips.
The result is visible at scale. WebAIM’s annual analysis of one million home pages has found automatically detectable accessibility failures on more than 94% of them in every year the study has run, and the top six failure types barely change: low-contrast text, missing image alternatives, empty links, unlabelled form inputs, empty buttons and a missing document language. These are not exotic edge cases. They are the first six rows of any WCAG 2.2 checklist.
What defeats most teams is not difficulty. It is that the Web Content Accessibility Guidelines are written as a technical standard for people building conformance tooling, not as a list of things you can check on a Tuesday afternoon. Eighty-six success criteria, three conformance levels, four abstract principles and a vocabulary that says “programmatically determined” when it means “the browser can read it”. Nobody wants to start.
This guide turns the standard into the list. It covers what a WCAG 2.2 checklist actually contains, the nine criteria that are new in version 2.2 and catch modern interfaces out, where UK and EU law now bites for private companies, how to test a site in a single day with free tools, what remediation genuinely costs in the UK, a ninety-day sequence that fixes the expensive problems first, and the mistakes that produce a green dashboard on a site nobody can use. Every figure in the charts is arithmetic on a number stated in the text, so you can substitute your own and rerun it.
If you want the surrounding context first, our older web accessibility for beginners piece is a gentler on-ramp, and the neurodiversity-first UX article covers the cognitive side that conformance testing barely touches.
Table of contents
- What a WCAG 2.2 Checklist Actually Covers
- Why a WCAG 2.2 Checklist Is Now a Legal and Commercial Requirement
- The Nine New Criteria That Make WCAG 2.2 Different
- The WCAG 2.2 Checklist: Perceivable
- The WCAG 2.2 Checklist: Operable
- The WCAG 2.2 Checklist: Understandable and Robust
- How to Run a WCAG 2.2 Checklist Audit in One Day
- What WCAG 2.2 Remediation Costs in the UK
- A 90-Day WCAG 2.2 Checklist Roadmap
- Where the WCAG 2.2 Checklist Overlaps With SEO
- Mistakes That Make a WCAG 2.2 Checklist Useless
- WCAG 2.2 Checklist: Frequently Asked Questions
- References
What a WCAG 2.2 Checklist Actually Covers
A WCAG 2.2 checklist is not one list. It is a set of testable statements — success criteria — organised under four principles and split across three conformance levels. Understanding that shape is what stops you testing the wrong things.
The four principles are the filing system, not the work
Content must be Perceivable, Operable, Understandable and Robust — POUR, if you like acronyms. The principles are how the criteria are filed, and they are useful for reasoning about a failure. They are not themselves testable. Nobody has ever fixed a bug called “not perceivable”.
The success criteria are the actual checklist items
Each criterion is a single pass-or-fail statement about the page. “Text has a contrast ratio of at least 4.5:1 against its background” is testable. “The site is inclusive” is not. WCAG 2.2 contains 86 of these statements, and every real WCAG 2.2 checklist is a subset of them.
Three levels, and only one of them is your target
Level A is the floor — content that is otherwise impossible to use. Level AA is the working standard that regulation, procurement and case law all point at. Level AAA contains criteria that cannot reasonably be met across a whole site, and the standard itself says so.
Level AA is 55 criteria, not 86
This is the single most useful number in the whole exercise. Of the 86 criteria in WCAG 2.2, 31 are Level A and 24 are Level AA. Meeting Level AA means meeting both, so your WCAG 2.2 checklist is 55 items long — not 86, and not the twelve things your automated scanner reported.
| Level | Criteria in WCAG 2.2 | Who this is for | Realistic verdict |
|---|---|---|---|
| A | 31 | Every site, without exception | Failing here means some people simply cannot use the page |
| AA | 24 (55 cumulative) | The legal and procurement standard | This is your target — achievable on any site with budget |
| AAA | 31 (86 cumulative) | Specialist services, specific content types | W3C states it cannot be met site-wide for all content |
Fifty-five items is a fortnight of focused work on a small site. Framed as “eighty-six criteria and a legal standard”, it is a project nobody starts.
Why a WCAG 2.2 Checklist Is Now a Legal and Commercial Requirement
For years, private UK companies treated accessibility as a public-sector obligation they had dodged. That reading was always wrong, and two regulatory changes have made it untenable.
The Equality Act 2010 has always applied to private businesses
Section 20 of the Equality Act 2010 requires service providers to make reasonable adjustments for disabled people. A website is a service. There is no size exemption, no e-commerce carve-out and no grace period, and the duty is anticipatory — you are expected to have made the adjustment before a disabled customer arrives, not after they complain.
Public sector regulations set the benchmark everyone else is measured against
The Public Sector Bodies Accessibility Regulations 2018 name WCAG Level AA explicitly and require a published accessibility statement. Private companies are not bound by them, but they establish what “reasonable” looks like in practice — and once a standard is named in regulation, it becomes the yardstick in every procurement questionnaire and every dispute.
The European Accessibility Act reaches UK companies selling into the EU
The European Accessibility Act has applied since 28 June 2025 to consumer-facing products and services placed on the EU market, including e-commerce, consumer banking, e-books, ticketing and transport. It is scoped by market, not by where the company is registered. A UK retailer shipping to Ireland or Germany is inside it, and its technical yardstick is WCAG Level AA.
Procurement now asks the question directly
Even where no regulation applies, the WCAG 2.2 checklist arrives through the back door. Enterprise and public-sector buyers ask for a conformance statement in the RFP. Universities, NHS trusts and local authorities ask as standard. “We have not assessed it” is a scored answer, and it scores badly against a competitor who attached a report.
The commercial case stands on its own
Roughly one in five UK adults reports a disability, and the population using the web is ageing faster than the design conventions serving it. Every barrier in a checkout is a conversion you already paid to acquire. A WCAG 2.2 checklist is a conversion-rate exercise that happens to also be a legal one.
The Nine New Criteria That Make WCAG 2.2 Different
WCAG 2.2 became a W3C Recommendation on 5 October 2023. It added nine success criteria to WCAG 2.1 and removed one — 4.1.1 Parsing, which modern browsers made obsolete. If your last audit predates October 2023, these nine are the gap in your coverage.
Two of the nine are Level A, four are Level AA
Only six of the nine new criteria affect a Level AA target: 3.2.6 Consistent Help and 3.3.7 Redundant Entry at Level A, plus 2.4.11 Focus Not Obscured, 2.5.7 Dragging Movements, 2.5.8 Target Size and 3.3.8 Accessible Authentication at Level AA. The other three are AAA and can wait.
They target patterns that did not exist when WCAG 2.0 was written
Sticky headers that hide the focused element. Drag-and-drop reordering with no button alternative. Tap targets sized for a mouse. Cognitive-function tests in login flows that block password managers. Every one of these is a 2020s design convention, and every one of them is now a documented failure.
Accessible Authentication is the one that surprises teams
3.3.8 says a login must not require a cognitive function test — remembering, transcribing or solving a puzzle — unless an alternative exists. Blocking paste into a password field fails it. So does a puzzle CAPTCHA with no non-cognitive route through. This is the criterion most likely to fail on an otherwise well-built site.
| Criterion | Name | Level | What it means on a real site |
|---|---|---|---|
| 2.4.11 | Focus Not Obscured (Minimum) | AA | Sticky headers and cookie bars must not completely hide the focused element |
| 2.4.12 | Focus Not Obscured (Enhanced) | AAA | No part of the focused element may be hidden |
| 2.4.13 | Focus Appearance | AAA | Minimum size and contrast for the focus indicator itself |
| 2.5.7 | Dragging Movements | AA | Anything draggable needs a single-pointer alternative |
| 2.5.8 | Target Size (Minimum) | AA | Interactive targets at least 24×24 CSS pixels, with defined exceptions |
| 3.2.6 | Consistent Help | A | Help links sit in the same relative place on every page |
| 3.3.7 | Redundant Entry | A | Do not ask for the same information twice in one process |
| 3.3.8 | Accessible Authentication (Minimum) | AA | No cognitive function test in login without an alternative |
| 3.3.9 | Accessible Authentication (Enhanced) | AAA | No object-recognition test either |
Six new items on a 55-item list is a manageable delta. It is also the delta most agencies have not yet absorbed, which is why “we built it to WCAG” deserves the follow-up question “which version”.
The WCAG 2.2 Checklist: Perceivable
Perceivable covers everything a person has to be able to sense before they can act. It is the largest slice of any WCAG 2.2 checklist and the one automated tools handle best.
Text alternatives for every non-text element
Every image, icon and chart needs an alternative that conveys its purpose. Decorative images take an empty alt="" so screen readers skip them. The common failure is not missing alt text — it is alt text that describes the file rather than the meaning, which is how you get “chart.png” read aloud in place of the number the chart exists to communicate.
Captions and transcripts for time-based media
Pre-recorded video needs captions and an audio description or a full text alternative. Pre-recorded audio needs a transcript. Auto-generated captions are a starting point, not a pass — the standard requires accuracy, and machine captions reliably mangle names, products and numbers.
Structure that survives being read aloud
Headings must nest in order, lists must be marked up as lists, and tables need real header cells. A screen reader user navigates by heading the way a sighted user skims. A page of visually-styled div elements with no heading structure is a page with no navigation at all.
Colour contrast at 4.5:1 for body text
Normal text needs 4.5:1 against its background; large text (18pt, or 14pt bold) needs 3:1. Interface components and meaningful graphics need 3:1 under 1.4.11. Low contrast is the single most common failure in the WebAIM data, and it is almost always a brand-palette decision made without a contrast checker open.
Never use colour alone to carry meaning
A red field border that is the only signal of a validation error fails. Add an icon, a message, or both. This one costs almost nothing to fix and is missed constantly.
Reflow to 320 pixels and 200% text zoom
At 400% zoom on a 1280px viewport — equivalent to a 320px-wide window — content must reflow without two-dimensional scrolling. Text must remain readable and functional at 200% zoom. Fixed-height containers and absolutely-positioned overlays are the usual culprits, and both fail on real phones as well as in the test.
The WCAG 2.2 Checklist: Operable
Operable is where the WCAG 2.2 checklist gets expensive, because these failures usually live in JavaScript rather than CSS.
Everything works from the keyboard
Every control must be reachable and usable with Tab, Shift+Tab, Enter, Space and the arrow keys, and there must be no keyboard trap. Custom dropdowns, modals, carousels and date pickers are where this breaks. The test costs nothing: unplug the mouse and try to complete your primary conversion.
The focus indicator must be visible and unobscured
2.4.7 requires a visible focus indicator; 2.4.11, new in 2.2, requires that a sticky header, cookie banner or chat widget does not completely hide the focused element. A CSS reset containing outline: none with no replacement is the most common single line of code that fails a WCAG 2.2 checklist.
Skip links and meaningful page titles
A “skip to main content” link lets keyboard users bypass forty navigation items on every page. Each page needs a unique, descriptive <title>. Both are ten-minute fixes that materially change the experience for anyone navigating linearly.
Link text that means something out of context
Screen reader users pull up a list of links and read it in isolation. Twelve links reading “read more” is twelve identical rows. Write the destination into the link text.
Enough time, and no unexpected motion
Session timeouts need warning and extension. Carousels and animations need a pause control. Nothing may flash more than three times per second. Respect prefers-reduced-motion — it is not a WCAG requirement in itself, but it is the cheapest way to satisfy the criteria around motion.
Target size of at least 24×24 CSS pixels
2.5.8 is new and it catches dense interfaces: icon-only buttons, table row actions, close buttons and pagination controls. There are exceptions for inline links and for targets with sufficient spacing, but the safe engineering answer is to make the tap area 24px even when the icon is smaller.
A single-pointer alternative to every drag
2.5.7 requires that anything achieved by dragging can also be achieved with a simple tap or click. Kanban boards, sortable lists, range sliders and map interfaces all need a non-drag route — buttons, a numeric input, a menu.
The WCAG 2.2 Checklist: Understandable and Robust
The last two principles are the shortest sections of the WCAG 2.2 checklist and the ones most often skipped entirely, because nothing in an automated report points at them.
Declare the page language
A single lang="en-GB" on the <html> element tells a screen reader which pronunciation rules to use. Without it, English text may be read with the wrong phonetics. Any passage in a different language needs its own lang attribute.
Predictable navigation and consistent help
Navigation must appear in the same relative order on every page, and components that do the same thing must be labelled the same way. 3.2.6, new in 2.2, extends this to help mechanisms — if your contact link sits in the footer on one page, it cannot move to the header on the next.
Labels, instructions and error handling that work
Every input needs a programmatically associated <label> — placeholder text is not a label and disappears the moment someone types. Errors must be identified in text, not just colour, and the fix must be described. Where a mistake is legally or financially significant, it must be reversible, checkable or confirmable.
Do not ask for the same thing twice
3.3.7 Redundant Entry says information already provided in a process must be auto-populated or available to select. Re-typing a delivery address as a billing address is the canonical failure, and it is a conversion problem as much as an accessibility one.
Name, role and value for every custom component
Robust is a single practical rule: if you build a custom component, assistive technology must be able to determine what it is, what state it is in, and what it does. Use native HTML elements wherever possible. The first rule of ARIA is not to use ARIA — a <button> is more robust than a div with six ARIA attributes bolted on.
Status messages announced without stealing focus
Cart updates, form validation summaries and search result counts need an appropriate live region so they are announced without moving focus. A confirmation that only appears visually is invisible to a screen reader user, who is left wondering whether the click registered at all.
How to Run a WCAG 2.2 Checklist Audit in One Day
You do not need a specialist to find the majority of your problems. A structured day with free tools will surface most of what a first-round WCAG 2.2 checklist audit would report.
Hour one: choose the pages, not the site
Audit templates, not URLs. Home, a category page, a product or service detail page, the checkout or enquiry form, a content page, search results, login, and the accessibility statement itself. Eight page types cover most of a normal site’s patterns, and fixing a template fixes every page built from it.
Hour two: run the automated pass
Run axe DevTools, WAVE and the Lighthouse accessibility audit across the eight templates. Expect contrast, alt text, labels and landmark issues. Treat the output as a starting list, not a verdict — automation catches roughly a third of the criteria in a WCAG 2.2 checklist and is blind to the rest.
Hour three: the keyboard-only pass
Unplug the mouse. Tab through each template and complete the primary task. Watch for invisible focus, focus hidden behind sticky elements, traps in modals, and controls you cannot reach at all. This single hour typically finds more real barriers than the whole automated pass.
Hour four: zoom and reflow
Set the browser to 400% zoom, then narrow the window to 320 CSS pixels. Look for horizontal scrolling, clipped text, overlapping elements and controls that disappear. Then set text spacing per 1.4.12 and check nothing is cut off.
Hour five: a screen reader pass on two journeys
Use NVDA on Windows or VoiceOver on macOS. You do not need fluency — read the home page top to bottom and complete one form. You are listening for unlabelled controls, meaningless link text, images announced as filenames, and errors that are never announced.
Hours six to eight: record, classify, cost
Write each finding as the criterion number, the template, the failure and the fix. Classify by severity — blocks a task, degrades a task, or is an irritation — and by effort. That sheet is your WCAG 2.2 checklist backlog, and it is what turns an audit into a plan.
| Method | Roughly what it covers | Cost | What only this method catches |
|---|---|---|---|
| Automated scan | About a third of criteria | Free to low | Contrast ratios, missing alt and labels, at volume |
| Keyboard pass | Most Operable criteria | Free, one hour | Focus traps, unreachable controls, hidden focus |
| Zoom and reflow | Adaptation criteria | Free, one hour | Clipping, overlap, lost controls at 320px |
| Screen reader pass | Robust and Understandable | Free, two hours | Meaningless announcements, silent state changes |
| Testing with disabled users | Real-world usability | £800–£2,500 | Technically conformant patterns that are still unusable |
What WCAG 2.2 Remediation Costs in the UK
Accessibility budgets fail because nobody separates the audit from the fix. These are realistic UK bands for a business website of roughly forty templates.
The in-house day: £0
The eight-hour routine above costs nothing but a developer’s day and finds the majority of first-round issues. Every business website should do this before spending anything, if only to size the problem honestly.
A specialist audit: £2,500–£6,000
An independent WCAG 2.2 checklist audit against all 55 Level AA criteria, with a written report, severity ratings and remediation guidance. Expect £2,500 for a small brochure site and £6,000 for a transactional one. This is what a procurement questionnaire actually wants attached.
The quick-win remediation sprint: £1,500–£4,000
Contrast, alt text, form labels, focus indicators, page language, skip links and link text. Usually two to five days of front-end work, and typically clears more than half the reported findings.
The structural sprint: £4,000–£14,000
Rebuilding custom components as accessible ones — dropdowns, modals, date pickers, carousels, data tables — plus the checkout or enquiry flow. This is where the money goes, and it is proportional to how much bespoke JavaScript the site carries.
Ongoing assurance: £350–£900 per month
Automated monitoring, a manual review each quarter, accessibility acceptance criteria in the definition of done, and a maintained accessibility statement. Without this, a remediated site drifts back within two release cycles.
The full route — audit, quick wins and structural work — lands between £8,000 and £24,000 for a mid-sized site. Set against a single discrimination claim, a lost enterprise tender or a checkout that quietly rejects a share of its traffic, that is not an expensive number.
A 90-Day WCAG 2.2 Checklist Roadmap
Sequence matters more than speed. Fixing templates before you have measured them means fixing the wrong templates.
Days 1–14: measure and publish
Run the eight-hour audit, build the findings sheet, and publish an honest accessibility statement naming the known gaps and a fix date. A candid statement is a defence; an aspirational one that claims conformance you do not have is the opposite.
Days 15–30: clear the quick wins
Contrast, alt text, labels, focus indicators, page language, skip links, link text and heading order. These are cheap, they are template-level, and clearing them makes the remaining backlog legible instead of overwhelming.
Days 31–60: fix the primary journey
Take the one journey that generates revenue — checkout, enquiry, booking, application — and make it pass every relevant item on your WCAG 2.2 checklist end to end. Keyboard, screen reader, 320px reflow, error handling, no redundant entry. One flawless journey beats eighty half-fixed pages.
Days 61–80: the structural components
Rebuild the custom components the audit flagged, in order of how many templates use them. A properly built modal or dropdown fixes the same failure everywhere it appears, which is why component work outperforms page work.
Days 81–90: verify, then defend the position
Re-audit the eight templates, update the accessibility statement with real dates, and add accessibility acceptance criteria to your definition of done. Put an automated scan in the deployment pipeline so a regression fails the build rather than surfacing in next year’s audit.
Where the WCAG 2.2 Checklist Overlaps With SEO
Accessibility and search visibility are not the same discipline, but a surprising amount of a WCAG 2.2 checklist is work a technical SEO audit would ask for anyway.
Semantic structure serves both audiences
Heading hierarchy, landmark regions, descriptive link text and real alt attributes are how a screen reader builds a mental model of the page — and how a crawler builds its understanding of what the page is about. Our technical SEO audit checklist and a WCAG 2.2 checklist share a meaningful number of line items.
Performance work and accessibility work overlap
Reflow, text zoom and reduced motion all push in the same direction as Core Web Vitals optimisation — less layout shift, fewer render-blocking dependencies, simpler DOM. The same restraint improves both scores.
Answer engines read what screen readers read
Generative and answer-engine surfaces extract from structure — headings, lists, tables, captions — for the same reason assistive technology does. Well-marked-up content is more extractable, which is the ground our AEO services and SXO services work covers.
Neither replaces the other
An accessible page is not automatically a ranking page, and a page that ranks may be unusable with a keyboard. Do not let an SEO agency claim your WCAG 2.2 checklist as covered, and do not assume conformance work will move rankings on its own.
Mistakes That Make a WCAG 2.2 Checklist Useless
These are the failures that produce a green dashboard on a site that a real user cannot operate.
Trusting an overlay widget
Accessibility overlays — the injected toolbar promising instant compliance — do not deliver conformance, and prominent disability advocacy groups have campaigned against them for years. They cannot fix semantics, keyboard order or component behaviour, because those live in your markup. They can, however, actively interfere with the assistive technology the user has already configured.
Treating the automated score as the finish line
A perfect Lighthouse accessibility score is compatible with a completely unusable site. Automation cannot judge whether alt text is meaningful, whether focus order is logical or whether an error message explains anything. Roughly two-thirds of a WCAG 2.2 checklist requires a human.
Auditing pages instead of components
Fixing forty pages one by one guarantees the forty-first regresses. Fix the header, the form field, the modal and the card — the things every page is assembled from — and the fix propagates.
Publishing an accessibility statement that is not true
An aspirational statement claiming full Level AA conformance you have not tested is worse than none. Name the standard, name the known gaps, name the fix dates and give people a route to report a problem.
Letting it regress after launch
Accessibility is a state a site passes through, not a state it stays in. Without acceptance criteria in the definition of done and a scan in the pipeline, the next redesign resets you to where you started. Building it into how the team ships is the only durable answer, and it is one of the things our software development practice builds into delivery by default.
Starting with AAA
Teams occasionally decide to be ambitious and target Level AAA. They stall on criteria the W3C itself says cannot be satisfied for all content, and the Level AA work that mattered never gets done. Hit 55 first.
WCAG 2.2 Checklist: Frequently Asked Questions
How many criteria are in a Level AA WCAG 2.2 checklist?
Fifty-five. Level AA conformance requires meeting all 31 Level A criteria plus all 24 Level AA criteria. The remaining 31 criteria in WCAG 2.2 are Level AAA and are not part of the standard target.
Does WCAG 2.2 replace WCAG 2.1?
It supersedes it as the current recommendation, and it is backwards compatible — meeting WCAG 2.2 Level AA means you also meet WCAG 2.1 Level AA. Some regulations still name 2.1 explicitly, so confirm which version a specific contract requires.
Is a private UK business legally required to meet WCAG 2.2?
No statute names WCAG for private companies, but the Equality Act 2010 requires reasonable adjustments, and WCAG Level AA is the standard courts, regulators and buyers use to judge what is reasonable. If you sell to EU consumers, the European Accessibility Act applies directly.
How long does it take to fix a typical business website?
Ninety days is realistic for a site of around forty templates using the roadmap above. Quick wins land in the first month; custom component work is the long pole.
Can an accessibility overlay make my site conformant?
No. Overlays cannot repair markup semantics, keyboard interaction or component state, and they frequently conflict with the assistive technology a user already runs. Fix the underlying code.
What should a WCAG 2.2 checklist audit report contain?
Findings mapped to individual success criterion numbers, the templates affected, severity, a described fix and an effort estimate. A report that gives you a score without a criterion-level breakdown is not actionable.
References
The WebAIM Million Annual Accessibility Report
WebAIM Contrast and Colour Accessibility
GOV.UK Service Manual: Understanding WCAG
Accessibility Requirements for Public Sector Websites and Apps
Public Sector Bodies Accessibility Regulations 2018
Deque axe Accessibility Testing Tools
