WCAG 2.2 checklist for 2026: all 56 Level A and AA success criteria, 6 new 2.2 criteria, common failures, and guidance on working toward web accessibility.
WCAG 2.2 Checklist: Complete AA Guide for 2026
94.8% of websites still fail basic WCAG accessibility standards. That is not a statistic from a decade ago. That is from the WebAIM Million 2025 report, which tested 1 million home pages and found that only about 1 in 20 passes WCAG requirements at the automated-detection level.
Here is the thing: most of those failures are not obscure edge cases. Low contrast text, missing image alt text, and unlabelled form inputs. These are fixable problems. But you cannot fix what you have not identified.
This checklist covers every Level A and Level AA success criterion in WCAG 2.2, including all six new criteria introduced in the October 2023 update. Use it to assess your website, prioritise what to fix, and track progress toward WCAG 2.2 AA conformance.
What is WCAG 2.2?
WCAG 2.2, or Web Content Accessibility Guidelines version 2.2, is the current international standard for web accessibility published by the World Wide Web Consortium (W3C) in October 2023. It defines 86 testable success criteria organised around four core principles: Perceivable, Operable, Understandable, and Robust (POUR). Level AA conformance requires meeting 56 of those criteria and is the level referenced by most accessibility laws globally, including the ADA, the European Accessibility Act (EAA), and Section 508.
The four POUR principles work like this. If you want a deeper look at how they apply in practice, Clym's guide to the POUR principles walks through each one with examples.
Perceivable: users can perceive all information and interface components, regardless of which senses they rely on.
Operable: users can navigate and operate the interface, whether they use a keyboard, mouse, switch, or voice control.
Understandable: users can understand both the content and how the interface works.
Robust: content is reliable enough for assistive technologies to interpret correctly, now and as they evolve.
WCAG versions: 2.0, 2.1, and 2.2 explained
WCAG has evolved through three versions since 2008. Each version is backward compatible, meaning that meeting WCAG 2.2 automatically satisfies 2.1 and 2.0 as well.
WCAG 2.0 | WCAG 2.1 | WCAG 2.2 | |
|---|---|---|---|
Published | 2008 | 2018 | Oct 2023 |
Total AA criteria | 38 | 50 | 56 |
Mobile/touch focus | Limited | Improved | Further improved |
Cognitive accessibility | Basic | Some additions | Strongest to date |
Backward compatible | Yes | Yes (extends 2.0) | Yes (extends 2.1) |
Current W3C recommendation | No | No | Yes |
The W3C recommends targeting WCAG 2.2 for all new and updated content. WCAG 3.0 is in active development but is not expected to be finalised before 2027. For now, WCAG 2.2 Level AA is the benchmark to target.
If you are currently working on WCAG 2.1, the section on what changed in 2.2 gives you a focused list of exactly what to add.
The three conformance levels: A, AA, and AAA
Each WCAG success criterion is assigned to one of three levels. They build on each other: you need to meet the lower levels before the higher ones count.
Level A covers the most critical barriers. A website that fails Level A criteria is largely or entirely inaccessible to users who rely on screen readers, keyboard navigation, or other assistive technology. This is the minimum threshold. For a full breakdown of how these levels compare, see Clym's guide to WCAG levels A, AA, and AAA.
Level AA is the target for most organisations. It requires meeting all Level A criteria plus additional requirements around colour contrast, navigation, resizing, and error handling. This is the level referenced by most accessibility laws and procurement policies globally.
Level AAA is the highest level. Not all content can meet every AAA criterion, and the W3C does not recommend it as a universal requirement. Some organisations aim for individual AAA criteria where feasible.
This checklist focuses on Level A and Level AA together, which represents full WCAG 2.2 AA conformance.
Why WCAG 2.2 matters right now
Here is some context that makes this more than a technical exercise.
According to the WebAIM Million 2025 report, the average home page has 51 distinct accessibility errors. That is a 10.3% improvement year over year, but it still means the overwhelming majority of websites create real barriers for users with disabilities. The problem is getting harder: the average home page now contains 1,257 elements, a 61% increase over six years.
There are over 1.3 billion people worldwide living with some form of disability, according to the World Health Organization. That is roughly 16% of the global population. Many rely on assistive technology to use the web, and inaccessible websites effectively shut them out.
The legal pressure is growing too. The European Accessibility Act required businesses operating in the EU to meet WCAG 2.1 AA from June 2025. ADA-related web accessibility lawsuits in the United States number in the thousands annually. The UK's public sector bodies must now meet WCAG 2.2 AA specifically.
Beyond legal requirements, accessible websites tend to rank better in search engines, load faster, and convert at higher rates. Accessibility improvements often improve the experience for everyone, not just users with disabilities.
The data backs this up. Most WCAG failures are fixable without a site rebuild. The six most common issues together account for 96% of all detected accessibility errors, and all six are structural changes your development team can address systematically.
Want to see where your website currently stands? Clym's free accessibility scanner can identify common issues across your site and give you a starting point for your review.
WCAG 2.2 Level A checklist
Level A criteria are the minimum requirements. Any failure at Level A creates significant barriers for users with disabilities and should be treated as a high-priority fix. There are 32 Level A criteria in WCAG 2.2, including two new ones introduced in version 2.2.
Criterion | Principle | What it means |
|---|---|---|
1.1.1 Non-text content | Perceivable | Every image, button, and non-text element has descriptive alternative text. |
1.2.1 Audio-only / video-only | Perceivable | Prerecorded audio-only content has a text transcript. Prerecorded video-only content has a transcript or audio description. |
1.2.2 Captions (prerecorded) | Perceivable | Prerecorded video content includes synchronised captions. |
1.2.3 Audio description or media alternative | Perceivable | Prerecorded video has an audio description or a full text alternative. |
1.3.1 Info and relationships | Perceivable | Headings, lists, tables, and form labels use proper semantic HTML so structure is communicated to assistive technology. |
1.3.2 Meaningful sequence | Perceivable | Content reading order is logical and intuitive when styling is removed. |
1.3.3 Sensory characteristics | Perceivable | Instructions never rely solely on shape, colour, size, or sound to convey meaning. |
1.4.1 Use of colour | Perceivable | Colour is not the only way to distinguish information, indicate an action, or prompt a response. |
1.4.2 Audio control | Perceivable | Any audio that plays automatically for more than 3 seconds can be paused, stopped, or muted. |
2.1.1 Keyboard | Operable | All functionality is available via keyboard with no time-based path required. |
2.1.2 No keyboard trap | Operable | Keyboard focus can always be moved away from any component using standard keys. |
2.1.4 Character key shortcuts | Operable | Single-character keyboard shortcuts can be turned off, remapped, or only activated on focus. |
2.2.1 Timing adjustable | Operable | Users can turn off, adjust, or extend time limits, with exceptions for real-time events. |
2.2.2 Pause, stop, hide | Operable | Moving, blinking, or scrolling content lasting more than 5 seconds can be paused, stopped, or hidden. |
2.3.1 Three flashes or below threshold | Operable | Content does not flash more than 3 times per second, or stays below general and red flash thresholds. |
2.4.1 Bypass blocks | Operable | A skip navigation link lets users jump past repeated content directly to the main content. |
2.4.2 Page titled | Operable | Every page has a descriptive, unique title that identifies its topic or purpose. |
2.4.3 Focus order | Operable | When navigated sequentially, focus order preserves meaning and operability. |
2.4.4 Link purpose | Operable | Each link's purpose can be determined from the link text alone, or from link text plus programmatic context. |
2.5.1 Pointer gestures | Operable | Any multi-point or path-based gesture (e.g. pinch, swipe) has a single-pointer alternative. |
2.5.2 Pointer cancellation | Operable | Actions triggered by a single pointer are not completed on the down-event unless essential. |
2.5.3 Label in name | Operable | For components with visible labels, the accessible name contains the visible label text. |
2.5.4 Motion actuation | Operable | Functionality triggered by device or user motion can also be operated by UI components, and users can disable motion activation. |
3.1.1 Language of page | Understandable | The default human language of the page is identified in the HTML lang attribute. |
3.2.1 On focus | Understandable | Receiving keyboard focus does not automatically trigger a change of context. |
3.2.2 On input | Understandable | Changing a form control setting does not automatically change context unless the user is warned in advance. |
3.3.1 Error identification | Understandable | Input errors are identified in text, and the error is described to the user. |
3.3.2 Labels or instructions | Understandable | Labels or instructions are provided whenever user input is required. |
3.3.7 Redundant entry (NEW in 2.2) | Understandable | Information previously entered by the user is auto-populated or available to select, so they do not have to re-enter it. |
3.2.6 Consistent help (NEW in 2.2) | Understandable | Help mechanisms such as contact details or a chat link appear in the same relative position on every page. |
4.1.2 Name, role, value | Robust | All UI components have accessible names and roles, and states and properties are programmatically set. |
WCAG 2.2 Level AA checklist
Level AA criteria build on the Level A requirements above. Meeting all Level A and Level AA criteria together means your website conforms to WCAG 2.2 AA. There are 24 Level AA criteria in WCAG 2.2, including four new ones introduced in version 2.2.
Criterion | Principle | What it means |
|---|---|---|
1.2.4 Captions (live) | Perceivable | Live video content includes synchronised captions. |
1.2.5 Audio description (prerecorded) | Perceivable | All prerecorded video content includes audio descriptions. |
1.3.4 Orientation | Perceivable | Content is not restricted to a single display orientation (portrait or landscape) unless essential. |
1.3.5 Identify input purpose | Perceivable | Form fields collecting personal data use autocomplete attributes so browsers can assist users. |
1.4.3 Contrast (minimum) | Perceivable | Text and images of text have a contrast ratio of at least 4.5:1. Large text (18pt or 14pt bold) requires 3:1. |
1.4.4 Resize text | Perceivable | Text can be resized up to 200% without assistive technology and without loss of content or functionality. |
1.4.5 Images of text | Perceivable | Text is used rather than images of text, except for logos and essential visual presentations. |
1.4.10 Reflow | Perceivable | Content can be presented in a single column at a viewport width of 320 CSS pixels without horizontal scrolling. |
1.4.11 Non-text contrast | Perceivable | UI components (such as form inputs, focus indicators) and graphical objects meet a 3:1 contrast ratio. |
1.4.12 Text spacing | Perceivable | No loss of content when the user overrides line height, letter spacing, word spacing, and paragraph spacing. |
1.4.13 Content on hover or focus | Perceivable | Tooltip or additional content that appears on hover or focus can be dismissed, hovered over, and persists until dismissed. |
2.4.5 Multiple ways | Operable | There is more than one way to locate a page within a website (e.g. site search plus navigation). |
2.4.6 Headings and labels | Operable | Headings and labels are descriptive so users understand what each section contains. |
2.4.7 Focus visible | Operable | Any keyboard-operable interface has a visible keyboard focus indicator. |
2.4.11 Focus not obscured - minimum (NEW in 2.2) | Operable | When a component receives keyboard focus, at least part of it remains visible and is not covered by sticky headers, overlays, or other author-placed content. |
2.5.7 Dragging movements (NEW in 2.2) | Operable | Any action that uses dragging can also be completed with a single pointer without dragging. |
2.5.8 Target size - minimum (NEW in 2.2) | Operable | Pointer targets are at least 24x24 CSS pixels, or have adequate spacing around them. |
3.1.2 Language of parts | Understandable | The language of passages or phrases that differ from the page's default language is identified in the markup. |
3.2.3 Consistent navigation | Understandable | Navigation that repeats across pages appears in the same relative order on each page. |
3.2.4 Consistent identification | Understandable | Components with the same function are identified consistently throughout the website. |
3.3.3 Error suggestion | Understandable | When an input error is detected and suggestions for correction are known, the suggestion is provided in text. |
3.3.4 Error prevention (legal, financial, data) | Understandable | For pages with legal commitments or financial transactions, submissions can be reversed, reviewed, or confirmed. |
3.3.8 Accessible authentication - minimum (NEW in 2.2) | Understandable | Users are not required to solve a cognitive function test (e.g. transcribing characters) to log in, unless alternatives or assistance are provided. |
4.1.3 Status messages | Robust | Status messages (such as form submission confirmations or errors) are announced by assistive technology without keyboard focus being moved. |
What is new in WCAG 2.2?
WCAG 2.2 introduces nine new success criteria and removes one obsolete criterion (4.1.1 Parsing, which was made redundant by improvements in how modern browsers handle HTML). See the W3C's full list of what is new in WCAG 2.2 for the technical details. Six of the nine new criteria apply at Level A or AA and are relevant to most organisations.
The new criteria in 2.2 address gaps that accessibility practitioners had flagged for years: focused elements hidden behind cookie banners or sticky headers, authentication flows that locked out users with cognitive disabilities, and touch targets too small for users with motor impairments.
Criterion | Level | What it requires |
|---|---|---|
2.4.11 Focus not obscured - minimum | AA | Focused components must not be entirely hidden behind sticky content, modals, or cookie banners. |
2.4.12 Focus not obscured - enhanced | AAA | Focused components must be entirely visible, with no obstruction at all. |
2.4.13 Focus appearance | AAA | Custom focus indicators must meet minimum size and contrast requirements. |
2.5.7 Dragging movements | AA | Any drag-based interaction must have a single-pointer alternative (e.g. click-to-place). |
2.5.8 Target size - minimum | AA | Touch and pointer targets must be at least 24x24 CSS pixels. |
3.2.6 Consistent help | A | Contact links, chat widgets, and self-help options must appear consistently across pages. |
3.3.7 Redundant entry | A | Previously provided information should be pre-filled or selectable rather than re-entered. |
3.3.8 Accessible authentication - minimum | AA | Log-in must not depend solely on cognitive tests like CAPTCHA without alternatives. |
3.3.9 Accessible authentication - enhanced | AAA | Log-in must not require a cognitive test of any kind. |
WCAG 2.1 vs WCAG 2.2: what changed
If you are already working to WCAG 2.1 AA, you need to add the following to reach full WCAG 2.2 AA conformance:
Add at Level AA: 2.4.11 Focus not obscured (minimum), 2.5.7 Dragging movements, 2.5.8 Target size (minimum), 3.3.8 Accessible authentication (minimum).
Add at Level A: 3.2.6 Consistent help, 3.3.7 Redundant entry.
Remove from testing: 4.1.1 Parsing, which is now obsolete and no longer tested.
Everything else in WCAG 2.1 remains unchanged in 2.2. The most common practical impact of the update is ensuring that sticky headers and floating elements do not obscure focused components, and that login flows offer alternatives to image-based CAPTCHA.
Who needs to follow WCAG 2.2?
WCAG 2.2 AA is referenced in accessibility legislation across multiple regions. The specific requirements vary by country, sector, and organisation type.
United States: Section 508 requires federal agencies and federally funded organisations to meet WCAG 2.0 AA as a minimum. The ADA is widely interpreted to require WCAG 2.1 AA for commercial websites, particularly those serving the public. ADA Title II rules published in 2024 set explicit timelines for state and local government websites. Meeting WCAG 2.2 satisfies all of these.
European Union: The European Accessibility Act (EAA) required businesses offering products and services in the EU to meet WCAG 2.1 AA from June 2025. The EU Web Accessibility Directive has required public sector bodies to meet WCAG 2.1 AA since 2018.
United Kingdom: Public sector websites must meet WCAG 2.2 AA specifically, under the Public Sector Bodies Accessibility Regulations.
Canada: The Accessible Canada Act and Ontario's AODA reference WCAG 2.0 AA, with many organisations moving toward 2.1 and 2.2.
Australia: Government agencies and departments are expected to meet WCAG 2.1 AA under the Digital Service Standard.
If you serve users in multiple regions, targeting WCAG 2.2 AA covers you across all of these frameworks simultaneously. Because 2.2 is backward compatible with 2.1 and 2.0, meeting the current standard satisfies older legislative references automatically.
The most common WCAG 2.2 failures (and how to fix them)
The WebAIM Million 2025 report found that 96% of all detected accessibility errors come from just six issue types. Fix these first and you address the vast majority of failures on your site.
Issue | % of pages affected (2025) | Quick fix |
|---|---|---|
Low contrast text | 79.1% | Run your colour palette through a contrast checker. Adjust foreground or background until you hit 4.5:1 for body text, 3:1 for large text. |
Missing image alt text | 55.5% | Add descriptive alt attributes to all informative images. Use alt="" for purely decorative ones so screen readers skip them. |
Missing form input labels | 48.2% | Link a visible |
Empty links | 45.4% | Add descriptive text, an aria-label, or a title attribute to every link, especially icon-only links. |
Empty buttons | 29.6% | Add visible text or an aria-label to every button. Icon-only buttons must have an accessible name. |
Missing document language | 15.8% | Add lang="en" (or the correct language code) to the element. This enables screen readers to use the right pronunciation rules. |
None of these fixes require a site rebuild. They are structural changes that can be addressed systematically with the right testing tools and a focused remediation sprint.
How to use this WCAG 2.2 checklist
This checklist is a starting point for accessibility reviews, not a replacement for a professional audit. Here is a practical approach for working through it.
Start with Level A. Any failure at Level A creates critical barriers. Work through the table above and record pass, fail, or not applicable for each criterion.
Move to Level AA. Once Level A is complete, work through the AA criteria. Pay particular attention to colour contrast, reflow at 320px, and the four new WCAG 2.2 criteria.
Run automated tools first. Automated scanners catch around 30 to 40% of WCAG failures, including the six most common issues. They are a useful first pass but cannot cover all 56 criteria.
Test with keyboard and screen reader. Many criteria, especially in the Operable and Robust principles, can only be verified by navigating with a keyboard and a screen reader such as NVDA, JAWS, or VoiceOver.
Document your findings and produce an accessibility statement. Record which criteria pass and which require remediation. An accessibility statement communicates your conformance level to users and is a legal requirement in some jurisdictions.
How Clym supports your WCAG accessibility efforts
Working toward WCAG 2.2 AA involves both technical fixes and ongoing monitoring. Clym's accessibility tools are designed to support that process across the areas where most websites struggle.
The Clym Accessibility Widget adds user-controlled adjustments to any website, with six pre-configured profiles covering the most common accessibility needs, from visual impairments and cognitive challenges to motor disabilities. Users can adjust colour contrast, text size, spacing, and navigation preferences without requiring the underlying site to be rebuilt. This supports criteria including 1.4.3 (contrast minimum), 1.4.4 (resize text), and 1.4.12 (text spacing).
For teams identifying where to start, Clym's accessibility testing and audit tools scan your site for common WCAG failures and generate a prioritised report of issues to address. This is particularly useful if you are working toward a regulatory deadline, such as the European Accessibility Act's June 2025 requirement for businesses operating in the EU, or preparing for a formal audit.
If you are required to publish an accessibility statement, Clym's accessibility statement tool helps you generate and maintain the documentation needed to communicate your conformance level to users. An accessibility statement is a legal requirement under the EU Web Accessibility Directive and the UK Public Sector Bodies Regulations.
Clym is not a substitute for a full audit or legal advice, but it can significantly reduce the effort involved in working toward WCAG 2.2 AA and in demonstrating ongoing accessibility commitment.
Conclusion
94.8% of websites still fail basic accessibility standards. That number has barely moved in six years. But it also means the organisations that do prioritise accessibility have a real advantage in usability, in legal standing, and in the experience they deliver to every user.
This WCAG 2.2 checklist gives you a working reference for all 56 Level A and AA criteria. Start with Level A to catch the critical barriers, use automated tools to identify the most common failures quickly, and test with a keyboard and screen reader for the criteria that automation cannot cover. If you are upgrading from WCAG 2.1, the six new Level A and AA criteria are your immediate focus.
Most WCAG failures are not architectural problems. They are fixable structural issues, often addressed without a rebuild. The deadlines are real, the users are real, and the path forward is clearer than most teams expect.
Ready to see where your website stands? Run Clym's free accessibility scanner to identify the highest-priority issues across your site or book a demo to see how Clym's full accessibility tools can support your WCAG review and ongoing accessibility efforts.
Frequently asked questions
WCAG 2.2 adds nine new success criteria to WCAG 2.1 and removes one obsolete criterion (4.1.1 Parsing). The new criteria cover focus visibility, touch target sizes, drag interaction alternatives, accessible authentication, and consistent help mechanisms. Meeting WCAG 2.2 AA automatically satisfies WCAG 2.1 AA requirements.
WCAG 2.2 is directly required for UK public sector websites under the Public Sector Bodies Accessibility Regulations. Many other laws, including the EU EAA and the US ADA, reference earlier versions (2.0 or 2.1). Since WCAG 2.2 is backward compatible, meeting 2.2 also satisfies those older requirements. Specific obligations vary by country, sector, and organisation type.
WCAG Level AA is the middle conformance level in WCAG. To conform at Level AA, you must meet all 32 Level A criteria (the most critical accessibility requirements) plus all 24 Level AA criteria, covering contrast ratios, navigation consistency, text sizing, and error handling. Level AA is the level referenced by most accessibility laws and procurement standards globally.
To conform at WCAG 2.2 Level AA, you must meet 56 criteria in total: all 32 Level A criteria plus all 24 Level AA criteria. WCAG 2.2 includes 86 testable criteria overall, excluding the now-obsolete 4.1.1 Parsing criterion.
Level A covers the most severe barriers, such as missing alt text, keyboard traps, and seizure-inducing content. Failing any Level A criterion makes content largely unusable for people relying on assistive technology. Level AA adds requirements around contrast, resizing, navigation consistency, and error handling. Meeting both levels together constitutes full WCAG 2.2 AA conformance.
Yes. WCAG 2.1 and 2.2 both include criteria specifically for touch interaction, screen orientation, and pointer gestures. WCAG 2.2 adds explicit touch target size requirements (2.5.8: pointer targets must be at least 24x24 CSS pixels). While WCAG was developed for web content, most mobile accessibility frameworks also reference WCAG principles.
WCAG 3.0, also known as W3C Accessibility Guidelines 3.0, is in active development but is not yet a formal standard. It is expected to use a scoring model rather than pass/fail criteria and will have a fundamentally different structure to WCAG 2.x. It is not expected to be finalized before 2027. WCAG 2.2 AA is the current standard to target.
Compliance Content Manager | CPACC (IAAP)
Alex is a Compliance Content Manager at Clym, where he researches and writes about everything related to data privacy and web accessibility compliance for businesses, helping them stay informed on their compliance needs and spreading awareness about making the web safer and more inclusive. When he's not writing about compliance, Alex has his nose in a book or is hiking in the great outdoors.