What's new in WCAG 2.2: the 9 new success criteria

WCAG 2.2 became a W3C Recommendation on 5 October 2023 and was updated on 12 December 2024. W3C lists the changes on its What's New in WCAG 2.2 page. W3C says the 2.0 and 2.1 success criteria are essentially the same in 2.2, with one exception. A site that meets WCAG 2.1 AA therefore mostly needs to add the new Level A and AA criteria below. In total WCAG 2.2 has 86 success criteria (31 at A, 24 at AA and 31 at AAA), 55 of them at A and AA, counted from the WCAG 2.2 Recommendation. WCAG 2.2 (the October 2023 text) is also published as ISO/IEC 40500:2025, per W3C.

Which law needs which version is a separate question, answered in which WCAG version the law requires. This page explains the criteria themselves. The full list of all 86 is on our WCAG 2.2 success criteria page, and the WCAG 2.2 checklist turns them into tasks.

The nine new criteria at a glance

Laws in practice name Level A and AA, so the six criteria at those levels (2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 and 3.3.8) are the ones that matter for most audits. The three Level AAA criteria are worth meeting where you can, and none of the laws in our version table requires Level AAA.

The nine new criteria in plain English

2.4.11 Focus Not Obscured (Minimum), Level AA

• What it requires: when a control receives keyboard focus, it is not entirely hidden by content you authored, such as a sticky header, a sticky footer or a banner. Partly covered is allowed at this level. Fully covered fails. W3C adds an exception: content the user opened, such as a chat window or a menu, may cover the focused control if the user can reveal that control without moving keyboard focus.
• Fails: a cookie banner pinned to the bottom of the screen fully covers a link that receives focus, and the banner does not close or move.
• Passes: a sticky footer sits at the bottom of the viewport, and scroll padding keeps the focused control above it.
• Who it helps: sighted keyboard users, including people using switches, voice input and on-screen keyboards, people with low vision who magnify the page, and people with attention or memory limits who need to find the current focus.
• How to test: tab through the page with sticky headers, sticky footers and chat widgets present, and confirm no focused control disappears completely behind them. W3C names CSS scroll-padding (technique C43) as a sufficient technique and a sticky footer or header completely hiding focused elements as a failure (F110). Read the exact wording.

2.4.12 Focus Not Obscured (Enhanced), Level AAA

• What it requires: the stricter version of 2.4.11. No part of the focused control may be hidden by content you authored.
• Fails: a sticky header overlaps the top edge of a focused link, even though most of the link is visible. A semi-transparent or blurred overlay over the focused control also fails.
• Passes: the page uses scroll padding so a focused link scrolls into clear space, or a notification that takes focus closes when focus leaves it.
• Who it helps: the same groups as 2.4.11, most of all magnifier users who pan around the screen and can lose a partly hidden focus.
• How to test: tab through every control with the same sticky and floating content present, and look for any overlap with the focused control, even a few pixels. W3C names CSS scroll-padding (technique C43) as a sufficient technique. Read the exact wording.

2.4.13 Focus Appearance, Level AAA

