Chapter 3: WCAG 2.2 New Success Criteria Deep Dive

WCAG 2.2 introduces nine new success criteria that address critical gaps in web accessibility, particularly for mobile users, people with cognitive disabilities, and those using alternative authentication methods. These additions reflect the evolution of web technology and user behavior since WCAG 2.1’s release in 2018.

Understanding these new requirements isn’t just about compliance—it’s about competitive advantage. Most web developers remain unaware of these changes, creating an opportunity for forward-thinking businesses to implement accessibility improvements before they become widespread expectations.

Each new success criterion addresses real-world barriers that affect millions of users daily. More importantly, these improvements often enhance usability for all users, creating business value that extends far beyond accessibility compliance.

2.4.11 Focus Not Obscured (Minimum) – Level AA

The Problem This Solves

Modern web interfaces frequently use sticky navigation bars, floating chat widgets, cookie banners, and promotional overlays that can completely hide the keyboard focus indicator. This creates an impossible situation for keyboard users who can’t see where they are on the page.

Real-World Scenario: A user navigating a checkout form with the Tab key reaches a credit card input field, but a sticky header covers the focused element. They can’t see what field they’re filling out or whether their input is being accepted.

Technical Requirements

When any user interface component receives keyboard focus, the focus indicator must not be entirely hidden by author-created content. The success criterion specifically requires that:

• Focus indicators remain visible when covered by author-created content
• User agent content (browser UI) obscuring focus doesn’t violate this requirement
• User-initiated content (opened dropdown menus) may temporarily obscure focus

Implementation Strategies

Detect Focus Collision:

/* Ensure focus indicators have sufficient z-index */
*:focus {
    z-index: 9999;
    position: relative;
}

/* Alternative: Adjust sticky elements when focus moves behind them */
.sticky-header {
    position: sticky;
    top: 0;
    z-index: 100;
}

/* Ensure focused elements scroll into view above sticky content */
.form-field:focus {
    scroll-margin-top: 80px; /* Height of sticky header + buffer */
}

JavaScript Solution for Dynamic Adjustment:

// Automatically adjust scroll position when focus is obscured
document.addEventListener('focusin', function(event) {
    const focusedElement = event.target;
    const stickyHeader = document.querySelector('.sticky-header');
    
    if (stickyHeader) {
        const headerHeight = stickyHeader.offsetHeight;
        const elementRect = focusedElement.getBoundingClientRect();
        
        // Check if focused element is behind sticky header
        if (elementRect.top < headerHeight) {
            const scrollOffset = window.pageYOffset + elementRect.top - headerHeight - 10;
            window.scrollTo({
                top: scrollOffset,
                behavior: 'smooth'
            });
        }
    }
});

Business Impact and Testing

Conversion Benefits: Checkout processes with obscured focus indicators show significantly higher abandonment rates among keyboard users. Fixing this issue often improves overall form completion rates.

Testing Method:

1. Navigate the entire site using only keyboard input
2. Identify any points where the focus indicator disappears behind page elements
3. Test with browser zoom at 200% to identify issues that appear at higher magnification
4. Use automated tools like axe-core to identify potential focus issues

Common Violations and Fixes

Sticky Navigation Overlays:

• Problem: Fixed headers with high z-index values hide focused elements
• Solution: Implement scroll-margin-top or dynamic positioning adjustments

Modal Dialog Issues:

• Problem: Background content remains focusable while modal is open
• Solution: Implement proper focus trapping and background content hiding

Floating Chat Widgets:

• Problem: Chat buttons or expanded windows cover focused form fields
• Solution: Position chat elements to avoid common focus areas or implement collision detection

2.4.12 Focus Not Obscured (Enhanced) – Level AAA

Enhanced Requirements

The AAA version requires that no part of the focus indicator be obscured by author-created content, providing superior keyboard navigation experience.

Implementation Difference: While Level AA allows partial obscuring, Level AAA requires complete visibility of focus indicators.

