WCAG 2.2 is the current W3C standard with 86 success criteria — 9 new since WCAG 2.1. Courts are citing it in ADA cases, and the European Accessibility Act is adopting it through EN 301 549. This interactive checklist covers every new criterion with implementation guidance.
WCAG 2.2 was published as a W3C Recommendation on October 5, 2023. It is fully backward-compatible with WCAG 2.1 — all existing criteria remain (except 4.1.1 Parsing, which was removed as obsolete). The 9 new criteria target three underserved user groups: people with cognitive and learning disabilities, people with low vision, and people with motor impairments using mobile or touch devices.
For organizations already meeting WCAG 2.1 AA, achieving WCAG 2.2 AA requires addressing just 6 additional criteria. For everyone else, WCAG 2.2 AA is the target to aim for — it encompasses all of 2.1 AA plus the new requirements.
The DOJ's 2024 ADA Title II rule specifies WCAG 2.1 AA as the minimum. But WCAG 2.2 is already being cited in federal court proceedings. The European Accessibility Act (effective June 2025) is adopting WCAG 2.2 through EN 301 549. Organizations that implement WCAG 2.2 AA now have the strongest possible compliance posture for both current and upcoming regulations.
Automated scanners catch only 30–40% of WCAG 2.2 issues. Many of the new criteria — particularly those addressing cognitive accessibility and focus management — require human evaluation.
Click any criterion to expand implementation details. Check items off as you address them. Your progress is tracked below.
People with motor impairments who cannot perform drag-and-drop gestures, including users of switch devices, mouth sticks, eye-tracking systems, and those with tremors or limited dexterity. Also benefits mobile users in one-handed or accessibility modes.
Provide click-to-select and click-to-place as an alternative to drag. For sliders, add increment/decrement buttons. For sortable lists, add "Move Up" / "Move Down" controls. For maps, provide zoom buttons and directional pads alongside pinch-and-drag. Ensure all alternatives are keyboard-accessible.
People with cognitive, memory, and learning disabilities. Users who struggle with CAPTCHAs, complex passwords, or multi-step verification requiring recall. Also benefits users with anxiety or processing disorders.
Support password managers (don't block paste in login fields). Offer email/SMS magic links, OAuth/SSO sign-in, biometric authentication, or passkeys. If CAPTCHAs are required, provide object recognition alternatives — not text transcription. Allow copy-paste of verification codes.
Sighted keyboard users and people with low vision who rely on focus indicators. When focus lands behind a sticky header or chat widget, users cannot see where they are on the page and may think their system has frozen.
Add scroll-padding-top equal to sticky header height. Ensure cookie banners and chat widgets don't overlap focused content. Use scroll-margin on anchor targets. Test by tabbing through every page with all sticky elements visible. Banners opened by the user are excluded from this requirement.
People with motor impairments, tremors, or limited fine-motor control. Mobile users operating devices one-handed or in motion. Older adults with reduced precision. Users of styluses, mouth sticks, or head pointers.
Set minimum min-height and min-width of 24px on buttons, links in navigation, form controls, and icon buttons. For smaller elements, ensure 24px of non-overlapping space by adding padding or margin. Audit icon buttons — they're the most common violators. Inline text links are exempt.
People with cognitive disabilities who rely on consistent, predictable interfaces. Users who need help completing tasks but struggle to locate support when it moves between pages. Also benefits all users through improved UX consistency.
Place help links (contact, chat, FAQ) in a consistent location — typically the footer or a fixed-position chat widget. Ensure the help mechanism appears in the same relative order within your page template on every page. If using a floating chat bubble, keep it in the same corner across all pages.
People with cognitive disabilities, memory impairments, and executive function limitations. Users who find form completion time-consuming or error-prone. Benefits everyone by reducing friction in multi-step processes like checkout and applications.
In multi-step forms, auto-populate fields from previous steps (e.g., shipping address → billing address). Provide "same as above" checkboxes. Store session data to persist across steps. For checkout flows, pre-fill known customer data. Review all multi-page processes for redundant fields.
The same users as 2.4.11, but this enhanced version eliminates even partial obstruction. Particularly important for users with low vision who need to see the entire focused element and its indicator.
All the same techniques as 2.4.11, plus ensure that sticky elements and overlays leave enough clearance for the full focus indicator (typically 2-3px outline). Test with visible focus indicators at every scroll position. Consider reducing sticky header height or making it collapsible.
People with low vision who cannot see thin or low-contrast focus indicators. Keyboard-only users who need clear visual confirmation of their position. Older adults with age-related vision changes.
Use outline: 2px solid with a color that has ≥3:1 contrast against adjacent colors. Avoid outline: none without replacement. For dark backgrounds, use light outlines; for light backgrounds, use dark outlines. Test with the browser's default focus indicator disabled. A 2px solid outline in a contrasting color passes in most cases.
The same users as 3.3.8, with additional protection for people who struggle with image-based recognition tests (e.g., "click all traffic lights"). Particularly benefits users with visual processing disorders.
All the same techniques as 3.3.8, but also eliminate image recognition CAPTCHAs. Use invisible reCAPTCHA, honeypot fields, or rate limiting instead of visual challenges. Support passkeys and WebAuthn for the most accessible authentication possible.
WCAG 2.2 removes Success Criterion 4.1.1 Parsing (previously Level A). Modern browsers and assistive technologies now handle HTML parsing robustly, making this criterion obsolete. Focus on semantic correctness and proper ARIA usage instead of strict parsing validation.
Not all criteria carry equal risk. Here's the recommended order based on legal exposure, user impact, and implementation effort.
2.5.8 Target Size (Minimum) — Most commonly violated on mobile. Easy to audit, easy to fix, and directly cited in accessibility lawsuits.
3.3.7 Redundant Entry — Checkout and form flows are primary lawsuit targets. Multi-step forms that re-ask for information are a clear violation.
2.4.11 Focus Not Obscured — Sticky headers hiding focused elements is extremely common and blocks keyboard-only users.
3.3.8 Accessible Authentication — Blocking paste in login fields or requiring CAPTCHAs without alternatives locks out users with cognitive disabilities.
2.5.7 Dragging Movements — Only affects sites with drag-and-drop interfaces, sliders, or interactive maps.
3.2.6 Consistent Help — Low implementation effort. Audit help mechanism placement across pages for consistency.
You only need to address the 6 new Level A and AA criteria listed above. The 3 Level AAA criteria (Focus Not Obscured Enhanced, Focus Appearance, Accessible Authentication Enhanced) are recommended but not required for legal compliance. Most organizations can achieve WCAG 2.2 AA within 2–4 weeks from a 2.1 AA baseline.
Our experts evaluate every page against all 86 WCAG 2.2 success criteria — then fix what's broken in your actual source code. One-time cost, permanent fixes.
Start Your AssessmentRelated: Title II Deadline · Overlay vs. Remediation