WCAG 2.2 for Product Teams: What Changed and What to Do in 90 Days

WCAG 2.2 is no longer a future consideration—it's the current standard that regulators, auditors, and enterprise buyers expect you to meet. The W3C officially published WCAG 2.2 in October 2023, and with its recent adoption into ISO 40500:2025, the standard now carries even more weight in procurement requirements and legal settlements.

Here's what product and engineering leaders need to understand about this WCAG 2.2 guide: you don't need to memorize all 87 success criteria. You need a prioritized WCAG 2.2 checklist that addresses the new requirements within the context of your existing product. The goal is a practical 90-day plan that integrates compliance into your normal development workflow.

This guide breaks down the nine new success criteria in product terms, identifies the highest-risk areas for digital product teams, and provides a framework for building a backlog that addresses WCAG 2.2 compliance without derailing your roadmap.

The 9 New Success Criteria – Product-Centric Overview

WCAG 2.2 introduces nine new success criteria beyond WCAG 2.1. The W3C's "What's New in WCAG 2.2" overview provides the official documentation, but understanding these in practical product terms—rather than specification language—is essential for prioritization.

Focus Not Obscured (2.4.11 / 2.4.12)

What it means in specification terms: When a component receives keyboard focus, it must not be entirely hidden by author-created content.

What it means for your product:

Sticky headers and navigation bars that remain fixed at the top of the viewport can obscure focused elements below them. If your header is 80px tall and a user tabs to a link near the top of the scrollable area, can they see what's focused?

Cookie consent banners and promotional overlays at the top or bottom of screens frequently hide focused content. When a user dismisses these, focus management matters.

Modal dialogs and tooltips that appear on hover or focus near content can obscure the very element triggering them.

Chat widgets and help icons anchored to viewport corners can cover focused elements as users tab through the page.

The AA criterion (2.4.11) requires focus not be entirely hidden. The AAA criterion (2.4.12) requires focus not be hidden at all—a stricter requirement most teams won't target initially.

Product action items: Audit all fixed-position elements. Test tab navigation through pages with sticky headers, footers, and widgets visible. Ensure focused elements scroll into unobscured view.

Dragging Movements and Target Size (2.5.7 / 2.5.8)

What it means in specification terms: Functionality using dragging movements must have single-pointer alternatives. Touch targets must meet minimum size requirements.

What it means for your product:

Drag-and-drop interfaces for file uploads, kanban boards, sortable lists, and image cropping must offer button-based or keyboard alternatives. The Web Accessibility Initiative's guidance on pointer gestures explains that users with motor impairments often cannot perform drag gestures reliably.

Sliders and range inputs for filtering, volume control, or image adjustment need arrow key support and potentially direct input fields.

Touch targets must be at least 24x24 CSS pixels (AA) with adequate spacing. Many mobile designs use targets that are too small, particularly in navigation, form controls, and action menus.

Interactive icons and controls that work fine with a mouse may be unusable for users with tremors or limited fine motor control.

Product action items: Inventory all drag-based interactions. Ensure each has a non-dragging alternative. Audit touch target sizes across mobile breakpoints. Pay special attention to icon buttons without text labels.

Accessible Authentication and Redundant Entry (3.3.7 / 3.3.8 / 3.3.9)

What it means in specification terms: Authentication processes must not require cognitive function tests. Users should not have to re-enter information already provided in the same session.

What it means for your product:

CAPTCHA challenges that require identifying objects, solving puzzles, or transcribing distorted text create barriers for users with cognitive disabilities. The W3C's understanding document on accessible authentication emphasizes that alternative authentication methods must be available.

Password requirements that demand memorization without allowing password managers create cognitive burdens. Copy-paste must work in password fields.

Multi-factor authentication flows that require transcribing codes or identifying images need accessible alternatives—email links, security keys, or biometric options.

Multi-step forms that ask for previously entered information (re-entering email, re-selecting options) violate redundant entry requirements. Auto-populate from session data where possible.

Account recovery flows often stack cognitive challenges: security questions, email verification, new password creation, and CAPTCHA. Simplify these paths.

Product action items: Audit all authentication flows. Ensure password fields allow paste. Provide CAPTCHA alternatives. Review multi-step processes for redundant data requests. Test with password managers enabled.

The "Big 3" for Digital Product Teams

While all nine new WCAG 2.2 criteria matter, three areas create the highest risk and effort for typical digital products:

Forms and Authentication

Forms drive business outcomes—signups, purchases, applications, support requests. WCAG 2.2's authentication and redundant entry requirements directly affect these critical flows.

Key areas to audit:

• Account creation and login
• Sign-in, including SSO flows
• Password reset and account recovery
• Multi-factor authentication setup and verification
• Checkout and payment forms
• Multi-step wizards and applications

Common failures:

• CAPTCHA without accessible alternatives
• Password fields blocking paste
• Asking for email twice in signup flows
• MFA requiring image recognition
• Session timeouts that lose entered data

Navigation and Focus Management

Focus obscuring requirements affect nearly every page with sticky elements—which is most modern web applications.

Key areas to audit:

• Sticky headers and navigation bars
• Cookie consent and promotional banners
• Chat widgets and help overlays
• Modal dialogs and popovers
• Dropdown menus that expand over content

Common failures:

• Headers covering focused elements on tab navigation
• Banners obscuring form fields receiving focus
• Modals not trapping focus appropriately
• Widgets anchored to viewport corners covering content

Complex Interactions (Gestures, Dragging, Sliders)

