WCAG 2.2: What Actually Changed

Twenty-four by twenty-four CSS pixels. That is the number most working designers will actually collide with in WCAG 2.2, and it is worth saying at the outset that it does not mean what most people repeat. It is not a rule that every button must be 24 pixels square. It is a rule with five exceptions, one of which lets a 16 pixel icon pass provided nothing sits too close to it.

WCAG 2.2 was published as a W3C Recommendation on 5 October 2023. If you visit the specification today you will see a different date at the top, 12 December 2024, and the discrepancy confuses people. The December 2024 document is a revised Recommendation. According to the W3C's own FAQ it modified the definitions of single pointer, used in an unusual or restricted way, motion animation and programmatically determined, alongside minor formatting and editorial changes. No success criteria were added or removed. If you are citing when WCAG 2.2 became a standard, the answer is October 2023.

What was added

Nine new success criteria. The count gets quoted a great deal, and on its own it overstates the work. Three of the nine are Level AAA, a level almost nobody conforms to as a whole. The practical delta for an organisation targeting AA, which is what almost every procurement document and accessibility policy actually asks for, is six criteria: two at Level A and four at Level AA.

What was removed, and why it matters more than it sounds

WCAG 2.2 removed 4.1.1 Parsing. The specification's own note is short: WCAG 2.2 has removed one success criterion, 4.1.1 Parsing. Authors that are required by policy to conform with WCAG 2.0 or 2.1 will be able to update content to WCAG 2.2, but may need to continue to test and report 4.1.1.

The reasoning is in the WAI's FAQ. Parsing was written when browsers and assistive technologies handled malformed markup inconsistently. Since then, the FAQ says, specifications (such as HTML) and browsers have improved how they handle parsing errors, and any remaining problem that genuinely affects users will fail other criteria, such as Info and Relationships (SC 1.3.1) or Name, Role, Value (SC 4.1.2). Therefore 4.1.1 is no longer needed for accessibility.

The part that gets missed: the criterion was not only removed going forward, it was neutralised backwards. In WCAG 2.1 and WCAG 2.0 it now carries a conformance note reading This Success Criteria should be considered as always satisfied for any content using HTML or XML. A duplicate ID or an unclosed tag is no longer a WCAG failure at any version. I have sat in reviews where an automated tool flagged duplicate IDs and the room treated it as an accessibility defect. It is a code quality defect, and it may well cause a real problem, but if it does, the real problem will be a 1.3.1 or a 4.1.2 failure and you should report it as one.

Focus, and the sticky header problem

2.4.11 Focus Not Obscured (Minimum) reads: When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

Two words carry the weight. Entirely sets the bar at Level AA: a partially covered focused element passes, and it takes the AAA version, 2.4.12, to require full visibility. Author-created excludes content the user has scrolled past; this is about things you put on top, not about the viewport.

The W3C's understanding document names the culprits without hedging. Sticky footers and headers. Non-modal dialogs. Chat widgets. And one specific pattern: A notification implemented as sticky content, such as a cookie banner, will fail this success criterion if it entirely obscures a component receiving focus.

The failure is almost always invisible to the person who designed it, because it only appears when someone tabs down the page and the browser scrolls the focused element to the very bottom edge of the viewport, directly under the sticky bar. The remedies offered are all layout decisions: make the banner modal so it must be dismissed, apply scroll-padding so the browser stops short of the sticky region, or have transient notifications close when focus leaves them.

2.4.13 Focus Appearance is AAA, but it is the only place in the guidelines that quantifies a focus indicator, so it is the number designers end up using anyway. It asks that an area of the indicator is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or sub-component and has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states. Two exceptions apply: where the indicator is the user agent's default and cannot be adjusted by the author, and where neither the indicator nor its background colour has been modified by the author.

The second exception is the strongest argument I know for leaving the browser's default focus ring alone. Touch it and you inherit a specification. Leave it and you do not.

Twenty-four pixels, correctly

2.5.8 Target Size (Minimum) states that the size of the target for pointer inputs is at least 24 by 24 CSS pixels, with five exceptions. The exceptions are the criterion.

2.5.8 Target Size (Minimum), Level AA

Default:
  a solid 24 x 24 CSS pixel square, axis-aligned, fits entirely
  within the target's boundaries.

Exceptions:

  Spacing      Undersized targets are positioned so that if a
               24 CSS pixel diameter circle is centred on the
               bounding box of each, the circles do not intersect
               another target or the circle for another
               undersized target.

  Equivalent   The function can be achieved through a different
               control on the same page that meets this criterion.

  Inline       The target is in a sentence, or its size is
               otherwise constrained by the line-height of
               non-target text.

  User agent   The size of the target is determined by the user
               agent and is not modified by the author.

  Essential    A particular presentation of the target is
               essential, or is legally required