When to Implement: Consider for high-stakes interfaces like financial transactions, healthcare portals, or accessibility-focused organizations seeking industry leadership.

2.4.13 Focus Appearance – Level AAA

Standardizing Focus Visibility

This criterion establishes specific requirements for focus indicator appearance, ensuring consistent, clearly visible focus across all interface elements.

Technical Specifications:

• Minimum area: Focus indicator must be at least 2 CSS pixels thick around the perimeter
• Contrast requirements: 3:1 contrast ratio against adjacent colors
• Change indicator: Focus state must visually differ from unfocused state

Implementation Example:

/* WCAG 2.4.13 compliant focus styling */
*:focus {
    outline: 2px solid #005fcc;
    outline-offset: 2px;
    /* Ensures 3:1 contrast ratio against most backgrounds */
}

/* Enhanced focus for better visibility */
button:focus,
input:focus,
select:focus,
textarea:focus {
    outline: 3px solid #0066cc;
    outline-offset: 2px;
    box-shadow: 0 0 0 1px #ffffff, 0 0 0 4px #0066cc;
}

2.5.7 Dragging Movements – Level AA

Addressing Touch Interface Barriers

Many modern interfaces rely on drag-and-drop, swiping, or pinching gestures that may be impossible for users with motor disabilities or those using assistive technologies.

Scope of Requirement: Any functionality that requires dragging movements must provide an alternative method using single-point activation (clicking, tapping, or keyboard interaction).

Common Implementations and Solutions

Image Carousels and Sliders:

• Standard Implementation: Swipe-only navigation
• Accessible Solution: Add previous/next buttons alongside swipe functionality
• Enhanced Option: Include keyboard arrow key support and dot navigation

<!-- Accessible carousel implementation -->
<div class="carousel" role="region" aria-label="Featured products">
    <button class="carousel-prev" aria-label="Previous product">‹</button>
    <div class="carousel-content">
        <!-- Carousel items -->
    </div>
    <button class="carousel-next" aria-label="Next product">›</button>
    <div class="carousel-dots">
        <button aria-label="Go to product 1" class="active"></button>
        <button aria-label="Go to product 2"></button>
        <button aria-label="Go to product 3"></button>
    </div>
</div>

Drag-and-Drop File Uploads:

• Standard Implementation: Drag-only file dropping
• Accessible Solution: Include traditional file input button
• Best Practice: Make both methods equally prominent

<!-- Accessible file upload -->
<div class="file-upload-area">
    <div class="drag-drop-zone">
        <p>Drag files here to upload</p>
        <strong>or</strong>
        <button type="button" onclick="document.getElementById('file-input').click()">
            Choose Files
        </button>
    </div>
    <input type="file" id="file-input" multiple style="display: none;">
</div>

Sortable Lists and Reordering:

• Standard Implementation: Drag-to-reorder functionality
• Accessible Solution: Up/down arrow buttons or dropdown position selectors

Business Considerations

Mobile Accessibility: These alternatives often improve usability for all mobile users, not just those with disabilities.

Touch Target Optimization: Implementing single-point alternatives typically requires attention to touch target sizing, creating compound accessibility benefits.

2.5.8 Target Size (Minimum) – Level AA

Mobile-First Accessibility Requirements

Touch targets must be at least 24×24 CSS pixels to ensure users with motor difficulties can accurately activate interface elements on touch devices.

Critical Business Impact: This requirement directly affects mobile conversion rates, as difficult-to-tap elements frustrate all users and create barriers for people with motor disabilities.

Technical Implementation

Minimum Requirements:

• Target size: 24×24 CSS pixels minimum
• Spacing consideration: Targets can be smaller if adequate spacing exists
• Equivalent alternatives: Small targets acceptable if larger alternatives exist elsewhere

CSS Implementation:

/* Ensure minimum touch target sizes */
button,
input[type="button"],
input[type="submit"],
.clickable-element {
    min-height: 24px;
    min-width: 24px;
    padding: 8px 12px; /* Provides comfortable touch area */
}

