WCAG 2.1 vs 2.2: Key Differences Explained

Quick answer: WCAG 2.1 vs WCAG 2.2

WCAG 2.1 and WCAG 2.2 are successive W3C recommendations that extend WCAG 2.0. WCAG 2.1, published in June 2018, focused on mobile, low vision and assistive tech gaps. WCAG 2.2, published as a W3C Recommendation in October 2023, adds additional success criteria that target mobile interactions and cognitive and learning disabilities.

Why the update matters

Both sets sit in the same WCAG 2.x family so techniques and conformance models remain compatible. The practical difference is new success criteria in 2.2 that change how some UI patterns must behave or appear. Organisations updating from 2.0 or 2.1 should treat 2.2 as the next step for stronger accessibility coverage.

High-level differences

• Scope: 2.1 expanded WCAG 2.0 to cover mobile, low-vision and expanded keyboard needs. 2.2 builds on that by adding targeted requirements for focus visibility, target size and certain interaction types.
• Focus: 2.1 emphasised device diversity and visual contrast. 2.2 emphasises interaction controls, focus management and cognitive support in user flows.
• Compatibility: 2.2 keeps the same conformance model (levels A, AA, AAA). A page that conforms to 2.2 also conforms to earlier 2.x success criteria where those apply.

Examples of what 2.2 adds or tightens

Rather than list every technical detail, here are concrete examples of the kinds of requirements 2.2 introduces. These reflect the areas 2.2 was designed to improve.

• Clearer focus indicators and behaviour so keyboard and switch users can see and interact reliably.
• Requirements that reduce accidental activation and make touch targets easier to operate on small screens.
• Limits on interaction patterns that rely on complex gestures or dragging without accessible alternatives.
• Guidance that helps people with cognitive and learning disabilities by making form flows and help easier to find and use.

Who benefits most

• Mobile users who need larger, well-spaced targets and robust focus handling.
• Keyboard and switch users who rely on clear focus and predictable focus order.
• People with low vision who depend on visible focus and non-visual cues.
• People with cognitive or learning disabilities who need simpler interactions and clearer on-screen help.

Migration checklist: practical steps to move from 2.1 to 2.2

1. Audit current compliance. Run an accessibility audit against your current baseline (2.0 or 2.1). Use automated tools then follow with manual checks.
2. Map new success criteria to components. Identify which UI components and user flows the 2.2 criteria affect, such as forms, menus and custom controls.
3. Prioritise by user impact. Fix items that block keyboard users, mobile interactions and people with cognitive needs first.
4. Update design tokens and components. Capture focus styles, spacing and touch target behaviour in your design system so fixes scale.
   • Document focus styles in component specs.
   • Add accessible alternatives for gesture-only controls.
5. Run regression and assistive-technology testing. Test with screen readers, keyboard-only navigation, and mobile devices.
6. Include users in testing. Recruit people who use assistive technologies or have relevant disabilities for real-world validation.
7. Record conformance and update your accessibility statement. Note which WCAG level and version you are targeting.

Testing methods and tools

Use a mix of automated and manual tests. No tool catches everything.

• Automated tools: axe, Lighthouse, WAVE, Accessibility Insights for spot checks.
• Manual checks: keyboard-only navigation, focus order, focus visibility, and touch target testing on actual devices.
• Assistive tech: test with NVDA, JAWS, VoiceOver and switch access where possible.
• User testing: sessions with people who have relevant disabilities will uncover real issues that tools miss.

Common mistakes teams make

• Treating 2.2 as a small cosmetic update. Some new criteria require engineering changes to component behaviour and event handling.
• Relying only on automated scans. Automated checks miss focus behaviour and cognitive clarity problems.
• Not updating design systems. Without central design updates, fixes are applied inconsistently across pages.
• Skipping user testing. Real users expose timing, sequencing and context issues that look fine in a lab.

Decision framework: where to invest first

Prioritise work that improves core user journeys and reduces legal risk.

• High priority: Login, checkout, forms, navigation, and any component used for critical transactions.
• Medium priority: Secondary tools, dashboards and administrative UIs used by smaller groups.
• Lower priority: Decorative widgets or private assets not used for public access.

Legal and procurement notes

WCAG itself is a technical standard. Governments and organisations reference WCAG in laws and procurement policies. Whether 2.2 is mandatory depends on local legislation and procurement rules where you operate. Check local regulators and your contracts for which WCAG version and level you must meet.

Quick testing checklist for 2.2-related issues

• Can you tab to every interactive control and see a visible focus?
• Do touch targets work reliably on small screens without accidental activation?
• Are gesture-only operations usable with a keyboard or a clear alternative?
• Are help and error solutions discoverable and consistent across pages?

Further reading and standards

Read the official WCAG documentation on the W3C site for the normative text and technique guidance. Also check platform-specific guidance from Apple, Google and Microsoft for mobile interaction patterns and assistive technology behaviour.

Summary

WCAG 2.2 builds on 2.1 by tightening rules around focus, interaction targets and cognitive support. Treat 2.2 as the next step if you already comply with 2.1. Start with an audit, prioritise core journeys, update design tokens and component behaviour, and validate with real users and assistive technologies.