The Web Content Accessibility Guidelines (WCAG) 2.2, published by the W3C in October 2023, build on WCAG 2.1 with nine new success criteria. The overarching goal remains the same: make web content perceivable, operable, understandable, and robust for people with disabilities — including visual, auditory, motor, and cognitive impairments.

WCAG 2.2 does not replace 2.1. It extends it. Every success criterion from 2.0 and 2.1 still applies (with one exception: 4.1.1 Parsing was removed as browsers now handle malformed HTML gracefully). The new criteria address gaps that the previous versions did not cover, particularly around focus visibility, alternative input methods, and cognitive accessibility.

Focus Not Obscured (2.4.11 and 2.4.12)

One of the most impactful additions. Focus Not Obscured (Minimum) at Level AA requires that when an element receives keyboard focus, it is at least partially visible — not completely hidden behind sticky headers, floating toolbars, or modal overlays.

The Level AAA version (Focus Not Obscured Enhanced) goes further: the focused element must be fully visible. In practice, this means:

• Sticky navigation bars must not cover focused elements beneath them. Use scroll-padding-top or dynamically adjust scroll position when tabbing.
• Cookie consent banners and chat widgets that float over content must not obscure the current focus target.
• Modal dialogs should trap focus within themselves so users cannot tab to obscured elements behind the overlay.

Dragging Movements (2.5.8)

This Level AA criterion ensures that any functionality triggered by dragging — such as reordering a list, moving a slider, or drawing on a canvas — also has a single-pointer alternative. Not everyone can perform drag gestures; users with motor impairments, users of switch devices, and users of assistive technology need click-based or keyboard-based alternatives.

Examples of compliant alternatives:

• A sortable list that supports drag-and-drop but also provides up/down arrow buttons for reordering
• A range slider that can be adjusted by clicking specific points on the track or by entering a value in an input field
• A map that supports pinch-to-zoom but also has zoom in/out buttons

Accessible Authentication (3.3.8 and 3.3.9)

Perhaps the most relevant criterion for modern web applications. Accessible Authentication (Minimum) at Level AA prohibits cognitive function tests — such as remembering a password, solving a CAPTCHA, or recognizing an image — as the sole login method.

This does not mean you cannot use passwords. It means you must provide at least one alternative that does not require memorization, transcription, or pattern recognition. Compliant approaches include:

1. Passkeys and biometric login — The user authenticates with a fingerprint, face scan, or device PIN. No cognitive test involved.
2. Password managers — If the login form supports copy-paste and autofill (no disabled paste or custom input fields that block autofill), password manager users can authenticate without memorizing anything.
3. Email or SMS magic links — A one-time login link sent to the user's email or phone. The user clicks the link; no password required.
4. OAuth and social login — Delegating authentication to a provider the user is already signed into.

The key insight: WCAG 2.2 does not ban passwords — it bans passwords as the only option when they require users to memorize or transcribe information without assistive technology support.

Consistent Help (3.2.6)

When a website provides help mechanisms — such as a contact phone number, chat widget, FAQ link, or support form — those mechanisms must appear in a consistent location across pages. If your contact link is in the footer on the homepage, it should be in the footer on every page. If the chat widget appears in the bottom-right corner, it should stay there throughout the site.

This helps users with cognitive disabilities who rely on predictable patterns to find assistance.

Practical Steps for WCAG 2.2 Compliance

For development teams looking to meet WCAG 2.2, here is a prioritized action list:

1. Audit focus management — Tab through your entire application with a keyboard. Ensure focused elements are never fully obscured and that focus order is logical.
2. Add single-pointer alternatives — Review every drag-and-drop interaction and provide button-based or keyboard-based alternatives.
3. Review authentication flows — Ensure your login supports paste, autofill, and at least one non-memory-based method like passkeys or magic links.
4. Standardize help placement — Pick consistent locations for support links, chat widgets, and contact information across all pages.
5. Test with real assistive technology — Automated tools like axe-core catch some issues, but manual testing with a screen reader (VoiceOver, NVDA) and keyboard-only navigation is essential for full conformance.

WCAG 2.2 is not just a compliance checkbox — it represents a meaningful step toward a web that works for everyone, regardless of ability. The new criteria address real barriers that millions of users face daily, and most of the fixes are straightforward engineering work that improves the experience for all users, not just those with disabilities.