What’s new in WCAG 2.2?

I. Introduction

1.1 What is WCAG

The Web Content Accessibility Guidelines (WCAG) are the internationally recognized standards for making websites, web applications, and digital content accessible to everyone, including people with disabilities.

Published by the World Wide Web Consortium (W3C) through its Web Accessibility Initiative (WAI), WCAG provides a common framework that helps organizations design and build digital experiences that are usable by people with a wide range of abilities.

Accessibility is not only about supporting users who are blind or deaf. It also benefits people with:

• Limited mobility who rely on keyboards or assistive devices
• Low vision or color vision deficiency
• Cognitive or learning disabilities
• Temporary impairments, such as a broken arm
• Situational limitations, such as using a phone in bright sunlight or in a noisy environment

Rather than prescribing specific technologies, WCAG defines outcome-based success criteria. This means the guidelines remain relevant as web technologies continue to evolve.

1.2 The Four Principles (POUR)

At the heart of WCAG are four foundational principles, commonly known as POUR. Every accessibility requirement in WCAG is built upon these principles.

1.2.1 Perceivable

Users must be able to perceive the information presented on the screen.

This means content should be available through multiple senses whenever possible.

Examples include:

• Providing alternative text for images
• Adding captions to videos
• Ensuring sufficient color contrast
• Allowing users to resize text without losing content or functionality

Ask yourself: Can every user perceive the information, regardless of how they access the page?

1.2.2 Operable

Users must be able to operate the interface and navigate the application.

Not everyone uses a mouse. Some users rely entirely on keyboards, switch devices, voice control, or other assistive technologies.

Common requirements include:

• Full keyboard accessibility
• Visible keyboard focus indicators
• Enough time to complete tasks
• Avoiding content that may trigger seizures
• Providing clear navigation mechanisms

Ask yourself: Can users successfully interact with every feature using their preferred input method?

1.2.3 Understandable

Both the content and the interface should be easy to understand.

Users should not have to guess what an action does or struggle to recover from mistakes.

Examples include:

• Writing clear instructions
• Using consistent navigation patterns
• Providing meaningful form labels
• Displaying helpful error messages with suggestions for correction

Ask yourself: Can users easily understand what to do and what happens next?

1.2.4 Robust

Content should be robust enough to work reliably across different browsers, devices, and assistive technologies.

This relies on following web standards and using semantic markup correctly.

Examples include:

• Using semantic HTML whenever possible
• Ensuring compatibility with screen readers
• Applying ARIA only when native HTML cannot provide the required semantics
• Avoiding invalid markup that may confuse assistive technologies

Ask yourself: Will this content continue to work with current and future technologies?

II. What’s new in WCAG 2.2

WCAG has evolved over time to address new technologies and user needs:

Version	Released	Highlights
WCAG 2.0	2008	Introduced the core accessibility principles and success criteria
WCAG 2.1	2018	Added support for mobile accessibility, low vision, and cognitive accessibility
WCAG 2.2	2023	Introduced new success criteria that improve accessibility for users with cognitive disabilities, limited mobility, and keyboard navigation

Because WCAG 2.2 builds upon previous versions, organizations adopting it automatically include the requirements from WCAG 2.0 and 2.1.

WCAG 2.2 introduces 9 new Success Criteria and removes SC 4.1.1 Parsing, resulting in an updated set of requirements that build upon WCAG 2.1. The following section summarize the new Success Criteria introduced in WCAG 2.2.

Note: WCAG Conformance Levels

Level	Description
A	Minimum accessibility requirements
AA	Industry-standard target for most organizations
AAA	Highest accessibility level, often difficult to achieve universally

2.1 Focus Not Obscured (Minimum) (SC 2.4.11 – Level AA)

Problem

Many websites use sticky headers, floating chat widgets, cookie banners, or other fixed elements that can overlap page content. As keyboard users move through the page, the focused element may become partially hidden, making it harder to identify where focus is located.

Real Example

A user tabs through a form located beneath a sticky header. When focus moves to a field near the top of the viewport, part of the field becomes hidden behind the header. The user can still see a portion of the focused element and recognize where focus is currently located.

Solution

Ensure that when an element receives keyboard focus, it is not completely obscured by author-created content such as sticky headers, floating panels, or banners. The focused element may be partially covered, but users must still be able to visually identify the focused component.

2.2 Focus Not Obscured (Enhanced) (SC 2.4.12 Level AAA)

Problem
Even when a focused element is partially visible, important information such as labels, instructions, or the focus indicator itself may still be hidden. This can make keyboard navigation confusing, especially in complex interfaces.

Real Example

A user navigates through an online checkout form. When the focus reaches the Place Order button, a sticky footer overlaps the bottom part of the button. The button is technically visible, so it satisfies SC 2.4.11, but part of the component remains hidden from view.

Solution

Ensure that no part of the focused component is obscured by author-created content. The entire element and its focus indicator should remain fully visible whenever it receives keyboard focus.

2.3 Focus Appearance (SC 2.4.13 – Level AAA)

Problem

Many modern interfaces use extremely subtle focus styles or remove them entirely, making keyboard navigation difficult.

Real Example

A website displays only a thin light-gray outline around focused buttons. On a white background, users can barely tell which element is active.

Solution

WCAG 2.2 defines specific requirements for the minimum area and contrast of the focus indicator, ensuring that keyboard users can easily identify the currently focused element.

2.4 Dragging Movements (SC 2.5.7 – Level AA)

Problem

