What's New in WCAG 2.2?

On October 5, 2023, the W3C published WCAG 2.2 as an official web standard. While WCAG 2.1 remains valid and widely referenced, WCAG 2.2 introduces nine new success criteria and removes one obsolete requirement. These changes reflect a deeper understanding of mobile accessibility, cognitive disabilities, and focus management.

The Legal Landscape

Adoption of WCAG 2.2 varies by jurisdiction:

United States - The ADA Title II regulations finalized in April 2024 require WCAG 2.1 Level AA for state and local government websites. Private sector requirements remain based on case law, with WCAG 2.1 AA as the de facto standard. That has been the main focus of these advent calendar posts. WCAG 2.2 isn't legally required yet, but represents best practice.
European Union - The European Accessibility Act and Web Accessibility Directive reference "EN 301 549," which incorporates WCAG standards "as amended from time to time." This means EU requirements effectively include WCAG 2.2, with typical 12-18 month transition periods for new requirements.
United Kingdom - Public sector websites must meet WCAG 2.1 AA currently, with expectations that WCAG 2.2 will be incorporated into regulations following a transition period.
Canada - The Accessible Canada Act and provincial legislation reference WCAG, with some provinces already requiring 2.1 AA and moving toward 2.2.

The trend is clear: WCAG 2.2 is becoming the expected standard globally. Even if your jurisdiction doesn't legally require it yet, adopting 2.2 proactively benefits your users and prepares you for future requirements.

What Changed

The Big Removal: 4.1.1 Parsing Is Obsolete

WCAG 2.2 removes Success Criterion 4.1.1 Parsing, which required valid HTML without duplicate IDs or improperly nested elements. When this criterion was introduced in WCAG 2.0 (2008), browsers handled invalid HTML inconsistently, causing problems for assistive technology.

Today, HTML5 specifies exactly how browsers must handle malformed markup, so all browsers error-correct consistently. Invalid HTML that actually causes accessibility problems is already covered by more specific criteria like 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value.

This doesn't mean you should write invalid HTML - it's still bad practice. But it's no longer a specific WCAG requirement.

Nine New Success Criteria

WCAG 2.2 adds two Level A criteria, four Level AA criteria, and three Level AAA criteria. For most organizations aiming for AA compliance, the four new AA criteria are what matter. We're not going to cover them all today, but we're picking one we are dealing with more, as we focus on more interactive user experiences:

2.5.7 Dragging Movements: The Touch Screen Challenge

Any functionality that requires dragging must have an alternative that doesn't require dragging. This is worth examining in detail because it affects many modern interfaces.

Why this matters:

Dragging requires fine motor control that many users can't reliably perform:

People with hand tremors or limited dexterity
Users of speech recognition software (try saying "drag this to there")
People with arthritis or RSI who find sustained pressing painful
Touch screen users with shaky hands
Anyone using assistive technology that doesn't support dragging

Common violations:

Range sliders: Many sliders can only be adjusted by dragging the handle. Alternative: provide arrow buttons to increment/decrement, or an input field where users can type a value.

Sortable lists: Drag-to-reorder lists are popular in content management, kanban boards, and priority setting. Alternative: provide "Move up," "Move down," or "Move to position" buttons for each item.

Drawing and signature tools: Drawing shapes or signing documents with a mouse/finger requires dragging. Alternative: provide keyboard controls, or for signatures specifically, allow uploaded images or typed names.

Interactive maps: Dragging to pan a map. Alternative: provide directional buttons (up, down, left, right) or a mini-map with click-to-center.

Calendar scheduling: Dragging to create or resize calendar events. Alternative: clicking to create events, then using form fields to set start/end times.

Image crop tools: Dragging corners to resize crop areas. Alternative: numeric input fields for dimensions, or preset aspect ratio buttons.

File upload: Drag-and-drop file upload is convenient but shouldn't be the only option. Always provide a "Choose file" button.

Better design patterns:

