WCAG 2.2 vs 2.1: What Changed and What Developers Need to Update

WCAG 2.2 became a W3C Recommendation in October 2023 and was adopted as an ISO standard (ISO/IEC 40500:2024) in October 2024. It is now the current version of the Web Content Accessibility Guidelines, superseding WCAG 2.1. For development teams already conforming to WCAG 2.1, the upgrade to 2.2 is incremental but important: nine new success criteria were added and one (4.1.1 Parsing) was removed. This article explains every change with code examples and provides a practical migration checklist.

Timeline and Status

• June 2018: WCAG 2.1 published as a W3C Recommendation.
• October 2023: WCAG 2.2 published as a W3C Recommendation.
• October 2024: WCAG 2.2 adopted as ISO/IEC 40500:2024.
• April 2026: ADA Title II requires WCAG 2.1 AA for large public entities (WCAG 2.2 is a superset and satisfies 2.1 requirements).

Because WCAG 2.2 is backward-compatible with 2.1, conforming to WCAG 2.2 automatically means you conform to 2.1 as well. If you are preparing for the ADA Title II deadline in April 2026, targeting WCAG 2.2 AA gives you both compliance with the regulation and alignment with the current standard.

Summary of Changes

WCAG 2.2 adds nine new success criteria across three conformance levels and removes one existing criterion:

For AA conformance — the level most regulations target — the new criteria you must address are: 2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), and 3.3.8 Accessible Authentication (Minimum). The Level A criteria (3.2.6 Consistent Help and 3.3.7 Redundant Entry) are also required for AA conformance, since AA includes all Level A criteria.

2.4.11 Focus Not Obscured (Minimum) — AA

When a user interface component receives keyboard focus, it must not be entirely hidden by author-created content. This commonly happens when sticky headers, cookie banners, chat widgets, or fixed-position footers overlap the focused element.

The “minimum” level requires that the focused component is not entirely obscured. Some partial obscuring is permitted at Level AA, though Level AAA (2.4.12) requires no part of the focused element to be hidden.

/* Problem: sticky header covers focused elements */
.site-header {
  position: sticky;
  top: 0;
  z-index: 100;
  height: 64px;
}

/* Fix: add scroll-padding to account for the header */
html {
  scroll-padding-top: 80px; /* header height + buffer */
}

/* Fix: ensure focused elements scroll into visible area */
:focus {
  scroll-margin-top: 80px;
}

/* Fix: for cookie banners, ensure they don't cover
   the entire viewport and can be dismissed */
.cookie-banner {
  position: fixed;
  bottom: 0;
  max-height: 30vh; /* limit height */
  z-index: 50;
}
.cookie-banner[aria-hidden="true"] {
  display: none;
}

2.4.12 Focus Not Obscured (Enhanced) — AAA

The enhanced version of the previous criterion. When a component receives keyboard focus, no part of it may be hidden by author-created content. This is a stricter requirement — even partial obscuring fails this criterion.

While AAA is not typically required by regulations, it represents the ideal user experience. If you are already addressing 2.4.11, the additional effort to meet 2.4.12 is often minimal: ensure sufficient scroll-margin on focusable elements and test that sticky elements never overlap any part of the focus indicator.

/* Enhanced: ensure full visibility of focused elements */
:focus-visible {
  scroll-margin-top: 100px;  /* generous margin above */
  scroll-margin-bottom: 100px; /* account for sticky footers */
}

/* If using a sticky bottom bar */
.bottom-bar {
  position: fixed;
  bottom: 0;
  height: 56px;
}

/* Add matching scroll padding */
html {
  scroll-padding-bottom: 72px; /* bar height + buffer */
}

2.4.13 Focus Appearance — AAA

When a user interface component has keyboard focus, the focus indicator must meet specific size and contrast requirements. The focus indicator must have an area of at least the size of a 2 CSS pixel thick perimeter of the unfocused component, and the contrast ratio between the focused and unfocused states must be at least 3:1.

This criterion ensures focus indicators are actually visible, not just technically present. A 1px dotted gray outline on a white background, for example, would not meet this requirement.

/* Problem: barely visible focus indicator */
button:focus {
  outline: 1px dotted #ccc; /* low contrast, thin */
}

/* Fix: high-contrast, sufficiently thick focus ring */
button:focus-visible {
  outline: 2px solid #1a56db; /* 2px thick, high contrast */
  outline-offset: 2px;        /* space between element and outline */
}

/* Alternative: use box-shadow for more styling control */
button:focus-visible {
  outline: none;
  box-shadow:
    0 0 0 2px #ffffff,   /* white inner ring */
    0 0 0 4px #1a56db;   /* blue outer ring = 2px thick */
}

2.5.7 Dragging Movements — AA

