WCAG 2.2 Explained: What Changed and Why It Matters

When an element receives keyboard focus, it must not be entirely hidden by other author-created content, such as sticky headers, cookie banners, or chat widgets. At least part of the focused element must remain visible. This addresses a common frustration for keyboard users who tab to a focused element only to find it completely obscured by a fixed-position banner.

A stricter version of 2.4.11. The focused element must be fully visible—no part of it may be hidden by other content. This is a Level AAA criterion, so it is aspirational for most organizations, but pursuing it leads to a significantly better keyboard navigation experience.

The keyboard focus indicator must be sufficiently visible. It needs a minimum area (at least as large as a 2px perimeter around the element) and a contrast ratio of at least 3:1 between the focused and unfocused states. This criterion ensures that focus indicators are not just present but actually usable by people with low vision.

Any functionality that requires a dragging movement (such as drag-and-drop reordering, slider controls, or map panning) must also be achievable through a single-pointer action without dragging. This benefits users with motor impairments who may have difficulty performing sustained dragging motions. For example, a sortable list should offer up/down buttons as an alternative to drag-and-drop.

Interactive targets must be at least 24 by 24 CSS pixels in size, with certain exceptions (inline links within text, targets where the size is controlled by the user agent, and targets where the size is essential to the information being conveyed). This criterion recognizes that small touch or click targets are a significant barrier for users with motor impairments, tremors, or limited dexterity—a common issue on mobile devices.

If a website provides help mechanisms (contact information, live chat, FAQ links, self-help options), these mechanisms must appear in the same relative order across all pages. Users with cognitive disabilities rely on predictable patterns to navigate websites and find help when they need it. Consistent placement reduces cognitive load and prevents users from becoming lost or frustrated.

Information that a user has previously entered or provided during a multi-step process must be auto-populated or available for selection, unless re-entering it is essential (e.g., for security confirmation). This reduces the cognitive and motor burden on users who have difficulty remembering or re-typing information. Common examples include shipping/billing address forms where the billing address should auto-populate from the shipping address.

Authentication processes must not require cognitive function tests (such as remembering a password, solving a CAPTCHA puzzle, or performing mental arithmetic) as the sole method of login, unless the test allows pasting (so password managers work), provides an alternative method, or uses object or personal content recognition. This criterion directly addresses a major barrier for users with cognitive and memory disabilities. Practical compliance means supporting password managers, offering passkey/biometric login options, or providing email-based magic links.

A stricter version of 3.3.8. Authentication must not rely on any cognitive function test at all, including object recognition and personal content identification. Only fully cognitive-free methods like biometrics, password managers with paste support, and passkeys meet this criterion.