2.5.8 Target Size (Minimum), Level AA

Default:
  a solid 24 x 24 CSS pixel square, axis-aligned, fits entirely
  within the target's boundaries.

Exceptions:

  Spacing      Undersized targets are positioned so that if a
               24 CSS pixel diameter circle is centred on the
               bounding box of each, the circles do not intersect
               another target or the circle for another
               undersized target.

  Equivalent   The function can be achieved through a different
               control on the same page that meets this criterion.

  Inline       The target is in a sentence, or its size is
               otherwise constrained by the line-height of
               non-target text.

  User agent   The size of the target is determined by the user
               agent and is not modified by the author.

  Essential    A particular presentation of the target is
               essential, or is legally required

2.5.8 Target Size (Minimum), Level AA

Default:
  a solid 24 x 24 CSS pixel square, axis-aligned, fits entirely
  within the target's boundaries.

Exceptions:

  Spacing      Undersized targets are positioned so that if a
               24 CSS pixel diameter circle is centred on the
               bounding box of each, the circles do not intersect
               another target or the circle for another
               undersized target.

  Equivalent   The function can be achieved through a different
               control on the same page that meets this criterion.

  Inline       The target is in a sentence, or its size is
               otherwise constrained by the line-height of
               non-target text.

  User agent   The size of the target is determined by the user
               agent and is not modified by the author.

  Essential    A particular presentation of the target is
               essential, or is legally required

The Spacing exception is what makes this liveable, and it is why the popular summary is wrong. A 16 by 16 pixel icon button passes if the nearest other target is far enough away that a 24 pixel circle centred on each does not touch the other's circle. In practice that means about 24 pixels between the centres of adjacent small targets. So a dense toolbar of small icons fails, and a single small close button in a corner passes. The criterion is measuring crowding, not size.

The Inline exception is the one that saves every link in a paragraph of body text. A link in a sentence is exempt, which means you do not need to add 24 pixels of padding to inline anchors, and should not.

The understanding document points designers at 2.5.5 Target Size (Enhanced), the older AAA criterion at 44 by 44 pixels, for important controls. That is the number Apple and Google's platform guidelines have circled around for years, and it remains a recommendation rather than a requirement at AA.

Dragging

2.5.7 Dragging Movements: All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.

This is the criterion that will cost the most to retrofit, because it is aimed at exactly the interactions that get prototyped in a design tool and look wonderful in a demo. The W3C's own examples of failure are a range slider operable only by dragging the thumb, a drag-to-reorder list with no alternative, a kanban board that only accepts drag and drop, and a carousel that only responds to a drag gesture.

The passing versions are not exotic. A slider that also moves when you click the track. A sortable list with up and down buttons. A kanban board where you can tap a card, then choose a column from a menu. A map with directional buttons alongside drag panning. A drawing tool where a selection rectangle can be made by clicking two corners instead of dragging between them.

Note the beneficiaries named in the understanding document: people with dexterity limitations, people using trackballs, head pointers and eye-gaze systems, and touchscreen users without a physical keyboard. The last group is not a small population, and it is not a disabled population. Drag-only interfaces are fragile for everyone.

The three about cognition

3.2.6 Consistent Help, Level A, is the one most often described wrongly. It reads: If a web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple web pages within a set of web pages, they occur in the same order relative to other page content, unless a change is initiated by the user. The listed mechanisms are human contact details, a human contact mechanism, a self-help option, and a fully automated contact mechanism such as a chatbot.

The understanding document is explicit that it does not require authors to provide help or access to help. The Criterion only requires that when one of the listed forms of help is available across multiple pages that it be in a consistent location. And "consistent location" is defined as order rather than position: note 2 says the same order relative to other page content can be thought of as how the content is ordered when the page is serialized. A help link can move visually in a responsive layout, provided its place in the document order does not shuffle.

3.3.7 Redundant Entry, Level A: information previously entered by or provided to the user that is required to be entered again in the same process is either auto-populated or available for the user to select. The exceptions cover re-entry that is essential, re-entry required for security, and information that is no longer valid. Confirming a new password by typing it twice is permitted under the security exception.

3.3.8 Accessible Authentication (Minimum), Level AA, is the most consequential of the three, and the one that has quietly broken a lot of standard login design. It states that a cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides one of: an alternative method that does not rely on a cognitive function test; a mechanism to assist the user in completing it; a test that is object recognition; or a test that identifies non-text content the user themselves provided.

