WCAG 2.2 Testing Checklist: Every New Success Criterion Explained

WCAG 2.2: What Changed for QA Teams

WCAG 2.2 introduces nine new success criteria that significantly impact your testing protocols. Released in October 2023, this update focuses heavily on mobile accessibility, cognitive disabilities, and user interface improvements. For enterprise QA teams, these changes require immediate attention as they're already being enforced by government agencies and courts.

The new criteria span all conformance levels: five at AA level (which most organizations target), three at A level, and one at AAA level. Unlike previous updates, WCAG 2.2 emphasizes practical user scenarios that your testing team encounters daily - from focus management in single-page applications to mobile touch target sizing.

Key testing areas now include authentication processes, mobile interaction patterns, and cognitive load reduction. Your existing automated testing tools like axe-core and Pa11y will catch some violations, but manual testing becomes crucial for criteria like "Consistent Help" and "Redundant Entry." Plan for 15-20% additional testing time to properly validate these new requirements across your web applications.

Testing Focus Appearance (2.4.11 AA)

Focus Appearance replaces the problematic Focus Visible criterion and requires visible focus indicators that meet specific contrast and size requirements. Your focus indicators must have a contrast ratio of at least 3:1 against adjacent colors and encompass the focused element with adequate thickness.

Use browser developer tools to test systematically. In Chrome DevTools, navigate to Elements > Styles and toggle :focus-visible states. Measure focus indicator thickness - it must be at least 2 CSS pixels thick or have an area equal to a 1px solid border around the element. For complex components like custom dropdowns or card layouts, verify the focus outline completely surrounds the interactive area.

Common failures include focus indicators that disappear on certain backgrounds, thin outlines on large buttons, and missing focus states on custom components. Test with keyboard navigation using Tab, Shift+Tab, and arrow keys. Tools like axe DevTools can identify missing focus states, but manual verification of contrast ratios using Colour Contrast Analyser remains essential for compliance validation.

Testing Focus Not Obscured (2.4.12 AA, 2.4.13 AAA)

Focus Not Obscured ensures keyboard users can always see focused elements, addressing common issues with sticky headers, modal overlays, and mobile keyboards. The AA level (2.4.12) requires the focused element to not be entirely hidden, while AAA level (2.4.13) demands no part be obscured.

Test systematically across different viewport sizes, starting with 320px width for mobile. Navigate through forms, navigation menus, and interactive elements using only keyboard input. Pay special attention to elements near fixed headers, floating action buttons, and cookie banners. Use browser zoom up to 200% and verify focused elements remain visible without requiring scrolling.

Document common problem areas: form inputs behind sticky navigation, modal close buttons hidden by mobile keyboards, and pagination controls obscured by chat widgets. For single-page applications using frameworks like React or Vue, test focus management during route changes and dynamic content updates. Screen recording tools help capture focus behavior for stakeholder review and developer handoff documentation.

Testing Dragging Movements (2.5.7 AA)

This criterion requires alternative methods for any functionality that depends on dragging gestures, such as sliders, drag-and-drop interfaces, and reordering lists. Users with motor disabilities must have single-pointer alternatives to complete these interactions successfully.

Identify all drag interactions in your application: image carousels, sortable lists, range sliders, file upload areas, and kanban boards. For each dragging interface, verify alternative input methods exist. Sliders need increment/decrement buttons or direct value input. Drag-and-drop file uploads require browse buttons. Sortable lists need keyboard controls or move-up/move-down buttons.

Test alternatives thoroughly - they should provide equivalent functionality, not reduced capability. For complex interfaces like calendar scheduling or data visualization tools, document the alternative interaction patterns. Use assistive technology like NVDA or JAWS to verify alternatives are properly announced. Tools like axe-core 4.6+ include basic detection for this criterion, but comprehensive testing requires manual validation of alternative interaction methods across different devices and input modalities.

Testing Target Size Minimum (2.5.8 AA)

Target Size Minimum mandates that clickable elements measure at least 24×24 CSS pixels, significantly larger than the previous 44×44 pixel guideline from mobile accessibility best practices. This criterion applies to all interactive elements including buttons, links, form controls, and custom interactive components.

Use browser developer tools to measure elements precisely. In Chrome DevTools, select elements and view computed dimensions in the Box Model panel. Elements smaller than 24×24 pixels must either be resized or have adequate spacing (24 pixels) from other interactive elements. Exceptions include inline links within text blocks and elements where size is essential to functionality.

Focus testing efforts on dense interfaces: navigation menus, data tables with action buttons, tag clouds, and mobile form controls. Icon-only buttons frequently violate this criterion - verify they meet size requirements or have sufficient spacing. For responsive designs, test across breakpoints as element sizes often change. Create a target size testing checklist including social media buttons, pagination controls, and mobile hamburger menus, as these commonly fail compliance audits.

Testing Consistent Help (3.2.6 A)

Consistent Help requires help mechanisms to appear in the same relative order across pages when multiple help options are available. This affects contact information, help documentation links, live chat buttons, and support ticket systems throughout your website or application.

Map all help mechanisms across your site: contact forms, phone numbers, help documentation, live chat widgets, FAQ sections, and tutorial links. Document their placement and order on different page types - homepage, product pages, checkout flow, and user dashboards. The relative order must remain consistent, though not all help options need to appear on every page.