• What it requires: when the focus indicator is visible, its area is at least that of a 2 CSS pixel thick perimeter around the unfocused control, and it changes by at least 3:1 in contrast between the focused and unfocused states. It does not apply if the browser draws the indicator and you cannot change it, or if you change neither the indicator nor its background.
• Fails: a 2 pixel inset outline, which does not cover enough area.
• Passes: a solid 2 pixel outline on the outer edge of a button, or a 3 pixel inset outline on a control large enough that its area is at least that of a 2 pixel perimeter (W3C's example is a 90 by 30 pixel button), with at least 3:1 change in contrast between the focused and unfocused pixels. You can compare two colors with our contrast checker.
• Who it helps: anyone who relies on the keyboard and needs to see which control will respond, and people with attention, short-term memory or executive-function limitations who need to find where focus is.
• How to test: tab to each control and compare the focused and unfocused states: is the indicator thick enough, and does it change by at least 3:1? W3C lists G195 (an author-supplied, visible focus indicator), C40 (a two-color indicator) and C41 (a strong indicator within the component) as sufficient techniques. Read the exact wording.

2.5.7 Dragging Movements, Level AA

• What it requires: anything that works by dragging can also be done with a single pointer action, such as a click or tap, without dragging. Exceptions: dragging is essential, or the browser provides the behavior and you do not modify it (scrollbars, pull-to-refresh).
• Fails: a task board where cards move between columns only by drag and drop.
• Passes: the same board also has a menu on each card to move it to another column, or a sortable list has up and down buttons. A map with directional buttons and a carousel with forward and back buttons also pass.
• Who it helps: people who cannot drag precisely, and people using adapted pointing devices such as trackballs, head pointers, eye-gaze systems or speech-controlled mouse emulators, for whom dragging is cumbersome and error-prone.
• How to test: find every drag interaction (sliders, sortable lists, boards, maps, file drops) and complete the task using only clicks or taps. W3C lists G219 (ensuring an alternative is available for dragging movements) as a sufficient technique and F108 as the failure. Read the exact wording.

2.5.8 Target Size (Minimum), Level AA

• What it requires: pointer targets are at least 24 by 24 CSS pixels. There are five exceptions: spacing (a 24 pixel circle centered on each undersized target does not overlap another target), an equivalent control elsewhere on the page, inline targets within a sentence, controls whose size the browser sets, and cases where the size is essential.
• Fails: a row of six 20 by 20 pixel icon buttons that touch each other.
• Passes: the same six icon buttons with gaps of at least 8 pixels between them, so the 24 pixel spacing circles clearly clear each other (W3C's own example uses 4 pixel gaps, which leaves no margin for error), or a link inside a paragraph, which is exempt as an inline target.
• Who it helps: touchscreen users, people with hand tremors or limited fine motor control, one-handed users, and people using a device on a moving vehicle.
• How to test: measure small buttons and icons in your browser's developer tools. If one is under 24 by 24 CSS pixels, check the spacing circle and the other four exceptions. W3C names C42 (min-height and min-width on the target container) as a sufficient technique. Read the exact wording.

3.2.6 Consistent Help, Level A

• What it requires: if a set of pages repeats a help mechanism, it appears in the same order relative to the other content on every page. The mechanisms covered are human contact details (phone, email, hours), human contact mechanisms (chat, a contact form), self-help options (an FAQ or support page) and automated contact such as a chatbot. The criterion covers the order of content, not its visual position, and does not require you to offer help.
• Fails: a "Contact us" link comes before the main content on the home page but after it on product pages.
• Passes: the contact link and chat button come in the same place in the page order on every page.
• Who it helps: people who may have difficulty locating help, who are more likely to find it when it is consistently placed, according to W3C's Understanding page.
• How to test: list the help items on a page, then check that the same items come in the same order relative to the other content on the other pages of the set. A change in visual position is fine if the order is unchanged. W3C names G220 (provide a contact-us link in a consistent location) as a sufficient technique. Read the exact wording.

3.3.7 Redundant Entry, Level A

• What it requires: if you ask for information the user already entered or was given earlier in the same process, you fill it in for them or let them select it. Exceptions: re-entry is essential (a memory game), it is needed for security (confirming a new password), or the earlier information is no longer valid. Browser autofill alone does not meet it, and it does not require saving data between sessions.
• Fails: checkout asks for the shipping address and then makes the customer retype the same address for billing, with no option to reuse it. Clearing a card number after a failed payment attempt also fails.
• Passes: a "billing same as delivery" option, or a form that keeps the card number after a failed payment.
• Who it helps: people with memory or cognitive disabilities, people who have trouble recalling information, and people with mobility impairments who use switch control or voice input and want less typing.
• How to test: walk through each multi-step process (checkout, registration, booking) and note every field that repeats information from an earlier step. Check that it is prefilled or selectable. W3C names G221 (provide data from a previous step in a process) as a sufficient technique. Read the exact wording.

3.3.8 Accessible Authentication (Minimum), Level AA

• What it requires: no step of logging in to an existing account depends on a cognitive function test (remembering, solving or transcribing) unless the step offers an alternative method that needs no such test, a mechanism that helps the user (a password manager or copy and paste), a test that asks the user to recognize objects, or a test that asks them to identify non-text content they provided to the site. It covers signing in, not creating an account.
• Fails: a login that blocks pasting into the password field, or asks the user to solve a math puzzle or type back distorted characters. A CAPTCHA whose audio alternative must be transcribed does not count as an alternative.
• Passes: username and password fields that browsers and password managers can fill and that allow pasting, or sign-in with WebAuthn (fingerprint, face or device PIN), a third-party OAuth login, or a two-factor option that confirms on the user's device.
• Who it helps: people with cognitive disabilities that affect memory, reading (such as dyslexia), numbers (such as dyscalculia), or perception and processing.
• How to test: try to sign in by pasting the password, and with a password manager. Check whether any step asks you to remember, solve or transcribe something without an alternative. W3C lists G218 (email link authentication) and H100 (properly marked up email and password inputs) as sufficient techniques, and F109 (preventing password or code re-entry in the same format) as a failure. Read the exact wording.

3.3.9 Accessible Authentication (Enhanced), Level AAA

• What it requires: the same as 3.3.8, with two exceptions removed. A required login step may no longer ask the user to recognize objects or to pick images, audio or video they supplied.
• Fails: a CAPTCHA that asks the user to select the pictures containing cars, when the login offers no other method and no helping mechanism. This passes at 3.3.8 and fails here.
• Passes: pasting allowed, password manager support, WebAuthn or OAuth sign-in, with no image or object test in the way.
• Who it helps: the same people as 3.3.8, with no exception for tests that rely on perception or processing.
• How to test: run the 3.3.8 checks, then also look for any object-recognition or personal-image test in the login. W3C lists G218 and H100 as sufficient techniques. Read the exact wording.

What was removed: 4.1.1 Parsing

WCAG 2.2 removed 4.1.1 Parsing. W3C's reason is that assistive technology no longer needs to parse HTML directly, so the criterion no longer has utility. WCAG 2.0 and 2.1 still contain it. The WCAG 2.2 Recommendation says authors required by policy to meet 2.0 or 2.1 may need to continue to test and report 4.1.1, so keep it in any report for a law that names those versions. See which WCAG version the law requires.

Where to start

1. Open your forms and login

   3.3.7 and 3.3.8 are the quickest wins: reuse entered data, allow pasting and let password managers work.

2. Tab through your site

   Press Tab with sticky headers, banners and chat widgets on. Check that the focused control is visible (2.4.11) and that its indicator is clear (2.4.13).

3. Check size, dragging and help

   Measure small icon buttons against 24 pixels, give every drag action a click or tap route, and keep contact and help links in one place.

4. Re-scan after changes

   A free scan reports what automated checks can find, and our methodology lists what no scanner can see. Several of these criteria need a person to test, so do not read a clean scan as proof of anything.