WCAG 2.2: What Actually Changed and Why It Matters
WCAG 2.2 became the recommended standard in October 2023. If you have been putting off reviewing the changes, now is the time.
The good news: most of 2.1 carries over. If your product was already compliant, you are not starting from scratch. The new success criteria target specific pain points that were not adequately covered before.
Let's break down what is new and what you need to do about it.
Focus appearance gets stricter
The new Focus Appearance criterion raises the bar for visible focus indicators. They need to be more prominent than before, with specific size and contrast requirements.
Your focus indicators must be at least 2 CSS pixels thick or have an area at least as large as a 2 pixel thick perimeter. They need 3:1 contrast against both the focused component and the background.
This directly addresses a common issue: focus indicators that are technically present but practically invisible. If users cannot see where focus is, keyboard navigation becomes guesswork.
Help for people with cognitive disabilities
Several new criteria specifically target cognitive accessibility. These are areas where previous versions of WCAG were notably weak.
Consistent Help means if you offer help mechanisms like contact info or chatbots, they appear in the same relative location across pages. Users should not hunt for support options on every page.
Redundant Entry prevents forcing users to enter the same information multiple times in a single session. If they have already given you their email address, do not make them type it again three pages later.
These seem obvious, yet they address real frustrations users face daily. Implementing them improves the experience for everyone, not just people with disabilities.
Authentication without cognitive tests
The Accessible Authentication criterion tackles a major accessibility barrier: cognitive function tests required to log in.
At Level AA, you cannot require users to solve puzzles, remember passwords, or transcribe text from images unless you provide an alternative. Password managers count as an alternative. So do biometric authentication and magic links.
This has major implications for how you implement login flows. Pure memorisation requirements are out. You need cognitive function test free alternatives.
Dragging movements need alternatives
Any functionality that relies on dragging must have a single pointer alternative. This covers drag and drop interfaces, sliders, sortable lists, anything requiring a dragging motion.
The fix usually means adding buttons or other controls that achieve the same result. A sortable list gets up and down buttons. A slider gets increment and decrement controls. A drag and drop file upload gets a traditional file picker.
This benefits people with motor disabilities who struggle with precise dragging motions, but also users on devices where dragging is awkward or unreliable.
Target size gets more specific
Touch targets need to be at least 24 by 24 CSS pixels, with some exceptions for inline links and controls where increasing the size would fundamentally change the functionality.
This is smaller than the 44 by 44 pixel requirement at Level AAA, but it is now required at Level AA. The practical impact: most of your interactive elements need to be bigger.
Check your icon buttons, close buttons on modals, and any compact UI controls. They probably need more padding or larger hit areas.
What this means for your roadmap
WCAG 2.1 is not deprecated. You have time to plan your transition. But legal requirements will eventually catch up, and early adopters gain competitive advantage.
Start with an audit against the new criteria. Identify gaps. Prioritise fixes based on user impact and implementation effort. Work them into your regular sprint planning rather than treating them as a separate project.
The changes in WCAG 2.2 are not arbitrary. They address real user needs that were not adequately covered before. Meeting them makes your product genuinely better for your users.
