WCAG 2.2: What's New and What It Means

WCAG 2.2 Overview

I was conducting an accessibility audit for a university admissions portal when a student with a cognitive disability showed me something that changed how I think about web accessibility. The CAPTCHA on the login page wasn't just difficult—it was impossible for her without help. She'd figured out workarounds over time, but the frustration was palpable. She could meet the academic requirements of a top university but couldn't independently log into its systems. That's the gap WCAG 2.2 aims to address.

The Web Content Accessibility Guidelines (WCAG) 2.2 became a W3C Recommendation in October 2023, building on WCAG 2.1 with additions that address user needs that weren't fully covered before. The emphasis this time is on cognitive accessibility—how we support users with memory challenges, learning disabilities, and executive function differences—along with mobile interactions that now dominate how many people access the web.

For organizations already targeting WCAG 2.1 compliance, 2.2 represents incremental additions rather than fundamental changes. But those additions address real usability barriers that affect significant user populations. The criteria aren't theoretical—they solve problems I see users struggle with every time I conduct user testing with people who have disabilities.

New Success Criteria

WCAG 2.2 introduces nine new success criteria that address gaps in the previous guidelines. Several of these codify what good designers have been doing intuitively; others establish new requirements that many sites don't currently meet. Let me walk through each one and explain not just what it requires, but why it matters and how to implement it.

2.4.11 Focus Not Obscured (Minimum) - Level AA

When a keyboard user navigates to an interactive element, they must be able to see it. This sounds obvious until you consider how many sites have sticky headers, cookie consent banners, chat widgets, or modal overlays that cover focused elements. I've tested sites where I could tab to a button but couldn't see it because the sticky header covered it completely.

Implementation means testing keyboard navigation with all your sticky elements visible. Ensure focused items scroll into view above or below fixed-position elements. Manage z-index thoughtfully so overlays don't hide interactive content. The criterion allows partial obstruction (that's what the "Minimum" means)—Level AAA's 2.4.12 requires no part of the focused element to be hidden.

2.4.13 Focus Appearance - Level AAA

Focus indicators must meet minimum size and contrast requirements. The thin, barely-visible focus outlines that many browsers default to aren't sufficient for users who rely on keyboard navigation. A user with low vision navigating by keyboard needs to see clearly which element has focus.

This is Level AAA, so it's not required for standard compliance. But it reflects good practice that benefits keyboard users regardless of compliance level. Design focus indicators that are visible, not just present.

2.5.7 Dragging Movements - Level AA

Any functionality that requires dragging must have a single-pointer alternative. This addresses users with motor impairments who can click but can't maintain pressure while moving the pointer. Drag-and-drop interfaces, sliders, and sortable lists all need alternatives.

Implementation means providing buttons or inputs alongside drag functionality. A slider needs increment/decrement buttons or a text input. A sortable list needs move-up/move-down buttons. A drag-to-select interface needs click-to-select, click-to-place. The drag functionality can remain for users who prefer it—you're adding alternatives, not removing features.

2.5.8 Target Size (Minimum) - Level AA

Touch targets must be at least 24×24 CSS pixels with adequate spacing, with exceptions for inline links and certain context-specific situations. This addresses the frustration of trying to tap small buttons on mobile devices—a problem for everyone but especially acute for users with motor impairments.

Implementation means auditing buttons, form controls, and clickable elements for sufficient tap area. You can add padding to increase target size without changing visual appearance. Pay particular attention to mobile interfaces where small targets create the most frustration. The inline exception covers text links within paragraphs, which would be visually awkward at 24px minimum.

3.2.6 Consistent Help - Level A

When help mechanisms (human contact, self-help options, chatbots) appear on multiple pages, they must appear in the same relative order. Users who find help on one page need to find it in the same place on other pages without relearning navigation.

This is a relatively easy criterion to meet if your site uses consistent templates. The challenge arises when different sections of a site were built by different teams with different conventions. Audit help mechanisms site-wide to ensure consistent placement.

3.3.7 Redundant Entry - Level A

