WCAG 2.2 Checklist: 9 New Success Criteria Explained

A WCAG 2.2 checklist provides engineering, design, and QA teams with the precise criteria needed to evaluate digital products against the latest international accessibility standard. Published by the World Wide Web Consortium (W3C) Web Accessibility Initiative, WCAG 2.2 builds directly upon previous versions while extending essential protections for users with cognitive, motor, and vision disabilities.

Adopting an actionable WCAG 2.2 checklist ensures that product teams do not merely audit legacy standards, but proactively engineer solutions that accommodate real-world assistive technology interactions. While organizations historically benchmarked against WCAG 2.1 AA, global regulatory bodies and procurement teams now reference the official W3C WCAG 2.2 Recommendation as the gold standard for enterprise accessibility.

Summary: Key Shifts in the WCAG 2.2 Framework

9 New Success Criteria: 2 at Level A, 4 at Level AA, and 3 at Level AAA.
1 Success Criterion Removed: Criterion 4.1.1 (Parsing) has been officially obsoleted.
Enhanced User Group Focus: Substantially expanded accommodations for users with cognitive limitations, attention deficits, and mobility challenges.
Direct Procurement Impact: Aligns with the upcoming enforcement timeline of the European Accessibility Act (Directive 2019/882).

What Changed Between WCAG 2.1 and WCAG 2.2

When expanding beyond WCAG 2.1, your updated WCAG 2.2 checklist must account for cognitive disabilities, low-vision users, and mobile touch targets. The underlying architecture remains backward compatible: any web page that conforms to WCAG 2.2 automatically satisfies WCAG 2.1 and WCAG 2.0. However, WCAG 2.2 addresses modern interface paradigms that previous revisions failed to anticipate, such as modal backdrops obscuring focused buttons, drag-and-drop workflow barriers, and memory-intensive authentication puzzles.

Crucially, WCAG 2.2 marks the first time in W3C history that an existing success criterion has been retired. Success Criterion 4.1.1 Parsing was marked as obsolete because modern browsers, assistive technologies, and HTML5 parsers now automatically correct common markup syntax errors that previously broke screen readers in the HTML 4 era.

Standard Version	Total Criteria	Primary Focus Areas	Legal Benchmark Status
WCAG 2.0 (2008)	61 criteria	Desktop web, HTML tables, static links, semantic markup	Section 508 baseline, legacy settlements
WCAG 2.1 (2018)	78 criteria	Mobile devices, responsive reflow, orientation, contrast	DOJ Title II Rule, global gold standard
WCAG 2.2 (Current)	86 criteria (9 new, 1 removed)	Touch target size, drag alternatives, auth memory, focus visibility	European Accessibility Act, modern enterprise RFPs

The 9 New Success Criteria: Level A Requirements

At Level A, the WCAG 2.2 checklist introduces essential guardrails for consistent user assistance and form efficiency. Level A criteria represent absolute foundational requirements; failing any Level A criterion creates a total blocker for specific assistive technology users.

SC 3.2.6 • Level A
Guideline 3.2: Predictable

Consistent Help

If a web page contains help mechanisms (such as human contact details, contact forms, self-help FAQs, or automated chatbots), those mechanisms must appear in the exact same relative order across all pages within the multi-page set.

Checklist Action: Ensure support links in your footer or floating chat widgets occupy an identical DOM and visual position across all page templates.

SC 3.3.7 • Level A
Guideline 3.3: Input Assistance

Redundant Entry

Information previously entered by or provided to the user that is required again in the same multi-step process must either be auto-populated or available for the user to select, unless re-entering the information is essential (e.g., verifying a password) or security-critical.

Checklist Action: In multi-page checkout flows, provide a “Same as billing address” checkbox to avoid forcing users with cognitive or motor fatigue to retype street addresses.

The 9 New Success Criteria: Level AA Requirements

For enterprise organizations targeting legal compliance, Level AA within the WCAG 2.2 checklist forms the primary benchmark for procurement and regulatory audits. The four new Level AA criteria represent substantial updates for modern web applications.

SC 2.4.11 • Level AA

Focus Not Obscured (Minimum)

When a user interface component receives keyboard focus, the component must not be entirely hidden due to author-created content (such as sticky headers, floating cookie banners, or sticky action bars).

SC 2.5.7 • Level AA

Dragging Movements

All functionality that uses a dragging movement for operation must be achievable by a single pointer without dragging, unless dragging is essential (such as freehand drawing canvas tools).

SC 2.5.8 • Level AA

Target Size (Minimum)

The size of the target for pointer inputs must be at least 24 by 24 CSS pixels, unless there is sufficient spacing between adjacent targets or the target is inline within running text.

SC 3.3.8 • Level AA

Accessible Authentication (Minimum)

A cognitive function test (such as remembering a password or solving an equation) must not be required for any step in an authentication process unless an alternative or assistance mechanism is provided.

Mobile & Touch Interaction Requirements

Mobile responsive design requires your WCAG 2.2 checklist to rigorously verify minimum target sizes of 24 by 24 CSS pixels. Under Success Criterion 2.5.8 Target Size (Minimum), small touch targets that were technically compliant under WCAG 2.1 now trigger conformance failures unless properly spaced.

According to the W3C Quick Reference Guide for Target Size, if a button measures 18 by 18 CSS pixels, it can still pass SC 2.5.8 if the interactive area has at least 3 pixels of circular buffer spacing surrounding it, preventing accidental adjacent taps from users with hand tremors.

CSS Remediation: WCAG 2.2 Target Size (SC 2.5.8)

// Bad: 16px icon button with 0 padding causes mis-taps

.icon-button { width: 16px; height: 16px; padding: 0; }

// Good: Expanding touch target to 24px minimum while maintaining visual icon size