For sliders: Include "+" and "-" buttons on either side of the slider handle, plus an editable value display
For sortable lists: Add a dropdown menu on each item: "Move to: [Top | Position 1 | Position 2 | ... | Bottom]"
For drawing: Provide shape tools with keyboard shortcuts, or let users define shapes with coordinate inputs
For maps: Arrow keys for panning, +/- keys for zooming, plus visible pan/zoom controls
For calendars: Click-to-create events with form fields for precise times

What about touch gestures?

This criterion specifically addresses dragging - maintaining contact while moving. Other touch gestures like:

Single tap (equivalent to click - fine)
Pinch to zoom (browser default - fine)
Swipe to scroll (browser default - fine)

...are not covered by this criterion, though other criteria address gesture-based navigation (2.5.1 requires pointer gestures to have alternatives).

Looking Ahead: WCAG 3.0

While we're discussing WCAG 2.2, it's worth noting that WCAG 3.0 is in active development. Currently in Working Draft status, WCAG 3.0 (also called "W3C Accessibility Guidelines" or "Silver") represents a fundamental rethinking of how we measure and achieve accessibility.

Key changes in WCAG 3.0 (as currently proposed):

Moving from pass/fail criteria to a scoring system
Testing with real users rather than just technical compliance
Broader scope beyond just web content
Focus on functional needs rather than technical implementation
More guidance for emerging technologies like AR/VR

However, WCAG 3.0 is still years away from becoming an official recommendation. The W3C has been clear that WCAG 2.x will remain the standard for the foreseeable future, with 2.2 representing the current state of the art. Organizations should focus on meeting WCAG 2.2 now, not waiting for 3.0.

What This Means for Your Site

If You're Already WCAG 2.1 AA Compliant

Review these specific areas:

Sticky headers and focus - Make sure focused elements aren't completely hidden
Draggable controls - Add keyboard or click alternatives to any drag-and-drop
Focus indicators - Ensure 2px minimum size and 3:1 contrast
Touch target sizes - Verify buttons and links are at least 24x24 pixels
Help location - Check that help mechanisms appear consistently across pages
Form processes - Auto-populate or provide selection for previously entered data
Authentication - Offer alternatives to cognitive function tests

If You're Starting Fresh

Build with WCAG 2.2 in mind from the beginning:

Design focus indicators that meet 2.4.13 (2px, 3:1 contrast)
Size all interactive elements at least 24x24 pixels
Use z-index carefully - never completely obscure focused elements
Build forms that remember data across steps
Choose modern authentication methods over CAPTCHAs
Provide non-dragging alternatives for all draggable interfaces

Timeline and Adoption

WCAG 2.2 became an official standard in October 2023, but adoption varies:

US federal requirements - Current ADA Title II regulations (finalized April 2024) reference WCAG 2.1 Level AA, not 2.2
EU regulations - The European Accessibility Act references WCAG "as amended from time to time," meaning 2.2 requirements apply
UK regulations - Similarly reference the latest version, with expected 12-month transition periods
Voluntary compliance - Many organizations are moving to 2.2 as best practice

Even if your jurisdiction doesn't legally require WCAG 2.2 yet, these criteria represent genuine improvements in accessibility and user experience. Adopting them proactively benefits your users and prepares you for future requirements.

The Bottom Line

WCAG 2.2 isn't a massive overhaul - if you're meeting 2.1 AA, you're close to 2.2 compliance. The new criteria address real gaps: mobile usability (touch targets, dragging), focus management (visibility, appearance), cognitive accessibility (redundant entry, authentication), and consistency (help location).

These aren't arbitrary new requirements - they're formalizing best practices that improve usability for everyone. Larger touch targets help everyone on mobile. Better focus indicators help everyone using keyboards. Eliminating redundant data entry helps everyone filling out forms.

As we close out this 24-day accessibility journey, remember: accessibility isn't about perfection or checking boxes. It's about continuously improving, understanding your users' needs, and building interfaces that work for everyone. WCAG 2.2 gives us better tools to do exactly that.

Start with what matters most for your users. Fix critical barriers first. Test with real people using assistive technology. And keep learning - because accessibility is a journey, not a destination.