A cognitive function test is defined as a task requiring the user to remember, manipulate or transcribe information. That includes memorisation, transcription, spelling and calculation. Entering your own name, email or phone number is explicitly excluded.

Two consequences are worth stating plainly. First, remembering a password is itself a cognitive function test, which is why nearly every login form relies on the Mechanism exception: the password manager is the assistive mechanism. The understanding document is blunt about what that means in practice. If user agents and password managers are actively blocked from filling in the fields, the page fails unless an alternative is provided. Blocking paste on a password field, or on a one-time code field, is now a conformance failure at Level AA. Second, transcribing a code from an email or an SMS into a field is transcription, and therefore a cognitive function test, unless copy and paste works.

On CAPTCHA the criterion is narrower than the headlines suggest. It does not ban CAPTCHA. Object recognition puzzles, the "select all the images with a bus" kind, are explicitly permitted at Level AA by the Object Recognition exception. Text transcription, arithmetic and logic puzzles are not, unless an alternative exists. The AAA version, 3.3.9, removes both the object recognition and personal content exceptions, which is what makes it genuinely hard.

What I would change first

If I had one afternoon and an existing product, I would spend it on three things in this order. Check whether paste is blocked anywhere in the authentication flow, because that is a Level AA failure that takes minutes to fix and is usually a deliberate decision someone made for security reasons that do not survive scrutiny. Tab through every page with a sticky element on screen and watch for focus disappearing underneath it. Then look at every place where drag is the only way to do something.

Target size I would leave until last, not because it matters least but because the Spacing exception means most interfaces are closer to passing than an automated report will suggest, and fixing it properly usually means rethinking density rather than adding padding.

One thing I cannot tell you: how any of this will be interpreted in litigation or procurement. The criteria are normative, the understanding documents are not, and the gap between the two is where every real argument happens. I have read both carefully and I still could not predict, for a genuinely marginal case, which way an auditor would call it.

Sources

• W3C, "Web Content Accessibility Guidelines (WCAG) 2.2", W3C Recommendation, 12 December 2024 (originally published 5 October 2023). Normative text of the new success criteria and the note on the removal of 4.1.1 Parsing. w3.org/TR/WCAG22/

• W3C Web Accessibility Initiative, "What's New in WCAG 2.2". Publication date of 5 October 2023 and the list of nine new success criteria with levels. w3.org/WAI/standards-guidelines/wcag/new-in-22/

• W3C Web Accessibility Initiative, "WCAG 2 FAQ". Rationale for removing 4.1.1 Parsing, its status as always satisfied in WCAG 2.0 and 2.1, and the contents of the 12 December 2024 revision. w3.org/WAI/standards-guidelines/wcag/faq/

• W3C, "Understanding SC 2.4.11: Focus Not Obscured (Minimum)", Understanding WCAG 2.2. Criterion text, sticky header and cookie banner failure patterns, and remedies. w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html

• W3C, "Understanding SC 2.5.8: Target Size (Minimum)", Understanding WCAG 2.2. Criterion text, the 24 by 24 CSS pixel square, the five exceptions including the 24 pixel diameter circle spacing test, and the reference to 2.5.5. w3.org/WAI/WCAG22/Understanding/target-size-minimum.html

• W3C, "Understanding SC 2.5.7: Dragging Movements", Understanding WCAG 2.2. Criterion text, beneficiaries, and the failing and passing examples for sliders, sortable lists, kanban boards, maps and drawing tools. w3.org/WAI/WCAG22/Understanding/dragging-movements.html

• W3C, "Understanding SC 3.2.6: Consistent Help", Understanding WCAG 2.2. Criterion text, the four listed help mechanisms, the note on serialised order, and the statement that help is not required to exist. w3.org/WAI/WCAG22/Understanding/consistent-help.html

• W3C, "Understanding SC 3.3.7: Redundant Entry", Understanding WCAG 2.2. Criterion text, exceptions, beneficiaries and the password confirmation note. w3.org/WAI/WCAG22/Understanding/redundant-entry.html

• W3C, "Understanding SC 3.3.8: Accessible Authentication (Minimum)", Understanding WCAG 2.2. Criterion text and its four exceptions, the definition of a cognitive function test, and the guidance on password managers, paste blocking and CAPTCHA. w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum.html

Related reading

• Reduced Motion and the Ethics of Animation

• Dark Patterns Stopped Being a Style Question

• The Contrast Formula, Its Known Flaws, and What Comes Next

• Designing the Empty State

More from the Moc Mallen Studio journal