Information previously entered in a process should be auto-populated or available for selection rather than requiring re-entry. This addresses both cognitive load and error potential. When I test with users with memory impairments, re-entering information across multi-step forms is consistently frustrating and error-prone.

Implementation means pre-filling forms with data from previous steps, allowing users to select from previous entries, and remembering information across multi-step processes. If a user entered their address on step one, don't ask for it again on step three—populate it automatically with the option to change.

3.3.8 Accessible Authentication (Minimum) - Level AA

Authentication shouldn't require cognitive function tests—things like remembering passwords, solving puzzles, or recognizing distorted text—unless alternatives exist. This is the CAPTCHA criterion, and it directly addresses the situation I described in my opening anecdote.

Implementation means supporting password managers (never block paste in password fields), offering alternative authentication methods (passkeys, biometrics, magic links), and using accessible CAPTCHA alternatives. The criterion doesn't ban CAPTCHAs entirely, but it requires alternatives for users who can't complete them.

3.3.9 Accessible Authentication (Enhanced) - Level AAA

The enhanced version allows no cognitive function tests at all for authentication, with limited exceptions. This is stricter than 3.3.8 and probably impractical for many sites, which is why it's Level AAA.

Removed Criterion

WCAG 2.2 removes one criterion from 2.1, which is unusual—previous versions only added requirements. Understanding why 4.1.1 Parsing was removed helps clarify what accessibility standards are really about.

4.1.1 Parsing - Removed

This criterion required HTML to be well-formed with complete start/end tags, proper nesting, and unique IDs. On the surface, this sounds reasonable—valid HTML is good practice. But the criterion was removed because modern browsers and assistive technologies handle parsing errors robustly. Invalid HTML rarely causes actual accessibility problems; the underlying issues (like duplicate IDs affecting form label associations) are covered by other criteria.

What this means practically: HTML validation is still good practice, but isolated parsing errors don't automatically fail WCAG 2.2 audits. The focus shifts to functional impact of markup issues. If a duplicate ID causes a screen reader to announce the wrong label for a form field, that's a 1.3.1 or 4.1.2 failure—the actual accessibility problem, not the technical parsing issue.

This removal reflects a maturation in how we think about accessibility standards. The goal isn't technical perfection—it's ensuring people can actually use the web. When a technical requirement doesn't map to real-world accessibility outcomes, removing it clarifies what actually matters.

Higher Ed Implications

For colleges and universities, several new criteria have direct implications for the systems students, faculty, and staff use daily. Higher education faces particular scrutiny on accessibility through OCR enforcement, and understanding how WCAG 2.2 applies to common higher ed scenarios helps prioritize remediation efforts.

Application and Registration Forms

Multi-step application forms are notorious for accessibility problems, and WCAG 2.2 addresses several pain points directly. Redundant Entry (3.3.7) means your application shouldn't ask for the student's address three times across different sections. Accessible Authentication (3.3.8) means your student portal login needs to work with password managers and offer alternatives to CAPTCHA. Target Size (2.5.8) means your mobile-responsive forms need buttons and fields that work on phone screens without frustration.

I've audited admissions applications that violated all three criteria simultaneously. The good news is that fixing these issues improves the experience for all applicants, not just those who need accommodations.

Learning Management Systems

LMS interfaces create specific WCAG 2.2 challenges. Dragging Movements (2.5.7) directly affects drag-and-drop quiz questions—those matching exercises and ordering activities need click-based alternatives. Focus Not Obscured (2.4.11) matters when sticky navigation or toolbars cover content as students navigate. Consistent Help (3.2.6) requires that help resources appear consistently across course pages.

If your institution uses a commercial LMS, evaluate whether the vendor has addressed WCAG 2.2. If they haven't, that's a conversation to have with their product team. If you build custom LMS integrations or content, ensure they meet the new criteria.

Course Content

Interactive course content often relies on patterns that WCAG 2.2 now explicitly addresses. Interactive elements in embedded simulations or exercises need adequate target sizes. Custom-styled interactive elements need visible focus indicators. Content authors may need training on these new requirements.

Implementation Priorities

