Skip to content
WCAG 2.2 Changes: What's New and How to Comply

WCAG 2.2 Changes: What's New and How to Comply

4 min read

What Is WCAG 2.2?

WCAG 2.2 is the latest version of the Web Content Accessibility Guidelines, published as a W3C Recommendation in October 2023. It builds on WCAG 2.1 by adding nine new success criteria and removing one existing criterion. These WCAG 2.2 changes address accessibility gaps that the previous version did not fully cover, particularly around mobile interactions, cognitive accessibility, and authentication.

If your website currently meets WCAG 2.1 AA, you are most of the way to WCAG 2.2 compliance. However, the new criteria introduce requirements that many sites do not meet out of the box, so an audit against the updated standard is essential.

New Success Criteria in WCAG 2.2

2.4.11 Focus Not Obscured (Minimum) — Level AA

When a user tabs to an interactive element, the focused element must not be entirely hidden by other content such as sticky headers, cookie banners, or chat widgets. At least part of the focused element must remain visible.

What to check: Tab through your site with sticky headers and footers active. If a focused element is fully covered by a sticky element, you need to adjust scroll padding, z-index behavior, or the focus management of your sticky components.

2.4.12 Focus Not Obscured (Enhanced) — Level AAA

The stricter version of 2.4.11 requires that the focused element is not obscured at all. No part of the focused component should be hidden by author-created content.

What to check: The same testing as 2.4.11 but with a zero-tolerance threshold for any occlusion of the focused element.

2.4.13 Focus Appearance — Level AAA

When a keyboard focus indicator is visible, it must meet minimum size and contrast requirements. Specifically, the focus indicator must have an area of at least the equivalent of a 2 CSS pixel thick perimeter of the focused element, and the contrast between the focused and unfocused states must be at least 3:1.

What to check: Measure your focus indicator size and contrast. Thin 1-pixel dotted outlines typically fail this criterion.

2.5.7 Dragging Movements — Level AA

Any functionality that uses dragging (like drag-and-drop interfaces, sliders, or sortable lists) must also be operable through a single-pointer alternative without dragging. This ensures that users who cannot perform drag gestures, whether due to motor impairments or device limitations, can still complete the task.

What to check: Identify every drag interaction on your site. Ensure each one has an alternative, such as move up/down buttons for sortable lists or a text input for sliders.

2.5.8 Target Size (Minimum) — Level AA

Interactive targets must be at least 24 by 24 CSS pixels, unless an alternative equivalent target exists, the target is inline within text, the size is determined by the user agent, or the specific presentation is essential.

What to check: Audit your clickable and tappable elements. Small icon buttons, close buttons on tags or chips, and compact navigation items are common failure points.

3.2.6 Consistent Help — Level A

If a website provides help mechanisms such as contact information, self-help options, or a help chat, these mechanisms must appear in the same relative order on every page. The help does not need to be on every page, but where it does appear, its position must be consistent.

What to check: Review your help features (contact links, FAQ links, chat widgets) across multiple pages. Ensure they are in the same position relative to other page elements.

3.3.7 Redundant Entry — Level A

When a user has already entered information in a multi-step process, that information should either auto-populate in subsequent steps or be available for the user to select. Users should not have to re-enter the same data (like their address or email) within the same session.

What to check: Walk through your multi-step forms and checkout flows. If any step asks for information that was provided in a previous step, auto-fill it or provide a selection mechanism.

3.3.8 Accessible Authentication (Minimum) — Level AA

Authentication processes must not require cognitive function tests such as memorizing a password, solving a puzzle, or performing arithmetic, unless the process provides at least one of these alternatives: an alternative authentication method, an assistive mechanism (like a password manager), or a cognitive function test that involves recognizing objects or personal content.

What to check: Review your login and authentication flows. CAPTCHAs that require puzzle-solving, password entry fields that block paste (preventing password manager use), and custom authentication challenges may all fail this criterion.

3.3.9 Accessible Authentication (Enhanced) — Level AAA

The stricter version removes the exception for object recognition. Authentication must not require any cognitive function test, period. Only copy/paste support (for password managers) and alternative authentication methods satisfy this criterion.

What Was Removed: 4.1.1 Parsing

WCAG 2.2 removed Success Criterion 4.1.1 (Parsing), which previously required that HTML be well-formed with complete start and end tags, proper nesting, unique IDs, and no duplicate attributes. Modern browsers and assistive technologies are now robust enough to handle parsing issues, making this criterion obsolete.

This is good news for developers: you no longer need to fix every HTML validation warning to claim WCAG conformance. However, writing clean, valid HTML remains a best practice for maintainability and consistent rendering.

Impact on Developers and Designers

What You Likely Need to Fix

  1. Sticky headers covering focused elements — The most common failure for the new focus obscured criteria. Add CSS scroll-padding-top to account for fixed header height.
  2. Small touch targets — The 24x24 pixel minimum catches many compact UI patterns. Increase padding on small buttons, icon links, and chip close buttons.
  3. Drag-only interactions — Sortable lists, kanban boards, and slider components need single-pointer alternatives.
  4. Multi-step forms re-requesting data — Pre-fill fields with previously entered information.
  5. Anti-paste on password fields — Never prevent pasting in authentication fields. Password managers depend on it.

What You Can Deprioritize

  • HTML validation issues related to the removed 4.1.1 criterion.
  • Level AAA criteria (2.4.12, 2.4.13, 3.3.9) if your compliance target is AA.

How to Audit for WCAG 2.2 Compliance

Automated Testing

Automated tools can catch a subset of WCAG 2.2 issues:

  • Target size — Tools can measure element dimensions and flag targets smaller than 24x24 pixels.
  • Consistent help — Automated scans can compare help element positions across pages.
  • Missing drag alternatives — Some tools flag drag handlers without companion click handlers.

Use the wcagkit contrast checker to verify that your focus indicators meet the contrast requirements relevant to the new focus appearance criterion.

Manual Testing

Many WCAG 2.2 criteria require manual verification:

  • Tab through your site and check that focused elements are never fully hidden behind sticky content.
  • Test every drag interaction for a pointer-based alternative.
  • Walk through multi-step processes and verify data is not re-requested.
  • Attempt to log in using only a password manager with paste.

Screen Reader and Keyboard Testing

Run through your site with a keyboard to test focus behavior and use a screen reader to verify that dynamic updates and help mechanisms are properly announced. The wcagkit heading analyzer can help verify your document structure meets the new criteria alongside existing heading requirements.

While WCAG 2.2 was published in October 2023, legal and regulatory adoption varies by jurisdiction:

  • EU: The European Accessibility Act references the latest harmonized standard. WCAG 2.2 adoption in the EN 301 549 standard is expected.
  • US: ADA lawsuits increasingly reference current WCAG versions. Courts have not mandated a specific version, but meeting the latest standard strengthens your compliance position.
  • UK, Canada, Australia: Each has its own accessibility legislation with varying WCAG version references.

Proactively adopting WCAG 2.2 reduces legal risk and demonstrates commitment to accessibility regardless of mandatory deadlines.

Conclusion

The WCAG 2.2 changes are practical and targeted, addressing real-world usability gaps around focus management, touch targets, cognitive accessibility, and authentication. Most sites that already meet WCAG 2.1 AA need only focused updates in a few areas.

Start your WCAG 2.2 audit by checking focus behavior with the wcagkit ARIA validator and contrast requirements with the contrast checker. Address sticky header focus occlusion, small touch targets, and drag-only interactions first, as these are the most common failures on existing sites.