Common violations occur when help elements shift position based on page layout or when different teams implement help features inconsistently. For e-commerce sites, verify help options maintain consistent ordering from product browsing through checkout completion. Single-page applications require special attention as help element positioning can change during route transitions. Create a help placement style guide to ensure development teams maintain consistency across future releases and design iterations.

Testing Redundant Entry (3.3.7 A)

Redundant Entry prevents users from re-entering the same information within a single session or process, reducing cognitive load and improving user experience. This criterion significantly impacts multi-step forms, checkout processes, and account registration flows.

Test all multi-step processes systematically. In checkout flows, verify shipping information auto-populates billing fields when users select "same as shipping." Account registration should not require password re-entry if secure input methods are available. Form data should persist when users navigate back to previous steps or recover from validation errors.

Essential information like passwords, credit card security codes, and biometric data are exempt from this requirement. However, names, addresses, phone numbers, and email addresses should not require re-entry within the same process. For complex applications, test scenarios where users might switch between tabs, experience session timeouts, or encounter server errors. Document expected auto-population behavior and verify your application remembers user input appropriately without compromising security requirements or user privacy.

Testing Accessible Authentication (3.3.8 AA, 3.3.9 AAA)

Accessible Authentication removes cognitive function barriers from login processes. The AA level (3.3.8) prohibits memory tests and cognitive puzzles, while AAA level (3.3.9) eliminates recognition tests. This directly impacts password policies, CAPTCHA implementation, and two-factor authentication methods.

Audit all authentication mechanisms: login forms, password reset flows, two-factor authentication, and account recovery processes. Verify that password managers can auto-fill credentials and that users aren't forced to memorize complex passwords without password manager support. Replace traditional CAPTCHAs with accessible alternatives like hCaptcha or implement risk-based authentication that doesn't burden users with cognitive tests.

Test multi-factor authentication options - SMS codes and authenticator apps are acceptable, but avoid systems requiring users to remember specific images or solve puzzles. For enterprise applications, coordinate with security teams to implement authentication methods that maintain security while removing cognitive barriers. Document acceptable authentication alternatives and verify backup access methods don't introduce additional cognitive requirements for users with disabilities.

Implementation Strategy for QA Teams

Implementing WCAG 2.2 testing requires updating your existing accessibility testing protocols and training team members on new success criteria. Start by auditing your current testing checklist and identifying gaps where WCAG 2.2 criteria aren't covered by existing automated tools or manual testing procedures.

Update your testing environments to include mobile devices and touch interfaces, as several new criteria specifically address mobile accessibility. Integrate focus appearance testing into your keyboard navigation protocols and establish consistent measurement procedures for target size validation. Train team members to identify dragging interactions and verify alternative input methods during functional testing.

Collaborate with development teams to establish coding standards that prevent common violations. Create component libraries with accessible focus indicators, implement consistent help placement patterns, and establish form handling that prevents redundant entry requirements. Plan for gradual rollout across existing applications, prioritizing high-traffic user flows and critical business processes. Regular training sessions and updated testing documentation ensure your team stays current with evolving accessibility requirements and testing methodologies.

Frequently Asked Questions

Do existing automated accessibility testing tools detect WCAG 2.2 violations?

Most automated tools have limited WCAG 2.2 coverage. axe-core 4.6+ detects some violations like missing focus indicators and small target sizes, but criteria like Consistent Help and Redundant Entry require manual testing. Update your automated testing suite and plan for increased manual validation.

How long should QA teams allocate for WCAG 2.2 testing in sprint planning?

Add 15-20% additional time to your current accessibility testing allocation. New criteria like Focus Not Obscured and Target Size require systematic measurement across multiple viewports and devices, while authentication and form flow testing becomes more comprehensive.

Which WCAG 2.2 changes have the biggest impact on mobile app testing?

Target Size Minimum (24×24 pixels) and Focus Not Obscured significantly impact mobile testing. These criteria require testing touch interfaces, virtual keyboard behavior, and focus management in responsive designs. Mobile-first testing approaches become essential for compliance.

Are there exceptions to the new target size requirements in WCAG 2.2?

Yes, inline links within text blocks are exempt, as are elements where size is essential to functionality (like map pins). Elements smaller than 24×24 pixels must have 24 pixels of spacing from other interactive elements to comply.

How do WCAG 2.2 authentication requirements affect password policies?

Organizations must ensure password managers can function properly and avoid requiring users to memorize complex passwords without tool support. CAPTCHA systems need accessible alternatives, and cognitive function tests in authentication flows must be eliminated.

Resources and Further Reading

WCAG 2.2 Official Specification Complete W3C documentation with detailed explanations of all WCAG 2.2 success criteria
axe-core Accessibility Testing Engine Open-source automated accessibility testing library with WCAG 2.2 support
WebAIM's WCAG 2.2 Checklist Comprehensive testing checklist covering all WCAG 2.2 success criteria with practical examples
Colour Contrast Analyser Tool Free tool for testing color contrast ratios required by WCAG 2.2 focus appearance criteria
NVDA Screen Reader Free screen reader for testing accessibility compliance and assistive technology compatibility