/* For smaller visual elements, expand the clickable area */
.small-icon-button {
    position: relative;
    display: inline-block;
}

.small-icon-button::before {
    content: '';
    position: absolute;
    top: -12px;
    left: -12px;
    right: -12px;
    bottom: -12px;
    min-width: 24px;
    min-height: 24px;
}

Practical Applications

Navigation Menus:

• Problem: Compact hamburger menus with tiny touch targets
• Solution: Ensure menu items and toggles meet minimum size requirements

Form Controls:

• Problem: Small checkboxes and radio buttons
• Solution: Expand clickable areas to include labels and provide adequate spacing

Social Media Icons:

• Problem: Tiny social sharing buttons
• Solution: Implement minimum sizing or group into larger, accessible components

Testing and Validation

Browser Developer Tools: Use device simulation to test touch target sizes across different screen densities.

Real Device Testing: Test on actual mobile devices with various finger sizes and motor abilities.

Automated Detection: Tools like axe-core can identify targets that fail size requirements.

3.2.6 Consistent Help – Level A

Reducing Cognitive Load Through Predictable Assistance

Help mechanisms must appear in the same relative order across pages, reducing the cognitive burden for users who need assistance finding help.

Covered Help Mechanisms:

• Contact information (phone, email, address)
• Help desk or support portal links
• Automated help options (chatbots, FAQ)
• Self-help resources (documentation, tutorials)

Implementation Strategy

Consistent Footer Pattern:

<!-- Maintain this order across all pages -->
<footer>
    <nav aria-label="Help and support">
        <ul>
            <li><a href="/contact">Contact Us</a></li>
            <li><a href="/help">Help Center</a></li>
            <li><a href="/faq">FAQ</a></li>
            <li><a href="/support">Live Chat</a></li>
        </ul>
    </nav>
</footer>

Template-Based Consistency: Use content management systems or templating engines to ensure help mechanisms appear identically across pages.

Business Benefits

Reduced Support Costs: Users who can easily find help are less likely to require direct support intervention.

Improved User Confidence: Predictable help availability increases user willingness to complete complex tasks.

3.3.7 Redundant Entry – Level A

Eliminating Unnecessary Data Re-entry

Users should not be required to re-enter information they’ve previously provided within the same session or process, unless necessary for security or data verification.

Scope and Exceptions:

• Session persistence: Information entered earlier in a process should be remembered
• Security exceptions: Passwords and sensitive data may require re-entry
• Verification exceptions: Confirmation fields (like email verification) remain acceptable

Technical Implementation

Form State Management:

// Session storage for form persistence
class FormPersistence {
    constructor(formId) {
        this.formId = formId;
        this.form = document.getElementById(formId);
        this.initializePersistence();
    }
    
    initializePersistence() {
        // Load saved data on page load
        this.loadFormData();
        
        // Save data on input changes
        this.form.addEventListener('input', (e) => {
            this.saveFieldData(e.target);
        });
    }
    
    saveFieldData(field) {
        if (field.type !== 'password') { // Exclude sensitive fields
            const key = `${this.formId}_${field.name}`;
            sessionStorage.setItem(key, field.value);
        }
    }
    
    loadFormData() {
        const formData = new FormData(this.form);
        for (let [name, value] of formData) {
            const key = `${this.formId}_${name}`;
            const savedValue = sessionStorage.getItem(key);
            if (savedValue) {
                const field = this.form.querySelector(`[name="${name}"]`);
                if (field && field.type !== 'password') {
                    field.value = savedValue;
                }
            }
        }
    }
}

Multi-Step Process Optimization:

• Progress indication: Show users where they are in the process
• Data persistence: Maintain information across steps
• Validation feedback: Provide immediate feedback to prevent later re-entry

E-commerce Applications

Checkout Optimization: Store shipping information for billing, allow address reuse, and maintain cart contents across sessions.