Approaching WCAG 2.2 adoption requires strategy. Not every issue has equal impact, and resources are finite. Here's how I recommend prioritizing the new criteria, based on typical effort required and impact on users.

Quick Wins

Some issues can be identified and fixed quickly. Audit sticky elements by tabbing through pages with fixed headers and banners visible—you'll immediately see if focus gets obscured. Check target sizes on key interactive elements with browser developer tools. Verify that help mechanisms appear consistently across your site's main sections. Enable password paste on login forms if you haven't already. These changes require relatively little development effort and address multiple new criteria.

Medium Effort

Some criteria require more substantial implementation work. Drag-and-drop interfaces need alternative interaction methods added—this means design work to figure out what the alternative looks like, plus development to implement it. Multi-step forms need persistence logic to track and pre-fill previously entered data. Focus indicators may need design attention to meet appearance guidelines without clashing with your visual design.

Significant Projects

Authentication changes can be significant projects depending on your current architecture. Replacing CAPTCHA with accessible alternatives may require evaluating and implementing new services. Retrofitting complex interactive applications built before WCAG 2.2 may require substantial refactoring. Third-party integrations that don't meet WCAG 2.2 may need vendor pressure, replacement, or workarounds.

1. Audit current state

   Assess your site against the new criteria specifically. Automated tools can help but manual testing is essential for many WCAG 2.2 criteria.

2. Prioritize by impact

   Focus on Level A criteria first, then AA. Consider user-facing importance, traffic to affected pages, and complaint patterns.

3. Address quick wins

   Fix issues that require minimal development effort to build momentum and demonstrate progress.

4. Plan larger efforts

   Budget and schedule significant remediation work. Include WCAG 2.2 requirements in ongoing development roadmaps.

5. Update policies

   Revise accessibility policies to reference WCAG 2.2. Update training and documentation for content creators.

Testing for WCAG 2.2

Testing the new criteria requires specific attention because many of them don't lend themselves well to automated checking. Tools can help identify potential issues, but human judgment remains essential for evaluating whether criteria are actually met.

Manual Testing Focus

Keyboard navigation testing becomes more important with WCAG 2.2. Tab through pages with sticky elements visible and watch for focus getting hidden. Test on actual mobile devices—simulators don't always reveal touch target problems accurately. Try drag-and-drop interfaces with only keyboard and verify alternatives exist and work. Walk through multi-step forms and check whether data persists appropriately. Test login with a password manager and observe whether it works smoothly.

Automated Testing Limitations

Automated tools can help but won't catch everything in WCAG 2.2. Focus obstruction depends on dynamic page state and scroll position—tools may check elements but miss real-world scenarios where content overlaps. Drag alternatives need functional verification beyond what static analysis provides. Consistency requires cross-page comparison that most tools don't handle well. Cognitive aspects like redundant entry often need human judgment to evaluate whether the user experience meets the intent.

Use automated tools as a starting point. They'll catch obvious issues like elements lacking focus indicators or extremely small targets. But budget for manual testing, especially by people who actually use assistive technologies or have the disabilities the criteria address.

Moving Forward

WCAG 2.2 represents continued evolution in accessibility standards, addressing real barriers that affect real users. The criteria aren't arbitrary additions—they reflect user research and advocacy from disability communities around cognitive accessibility and mobile interactions. When you implement these criteria, you're addressing problems that people actually encounter.

For organizations already committed to accessibility, WCAG 2.2 is a manageable step forward. The additions are targeted and the implementation paths are clear. For those beginning their accessibility journey, targeting WCAG 2.2 from the start means building more usable experiences for everyone—because accessible design benefits all users, not just those who need accommodations.

The student I mentioned at the beginning of this article now works in tech accessibility. She told me recently that every time she encounters a site that implements accessible authentication, she thinks about how different her college experience might have been if those standards had existed then. That's what these guidelines are about—not compliance checkboxes, but removing barriers that prevent capable people from doing what they need to do. WCAG 2.2 gives us clearer guidance on practices that make the web work better for people with cognitive disabilities, motor impairments, and mobile users. That's good for compliance and good for users.