The Web Content Accessibility Guidelines (WCAG) 2.2 became a W3C Recommendation in October 2023, marking the latest evolution of the world's most widely adopted accessibility standard. Whether you are a developer, designer, product manager, or compliance officer, WCAG 2.2 is the benchmark your digital products will be measured against. This guide breaks down everything you need to know — from the foundational principles to the new success criteria and practical steps for conformance.
What WCAG Actually Is
WCAG is a set of technical guidelines published by the World Wide Web Consortium (W3C) through its Web Accessibility Initiative (WAI). The guidelines define how to make web content more accessible to people with disabilities, including those with visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. WCAG is not a law in itself, but it is referenced by nearly every accessibility law and regulation worldwide — including the Americans with Disabilities Act (ADA), Section 508, the European Accessibility Act (EAA), and EN 301 549.
WCAG 2.2 builds on WCAG 2.1, which itself built on WCAG 2.0. The guidelines are designed to be backward-compatible: if you meet WCAG 2.2, you also meet 2.1 and 2.0. One notable change in 2.2 is that Success Criterion 4.1.1 Parsing was removed, as modern browsers and assistive technologies no longer need it.
The Four Principles: POUR
Every WCAG success criterion maps to one of four foundational principles, collectively known as POUR:
- Perceivable: Information and user interface components must be presentable to users in ways they can perceive. This means providing text alternatives for images, captions for video, and ensuring content can be presented in different ways without losing meaning.
- Operable: User interface components and navigation must be operable. Users must be able to interact with all controls and navigation using a keyboard, have enough time to read and use content, and not encounter content that could cause seizures.
- Understandable: Information and the operation of the user interface must be understandable. Text must be readable, web pages must operate in predictable ways, and users must be helped to avoid and correct mistakes.
- Robust: Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies. This means using valid, semantic markup and ensuring compatibility with current and future tools.
What Changed in WCAG 2.2
WCAG 2.2 introduces nine new success criteria. Six of them are at Level A or AA, meaning they will be required for most organizations aiming for standard conformance. Here are the most impactful:
Focus Not Obscured (Minimum) — 2.4.11 (Level AA)
When a user interface component receives keyboard focus, it must not be entirely hidden by author-created content such as sticky headers, footers, or modal overlays. This criterion addresses a frustratingly common problem where keyboard users tab to a focused element only to find it hidden behind a fixed navigation bar or a cookie consent banner. At minimum, some part of the focused element must remain visible.
Focus Appearance — 2.4.13 (Level AAA)
This criterion defines minimum requirements for focus indicators: the focus indicator area must be at least as large as a 2 CSS pixel thick perimeter of the unfocused component, and the contrast between the focused and unfocused states must meet a 3:1 ratio. While this is Level AAA, many organizations are adopting it as a best practice because poor focus visibility is one of the most common barriers for keyboard users.
Dragging Movements — 2.5.7 (Level AA)
Any functionality that uses a dragging movement — such as drag-and-drop interfaces, sliders, or map panning — must also be operable with a single pointer without dragging. This is essential for users who cannot perform drag gestures due to motor impairments. For example, a sortable list that uses drag-and-drop must also provide up/down buttons or another single-click alternative.
Target Size (Minimum) — 2.5.8 (Level AA)
Interactive targets must be at least 24 by 24 CSS pixels, or there must be sufficient spacing between undersized targets so that users do not accidentally activate the wrong control. This criterion has several exceptions — inline links within text, user-agent-controlled targets, and cases where the size is essential to the information being conveyed are all exempt.
Consistent Help — 3.2.6 (Level A)
If a website provides help mechanisms — such as a contact phone number, email address, chat widget, or self-help FAQ link — those mechanisms must appear in the same relative order across pages. This helps users with cognitive disabilities reliably find help when they need it without having to re-learn each page.
Redundant Entry — 3.3.7 (Level A)
Information previously entered by or provided to the user that is required for the same process must either be auto-populated or available for the user to select. This prevents forcing users to re-enter the same data within a multi-step process, such as entering a shipping address and then being asked to type it again for billing. Exceptions exist for security re-entry and when previously entered data is no longer valid.
Conformance Levels: A, AA, and AAA
WCAG defines three conformance levels. Level A is the minimum — these are issues that will completely block some users if not addressed. Level AA is the standard most laws and regulations reference, and it includes all Level A criteria plus additional requirements. Level AAA is the highest level and represents the best possible accessibility, but it is not typically required by regulation because some criteria cannot reasonably be applied to all content.
For most organizations, Level AA conformance is the target. This means meeting all Level A and Level AA success criteria across your site. In WCAG 2.2, that is 55 success criteria (following the removal of 4.1.1 Parsing).
Getting Started: Practical Steps
- Run an automated scan: Tools like axe-core or Lighthouse can catch roughly 30 to 40 percent of WCAG issues instantly. This gives you a baseline and identifies low-hanging fruit.
- Test with a keyboard: Unplug your mouse and try to complete your core user flows using only Tab, Enter, Space, Escape, and arrow keys. Note where focus is lost, trapped, or invisible.
- Test with a screen reader: Use VoiceOver on macOS, NVDA on Windows, or TalkBack on Android. Listen to how your pages are announced and whether interactive elements are labeled correctly.
- Audit your top flows: Do not try to audit every page at once. Start with your most critical user journeys — onboarding, checkout, search, primary content consumption — and expand from there.
- Integrate into your workflow: Add accessibility checks to your CI pipeline, design review process, and QA checklist. Accessibility is much cheaper to address during development than after launch.
Why It Matters Beyond Compliance
Accessible software serves more people. Approximately 16 percent of the global population lives with some form of disability, and situational and temporary impairments — broken arms, bright sunlight, noisy environments — affect everyone. Building to WCAG 2.2 standards improves usability for all users, strengthens your SEO through better semantic markup, and reduces legal risk in an enforcement landscape that is tightening worldwide.
WCAG 2.2 is not the finish line. WCAG 3.0 is in development and will eventually introduce a new conformance model. But 2.2 is the standard that matters today, and the work you do to meet it will carry forward into whatever comes next.