Some interactions require users to drag and drop, which can be difficult or impossible for people with limited motor control.

Real Example

A Kanban board only allows tasks to be moved by dragging cards between columns.

Solution

Provide an alternative method such as tap-to-select and tap-to-drop, move buttons, or context menu actions so users do not need to perform drag gestures.

2.5 Target Size (Minimum) (SC 2.5.8 – Level AA)

Problem

Small buttons or links are difficult to activate, especially on touch devices or for users with limited dexterity.

Real Example

A mobile app places tiny edit and delete icons next to each other. Users frequently tap the wrong one.

Solution

Interactive targets should be at least 24 × 24 CSS pixels unless specific exceptions apply. When smaller controls are necessary, sufficient spacing should be provided to reduce accidental activation.

2.6 Consistent Help (SC 3.2.6 – Level A)

Problem

When users need assistance, they expect help options to be easy to find. If support links, live chat, or contact information appear in different locations on different pages, users, especially those with cognitive disabilities, may struggle to locate them.

Real Example

On an insurance website, the Contact Support button appears in the top navigation on the homepage, but moves to the footer on the claims page and is hidden inside a menu on the payment page. Users who need help must repeatedly search for it.

Solution

Keep help mechanisms, such as live chat, contact information, FAQs, or support links, in a consistent location across the website whenever they are available.

2.7 Redundant Entry (SC 3.3.7 – Level A)

Problem

Users are sometimes asked to enter the same information multiple times during a single process.

Real Example

An e-commerce checkout asks for the shipping address, then requires the user to manually enter the exact same address again for billing even though it hasn’t changed.

Solution

Automatically reuse information that has already been provided, or allow users to confirm existing data instead of typing it again.

2.8 Accessible Authentication (Minimum) (SC 3.3.8 – Level AA)

Problem

Many authentication processes require users to complete cognitive tasks such as remembering passwords, entering one-time codes, solving puzzles, or transcribing characters from images. These tasks can create significant barriers for people with cognitive disabilities, memory impairments, or learning difficulties.

Real Example

A banking website requires users to log in with username and password. However, it also supports password managers and allows users to paste credentials instead of manually typing them. Users who have difficulty remembering or entering complex passwords can still complete authentication successfully.

Solution

Avoid requiring users to rely solely on memory or complex cognitive tasks. If cognitive challenges are present, provide an accessible alternative or a mechanism that assists users, such as password managers, passkeys, copy-and-paste support, or alternative authentication methods.

2.9 Accessible Authentication (Enhanced) (SC 3.3.9 – Level AAA)

Problem

Even when alternatives exist, authentication processes that depend on cognitive function tests can still create unnecessary barriers and increase effort for many users.

Real Example

A website requires users to solve a visual CAPTCHA before signing in. Although an alternative verification method is available, users must still complete a cognitive challenge as part of the authentication flow.

Solution

Design authentication processes that do not depend on cognitive function tests. Whenever possible, use methods such as passkeys, biometric authentication, magic links, device-based authentication, or other approaches that do not require users to remember information, solve puzzles, or perform similar cognitive tasks.

III. How each role applies WCAG

3.1 Product Manager (PM)

Product Managers set the direction for accessibility by ensuring it is included in product planning and prioritization.

Key responsibilities

• Define accessibility as a product quality goal.
• Include accessibility in the product roadmap and backlog.
• Allocate time for accessibility reviews and testing.
• Balance business priorities with accessibility requirements.
• Encourage accessibility awareness across the organization.

3.2 Business Analyst (BA)

Business Analysts translate WCAG requirements into clear business and functional requirements.

Key responsibilities

• Identify applicable WCAG Success Criteria.
• Document accessibility requirements in user stories.
• Define accessible acceptance criteria.
• Clarify expected behavior for keyboard users and assistive technologies.
• Ensure accessibility requirements are not overlooked during requirement analysis.

3.3 UX/UI Designer

Designers have one of the biggest influences on accessibility because many accessibility issues originate during the design phase.

Key responsibilities

• Use sufficient color contrast.
• Design visible keyboard focus states.
• Ensure touch targets are large enough.
• Avoid relying solely on color to communicate information.
• Create consistent layouts and navigation patterns.
• Design accessible forms, error messages, and feedback.

3.4 Developer

Developers bring accessible designs to life through proper implementation.

Key responsibilities

• Use semantic HTML whenever possible.
• Ensure full keyboard accessibility.
• Implement accessible forms with labels and error handling.
• Use ARIA only when native HTML cannot provide the required semantics.
• Support screen readers and assistive technologies.
• Follow WCAG requirements during implementation—not just after testing.

3.5 Tester (QC/QA)

Accessibility testing verifies that accessibility requirements work as intended in the final product.

Automated tools are helpful, but they can detect only a portion of accessibility issues. Manual testing remains essential.

Key responsibilities

• Test keyboard-only navigation.
• Verify visible focus indicators.
• Check color contrast.
• Test forms and error handling.
• Use screen readers for critical user flows.
• Validate accessibility with both automated and manual testing.

IV. Conclusion

WCAG 2.2 is more than a set of technical guidelines, it’s a framework for creating digital experiences that everyone can use. While the new Success Criteria focus on improving accessibility for people with disabilities, they also lead to better usability for all users.

The key takeaway is that accessibility is a team effort. From planning and design to development and testing, every role contributes to building inclusive products. By making accessibility part of your everyday workflow, you’ll not only move closer to WCAG compliance but also create products that are more user-friendly, resilient, and inclusive from the start.