WCAG 2.2 Explained

The W3C developed the Web Content Accessibility Guidelines (WCAG) as part of the Web Accessibility Initiative (WAI). These guidelines are the global standard for digital accessibility. Most legal regulations (including the Americans with Disabilities Act (ADA), the European Accessibility Act (EAA), and Canada’s AODA) use WCAG as the basis for enforcement.

WCAG Versions

• WCAG 2.0 (2008)
• WCAG 2.1 (2018)
• WCAG 2.2 (2023)
• WCAG 3.0 (Silver) is in development

Each version is backward compatible, meaning compliance with 2.2 also covers 2.1 and 2.0.

WCAG 2.2 introduces nine new success criteria:

Let’s go through them one by one.

What it means: When an element receives keyboard focus (like a button or link), the focus indicator must be clearly visible and meet minimum contrast and size requirements.

Why it matters: Some users navigate only by keyboard. Without a visible focus indicator, they can’t tell where they are on the page.

How to implement:

• Use a visible outline or border with at least 3:1 contrast.
• The indicator should be at least 1 pixel thick and surround the component or touch it closely.
• Avoid removing :focus styles in CSS (common with outline: none;).

button:focus {  outline: 2px solid #005fcc;  outline-offset: 2px; }

What it means: The element with focus must not be hidden behind sticky headers, modals, or other UI components.

Why it matters: If users can't see what is selected, they can’t interact with it.

How to implement:

• Use scroll-margin to ensure focused elements scroll into view:

.scroll-target {  scroll-margin-top: 100px; }

• Test interactions with modals and fixed headers to ensure focus remains visible.

What it means: Users must be able to perform tasks without needing to drag items.

Why it matters: Drag-and-drop actions are difficult for users with tremors, motor impairments, or those using assistive tech.

How to implement:

• Provide alternative input methods, like buttons to move items up/down instead of dragging.
• Use keyboard-accessible reorder controls.

What it means: Interactive targets like buttons, links, and icons must be at least 24x24 CSS pixels in size.

Why it matters: Small tap targets are hard to activate on mobile or for users with limited dexterity.

How to implement:

• Enlarge buttons and links visually and/or through padding.
• Ensure sufficient spacing between interactive elements.

.button {  padding: 12px 16px;  min-height: 24px;  min-width: 24px; }

What it means: If your site offers help features (like live chat, contact info, or FAQs), they must appear consistently across pages.

Why it matters: Users with memory or cognitive challenges benefit from predictability.

How to implement:

• Place help links in the same location and with the same label across the site.
• Avoid hiding help in different menus or footers from page to page.

What it means: Users should not have to re-enter the same information multiple times in a single session.

Why it matters: Repetition causes fatigue and frustration, especially for users with cognitive disabilities.

How to implement:

• Use session storage or cookies to remember previous inputs.
• Pre-fill fields when the information is already known (e.g., billing and shipping addresses).

What it means: Users must be able to log in without needing to solve puzzles, remember passwords, or retype characters from memory — unless alternatives are provided.

Why it matters: CAPTCHAs, complex passwords, and two-step logins are barriers for users with cognitive disabilities.

How to implement:

• Offer password managers and third-party login options (e.g., “Continue with Google”).
• Avoid using image-only CAPTCHAs. Use accessible methods like math problems or toggle verification.
• Consider passkeys, biometrics, or email magic links as alternatives.

Adopting WCAG 2.2 is not just about staying ahead of lawsuits, though that’s a real concern. With the European Accessibility Act enforcement beginning June 28, 2025, and an increase in digital accessibility litigation in the US, now is the time to update your site. Organizations that comply early:

• Reduce legal exposure
• Improve SEO and site usability
• Enhance brand reputation
• Increase conversions and user satisfaction

Here’s a step-by-step checklist to implement WCAG 2.2:

1. Audit Your Site

• axe DevTools
• WAVE Accessibility Checker
• Lighthouse

2. Fix Focus and Input Issues

• Review keyboard navigation
• Improve visible focus indicators
• Add drag-free interaction options

3. Improve Mobile UX

• Increase target sizes
• Test tap interactions

4. Review Forms and Authentication

• Eliminate redundant entry
• Make login options accessible

5. Involve Real Users

Test your site with users who have disabilities to catch barriers that automated tools miss.

WCAG 2.2 is a step forward in making the web more inclusive, especially for people with cognitive and motor impairments. While it builds on WCAG 2.1, it introduces important requirements that may require updates to your design system, codebase, and content.

Accessibility is not a one-time task. It’s an ongoing commitment to designing with empathy and ensuring everyone can participate fully in the digital world. If your team needs support navigating WCAG 2.2, consider working with accessibility experts who can help you audit, fix, and future-proof your website.