Learn
What's New in WCAG 2.2
WCAG 2.2 became the W3C Recommendation in October 2023 and is now the current standard. It added 9 new success criteria to address gaps in keyboard accessibility, focus visibility, touch targets, and cognitive load. It also removed one criterion from WCAG 2.1.
This page explains each new criterion in plain language, who it affects, and where you can practice the relevant patterns in the playground.
The 9 new success criteria
WCAG 2.2 is backwards compatible with 2.1. All 2.1 criteria still apply. The 9 new criteria are additions, not replacements. One 2.1 criterion was removed.
01
2.4.11 Focus Appearance (Minimum)
WCAG conformance level AAWhen a keyboard focus indicator is visible, it must meet minimum size and contrast requirements. A thin 1px outline that barely shows is not enough.
Who is affected
- Keyboard-only users
- Low vision users
- Anyone who relies on seeing where focus is
What to do
The focus indicator must have a perimeter of at least the CSS outline with a 2px offset, and must have a 3:1 contrast ratio against adjacent colours.
Try in the playground
02
2.4.12 Focus Appearance (Enhanced)
WCAG conformance level AAAA stricter version of 2.4.11. The focus indicator must be at least as large as a 2px perimeter around the component and meet a higher 4.5:1 contrast ratio.
Who is affected
- Same as 2.4.11, with stricter requirements for users with more significant low vision
What to do
Aim for a clearly visible, high-contrast focus ring on every interactive element. Most well-designed focus styles naturally meet this level.
Try in the playground
03
2.4.13 Focus Appearance
WCAG conformance level AAIn the final WCAG 2.2 Recommendation, this criterion supersedes the draft 2.4.11 Focus Appearance (Minimum) requirement.
The focus indicator must have sufficient size and contrast to be clearly visible. This is the primary focus appearance requirement in WCAG 2.2.
Who is affected
- Keyboard-only users
- Low vision users
What to do
Ensure focus indicators have at least 2px offset, meet 3:1 contrast against adjacent colours, and are clearly distinguishable from unfocused states.
Try in the playground
04
2.5.7 Dragging Movements
WCAG conformance level AAAny action that requires dragging must also be achievable with a single pointer action such as a click or tap. Drag-only interfaces lock out users who cannot perform precise dragging motions.
Who is affected
- People with motor disabilities
- Users with tremors or reduced dexterity
- Anyone using a switch or voice control
What to do
For every drag interaction in your UI, provide an alternative: a button, a click target, or a keyboard shortcut that achieves the same result.
Try in the playground
This playground does not currently have a drag pattern demo. A dedicated component is planned for a future update. For now, see the W3C guidance below.
05
2.5.8 Target Size (Minimum)
WCAG conformance level AAInteractive targets must be at least 24x24 CSS pixels, or have sufficient spacing around them so adjacent targets do not overlap a 24px circle centred on each.
Who is affected
- People with motor disabilities
- Users with tremors or reduced dexterity
- Mobile users with large fingers or imprecise touch
What to do
Aim for 44x44px touch targets for all interactive elements. Use padding rather than increasing the visible size if needed.
Try in the playground
06
3.2.6 Consistent Help
WCAG conformance level AAIf a help mechanism (contact link, chat, phone number, or self-help tool) appears on multiple pages, it must appear in the same location on each page.
Who is affected
- People with cognitive disabilities
- Anyone who relies on predictable page structure
- Users with memory difficulties
What to do
Place help links, contact details, and support options in a consistent location across all pages. The footer or a persistent nav element works well.
Try in the playground
07
3.3.7 Redundant Entry
WCAG conformance level AUsers should not have to enter the same information twice in the same session. If information was already provided, auto-populate it or let users confirm it rather than retyping.
Who is affected
- People with cognitive disabilities
- Users with motor disabilities who find typing difficult
- Anyone completing multi-step forms
What to do
In multi-step forms or processes, carry forward information already entered. Pre-fill known fields and let users confirm rather than re-enter data.
Try in the playground
08
3.3.8 Accessible Authentication (Minimum)
WCAG conformance level AAAuthentication processes must not require users to solve cognitive function tests (puzzles, memory tasks, or transcribing characters) unless an alternative is provided or the test involves recognising objects or personal content.
Who is affected
- People with cognitive disabilities
- Users with dyslexia or memory difficulties
- Anyone who struggles with CAPTCHAs
What to do
Avoid text-based CAPTCHAs without alternatives. Allow password managers to autofill. Provide object recognition alternatives where tests are required.
Try in the playground
09
3.3.9 Accessible Authentication (Enhanced)
WCAG conformance level AAAA stricter version of 3.3.8. No cognitive function tests are allowed at all during authentication, with no exceptions.
Who is affected
- Same as 3.3.8, with no exceptions permitted
What to do
Use passwordless authentication, magic links, or passkeys. If a test is required, it must not involve cognitive tasks of any kind.
Try in the playground
WCAG 2.2 changes and how this site covers them
What was removed from WCAG 2.1
One success criterion was removed in WCAG 2.2:
4.1.1 Parsing (Level A) was removed because modern browsers and assistive technologies handle malformed HTML much better than they did when 2.1 was written. The requirement to have well-formed HTML is now considered a baseline expectation rather than a separately testable criterion.
If you are auditing against WCAG 2.2, you do not need to test for 4.1.1 Parsing.
How this site covers WCAG 2.2
The playground currently covers these 2.2 criteria through existing patterns:
2.4.11 / 2.4.13 Focus Appearance
Navigation, Dropdown, and Modal demonstrate visible focus indicators with sufficient contrast.
2.5.8 Target Size
Icon Button shows correct touch target sizing with padding.
3.2.6 Consistent Help
Navigation shows consistent landmark structure across pages.
3.3.7 Redundant Entry
Form Validation shows patterns that reduce repeated input.
3.3.8 Accessible Authentication
Form Validation shows accessible input patterns without cognitive barriers.
2.5.7 Dragging Movements
PlannedA dedicated playground component is planned for a future update. See the criterion card above for W3C guidance.
Further reading
WCAG in Practice
Dev tools install guidewcag-kit MCP, Claude Skill for Claude Projects, and WCAG Lens for VS Code while you implement fixes.
GitHub
Claude Skill (download) (opens in a new tab)Ask about WCAG 2.2 criteria and UI patterns from Claude Projects with accessibility-aware context.
W3C
WCAG 2.2 official specification (opens in a new tab)The authoritative W3C standard. All 9 new criteria with full understanding documents.
W3C
What's new in WCAG 2.2 (opens in a new tab)A concise W3C summary of every change from 2.1 to 2.2.
WebAIM
WebAIM WCAG 2.2 checklist (opens in a new tab)Practical checklist format for all WCAG 2.2 criteria.
Put it into practice
See WCAG 2.2 patterns in the playground
Open interactive demos for focus, target size, forms, and navigation. Pair this page with Accessibility is for everyone for disability context, or use the page checker on a live URL.