Any functionality that uses a dragging movement (such as drag-and-drop) must also be achievable through a single-pointer alternative without dragging. This applies unless dragging is essential to the functionality or the browser/OS controls the movement.

This criterion exists because dragging requires fine motor control and a precise path of movement. Users with motor impairments, tremors, or those using assistive devices like head pointers or mouth sticks often cannot perform drag operations reliably.

<!-- Problem: sortable list only supports drag-and-drop -->
<ul class="sortable-list">
  <li draggable="true">Item 1</li>
  <li draggable="true">Item 2</li>
  <li draggable="true">Item 3</li>
</ul>

<!-- Fix: add single-pointer move buttons as alternative -->
<ul class="sortable-list">
  <li>
    <span>Item 1</span>
    <button aria-label="Move Item 1 up" disabled>Up</button>
    <button aria-label="Move Item 1 down">Down</button>
  </li>
  <li>
    <span>Item 2</span>
    <button aria-label="Move Item 2 up">Up</button>
    <button aria-label="Move Item 2 down">Down</button>
  </li>
  <li>
    <span>Item 3</span>
    <button aria-label="Move Item 3 up">Up</button>
    <button aria-label="Move Item 3 down" disabled>Down</button>
  </li>
</ul>

<!-- Another example: slider with increment/decrement -->
<div role="group" aria-label="Price range">
  <input type="range" min="0" max="1000" id="price-slider"
         aria-label="Price" />
  <!-- Single-pointer alternative -->
  <button aria-label="Decrease price by 10">-</button>
  <input type="number" min="0" max="1000" id="price-input"
         aria-label="Price value" />
  <button aria-label="Increase price by 10">+</button>
</div>

2.5.8 Target Size (Minimum) — AA

Interactive targets must be at least 24 by 24 CSS pixels, unless one of several exceptions applies: the target has sufficient spacing from adjacent targets, an equivalent control meeting the size requirement is available on the same page, the size is determined by the user agent (e.g., default checkboxes), or the specific presentation is legally or informationally essential.

Inline links within text paragraphs are exempt from this requirement. The criterion primarily targets buttons, icons, form controls, and other discrete interactive elements.

/* Problem: small icon buttons */
.icon-button {
  width: 20px;
  height: 20px;
  padding: 0;
}

/* Fix: ensure minimum 24x24px target size */
.icon-button {
  min-width: 24px;
  min-height: 24px;
  padding: 4px; /* padding counts toward target size */
  display: inline-flex;
  align-items: center;
  justify-content: center;
}

/* Alternative: if visual size must stay small,
   use padding to extend the clickable area */
.small-icon-button {
  width: 16px;   /* visual icon size */
  height: 16px;
  padding: 4px;  /* extends target to 24x24px */
  box-sizing: content-box;
}

/* For adjacent targets, ensure spacing */
.button-group .icon-button {
  min-width: 24px;
  min-height: 24px;
}
.button-group .icon-button + .icon-button {
  margin-left: 8px; /* spacing between targets */
}

3.2.6 Consistent Help — A

If a website provides any of the following help mechanisms, they must appear in the same relative order across pages: human contact details (phone, email), human contact mechanisms (chat, contact form), self-help options (FAQ, help pages), and fully automated contact mechanisms (chatbots). The help mechanism does not need to be on every page, but when present, it must be in a consistent location.

This criterion helps users with cognitive disabilities who rely on consistent patterns to find help. If the “Contact Us” link is in the footer on one page and in the header on another, users may not be able to find it.

<!-- Consistent help: same footer structure across all pages -->
<footer>
  <nav aria-label="Footer navigation">
    <ul>
      <li><a href="/about">About</a></li>
      <li><a href="/faq">FAQ</a></li>
      <!-- Help mechanisms in consistent order: -->
      <li><a href="/contact">Contact Us</a></li>
      <li><a href="/support">Support Center</a></li>
    </ul>
  </nav>
</footer>

<!-- If using a chat widget, position it consistently -->
<!-- Always bottom-right, on every page where it appears -->
<div class="chat-widget" style="position: fixed;
     bottom: 16px; right: 16px;">
  <button aria-label="Open support chat">Chat with us</button>
</div>

3.3.7 Redundant Entry — A

Information previously entered by or provided to the user during a process must be either auto-populated or available for the user to select, unless re-entering the information is essential (for security, such as re-entering a password) or the previously entered information is no longer valid.

This criterion reduces the cognitive and motor burden on users who must navigate multi-step forms. Asking for the same address, email, or name on multiple pages of a checkout flow is a common violation.

<!-- Problem: asking for email again on step 2 -->
<!-- Step 1 -->
<label for="email">Email</label>
<input type="email" id="email" name="email" />

<!-- Step 2: asks for email again -->
<label for="confirm-email">Confirm your email</label>
<input type="email" id="confirm-email" name="confirm_email" />

