WCAG 2.2's six new A and AA criteria, in the order we'd fix them

If your site already meets WCAG 2.1 AA, WCAG 2.2 adds six A and AA success criteria, and they are not equally urgent. Fix authentication and obscured focus first, because they stop people outright and cost little; leave Consistent Help for last, because most sites already pass it by accident.

WCAG 2.2 became a W3C Recommendation on October 5, 2023. It added 9 success criteria in all, three of them at Level AAA, and it removed 4.1.1 Parsing. The six at A and AA are the ones that show up in audits, procurement questionnaires, and conformance claims, so they are the ones worth a plan. Here is ours, ranked by who is blocked and what the fix costs, with code your team can ship this sprint.

The order at a glance

Dragging would rank first on a site where dragging is the only way to finish a core task. Most sites have little dragging, which is why it sits third.

First, the fixes that stop people at the door

3.3.8 Accessible Authentication (Minimum)

A login step can't require a cognitive function test, such as remembering a password or transcribing a code, unless there is an alternative method, a mechanism that helps (password managers and copy and paste both count), or the test is object recognition or personal content the user supplied. In practice, the failures are almost always self-inflicted:

• Scripts that block paste in password or code fields.
• Fields built so that password managers can't fill them.
• One-time codes split into six inputs, where pasting fills only the first box.
• Text-transcription CAPTCHAs with no alternative.

The fix is mostly deleting code and adding attributes:

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

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

<label for="otp">Code from your text message</label>
<input id="otp" name="otp" inputmode="numeric" autocomplete="one-time-code" maxlength="6">

If the design insists on separate boxes, handle paste so the code lands where it should:

document.querySelector('.otp-group').addEventListener('paste', (event) => {
  const digits = event.clipboardData.getData('text').replace(/\D/g, '').split('');
  const boxes = [...event.currentTarget.querySelectorAll('input')];
  if (digits.length !== boxes.length) return;
  event.preventDefault();
  boxes.forEach((box, i) => { box.value = digits[i]; });
  boxes.at(-1).focus();
});

Object-recognition CAPTCHAs are allowed at AA, but they remain a barrier for blind users, so offer a non-visual route anyway.

2.4.11 Focus Not Obscured (Minimum)

When an element receives keyboard focus, content you added can't hide it entirely. Partly hidden passes at AA; the AAA version asks for no overlap at all. The usual culprits are sticky headers, sticky footers, cookie banners, and chat launchers. W3C's sufficient technique for the sticky header case is CSS scroll-padding, which tells the browser to leave room when it scrolls a focused element into view:

:root { --header-height: 4.5rem; }

.site-header {
  position: sticky;
  top: 0;
  min-height: var(--header-height);
}

html {
  scroll-padding-top: calc(var(--header-height) + 0.5rem);
  scroll-padding-bottom: 5rem; /* room for a fixed cookie bar */
}

Test it the way users meet it. Load a long page with the cookie banner still open, then Tab all the way to the bottom. If focus disappears under the banner, either reserve space for it, as above, or make it a proper modal dialog that holds focus until it is dismissed.

Then the fixes that need design time

2.5.7 Dragging Movements

Anything you can do by dragging must also be possible with a single pointer, a click or a tap, unless dragging is essential. A keyboard alternative alone does not satisfy this criterion; the people it protects may be using a mouse or head pointer that can click but can't hold and move. Common candidates are sortable lists, kanban boards, custom sliders, map panning that replaces the browser's own scrolling, and file drop zones. A drop zone with a "Choose file" button already passes. A native range input passes if you haven't changed how it drags.

For sortable lists, add buttons:

<li>
  <span>Quarterly report</span>
  <button type="button">Move up<span class="visually-hidden">: Quarterly report</span></button>
  <button type="button">Move down<span class="visually-hidden">: Quarterly report</span></button>
</li>
<!-- once, outside the list -->
<p role="status" class="visually-hidden" id="sort-status"></p>

After each move, write the new position into the status element ("Quarterly report, position 2 of 7") so screen reader users hear the result too. The visible label stays at the start of each button's accessible name, which keeps voice control users on the right side of 2.5.3 Label in Name.

