
WCAG 2.2
What Designers and Website Owners Need to Know
2-minute read
WCAG 2.2 introduces new success criteria that make websites more usable for people with cognitive, motor, and visual impairments. Whether you run a website, design user interfaces, or write code, this article will walk you through what’s changed, and serve as the launch point for a series of deep dives into the latest accessibility guidelines.
Evolving Standards
Web accessibility standards are evolving, and with the release of WCAG 2.2 in late 2023, there’s more emphasis than ever on inclusivity for users with cognitive and motor impairments.
This post gives you:
- A quick primer on what WCAG is and why WCAG 2.2 matters.
- A breakdown of what’s new compared to WCAG 2.1.
- A preview of each new success criterion in 2.2.
- A launchpad for deeper articles that explain what each update means and how to meet it.
What is WCAG?
(If this is old-hat, skip ahead to: New Success Criteria in WCAG 2.2)
The Web Content Accessibility Guidelines (WCAG) are international standards developed by the W3C that help make websites accessible to people with disabilities. They’re built on four principles. To visitors, websites must be:
- Perceivable
- Operable
- Understandable
- Robust
We’re now on version 2.2, which was finalized in October 2023. It builds on WCAG 2.1 by introducing nine new success criteria, with a strong focus on reducing cognitive load, improving focus visibility, and making interactions easier for users with limited motor control.
If your site already complies with WCAG 2.1 AA, the update isn’t massive, but it is meaningful.
Why WCAG 2.2 Matters
Most of the new criteria are designed to reduce friction for users with:
- Memory, attention, or executive function difficulties
- Limited fine motor control or dexterity
- Situational limitations (e.g., mobile use or temporary injury)
These changes don’t just benefit people with disabilities; they improve UX for everyone.
Who’s Affected?
- Website Owners - Risk mitigation, SEO, and inclusivity
- Designers - Updates to focus indicators, touch targets, and help availability
- Developers - Keyboard navigation, authentication, and alternative input methods
Accessibility touches all aspects of a website: Content, design, and functionality. Everyone involved in your site needs to be on the same page.
What’s New in WCAG 2.2?
Compared to WCAG 2.1:
- One outdated criterion (4.1.1 Parsing) was removed.
- Nine new success criteria were added.
- All updates are backward-compatible; no need to start from scratch.
The new guidelines focus heavily on:
- Focus visibility (2.4.11 - 2.4.13)
- Alternative input options (2.5.7 - 2.5.8)
- Easier authentication (3.3.7 - 3.3.9)
- Consistent help (3.2.6)
WCAG 2.2 In Depth: What’s Coming in This Series
Below is a preview of the articles in this series. Links will be added as each post goes live:
Navigation & Focus
2.4.11 Focus Not Obscured (Minimum) (AA)
Ensures that keyboard focus indicators aren’t hidden behind sticky headers, modals, or other overlapping elements. If users can’t see where they are, they can’t use the site.
2.4.12 Focus Not Obscured (Enhanced) (AAA)
Builds on the previous criterion by requiring focus indicators to be fully visible—not just partially peeking out from behind other UI elements.
2.4.13 Focus Appearance (AAA)
Sets minimum size and contrast requirements for focus indicators, making sure they’re easy to spot; even for users with low vision or cognitive distractions.
Motor Accessibility
2.5.7 Dragging Movements (AA)
Requires that any drag-and-drop interaction be accompanied by a simpler alternative — like tapping or clicking — so users who can’t drag precisely aren’t excluded.
2.5.8 Target Size (Minimum) (AA)
Interactive elements like buttons and links must meet a minimum target size, helping users with limited dexterity avoid accidental clicks and navigation errors.
Cognitive Support
3.2.6 Consistent Help (A)
Help mechanisms (like contact info, chat, or FAQs) must appear consistently across pages, so users always know where to turn when they’re stuck.
3.3.7 Redundant Entry (A)
Users shouldn’t have to re-enter the same information multiple times within a process (unless it’s absolutely necessary). Repetition = frustration.
Accessible Authentication
3.3.8 Accessible Authentication (AA)
Login processes must include alternatives to memory-based tasks (like passwords) by supporting copy/paste, password managers, or passwordless options.
3.3.9 Accessible Authentication (No Exception) (AAA)
Tightens the rule above. All users must be able to authenticate without needing to remember or transcribe anything, no exceptions.
Deep Dive
In the coming weeks we’ll look at each of these criteria in detail and examine what they mean, why they’ve been implemented, and how to apply them in your work with visual and code examples.
Until next time…