<!-- Fix: auto-populate from previous step -->
<!-- Step 2: pre-filled, editable -->
<label for="confirm-email">Email (from previous step)</label>
<input type="email" id="confirm-email" name="confirm_email"
       value="user@example.com" />

<!-- Or: "Same as billing address" checkbox -->
<fieldset>
  <legend>Shipping Address</legend>
  <label>
    <input type="checkbox" id="same-address"
           onchange="copyBillingAddress()" />
    Same as billing address
  </label>
  <!-- Address fields pre-populate when checked -->
</fieldset>

3.3.8 Accessible Authentication (Minimum) — AA

Authentication processes must not require a cognitive function test (such as remembering a password, solving a puzzle, or performing a calculation) unless at least one of the following is true: an alternative authentication method is available, a mechanism assists the user in completing the test (such as paste support or password managers), the test involves object recognition (identifying photos containing a specific object), or the test involves personal content the user provided to the website.

In practical terms: support paste in password fields, do not block password managers, and do not use CAPTCHAs that require cognitive problem-solving as the only authentication path.

<!-- Problem: blocking paste in password field -->
<input type="password" id="password"
       onpaste="return false;"
       autocomplete="off" />

<!-- Fix: allow paste and password managers -->
<input type="password" id="password"
       autocomplete="current-password" />

<!-- Problem: CAPTCHA as only authentication method -->
<div class="captcha">
  <p>Type the distorted text you see below:</p>
  <img src="/captcha.png" alt="" />
  <input type="text" name="captcha" />
</div>

<!-- Fix: provide alternative authentication -->
<div class="auth-options">
  <!-- Option 1: standard login with password manager support -->
  <form>
    <label for="username">Email</label>
    <input type="email" id="username"
           autocomplete="username" />
    <label for="pw">Password</label>
    <input type="password" id="pw"
           autocomplete="current-password" />
    <button type="submit">Sign in</button>
  </form>

  <!-- Option 2: passwordless alternative -->
  <button type="button" onclick="sendMagicLink()">
    Sign in with email link
  </button>

  <!-- Option 3: third-party authentication -->
  <button type="button" onclick="signInWithGoogle()">
    Sign in with Google
  </button>
</div>

3.3.9 Accessible Authentication (Enhanced) — AAA

The enhanced version is stricter: the object recognition and personal content exceptions from 3.3.8 are removed. At this level, the only acceptable cognitive function test is one where a mechanism assists the user (such as paste support or a password manager), or an alternative method is provided that does not require any cognitive function test.

Practically, this means that image-based CAPTCHAs (“select all traffic lights”) would fail at AAA even though they pass at AA. If you target AAA conformance, use invisible CAPTCHAs (like reCAPTCHA v3), server-side bot detection, or eliminate CAPTCHAs entirely in favor of rate limiting and other non-interactive countermeasures.

<!-- AAA-compliant: invisible CAPTCHA -->
<!-- No cognitive test presented to the user -->
<form id="login-form">
  <label for="user-email">Email</label>
  <input type="email" id="user-email"
         autocomplete="username" />
  <label for="user-pw">Password</label>
  <input type="password" id="user-pw"
         autocomplete="current-password" />

  <!-- reCAPTCHA v3: no user interaction required -->
  <input type="hidden" name="recaptcha_token" id="recaptcha" />
  <button type="submit">Sign in</button>
</form>

<script>
  // Score-based bot detection, no user challenge
  grecaptcha.ready(function() {
    grecaptcha.execute('site_key', { action: 'login' })
      .then(function(token) {
        document.getElementById('recaptcha').value = token;
      });
  });
</script>

4.1.1 Parsing — Removed

WCAG 2.2 removes Success Criterion 4.1.1 Parsing, which previously required that HTML be well-formed: elements have complete start and end tags, are nested correctly, do not contain duplicate attributes, and have unique IDs.

Why was it removed? When WCAG 2.0 was written in 2008, assistive technologies often built their own DOM representation by parsing HTML directly. Malformed markup could cause these parsers to fail. Today, all major assistive technologies use the browser's accessibility API (which consumes the browser's own DOM), so they are no longer affected by parsing issues in the source HTML. The browser handles error recovery, and the resulting accessibility tree is consistent regardless of minor markup errors.

Important: This does not mean you should stop writing valid HTML. Duplicate IDs still cause real accessibility problems: they break aria-labelledby and aria-describedby references, and they cause <label for="..."> associations to fail. These issues are now covered by other success criteria (4.1.2 Name, Role, Value and 1.3.1 Info and Relationships) rather than 4.1.1. Valid HTML remains a best practice; it just no longer has its own dedicated WCAG criterion.

<!-- These issues are still problems under other criteria -->

<!-- Duplicate ID breaks label association (fails 4.1.2) -->
<label for="name">First name</label>
<input id="name" type="text" />
<label for="name">Last name</label>  <!-- wrong: same id -->
<input id="name" type="text" />

