What changed in WCAG 2.2

WCAG 2.2 became a W3C Recommendation on 5 October 2023. It adds nine success criteria to WCAG 2.1 and removes one, 4.1.1 Parsing. Existing criteria keep their numbers, so if your product already meets 2.1 Level AA, moving to 2.2 AA means checking six new criteria: two at Level A and four at Level AA. The other three are AAA.

Most of the new criteria target problems that are common in crypto interfaces: sticky headers that hide focus, tiny copy buttons, sliders that only work by dragging, and login screens that block paste. Here is each one, with what it means for a typical dApp.

The nine at a glance

Focus you can actually see

2.4.11 Focus Not Obscured (Minimum) fails when a keyboard user tabs to an element and it disappears completely behind something you built: a sticky header, a cookie banner, a fixed "Connect wallet" bar, a toast stack. Partly covered passes at AA; entirely covered fails. 2.4.12 at AAA requires that no part of it is covered. The usual fix is scroll-padding on the scrolling element, explained in detail in focus not obscured.

2.4.13 Focus Appearance gives focus rings a measurable spec. The indicator's area must be at least as large as a 2 CSS pixel thick perimeter around the unfocused component, and the same pixels must change by a contrast ratio of at least 3:1 between the unfocused and focused states. A solid 2px outline in a color with 3:1 against the background usually satisfies it. It makes a good design system default even if you don't target AAA; see designing visible focus styles.

Pointer input

2.5.7 Dragging Movements says that any function operated by dragging must also be possible with a single pointer without dragging, unless dragging is essential. DeFi interfaces are full of drag interactions:

• a "percentage of balance" slider under the amount field;
• the two handles of a concentrated-liquidity price range chart;
• drag-to-reorder lists of watched tokens;
• "slide to confirm" controls on mobile web.

The fixes are ordinary: let a tap on the slider track set the value, add min and max price inputs with step buttons next to the range chart, add "move up" and "move down" actions to the list, and offer a plain confirm button. A keyboard alternative alone doesn't satisfy this criterion; the requirement is about people using a single pointer, such as a head pointer or a stylus held by someone with a tremor.

2.5.8 Target Size (Minimum) sets 24 by 24 CSS pixels as the minimum pointer target, with exceptions for spacing, an equivalent control, inline links, user agent controls and essential cases. Copy buttons next to addresses and close icons in modals are the usual suspects. The target size guide shows how to measure and fix them.

Help and repeated information

3.2.6 Consistent Help doesn't require you to offer help. It says that if a help mechanism repeats across a set of pages (contact details, a contact form or chat, a self-help page such as docs or FAQ, or an automated assistant), it appears in the same order relative to the other content on each page. If the "Support" link sits in the header on the swap page, it shouldn't move to the footer on the bridge page.

3.3.7 Redundant Entry applies within a single process. Information the user already entered or was given must be filled in automatically or offered for selection, not typed again. In a bridge or send flow that means the destination address entered on step one is shown and reused on the review step. Recently used addresses can be offered as choices. The criterion has exceptions when re-entry is essential, when it's needed for security, or when the earlier information is no longer valid. Retyping an address "for safety" may fall under the security exception, but a clear review screen showing the full checksummed address usually protects people better.

Authentication without memory tests

3.3.8 Accessible Authentication (Minimum) says no step of a login may require a cognitive function test, such as remembering a password, transcribing a code or solving a puzzle, unless at least one of these holds: there is another method without such a test, a mechanism helps the user complete it, the test is recognizing objects, or the test is identifying content the user provided. Password managers and paste count as that helping mechanism, which is why blocking paste is a classic failure.

For a centralized exchange or a custodial wallet with an email login, the practical rules are short: allow paste everywhere, use the right autocomplete values, and don't split a one-time code into six boxes that break paste and autofill.

<label for="email">Email</label>
<input id="email" type="email" autocomplete="username">

<label for="password">Password</label>
<input id="password" type="password" autocomplete="current-password">

<label for="otp">6-digit code</label>
<input id="otp" inputmode="numeric" autocomplete="one-time-code" maxlength="6">

Image puzzles need an alternative path. Wallet-based sign-in, such as Sign-In with Ethereum (EIP-4361), asks the user to approve a signature rather than recall anything on your site, so it generally doesn't introduce a memory test of its own.

3.3.9 Accessible Authentication (Enhanced) at AAA drops the object recognition and personal content exceptions, so "pick all the images with a bicycle" or "choose the photo you uploaded" are no longer acceptable on their own.

4.1.1 Parsing is gone

4.1.1 required markup without errors such as duplicate attributes or improperly nested elements. Assistive technology no longer parses HTML itself; it relies on the browser, which handles malformed markup in consistent, specified ways. The problems that still matter are caught by other criteria, mainly 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value. That is why WCAG 2.2 removed it as obsolete.

Don't read this as permission to ship duplicate IDs. If two inline SVG icons on a page both contain <title id="title"> and an aria-labelledby points at it, the second icon may be announced with the first icon's name. When the names differ, that is a failure under 1.1.1 or 4.1.2 rather than 4.1.1, and the same duplication can break gradients, as described in SVG ID collisions.

Where to start

If you already meet 2.1 AA, work in this order:

1. Tab through every page that has a sticky header, bottom bar or banner, scrolling both down and back up.
2. Measure the hit areas of copy, close, explorer and info icons.
3. Find every slider, range handle and drag interaction and add a non-drag alternative.
4. Check that login, two-factor and password fields accept paste and autofill.
5. Walk through send and bridge flows looking for anything asked twice.
6. Make sure support and docs links appear in the same order on every page.