WCAG 2.2 became the definitive web accessibility standard on October 5, 2023 — and as of 2026, it's the baseline that accessibility laws around the world actually reference. The European Accessibility Act, EN 301 549, and updated Section 508 guidance all point to WCAG 2.2 Level AA. If you're still auditing against WCAG 2.1, you're working from an outdated checklist. This guide gives you a practical, actionable checklist for every criterion — with specific pass/fail tests you can run without specialized tools. We've organized the 9 new success criteria separately so you can see exactly what changed from 2.1 to 2.2, and what you actually need to fix.
What Is WCAG 2.2 and Why Does It Matter in 2026
WCAG 2.2 (Web Content Accessibility Guidelines 2.2) is the current international standard for web accessibility, published by the W3C Web Accessibility Initiative. It contains 87 success criteria organized around four principles: Perceivable, Operable, Understandable, and Robust — the POUR framework.
Here's why WCAG 2.2 matters right now in 2026: virtually every major accessibility regulation now references it explicitly. The European Accessibility Act (EAA) mandates WCAG 2.2 Level AA for all digital products sold in the EU. EN 301 549 v4.1.1 — the technical standard behind EAA compliance — is aligned to WCAG 2.2. In the US, the DOJ has published guidance clarifying that ADA compliance for websites requires WCAG 2.2 AA. UK PSBAR similarly references the EN 301 549 standard.
WCAG 2.2 introduced 9 new success criteria targeting three groups that WCAG 2.1 underserved: users with low vision, users with cognitive and learning disabilities, and mobile users with motor impairments. It also removed one obsolete criterion: 4.1.1 Parsing, which was made redundant by modern browser error correction.
The checklist below covers all 87 criteria. For each of the 9 new WCAG 2.2 criteria, you'll find detailed implementation guidance. For the 78 carried over from 2.1 (minus Parsing), we provide a concise pass/fail test — the kind you can run during a manual audit in about 90 minutes on a representative page sample.
The 9 New WCAG 2.2 Success Criteria (Complete Breakdown)
These are the criteria that separate WCAG 2.2 from 2.1. If you've already audited against WCAG 2.1 AA, focus your effort here first.
2.4.11 Focus Not Obscured (Minimum) — Level AA
What it requires: When a keyboard-focusable component receives focus, it must be at least partially visible. It cannot be entirely hidden behind sticky headers, cookie banners, chat widgets, or other fixed-position overlays.
How to test: Tab through your entire page with a keyboard. Pay attention to any focused element that disappears behind a sticky nav bar or a bottom chat bubble. Even partial visibility counts as passing — but zero visibility fails.
Common failures: Sticky headers that cover focused form fields; GDPR consent banners that overlap the first interactive element on page load; floating chat widgets that obscure footer links.
2.4.12 Focus Not Obscured (Enhanced) — Level AAA
What it requires: The focused component must be fully visible — no part of it obscured. This is the AAA version of 2.4.11 and only required if you target AAA compliance.
2.4.13 Focus Appearance — Level AAA
Focus indicators must have a minimum area (perimeter of the focus indicator squared) and sufficient contrast ratio (3:1 minimum between focused/unfocused states). AAA only — but still worth implementing for Level AA sites that want strong UX.
2.5.7 Dragging Movements — Level AA
What it requires: Any functionality that requires dragging must also be achievable through a single pointer action (click, tap) — unless the dragging is essential to the function.
How to test: Identify all drag-and-drop interactions on your site (sliders, reorderable lists, map panning, carousels). For each one, verify there is an alternative: arrow buttons, input fields, single-click alternatives.
Common failures: Kanban boards or to-do list reordering with no keyboard/click alternative; range sliders with no direct value input; map widgets with no +/- zoom buttons.
2.5.8 Target Size (Minimum) — Level AA
What it requires: Interactive targets (buttons, links, form controls) must be at least 24x24 CSS pixels, measured as the bounding box of the target including any spacing around it. There are important exceptions: inline text links, targets where size is controlled by the browser, and targets that have equivalent alternatives elsewhere.
How to test: Open DevTools and inspect your smallest interactive elements. Measure the clickable/tappable area including padding. A 16px icon button with 4px padding on each side has a 24x24 target — that passes. An icon button with no padding at 16x16 fails.
Common failures: Icon-only buttons without padding; social share buttons; close (×) buttons on modals; table row action icons.
3.2.6 Consistent Help — Level A
What it requires: If your site provides any help mechanisms (live chat, phone number, email link, FAQ link, chatbot), they must appear in the same relative location across all pages. You don't need to add help — but if it exists, it must be consistently placed.
How to test: Navigate between 5 different pages. If a chat widget or help phone number appears in the footer or top navigation on the home page, check that it appears in the same location on the checkout page, the contact page, and the product pages.
3.3.7 Redundant Entry — Level A
What it requires: Users should not be asked to re-enter information they've already provided within the same session — unless re-entry is essential (for security confirmation like email re-entry on sign-up) or the information is no longer valid.
How to test: Walk through your checkout or multi-step registration flow. If you ask for a billing address and then ask for it again on a separate screen, you fail. Auto-fill, copy-forward, or selecting from previously entered data all pass.
3.3.8 Accessible Authentication (Minimum) — Level AA
What it requires: Login processes must not require users to solve cognitive tests (like remembering a password unaided, solving a puzzle, or transcribing distorted text) unless an alternative authentication method is available. Passwords managers must not be blocked.
How to test: Check if your login form allows paste into password fields (blocking paste is a common failure). Check if CAPTCHA is used — if it is, verify there's an audio alternative or another authentication path. Check that autocomplete is not suppressed on password fields.
Common failures: autocomplete="off" on password fields; JavaScript that blocks paste; image-only CAPTCHAs with no audio alternative; security questions that require recall without hints.
3.3.9 Accessible Authentication (Enhanced) — Level AAA
Removes the exception for copy-paste and password managers being sufficient. Requires that no cognitive function test is needed at any authentication step. AAA only.
WCAG 2.2 Full Checklist: Level A Criteria (Pass/Fail Tests)
Level A is the minimum threshold — failures here create complete barriers for users with disabilities. No Level A failures are acceptable in a conformant site.
1.1 Text Alternatives
1.1.1 Non-text Content (A) — All non-decorative images, icons, buttons, charts, and form inputs have descriptive alt text or labels. Decorative images use alt="". Test: Disable images in your browser and verify every meaningful visual still has a text equivalent.
1.2 Time-based Media
1.2.1 Audio-only / Video-only (A) — Pre-recorded audio has a transcript; pre-recorded video has either audio description or a text alternative.
1.2.2 Captions (Pre-recorded) (A) — All pre-recorded video with audio has synchronized captions.
1.2.3 Audio Description or Media Alternative (A) — Pre-recorded video has audio description or a full text alternative (Level AA requires audio description by default via 1.2.5).
1.3 Adaptable
1.3.1 Info and Relationships (A) — Structure, relationships, and meaning conveyed visually are also programmatically determinable. Tables have headers; form fields have associated labels; lists use real list markup.
1.3.2 Meaningful Sequence (A) — Reading order in the DOM matches the visual reading order.
1.3.3 Sensory Characteristics (A) — Instructions don't rely solely on shape, color, size, or position (e.g., "click the green button" fails; "click the Submit button" passes).
1.4 Distinguishable
1.4.1 Use of Color (A) — Color alone is not used to convey information (e.g., error fields need more than a red border — they need an error icon or text).
1.4.2 Audio Control (A) — Audio that plays automatically for more than 3 seconds can be paused, stopped, or its volume reduced independently of the system volume.
2.1 Keyboard Accessible
2.1.1 Keyboard (A) — All functionality is available via keyboard without requiring specific timing for keystrokes. Test: Navigate your entire site using only Tab, Shift+Tab, Enter, Space, and arrow keys.
2.1.2 No Keyboard Trap (A) — Keyboard focus is never trapped — users can always tab out of any component. Test: Tab into every modal, widget, and embedded iframe.
2.1.4 Character Key Shortcuts (A) — If single-character keyboard shortcuts exist, they can be turned off, remapped, or are only active on focus.
2.2 Enough Time
2.2.1 Timing Adjustable (A) — If time limits exist, users can turn them off, adjust them, or extend them.
2.2.2 Pause, Stop, Hide (A) — Moving, blinking, or scrolling content that starts automatically can be paused.
2.3 Seizures and Physical Reactions
2.3.1 Three Flashes or Below Threshold (A) — Nothing flashes more than 3 times per second (or is below the safe threshold).
2.4 Navigable
2.4.1 Bypass Blocks (A) — A mechanism to skip repeated content (like a nav) is provided. Typically a "Skip to main content" link as the first focusable element.
2.4.2 Page Titled (A) — Every page has a unique, descriptive <title> tag.
2.4.3 Focus Order (A) — Keyboard focus order is logical and follows the reading order.
2.4.4 Link Purpose (In Context) (A) — Each link's purpose is clear from its text alone or from surrounding context. "Click here" and "Read more" links fail without context.
2.5 Input Modalities
2.5.1 Pointer Gestures (A) — Functions requiring multi-point or path-based gestures (pinch-to-zoom, swipe) also work with a single pointer.
2.5.2 Pointer Cancellation (A) — Single-pointer actions can be cancelled (using mouseup/pointerup, not mousedown/touchstart triggers for actions).
2.5.3 Label in Name (A) — For interactive elements with visible text labels, the accessible name includes the visible text.
2.5.4 Motion Actuation (A) — Device motion-triggered functionality (shake to undo, tilt to scroll) can also be operated without device motion, and can be disabled.
2.5.6 Concurrent Input Mechanisms (A) — The page doesn't restrict use of input methods (keyboard, mouse, touch, stylus) based on what was last used.
3.2.6 Consistent Help (A) — NEW in WCAG 2.2. See detailed guidance above.
3.3.7 Redundant Entry (A) — NEW in WCAG 2.2. See detailed guidance above.
2.6–3.3 (Remaining Level A)
3.1.1 Language of Page (A) — The lang attribute on <html> correctly identifies the page language.
3.2.1 On Focus (A) — Focusing an element doesn't trigger a context change.
3.2.2 On Input (A) — Changing a form input doesn't automatically trigger a context change without prior warning.
3.3.1 Error Identification (A) — Errors are identified in text and described to the user.
3.3.2 Labels or Instructions (A) — All form fields have labels or instructions.
4.1.2 Name, Role, Value (A) — All interactive UI components have programmatic names, roles, and states available to assistive technology (screen readers).
4.1.3 Status Messages (A) — Status messages ("Item added to cart", "Form saved") are programmatically determinable without receiving focus — typically via ARIA live regions.
WCAG 2.2 Full Checklist: Level AA Criteria (Pass/Fail Tests)
Level AA is the legal compliance target for virtually all global accessibility regulations in 2026. Your site needs to pass both Level A and Level AA criteria.
1.2 Time-based Media (AA)
1.2.4 Captions (Live) (AA) — Live audio has real-time captions.
1.2.5 Audio Description (Pre-recorded) (AA) — All pre-recorded video with visual-only information has audio descriptions.
1.3 Adaptable (AA)
1.3.4 Orientation (AA) — Content doesn't lock to portrait or landscape orientation unless essential. Test: Rotate your mobile device and verify the page reflows.
1.3.5 Identify Input Purpose (AA) — Form fields that collect personal data use appropriate autocomplete attributes (name, email, tel, street-address, etc.).
1.4 Distinguishable (AA)
1.4.3 Contrast (Minimum) (AA) — Text has at least 4.5:1 contrast ratio against its background (3:1 for large text — 18pt or 14pt bold). Test with a color contrast checker tool.
1.4.4 Resize Text (AA) — Text can be resized to 200% without loss of content or functionality. Test: In browser settings, increase text size to 200% and check for horizontal overflow or truncated content.
1.4.5 Images of Text (AA) — Actual text is used instead of images of text wherever possible.
1.4.10 Reflow (AA) — Content reflows at 320px viewport width (equivalent to 400% zoom on a 1280px screen) without horizontal scrolling or loss of functionality. This is crucial for mobile and zoom users.
1.4.11 Non-text Contrast (AA) — UI components (form borders, focus indicators, icons) and informational graphics have at least 3:1 contrast against adjacent colors.
1.4.12 Text Spacing (AA) — No loss of content or functionality when the following are applied: line height 1.5×; paragraph spacing 2×; letter spacing 0.12em; word spacing 0.16em.
1.4.13 Content on Hover or Focus (AA) — Tooltip/popup content triggered by hover or focus is dismissible, hoverable (pointer can move to it without it disappearing), and persistent (stays until dismissed or focus moves).
2.4 Navigable (AA)
2.4.5 Multiple Ways (AA) — Multiple ways exist to find any page (search, navigation, sitemap) — except pages that are steps in a process.
2.4.6 Headings and Labels (AA) — Headings and labels are descriptive. "Section 1" fails; "WCAG 2.2 New Success Criteria" passes.
2.4.7 Focus Visible (AA) — Any keyboard-operable interface has a visible focus indicator. Test: Tab through the page and verify focus is always visually obvious.
2.4.11 Focus Not Obscured (Minimum) (AA) — NEW in WCAG 2.2. See detailed guidance above.
2.5 Input Modalities (AA)
2.5.7 Dragging Movements (AA) — NEW in WCAG 2.2. See detailed guidance above.
2.5.8 Target Size (Minimum) (AA) — NEW in WCAG 2.2. See detailed guidance above.
3.1 Readable (AA)
3.1.2 Language of Parts (AA) — Phrases or passages in a different language than the page have the correct lang attribute.
3.2 Predictable (AA)
3.2.3 Consistent Navigation (AA) — Navigation that repeats across pages appears in the same relative order each time.
3.2.4 Consistent Identification (AA) — Components with the same function across pages are identified consistently (same label, same icon).
3.3 Input Assistance (AA)
3.3.3 Error Suggestion (AA) — When an input error is detected and suggestions are known, the suggestion is provided to the user.
3.3.4 Error Prevention (Legal, Financial, Data) (AA) — For pages with legal/financial consequences or data deletion, submissions are reversible, verifiable, or confirmable.
3.3.8 Accessible Authentication (Minimum) (AA) — NEW in WCAG 2.2. See detailed guidance above.
4.1 Compatible (AA)
No additional AA criteria beyond Level A for this principle — but with 4.1.1 Parsing removed in WCAG 2.2, the full focus is on 4.1.2 Name, Role, Value and 4.1.3 Status Messages.
What Was Removed: The 4.1.1 Parsing Criterion
WCAG 2.2 removed criterion 4.1.1 Parsing, which required HTML to be free of start/end tag errors, duplicate attributes, and improperly nested elements. This might seem surprising, but the reasoning is sound: modern browsers handle malformed HTML gracefully and consistently, and assistive technologies now rely on the browser's accessibility tree rather than parsing raw HTML directly.
If you have old audit reports that flag 4.1.1 Parsing failures (duplicate IDs, unclosed tags, etc.), those are no longer WCAG violations under 2.2. However, duplicate IDs still cause practical accessibility problems when used as targets for aria-labelledby or aria-describedby, so fixing them remains good practice.
The net result: WCAG 2.2 has 87 success criteria (78 from 2.1 minus Parsing, plus 9 new). When you see articles claiming "86 criteria" or "88 criteria," they're using outdated or incorrect counts.
How to Prioritize Your WCAG 2.2 Audit
A full WCAG 2.2 audit against all 87 criteria takes significant time. Here's how to prioritize for maximum impact:
Start with automated detection. Run your site through an automated scanner first. Good automated tools catch 30-57% of WCAG violations reliably — mainly contrast failures, missing alt text, missing form labels, and invalid ARIA. Our free accessibility scanner covers WCAG 2.2 Level AA automated checks across your full URL set and gives you a prioritized issues list.
Layer manual keyboard testing. Tab through your most important user journeys: home page, product/service page, checkout/contact form, login. This catches focus traps, focus obscured (2.4.11), and keyboard navigation failures that automated tools miss entirely. Expect 30-45 minutes per journey for a thorough manual test.
Then run screen reader testing. Use NVDA + Firefox (Windows) or VoiceOver + Safari (macOS/iOS) on your core user journeys. This surfaces name/role/value failures, live region issues, and reading order problems. Our accessibility audit checklist includes a full screen reader testing protocol.
For the 9 new WCAG 2.2 criteria specifically: Focus Not Obscured (2.4.11) and Target Size (2.5.8) are the most common failures on sites that were already WCAG 2.1 compliant. Accessible Authentication (3.3.8) catches many e-commerce sites blocking password paste. Dragging Movements (2.5.7) is relevant if you have any drag-and-drop UI.
WCAG 2.2 by Law: Which Regulations Require It in 2026
Understanding which laws reference WCAG 2.2 directly affects how you communicate compliance to stakeholders. Here's the current landscape:
European Accessibility Act (EAA) — EU, deadline June 28, 2025. Applies to companies offering products or services in the EU with more than 10 employees or €2M+ annual turnover. Technically references EN 301 549, which aligns to WCAG 2.2 Level AA. Fines range from €10,000 to €250,000 per violation depending on country. Our detailed EAA fines guide breaks this down by jurisdiction.
ADA (Americans with Disabilities Act) — US. While ADA doesn't specify a technical standard in the statute, DOJ settlements and court cases consistently use WCAG 2.1 AA as the benchmark. Updated DOJ guidance from 2024 references WCAG 2.2. Non-compliance carries civil penalties and litigation risk — over 4,600 web accessibility lawsuits were filed in the US in 2023.
Section 508 — US Federal Agencies. Federal agencies and contractors must comply with Section 508, which incorporates WCAG 2.0 Level AA by reference. The Access Board is reviewing alignment to WCAG 2.2. For federal contractors, see our Section 508 compliance guide.
UK Equality Act / PSBAR. Public Sector Bodies Accessibility Regulations reference EN 301 549, which in turn references WCAG 2.2. UK private sector accessibility obligations under the Equality Act remain litigation-driven.
Canada (ACA / AODA / AER). The Accessible Canada Act and provincial regulations like AODA (Ontario) reference WCAG 2.0 or 2.1 in current technical standards, but WCAG 2.2 is the practical target for new development.
How to Document WCAG 2.2 Conformance
Conformance to WCAG 2.2 is all-or-nothing per level: to claim Level AA conformance, you must pass all Level A AND Level AA criteria across your entire website. In practice, most organizations aim for "substantial conformance" — passing the large majority of criteria with documented known exceptions.
Accessibility Statement. EU law (EAA), UK PSBAR, and several other regulations require a published accessibility statement. This document identifies your conformance level, lists known exceptions, provides contact information for reporting barriers, and references your last audit date. Our accessibility statement template gives you a ready-to-use structure.
VPAT / ACR (Accessibility Conformance Report). For enterprise software and government procurement, a Voluntary Product Accessibility Template (VPAT) documents WCAG 2.2 conformance criterion by criterion. US federal procurement often requires a VPAT as part of the vendor selection process.
Ongoing monitoring. A one-time audit is not sufficient for claiming conformance — websites change constantly. Set up automated monitoring on your key pages so new content doesn't introduce regressions. Our monitoring service runs weekly automated WCAG 2.2 AA checks across your full URL set and alerts you to new failures before they compound.
Audit trail. Keep records of your audits: who performed them, what methodology was used (automated + manual + screen reader), which pages were tested, and what remediation was done. This documentation is critical if you face a complaint or legal challenge.
Quick Reference: WCAG 2.2 Priority Fix List
Based on real audit data from thousands of websites, these are the most common WCAG 2.2 failures in 2026. Fix these first for fastest compliance improvement:
1. Color contrast failures (1.4.3, 1.4.11) — The most common issue on virtually every site. Gray text on white backgrounds, low-contrast placeholder text, and icon-only buttons without sufficient contrast against their backgrounds. Our audit guide shows you how to use automated tools to catch all contrast failures across your full page set in one pass.
2. Missing or inadequate alt text (1.1.1) — Images with no alt attribute, images with alt text that just describes the file name ("image001.jpg"), and informational icons with no accessible name.
3. Form labels missing (1.3.1, 3.3.1, 3.3.2) — Placeholder text used instead of a real <label> element; inputs without any accessible name.
4. Focus obscured (2.4.11) — NEW in WCAG 2.2. Sticky headers covering focused elements when users tab through forms or navigation. Often a one-line CSS fix: scroll-padding-top: [header-height].
5. Keyboard navigation failures (2.1.1) — Interactive elements that can only be operated with a mouse (custom dropdowns, date pickers, media players). Test by tabbing through your entire checkout or signup flow.
6. Target size failures (2.5.8) — NEW in WCAG 2.2. Small icon buttons without sufficient padding. Adding padding: 4px to a 16×16 icon creates a 24×24 target that passes.
7. Password paste blocked (3.3.8) — NEW in WCAG 2.2. Many sites block paste on password fields using JavaScript. Remove this restriction — it's both an accessibility failure and damages UX for all users.
8. Missing skip link (2.4.1) — Add <a href="#main" class="skip-link">Skip to main content</a> as the first element in your HTML body. Visually hidden by default, visible on focus.
Run a free scan on your site to get a personalized priority list specific to your pages: web-accessibility-checker.com.
Related Resources
To go deeper on specific topics covered in this WCAG 2.2 checklist:
- Best Accessibility Checker Tools in 2026 — Compare automated tools that help you audit WCAG 2.2 compliance at scale
- Accessibility Audit Checklist — A step-by-step manual audit protocol for WCAG 2.2
- ADA Compliance Website Guide — US-specific compliance requirements and WCAG 2.2 alignment
- Web Accessibility Audit Guide — How to structure a professional WCAG 2.2 audit from scratch
- ARIA Labels Best Practices — Correctly implementing accessible names for complex UI components
- EAA Fines and Penalties by Country — Financial consequences of WCAG 2.2 non-compliance across EU member states
- WCAG 3.0 Preparation Guide — What comes after WCAG 2.2 and how to future-proof your accessibility program