<!-- Fix: unique IDs -->
<label for="first-name">First name</label>
<input id="first-name" type="text" />
<label for="last-name">Last name</label>
<input id="last-name" type="text" />

How to Test for WCAG 2.2

Not all automated testing tools have fully updated their rulesets for WCAG 2.2. When choosing a scanner, verify that it explicitly supports the new criteria. Here is what to look for:

• Focus Not Obscured (2.4.11): Most automated tools cannot fully test this, as it requires understanding the visual stacking context. Manual keyboard testing is essential. Tab through your page and verify that focused elements are never fully hidden behind sticky headers, banners, or overlays.
• Target Size (2.5.8): Some automated tools can measure element dimensions and flag targets smaller than 24x24px. Manual verification is needed for cases where spacing exceptions apply.
• Dragging Movements (2.5.7): Automated tools generally cannot detect drag-and-drop functionality. This requires manual review of any interactive component that uses drag operations.
• Consistent Help (3.2.6): Automated tools can compare page structures across multiple pages, but manual review is more reliable. Check that help mechanisms appear in the same relative order across your site.
• Redundant Entry (3.3.7): This requires manual testing of multi-step processes. Walk through every form workflow and verify that previously entered data is auto-populated or selectable.
• Accessible Authentication (3.3.8): Manually review your login and registration flows. Verify that password fields support paste, autocomplete attributes are present, and alternative authentication methods are available if CAPTCHAs are used.

A11yMate uses the axe-core engine, which actively updates its ruleset as WCAG 2.2 rules are implemented. For automated checks, it covers criteria like target size and focus visibility. For the criteria that require manual testing, use A11yMate for the automated baseline and supplement with keyboard and workflow testing. Our accessibility testing guide covers the complete manual testing process.

Migration Checklist: WCAG 2.1 to 2.2

If your site already conforms to WCAG 2.1 AA, use this checklist to identify the gaps for WCAG 2.2 AA conformance:

1. Audit focus visibility (2.4.11). Keyboard-navigate through every page. Verify that no focused element is fully obscured by sticky headers, floating banners, cookie consent bars, chat widgets, or fixed footers. Add scroll-margin-top and scroll-padding-top as needed.
2. Measure target sizes (2.5.8). Identify all interactive elements: buttons, links (outside of text), form controls, icon actions. Verify each has a target area of at least 24x24 CSS pixels. Fix undersized targets with padding, minimum width/height, or spacing adjustments.
3. Provide drag alternatives (2.5.7). Inventory all drag-and-drop interactions: sortable lists, kanban boards, sliders, map interactions, file upload zones. For each, verify that a single-pointer alternative exists (buttons, select menus, text inputs).
4. Verify consistent help placement (3.2.6). Check that help mechanisms (contact links, chat widgets, support pages, FAQ links) appear in the same relative order on every page where they are present.
5. Eliminate redundant data entry (3.3.7). Walk through every multi-step form and process. Verify that previously entered information is auto-populated or available for selection. Add “same as billing address” patterns where applicable.
6. Review authentication flows (3.3.8). Confirm that password fields accept paste input and have appropriate autocomplete values. If CAPTCHAs are used, ensure an alternative method is available. Consider adding passwordless authentication or third-party sign-in options.
7. Clean up 4.1.1 Parsing workarounds. If you have tooling or processes that specifically targeted 4.1.1 compliance, review whether they are still needed. Keep duplicate-ID fixes (they are still required under 4.1.2) but remove any over-engineered HTML validation workflows that existed solely for 4.1.1.
8. Run automated scans with a WCAG 2.2 scanner. Use a tool that supports the updated criteria. A11yMate uses the latest axe-core engine, which incorporates WCAG 2.2 rules as they are released. Fix all reported violations.
9. Update your accessibility statement. Change your conformance target from WCAG 2.1 AA to WCAG 2.2 AA. Update the audit date and document any known limitations.

What About WCAG 3.0?

WCAG 3.0 (tentatively titled “W3C Accessibility Guidelines 3.0”) is in development but far from finalization. As of early 2026, it remains a Working Draft with significant structural changes proposed, including a new scoring model that replaces the A/AA/AAA conformance levels. However, WCAG 3.0 is not expected to become a W3C Recommendation for several years, and no regulation currently references it. WCAG 2.2 is the standard to target today.

Further Reading

• 2026 ADA Website Compliance: What Small Businesses Need to Know — ADA Title II deadline and how to prepare
• Fix Common WCAG Violations: A Developer's Guide — Code examples for the 10 most common issues
• How to Check Website Accessibility in 2026 — Complete testing walkthrough
• Best WCAG Accessibility Checkers Compared (2026) — Find the right tool for your workflow