.icon-button {
min-width: 24px;
min-height: 24px;
display: inline-flex;
align-items: center;
justify-content: center;
padding: 4px;
}

Similarly, Success Criterion 2.5.7 Dragging Movements mandates that any Kanban board, price range slider, or reorderable list must provide single-tap alternatives. For example, a draggable item must offer “Move Up” and “Move Down” click buttons so users operating head pointers or eye-gaze tracking can complete the task without holding a drag gesture.

Cognitive & Authentication Requirements

Authentication workflows evaluated through a WCAG 2.2 checklist must eliminate cognitive function tests like complex puzzles or CAPTCHAs. Under Success Criterion 3.3.8 Accessible Authentication, users must not be forced to memorize characters, perform mental calculations, or solve distorted visual puzzles to log into their accounts.

Non-Compliant Patterns

Blocking password manager copy-and-paste via JavaScript
CAPTCHAs requiring image pattern recognition or math equations
Requiring users to transcribe two-factor SMS codes manually without paste support
Timed sessions with complex cognitive challenges without extension options

Permitted Compliant Alternatives

Allowing standard clipboard paste for passwords and 2FA tokens
WebAuthn, Passkeys, and biometric device authentication (Touch ID, Face ID)
Magic email login links and OAuth single sign-on (Google, Apple, Microsoft)
Object recognition tests that provide an audio-based alternative mechanism

Focus Appearance & Obscuring Elements

Keyboard accessibility in the WCAG 2.2 checklist mandates that sticky headers or cookie banners never obscure active interactive elements. Under Success Criterion 2.4.11 Focus Not Obscured (Minimum), when a sighted keyboard user tabs through links, input fields, or buttons, author-created overlays must not completely cover the focused element.

Common enterprise culprits include fixed position sticky navigation bars, bottom cookie consent prompts, and floating customer support dialogs. When a user tabs down a webpage, the focused link frequently scrolls underneath a fixed header. To remedy this, developers utilize the CSS scroll-padding-top property on the root container, ensuring that browser scroll actions automatically leave sufficient clearance below fixed headers.

SC 2.4.13 • Level AAA
Focus Appearance Benchmark

While Level AA requires that focus is not completely hidden, Level AAA criterion 2.4.13 defines mathematical parameters for the focus indicator itself: a minimum 2-pixel solid perimeter outline with at least a 3:1 contrast ratio against both the unfocused state and the adjacent background.

Enterprise Developer Implementation & Testing Workflows

Engineering leads integrate the WCAG 2.2 checklist directly into automated pull request checks and manual acceptance testing. While automated rule engines like axe-core catch syntax omissions, manual verification remains indispensable because criteria such as Accessible Authentication (3.3.8) and Consistent Help (3.2.6) involve complex behavioral flows that static scanners cannot interpret.

Professional auditors execute a WCAG 2.2 checklist across representative user journeys, combining assistive technology testing with DOM inspection. Pairing automated linting with certified human evaluations guarantees full legal defense against Section 508 disputes and ADA litigation.

Operational WCAG 2.2 Sprint Checklist for Engineers

Help Mechanism Uniformity: Confirm chat widget, FAQ link, and telephone contact appear at the same relative DOM location on all page views. (SC 3.2.6)
Form Redundancy Prevention: Verify checkout and application forms auto-populate previously collected shipping or personal data. (SC 3.3.7)
Scroll Padding on Fixed Elements: Ensure scroll-padding-top prevents sticky navigation bars from covering focused inputs. (SC 2.4.11)
Single-Pointer Drag Fallbacks: Provide buttons or tap alternatives for any draggable slider, sortable card, or map gesture. (SC 2.5.7)
24×24 Pixel Touch Minimums: Audit all standalone mobile icons, radio buttons, and pagination controls for 24px bounding boxes. (SC 2.5.8)
Unrestricted Password Paste: Remove any JavaScript handlers disabling clipboard paste events across login and registration fields. (SC 3.3.8)

Certified Conformance Assurance

Validate Your Digital Products Against WCAG 2.2

Need an exhaustive evaluation? Download our engineer-reviewed WCAG 2.2 checklist or schedule a certified enterprise audit with our IAAP-accredited accessibility specialists.

Book WCAG 2.2 Audit

Scan Website Free

Frequently Asked Questions

What is the difference between a WCAG 2.1 and a WCAG 2.2 checklist?

A WCAG 2.2 checklist incorporates 9 additional success criteria focused on mobile target sizing (2.5.8), cognitive authentication without memory puzzles (3.3.8), drag-and-drop alternatives (2.5.7), and preventing sticky headers from hiding keyboard focus (2.4.11). Additionally, WCAG 2.2 removes the obsolete 4.1.1 Parsing criterion.

Is adopting a WCAG 2.2 checklist legally required under the ADA?

Title II of the Americans with Disabilities Act specifically benchmarks WCAG 2.1 Level AA for state and local government entities. However, federal courts and enterprise procurement teams treat WCAG 2.2 as the definitive best practice. Complying with WCAG 2.2 automatically ensures full compliance with WCAG 2.1 and 2.0 standards.

Why was Success Criterion 4.1.1 Parsing removed in WCAG 2.2?

Criterion 4.1.1 was created in 2008 when assistive technology relied directly on browser DOM parsing that broke upon minor HTML syntax errors. Modern browsers handle HTML parsing errors uniformly and repair invalid code automatically before exposing the accessibility tree, rendering the rule redundant.

Can automated accessibility scanners verify all WCAG 2.2 criteria?

No. Automated tools can only detect approximately 30% to 40% of WCAG criteria. New requirements such as Accessible Authentication (3.3.8), Dragging Movements (2.5.7), and Consistent Help (3.2.6) involve contextual user experience logic that requires certified human testing.