Modern interfaces rely heavily on gesture-based interactions that WCAG 2.2 now explicitly addresses.

Key areas to audit:

• Drag-and-drop file uploaders
• Sortable lists and kanban boards
• Image cropping and editing tools
• Slider-based filters and settings
• Mobile swipe gestures for navigation
• Touch-based carousels and galleries

Common failures:

• Drag-to-upload without click alternative
• Sortable lists requiring drag with no keyboard reorder
• Sliders without arrow key support or direct input
• Swipe-only navigation without button alternatives

Turning WCAG 2.2 into a 90-Day Backlog

Compliance isn't achieved through awareness—it requires engineering work. Here's how to translate this WCAG 2.2 checklist into actionable backlog items.

Step 1 – Inventory Affected Flows

Before writing tickets, understand your exposure. Create a matrix mapping WCAG 2.2 criteria against your product's key flows. The MDN Web Docs accessibility guides provide excellent technical references for each criterion.

For example:

• Signup flow: Check header overlap, mobile CTAs, CAPTCHA audit, email re-entry
• Checkout: Cookie banner overlap, payment button sizes, address re-entry
• Dashboard: Nav overlap with widgets, drag widgets, icon button sizes, MFA flow
• Mobile app: Tab bar issues, gesture navigation, all touch targets, biometric auth

This inventory reveals where WCAG 2.2 actually intersects your product, avoiding wasted effort auditing irrelevant criteria.

Step 2 – Create Epics and Stories

Group related work into epics that engineering teams can reason about:

Epic: Accessible Authentication

• Story: Add honeypot CAPTCHA alternative to signup
• Story: Ensure password fields allow paste across all forms
• Story: Add security key option for MFA
• Story: Auto-populate email in password reset confirmation

Epic: Focus Management Cleanup

• Story: Adjust scroll behavior for sticky header focus
• Story: Update cookie banner to not obscure focused elements
• Story: Audit and fix chat widget viewport positioning
• Story: Ensure modal focus trapping works correctly

Epic: Drag Interaction Alternatives

• Story: Add keyboard reorder to dashboard widgets
• Story: Create click-to-upload alternative for drag-drop zone
• Story: Add increment buttons to slider filters

Epic: Touch Target Sizing

• Story: Audit mobile touch targets site-wide
• Story: Increase icon button sizes to 24px minimum
• Story: Add spacing between adjacent interactive elements

Step 3 – Prioritize by Risk and Traffic

Not all WCAG 2.2 work is equal. Prioritize based on:

Traffic volume: Issues in high-traffic flows affect more users. Fix signup before settings.

Business criticality: Checkout and payment issues directly affect revenue. Prioritize over nice-to-have features.

Fix complexity: Quick wins (enabling paste in password fields) should ship immediately. Larger architectural changes (drag alternatives) can be phased.

A practical 90-day breakdown:

Days 1-30: Audit and quick wins

• Complete flow inventory
• Ship easy fixes (paste in password fields, basic target sizing)
• Create epic-level backlog items

Days 31-60: High-priority remediation

• Authentication flow improvements
• Focus management fixes for primary pages
• Mobile touch target audit and fixes

Days 61-90: Complex interactions and monitoring

• Drag alternative implementations
• Comprehensive focus testing across all sticky elements
• Establish regression testing in CI/CD

How Automation Simplifies WCAG 2.2 Compliance

Manual testing for WCAG 2.2 compliance is necessary but doesn't scale. Automation handles the repetitive scanning that makes continuous compliance possible.

Automated checks catch known patterns: Target size violations, missing form labels, focus order issues, and many other criteria can be detected automatically across every page of your site. The Deque University's axe-core rules documentation shows which WCAG criteria can be automatically tested.

CI/CD integration prevents regressions: Once you fix focus management, automated tests ensure new features don't reintroduce the problem. TestParty integrates into your deployment pipeline to catch issues before they reach production.

Continuous monitoring tracks progress: Dashboards show WCAG 2.2 criterion coverage over time, making progress visible to stakeholders and identifying areas needing attention.

Prioritization based on actual impact: Automated scanning across your full site reveals which issues appear most frequently and on highest-traffic pages, informing prioritization.

The goal isn't replacing human judgment—it's augmenting limited accessibility expertise with scalable detection, so your specialists focus on complex issues automation can't catch.

Conclusion – WCAG 2.2 as an Opportunity to Improve UX

This WCAG 2.2 guide isn't just about meeting standards—it's about building better products. Every new criterion addresses a real user need:

• Focus visibility helps everyone understand where they are on a page
• Drag alternatives make interfaces work across devices and abilities
• Authentication improvements reduce friction for all users
• Target sizing benefits anyone using mobile devices
• Reducing redundant entry respects everyone's time

Product teams that frame WCAG 2.2 compliance as a usability initiative—rather than a compliance burden—build competitive advantages. Your accessible authentication flow isn't just legally safe; it converts better. Your keyboard-navigable drag-and-drop isn't just compliant; it works for power users with keyboards.

The 90-day timeline is achievable with focused effort. The WCAG 2.2 checklist becomes manageable when mapped to your actual product flows. And the result is a product that works better for everyone.

Need help translating WCAG 2.2 into a concrete backlog? Talk to our team about a 90-day implementation plan tailored to your product and tech stack.

Related Articles:

• Automated WCAG 2.1 Testing: AI Implementation Guide 2025
• WCAG 2.2 Is Now ISO 40500:2025: What This Historic Change Means for Digital Leaders
• Building Accessibility Checks Into Modern CI/CD Workflows