Account Creation: Pre-populate registration forms with information provided during checkout.

3.3.8 Accessible Authentication (Minimum) – Level AA

Revolutionary Authentication Requirements

This criterion fundamentally changes how we think about user authentication by requiring alternatives to cognitive function tests.

Prohibited Authentication Methods (unless alternatives exist):

• Memory tests: Passwords, security questions, PINs
• Cognitive puzzles: CAPTCHAs requiring problem-solving
• Recognition tests: “Select all images with traffic lights”
• Personal information: “What street did you grow up on?”

Alternative Authentication Methods

Biometric Authentication:

<!-- Web Authentication API implementation -->
<button id="biometric-login" onclick="authenticateWithBiometrics()">
    Sign in with fingerprint or face recognition
</button>

<script>
async function authenticateWithBiometrics() {
    if (window.PublicKeyCredential) {
        try {
            const credential = await navigator.credentials.get({
                publicKey: {
                    challenge: new Uint8Array(32),
                    allowCredentials: [{
                        id: userCredentialId,
                        type: 'public-key'
                    }]
                }
            });
            // Process authentication
        } catch (error) {
            // Fallback to alternative method
            showEmailVerification();
        }
    }
}
</script>

Email Verification Links:

• Implementation: Send unique, time-limited login links instead of requiring password entry
• User Experience: Users click link in email to authenticate
• Security: Links expire and are single-use

OAuth Integration:

• Single Sign-On: Allow authentication through established platforms (Google, Facebook, Microsoft)
• Reduced Friction: Users don’t need to remember site-specific credentials
• Security Benefits: Leverage platform security measures

Business Implementation Strategy

Gradual Transition: Implement accessible authentication alongside traditional methods initially.

User Education: Help users understand and adopt new authentication methods.

Fallback Options: Always provide multiple authentication paths for user choice.

3.3.9 Accessible Authentication (Enhanced) – Level AAA

Complete Elimination of Cognitive Tests

The AAA version removes all cognitive function test requirements, providing the highest level of authentication accessibility.

Implementation: All authentication must use methods that don’t require users to remember, manipulate, or process information cognitively.

Enterprise Considerations: Financial services and healthcare organizations may find this level necessary for comprehensive accessibility.

Integration and Implementation Planning

Prioritization Framework

High Impact, Low Effort:

1. Focus Not Obscured (2.4.11): Often requires simple CSS adjustments
2. Target Size (2.5.8): Improves usability for all mobile users
3. Consistent Help (3.2.6): Template-based implementation

High Impact, Medium Effort:

1. Redundant Entry (3.3.7): Requires session management implementation
2. Dragging Movements (2.5.7): Needs alternative interaction methods

High Impact, High Effort:

1. Accessible Authentication (3.3.8/3.3.9): May require fundamental authentication redesign

Testing and Validation Strategy

Automated Testing Integration: Include WCAG 2.2 criteria in continuous integration pipelines using tools that support the latest standards.

Manual Testing Protocols: Develop testing checklists specific to each new criterion.

User Testing: Include users with disabilities in testing processes to validate real-world effectiveness.

Maintenance and Evolution

Standard Updates: Monitor WCAG working group for additional clarifications and implementation guidance.

Technology Evolution: Stay current with browser support for new accessibility APIs and authentication methods.

Team Training: Ensure development teams understand the business rationale and technical implementation of each new criterion.

---

Preparing for Implementation Success

Understanding WCAG 2.2’s new requirements provides the foundation for modern accessibility compliance. The next chapter transforms this knowledge into practical action with a comprehensive compliance checklist that guides systematic implementation.

You’ll discover step-by-step procedures for auditing your current site against all WCAG 2.2 requirements, prioritizing improvements for maximum impact, and validating your implementations to ensure lasting compliance.

Ready to turn expertise into execution? Chapter 4 provides the tactical implementation framework that transforms accessibility knowledge into business results.