2.5.8 Target Size (Minimum)

Pointer targets must be at least 24 by 24 CSS pixels, with exceptions for targets spaced far enough apart, targets with an equivalent control elsewhere, links inline in a sentence, controls drawn by the browser, and cases where the size is essential. The spacing exception works like this: center a circle 24 CSS pixels across on each undersized target, and if no circle touches another target or another circle, the targets pass.

Typical failures are close buttons, pagination links, carousel dots, social icons, and the little "x" on filter chips. The fix usually belongs in the component library, not the page, and the trick is to grow the hit area without growing the icon:

.icon-button {
  display: inline-grid;
  place-items: center;
  min-inline-size: 24px;
  min-block-size: 24px;
}
.icon-button svg { inline-size: 16px; block-size: 16px; }

.carousel-dots { display: flex; gap: 8px; }
.carousel-dots button { inline-size: 24px; block-size: 24px; padding: 0; }

Treat the minimum as a floor. For primary actions on touch screens, the 44 by 44 pixel size from 2.5.5 Target Size (Enhanced), a AAA criterion, is the better design target.

Last, the criteria about process

3.3.7 Redundant Entry

Within a single process, information the user already entered, or that you already gave them, must be filled in for them or offered for selection. Exceptions cover re-entry that is essential, re-entry required for security, such as confirming a new password, and information that is no longer valid. W3C is explicit that the browser's own autofill doesn't count. Your site has to supply the data.

The classic case is checkout:

<fieldset>
  <legend>Billing address</legend>
  <label>
    <input type="checkbox" id="billing-same" checked>
    Same as shipping address
  </label>
  <!-- Billing fields stay hidden while checked and are prefilled from shipping when unchecked -->
</fieldset>

Keep autocomplete tokens on every personal-data field anyway, such as autocomplete="shipping postal-code" and autocomplete="billing postal-code". They are how you meet 1.3.5 Identify Input Purpose, and they save everyone typing. They just aren't how you meet 3.3.7. Multi-step applications are the other common failure: if step four asks for the email address from step one, show it, prefilled.

3.2.6 Consistent Help

This one doesn't require you to offer help. If you do offer human contact details, a contact form or chat, a self-help page, or an automated assistant on multiple pages, it must appear in the same order relative to the other content on each page. Sites usually pass by default because the footer is shared. They fail at the edges: a landing page built in a different page builder, a checkout template that drops the footer, a chat launcher injected in different places on different templates. Check five templates, list the help mechanisms in DOM order, and compare.

The AAA additions and the criterion that left

The three AAA additions are 2.4.12 Focus Not Obscured (Enhanced), 2.4.13 Focus Appearance, and 3.3.9 Accessible Authentication (Enhanced). None is required for an AA claim. Focus Appearance is still worth reading before your next design-system release, because it is the clearest specification anyone has written for a visible focus indicator.

4.1.1 Parsing was removed as obsolete, because browsers and assistive technology no longer stumble over the markup errors it targeted. If your backlog has issues filed under 4.1.1, close them under that number, but read them first. A duplicated id that breaks an aria-labelledby reference is still a failure. It just belongs under 1.3.1 Info and Relationships or 4.1.2 Name, Role, Value now.

Where to begin on Monday

Log in with a password manager, then with a pasted one-time code. Tab through your three busiest templates with the cookie banner open. Search your code for drag handlers, and measure your icon buttons. That hour of checks will tell you whether WCAG 2.2 is a sprint or a quarter. If you'd like a full baseline, our WCAG 2.2 accessibility audit covers all 55 A and AA criteria, and our remediation team ships the fixes as reviewed pull requests.

Sources

1. W3C Web Accessibility Initiative: What's New in WCAG 2.2
2. W3C, Understanding WCAG 2.2: Target Size (Minimum)
3. Understanding WCAG 2.2: Accessible Authentication (Minimum)
4. Understanding WCAG 2.2: Focus Not Obscured (Minimum)
5. Understanding WCAG 2.2: Dragging Movements
6. Understanding WCAG 2.2: Redundant Entry