What Is WCAG 2.2?
WCAG 2.2 is the Web Content Accessibility Guidelines version 2.2, published by the World Wide Web Consortium (W3C) in October 2023. It is the current W3C Recommendation for web accessibility and supersedes WCAG 2.1 as the definitive standard for accessible web content.
WCAG 2.2 adds 6 new success criteria at Levels A and AA, focused on three areas that prior versions underaddressed: keyboard focus visibility for fixed-position page elements, mobile accessibility for users who cannot perform complex gestures or dragging operations, and cognitive accessibility for authentication and multi-step forms. The new criteria respond directly to real-world accessibility barriers identified through years of user research and accessibility audits.
AdaScanPro tests against WCAG 2.2 AA, giving your site the most current and comprehensive compliance evaluation available.
The WCAG Timeline
Understanding where WCAG 2.2 sits in the standards timeline helps clarify what it means for compliance.
WCAG 2.0 — December 2008
The original WCAG 2.x framework. Established the four principles (Perceivable, Operable, Understandable, Robust) and the three-level conformance model (A, AA, AAA). 38 success criteria at Levels A and AA. Remained the primary reference standard for over a decade.
WCAG 2.1 — June 2018
Added 17 new success criteria addressing mobile accessibility, low vision users, and cognitive accessibility improvements. Brought the total to 50 criteria at Levels A and AA. Adopted by the DOJ as the basis for the April 2026 federal mandate and referenced in the majority of ADA website lawsuits and settlements.
WCAG 2.2 — October 2023
The current W3C Recommendation. Adds 6 new success criteria (5 at Level AA, 1 split across Levels A and AA). Removes the obsoleted Parsing criterion (4.1.1). Brings the total to 56 criteria at Levels A and AA. Fully backward-compatible with WCAG 2.1.
WCAG 3.0 — In development
A more significant restructuring of the guidelines framework. No fixed release date. Will use a different conformance model. Not yet referenced in any legal standards.
For compliance purposes, WCAG 2.2 AA is the version to target today.
The 6 New A/AA Success Criteria
Here is each new criterion, what it requires, and what it means in practice.
2.4.11 Focus Not Obscured (Minimum) — Level AA
When a user interface component receives keyboard focus, the focused element must not be entirely hidden by author-created content.
The problem it solves: Sticky navigation bars, fixed footers, cookie banners, and modal overlays frequently cover the element a keyboard user is focused on. The user presses Tab and the focused element scrolls behind the sticky header, disappearing from view. The user has no idea where they are on the page.
In practice: Ensure that when any interactive element receives focus, it remains at least partially visible on screen. Use CSS scroll-margin or scroll-padding to account for sticky headers. Test by tabbing through every page while a sticky header or footer is present and confirming the focused element is never fully obscured.
Business impact: Especially relevant for e-commerce sites with persistent shopping carts, SaaS dashboards with fixed toolbars, and any site with cookie consent banners that persist during browsing.
2.5.7 Dragging Movements — Level AA
Any functionality that uses a dragging motion must also be achievable through a single-pointer alternative that does not require dragging.
The problem it solves: Drag-and-drop interfaces, sliders requiring dragging, and sortable lists that only support drag-to-reorder are inaccessible to users with motor impairments who cannot reliably hold a pointer button down while moving. This includes users with tremors, limited fine motor control, or those using switch access devices.
In practice: For every drag-and-drop interaction, provide an equivalent that works with single clicks or taps. A file upload that supports drag-and-drop should also support click-to-browse. A sortable list should provide up/down buttons or a keyboard-accessible alternative. A range slider that requires dragging should also support click-to-set on the track.
Business impact: Affects any application with drag-and-drop file uploads, kanban boards, image galleries with drag-to-reorder, and custom range sliders.
2.5.8 Target Size (Minimum) — Level AA
Interactive targets must have a size of at least 24x24 CSS pixels, unless an equivalent target for the same function is sufficiently large or the target is inline within text.
The problem it solves: Tiny click targets are a persistent barrier for users with motor impairments, users on touchscreens, and older users. Icon-only buttons, close icons on tags, and densely packed navigation links frequently fall below usable tap target sizes, leading to missed taps and frustration.
In practice: Check all interactive elements with browser DevTools. Buttons, links, checkboxes, radio buttons, and form controls should meet the 24x24px minimum. Note that this criterion allows exceptions: if two small targets overlap and together cover a sufficient area, or if a link within a paragraph of text is naturally constrained by the text flow, the minimum may not apply. The intent is standalone interactive elements.
Business impact: Relevant for any site with small icon buttons (close, delete, edit icons), tag-based filtering interfaces, and dense navigation menus.
3.2.6 Consistent Help — Level A
If a help mechanism appears on multiple pages of a site (such as a chat widget, phone number, contact link, or FAQ link), it must appear in the same relative order in the content on each page.
The problem it solves: Users with cognitive disabilities rely on consistent placement of help resources to find support when they encounter difficulties. When a chat widget appears in the bottom-right corner on the homepage but is absent or repositioned on other pages, users who need help cannot reliably find it.
In practice: Audit all pages for help mechanisms: live chat widgets, contact phone numbers, help center links, FAQ links, and email links. Verify they appear in a consistent position in the page structure (not necessarily the same pixel location, but the same relative position in the DOM and visual layout). This is usually satisfied if your header, footer, and persistent UI elements are consistent across pages.
Business impact: Primarily affects sites where help resources are inconsistently placed — for example, a chat widget that only appears on certain pages, or contact information that appears in the footer on some pages but not others.
3.3.7 Redundant Entry — Level A
Information previously entered by or provided to the user that is required again in the same session must be auto-populated or made available for selection, unless re-entering is essential, for security, or the information is no longer valid.
The problem it solves: Multi-step forms that ask users to re-enter information already provided earlier in the same flow are a significant barrier for users with cognitive disabilities, motor impairments, and anyone using assistive technology. Re-entering a name, email address, or shipping address that was captured two steps earlier is frustrating and error-prone.
In practice: Review all multi-step forms. If a user enters their email on step 1 and the same email is required on step 3, pre-populate it. If a shipping address is entered and a billing address field appears, offer a checkbox to use the same address. Review checkout flows, registration funnels, and application forms.
Business impact: Directly affects e-commerce checkout flows, multi-step registration forms, insurance or financial applications, and any wizard-style interface.
3.3.8 Accessible Authentication (Minimum) — Level AA
Authentication processes must not require a cognitive function test (such as solving a puzzle, transcribing distorted text, or performing a calculation) unless an alternative method is available, or the test can be completed with the assistance of a tool (such as a password manager or copy-paste).
The problem it solves: CAPTCHA puzzles, image recognition challenges, and math-based verification barriers are inaccessible to users with cognitive disabilities, users with dyslexia, and users who rely on password managers and autofill for reliable, secure login. The criterion does not prohibit CAPTCHAs entirely — it requires that if a cognitive test is used, an alternative method is available.
In practice: Ensure your login and registration forms support copy-paste into password fields (do not disable paste). Support password managers by using standard HTML input types and not overriding browser autocomplete. If you use CAPTCHA, provide an accessible alternative (audio CAPTCHA, support for assistive technology bypass). Passkeys and magic links naturally satisfy this criterion.
Business impact: Affects every site with a login form. The minimum requirement (supporting password managers and copy-paste) is low-effort and already best practice for security and UX. The higher implication is for sites using aggressive CAPTCHA that blocks assistive technology users.
What Was Removed
WCAG 2.2 removed one success criterion that existed in WCAG 2.1:
4.1.1 Parsing (Level A) — This criterion required well-formed HTML: unique IDs, proper nesting, complete open and close tags, and no duplicate attributes. It was removed from WCAG 2.2 because modern browser parsing engines and assistive technology implementations have become robust enough that most HTML parsing errors no longer create accessibility barriers. The W3C determined the criterion no longer served its original purpose in the current browser ecosystem.
Removing 4.1.1 does not mean HTML quality is unimportant. Well-formed HTML remains a development best practice and can still affect assistive technology behavior in edge cases. AdaScanPro retains this check as a best-practice warning even though it no longer counts against WCAG 2.2 AA conformance.
Backward Compatibility
WCAG 2.2 is fully backward-compatible with WCAG 2.1 and WCAG 2.0.
Every success criterion in WCAG 2.0 is included in WCAG 2.1. Every success criterion in WCAG 2.1 (except the removed 4.1.1) is included in WCAG 2.2. This means that a site that conforms to WCAG 2.2 AA also conforms to WCAG 2.1 AA.
The practical implication: targeting WCAG 2.2 AA automatically satisfies the federal WCAG 2.1 AA mandate and any court or settlement standard referencing WCAG 2.1. There is no trade-off involved in targeting the higher standard. You get full legal coverage against WCAG 2.1 claims while also being current with the W3C's latest guidance.
WCAG 2.2 vs the Federal Deadline
The DOJ's April 24, 2026 rule mandates WCAG 2.1 AA for state and local government entities. Courts and plaintiffs' attorneys in private lawsuits have similarly referenced WCAG 2.1 AA as the benchmark.
Meeting WCAG 2.2 AA exceeds this requirement. Any organization that achieves WCAG 2.2 AA conformance satisfies the WCAG 2.1 AA standard by definition, since 2.2 is a superset of 2.1 (minus the obsoleted Parsing criterion, which 2.2 organizations can still implement as best practice).
Looking ahead: The European Accessibility Act (EAA), which takes effect June 2025 for new products and services, references EN 301 549, which in turn references WCAG. As EN 301 549 is updated to align with WCAG 2.2, organizations targeting 2.2 will be positioned for EU compliance as well. The EU is ahead of the US in adopting 2.2 as its normative reference.
For US businesses with European customers or operations, targeting WCAG 2.2 AA now covers both the federal US mandate and the direction of EU requirements simultaneously.
Why It Matters for Your Business
Courts follow current standards. Plaintiffs' attorneys are already citing WCAG 2.2 in demand letters and complaints as the current W3C standard. A site that meets only WCAG 2.1 but fails 2.2 criteria provides a new vector for claims, particularly around the new focus visibility and target size requirements that are easy to identify through automated scanning.
Competitors are moving to 2.2. If your competitors are marketing WCAG 2.2 compliance and you are marketing 2.1, you are already behind in any procurement or enterprise sales process where accessibility documentation is evaluated.
The new criteria address real user barriers. The six new success criteria are not bureaucratic additions — they address genuine barriers that affect real users. Sticky headers that cover focused elements frustrate screen reader and keyboard users daily. Drag-only interfaces exclude users with motor impairments. Small tap targets cause errors on every touchscreen visit. Fixing these improves the experience for all users, not just those with disabilities.
Future-proofing. WCAG 3.0 is in development. It represents a more significant structural change. Organizations that stay current with 2.x updates build the processes and tooling to track future standard changes proactively, rather than scrambling to catch up after standards shift.
Mobile UX improvement. Several of the new 2.2 criteria — particularly target size and dragging alternatives — directly improve the mobile experience for all users. Meeting 2.2 delivers both compliance and measurable UX improvements.
Check Your Site Against WCAG 2.2
AdaScanPro scans against all 55+ WCAG 2.2 AA criteria, including the six new requirements added in October 2023. A free scan identifies which criteria your site passes and fails, with a prioritized remediation roadmap for every violation found.
In 60 seconds, you will know exactly where you stand against the current standard.
Scan your website free to check against WCAG 2.2 AA today.
Tags
Share this article