If your team is comparing WCAG 2.1 vs 2.2, the most important thing to know is that WCAG 2.2 does not replace the foundation of WCAG 2.1. It builds on it. That means teams that already worked toward WCAG 2.1 are not starting over, but they do need to review several new requirements that affect common user journeys such as logging in, completing forms, using mobile interfaces, and navigating with a keyboard.
For compliance, product, design, and engineering teams, the update matters because the new criteria focus on real interaction barriers that often appear in modern websites and apps. Many of them are especially relevant for people with cognitive disabilities, low vision, limited dexterity, or users who rely on keyboard navigation rather than a mouse or touch gestures.
In this guide, we will break down the difference between WCAG 2.1 and 2.2, explain the 9 new success criteria in plain language, and show practical examples of what to review.
WCAG 2.2 is an incremental update to WCAG 2.1. The core structure remains the same: the same four principles, the same levels of conformance, and the same broad goal of making digital experiences more accessible.
The main difference is that WCAG 2.2 adds nine new success criteria. These additions strengthen accessibility expectations in areas that are easy to overlook in fast-moving product environments, especially when teams depend heavily on visual design patterns, custom components, or mobile-first interactions.
In practical terms, WCAG 2.2 asks teams to pay closer attention to:
So when people ask, “What is the difference between WCAG 2.1 and 2.2?” the short answer is this: WCAG 2.2 expands coverage for common usability barriers that directly affect accessibility.
Below is a practical overview of each new criterion and what it means in real-world digital experiences.
When a user tabs through a page, the focused element must not be completely hidden by other content.
Example: A sticky header stays fixed at the top of the screen. As a keyboard user tabs through form fields near the top of the page, the currently focused field scrolls under the header and disappears from view. The user knows focus moved, but cannot see where it is.
What to review:
This criterion is especially relevant on responsive layouts where overlays and fixed-position elements can unintentionally cover focused controls.
This builds on the previous criterion. Instead of allowing the focused element to remain at least partially visible, the enhanced version expects it to be fully visible.
Example: A keyboard user tabs to a button inside a scrollable container. Only the bottom edge of the button is visible, making it difficult to identify what is selected.
What to review: Custom modals, internal scroll regions, settings drawers, and embedded interfaces where focus management is handled with JavaScript.
Keyboard focus indicators must be visible enough to identify the selected component clearly.
Example: A site uses a very faint light-gray outline for focused links and buttons. On a white background, many users will struggle to detect it. Technically there is a focus style, but in practice it is too weak to be useful.
What to review:
This is one of the most important additions in WCAG 2.2 because teams often remove or soften browser defaults without replacing them with a strong, consistent alternative.
Any function that requires dragging should also be operable with a simple pointer interaction, unless dragging is essential.
Example: A user must drag a map pin to select a location, reorder a task card by dragging, or move a slider handle to choose a value. If there is no tap, click, or keyboard alternative, some users may be blocked.
What to review:
For many teams, this criterion affects product features more than marketing pages.
Interactive targets should meet a minimum size so users can activate them more reliably.
Example: A mobile interface places several tiny icon buttons close together in a toolbar. Users with motor limitations, tremors, or those using a device one-handed may activate the wrong control repeatedly.
What to review:
This criterion is especially relevant for responsive design and touch-heavy workflows.
If a page or process includes help mechanisms, those help options should appear in a consistent location across a set of pages.
Example: During checkout or onboarding, live chat appears on one step, a help link moves to the footer on another, and contact support is missing entirely on a third step. Users who need assistance may lose time trying to find help again.
What to review:
Consistency matters here as much as availability.
Users should not be required to enter the same information again in the same process unless it is essential, required for security, or previously entered information is no longer valid.
Example: A user enters their billing address in step one of a multi-step form, then must type it again in a later step even though the system already has it.
What to review:
This criterion can reduce friction for all users, but it is particularly helpful for people with cognitive disabilities, memory limitations, or fatigue.
Authentication steps should not rely on cognitive function tests unless an accessible alternative is provided.
Example: A login flow asks the user to solve a puzzle, remember a sequence of characters, or transcribe text from a distorted image without offering another accessible method.
What to review:
This is one of the most discussed WCAG 2.2 additions because authentication is often a major accessibility barrier.
The enhanced version goes further by reducing reliance on recognition, recall, or transcription tasks during authentication.
Example: A user receives a code and must manually copy it from one screen to another, or must identify specific images from a visual challenge. Even if technically possible, the process may still create unnecessary barriers.
What to review: Passwordless options, magic links, passkeys, autofill support, password managers, and alternative verification methods that reduce cognitive load.
From a compliance perspective, WCAG 2.2 is not just a checklist update. It reflects a broader expectation that accessible experiences should work in realistic conditions, not only in ideal test scenarios.
That matters because many accessibility issues now appear in dynamic interfaces rather than static pages. Teams are working with sticky UI, modal-heavy workflows, mobile gestures, embedded tools, and custom design systems. The new criteria are closely tied to those patterns.
For compliance, privacy, and digital teams, WCAG 2.2 introduces three important implications:
Teams that already perform periodic audits may also benefit from continuous monitoring and workflow-based testing, especially for high-risk pages and transaction paths. For a forward-looking view of how automation can support accessibility operations, see AI Agents Are Here: How Autonomous AI Will Quietly Take Over Your Accessibility To-Do List.
Review component libraries for visible focus states, tap target sizing, and layouts where sticky elements can cover focused controls. If your team uses design files as the source of truth, it is better to catch these issues before development than after release.
Test keyboard navigation through real page states, not only static screens. Open menus, modals, consent interfaces, and form validation messages. Check whether focus remains visible and whether interactions that depend on drag can be completed another way.
Run scenario-based tests for login, checkout, onboarding, account recovery, and support access. WCAG 2.2 includes several criteria that only become obvious when a full workflow is tested from start to finish.
Make sure accessibility documentation, audit scope, and remediation planning reflect the newer criteria. If your organization is preparing conformance documentation or reviewing vendor accessibility maturity, updated testing criteria can affect how readiness is assessed. Corpowid also offers support around audit-backed reporting and documentation through its VPAT and ACR services.
If you need a practical starting point, begin with the areas most likely to reveal WCAG 2.2 gaps:
These areas often combine multiple risk factors: dynamic content, custom controls, overlays, repeated data entry, and high user pressure.
If your site also includes consent banners or persistent interface layers, it is worth reviewing how those elements interact with keyboard focus and visibility. Related operational guidance can be found in Inside the 4-in-1 Widget: Accessibility, Consent, Legal and Company Info in One Script.
If your organization already aligned with WCAG 2.1, the most efficient approach is usually a gap assessment rather than a full restart.
Identify where the 9 new success criteria are most likely to apply: authentication, forms, mobile navigation, draggable interfaces, and support flows.
Many WCAG 2.2 issues repeat across components. Strengthening focus styles, target sizes, and component behavior at the system level is more efficient than fixing each page individually.
Some accessibility issues can be detected automatically, but others require manual review, especially around focus visibility, workflow consistency, and authentication friction.
Start with the pages where users complete key tasks: register, log in, request support, submit forms, and complete transactions.
Accessibility is not a one-time project. New releases, third-party scripts, and design updates can introduce regressions. Ongoing monitoring helps teams catch issues earlier and maintain readiness over time.
The difference between WCAG 2.1 and 2.2 is not about a complete rewrite of accessibility practice. It is about closing important gaps in how people actually use digital products.
The 9 new success criteria focus on everyday barriers: hidden focus, weak focus indicators, tiny targets, drag-only interactions, inconsistent help, repeated data entry, and difficult authentication flows. For modern websites and apps, these are not edge cases. They are common patterns.
For digital teams, the best next step is to treat WCAG 2.2 as a practical update to your accessibility program: review your design system, test critical workflows, and put monitoring in place so improvements last.
If your organization is evaluating broader website legal compliance alongside accessibility, Corpowid’s platform approach also connects accessibility, consent, and compliance operations in one place.
No. WCAG 2.2 builds on WCAG 2.1 rather than replacing its foundation. The main change is the addition of nine new success criteria.
In practice, WCAG 2.2 places more emphasis on keyboard focus visibility, target size, drag alternatives, consistent help, and accessible authentication.
Not always. Many organizations can start with a targeted gap review focused on the new WCAG 2.2 criteria, especially across critical user journeys and shared components.
Start with login, sign-up, password recovery, checkout, application forms, mobile navigation, and any interface that uses sticky elements, overlays, or drag-and-drop interactions.
Because login and verification steps often create avoidable barriers for users with cognitive disabilities or users who rely on assistive technology. WCAG 2.2 pushes teams to offer more accessible ways to authenticate.
Small accessibility issues on product and checkout pages can create major friction for shoppers and compliance risk for businesses. Here are the e-commerce accessibility UX fixes that deserve attention first.
Choosing between an accessible HTML report and a tagged PDF affects usability, accessibility, maintenance, and compliance readiness. Here’s how to decide which format to publish and when a dual-format approach may be the better option.
Corpowid has been recognized by Gartner, a leading global research and advisory firm, for our innovation and performance in digital accessibility. These badges reflect our commitment to creating inclusive, AI-powered web experiences.
TR
