Two Years Later and Most Sites Still Fail

WCAG 2.2 became official in October 2023. That was over two years ago. Plenty of time to read six new success criteria and update your codebase.

Almost nobody did.

We audit sites for a living, and roughly 80% of the ones that claim WCAG 2.2 compliance fail at least one of the new criteria. The most common reaction when we flag a 2.2 failure is "wait, that is new?" Yes. It has been new for over two years. We are starting to think "new" might not be the right word anymore.

This post is the practical reference we wish someone had written in 2023. Every new criterion, what it actually means in your codebase, and the code to fix it. We read the W3C documents so you do not have to. They are exactly as thrilling as you would imagine.

Quick Context

If you are targeting WCAG 2.2 Level AA (the standard for Section 508, ADA compliance, and EN 301 549), you need to meet 6 of the 9 new criteria. The remaining 3 are Level AAA, which is the accessibility equivalent of extra credit. We will cover all 9, but the AA criteria are where your audit will pass or fail.

The 6 New Level AA Criteria

2.4.11: Focus Not Obscured (Minimum)

The rule: When an element receives keyboard focus, it must not be entirely hidden by other content.

What actually happens: A user tabs to a button. Your sticky nav sits on top of it. The user has no idea where their focus went. They are now just pressing Tab and hoping for the best, which is not a great user experience and an even worse audit result.

The offenders are always the same: sticky headers, cookie consent banners (the ones that are supposedly about user experience), floating chat widgets, and fixed toolbars. Basically, every element your designer added to "always be visible" is now hiding the things your users are trying to reach. The irony is not lost on us.

The fix:

/* Two lines. That is the whole fix for most sites. */
:focus-visible {
  scroll-margin-top: 100px;  /* Height of your sticky header + buffer */
  scroll-margin-bottom: 80px; /* Height of that cookie banner you added for "compliance" */
}

We see this failure on roughly half the sites we audit. The fix takes about 90 seconds. The contrast between how common this issue is and how easy it is to solve never stops being funny to us.

2.5.7: Dragging Movements

The rule: Any functionality that uses dragging must also work with a single pointer and no dragging.

Translation for product managers: That Kanban board your team spent two sprints building? It needs buttons too.

Drag-to-reorder is everywhere. Kanban boards, sortable lists, dashboard widgets, image croppers. Every single one of these needs a non-drag alternative. Not because the W3C has opinions about your UI patterns, but because users with motor impairments, tremors, or anyone using assistive pointing devices literally cannot perform drag operations. Your beautiful drag-and-drop is a brick wall for them.

The fix:

// Your designer will not love this. Ship it anyway.
<SortableList onDragEnd={handleReorder}>
  {items.map((item, index) => (
    <SortableItem key={item.id}>
      {item.label}
      <button onClick={() => moveUp(index)} aria-label={`Move ${item.label} up`}>↑</button>
      <button onClick={() => moveDown(index)} aria-label={`Move ${item.label} down`}>↓</button>
    </SortableItem>
  ))}
</SortableList>

Are up/down buttons elegant? No. Do they make your sortable list usable by everyone? Yes. We will take functional over elegant every time. You can always make the buttons prettier later. You cannot make a drag-only interface accessible later without adding buttons anyway.

2.5.8: Target Size (Minimum)

The rule: Interactive targets must be at least 24x24 CSS pixels.

The most failed criterion in all of WCAG 2.2. We have done the informal math. If you are going to fail one of the new criteria, it is going to be this one. It is also the most tedious to fix because it touches every interactive element on every page. Every button, every link, every form control. Good luck.

button, a, input, select,
[role="button"], [role="tab"], [role="menuitem"] {
  min-height: 24px;
  min-width: 24px;
}

24 pixels is the minimum. We build to 44px because we have tried tapping a 24px button on a phone with adult human thumbs. It is technically possible in the same way that parallel parking a bus is technically possible. You can do it, but nobody is going to enjoy the experience.

3.2.6: Consistent Help

The rule: Help mechanisms must appear in the same relative order across pages.

This is the freebie. If your help link is in the footer on every page, congratulations, you pass. If your chat widget floats in the bottom-right corner everywhere, you pass. If your "Contact Us" link is in the same nav position on every template, you pass.

The only way to fail this is to play musical chairs with your help links across different page templates. Nobody does this on purpose, but it does happen when your marketing site was built by Agency A in 2021, your app was built by Team B in 2023, and your blog runs on a WordPress theme from who knows when. Each one put the help link somewhere different.

The fix: Pick a spot. Put help there. Leave it there. On every page. That is genuinely the whole criterion.

3.3.7: Redundant Entry

The rule: Do not make users re-enter information they already provided in the same process.

If you have ever filled out a government form that asked for your name on page 1, your name again on page 3, and then your name one more time on page 5 "for our records," you understand why this criterion exists. We have remediated applications that asked for the same email address three times in a single checkout flow. At that point you are not verifying the data. You are just testing the user's patience.

The fix:

  • Auto-populate shipping from billing
  • Pre-fill forms from previous steps
  • Use autocomplete so browsers can do the work for you
<input
  type="email"
  name="email"
  autoComplete="email"
  defaultValue={previouslyEnteredEmail}
  // Yes, that is all it takes. Yes, most forms still do not do this.
/>

3.3.8: Accessible Authentication (Minimum)

The rule: Authentication flows must not require cognitive function tests unless an alternative is provided.

In practice, this means one thing: stop blocking paste in password fields.

We genuinely do not understand why this is still happening in 2026. Someone, at some point, decided that preventing users from pasting passwords was a security feature. It is not. It just breaks password managers, which are the single best thing most users do for their actual security. Blocking paste does not stop attackers. It stops your users. From logging in. To your own product.

Other ways to fail this:

  • "Type the characters you see in this image" as the only auth path (CAPTCHAs without alternatives)
  • "Copy this 6-digit code and type it in" without allowing paste (just... let them paste it)
  • Custom input components that fight with browser autofill

The spirit of this criterion is simple: logging in should not be a cognitive challenge. Password managers, passkeys, biometrics. These things exist. Let people use them.

The 3 Level AAA Criteria

Not required for most compliance targets. Worth knowing about. Worth building to if you want to be ahead of the curve instead of perpetually one audit cycle behind it.

2.4.12: Focus Not Obscured (Enhanced)

The enhanced version of 2.4.11 says no part of the focused element can be hidden, not just "not entirely hidden." If you did the scroll-margin fix well, you probably pass this too. If you did it lazily with a 20px margin and your header is 80px tall, you do not.

2.4.13: Focus Appearance

Your focus indicator needs to meet specific size and contrast requirements. The math gets into "perimeter of the element times 2 CSS pixels" territory, which is the kind of sentence that makes developers question their career choices. Practical answer: if you are using a solid 2-3px outline with a 3:1 contrast ratio against the background, you are fine. If you are using the browser default, you are probably fine. If you removed the focus indicator because it "looked ugly," we need to talk.

2.5.8: Target Size (Enhanced)

44x44px instead of 24px. This is what we build to at Modern Softworks. If you followed our earlier recommendation, you already pass the enhanced version. Look at you, exceeding standards without even trying.

What This Means for Your Next Audit

If you are currently passing WCAG 2.1 AA, here is your upgrade checklist:

  1. Sticky and fixed elements covering focused content (2.4.11)
  2. Drag interactions missing pointer alternatives (2.5.7)
  3. Target sizes under 24px (2.5.8)
  4. Help placement inconsistent across templates (3.2.6)
  5. Multi-step forms requesting the same data twice (3.3.7)
  6. Auth flows blocking paste or requiring CAPTCHAs without alternatives (3.3.8)

Honest assessment: most well-built applications pass 4 through 6 without changes. The real work is target sizes (because it touches everything and you will find 18px icon buttons you forgot existed) and focus obscuring (because nobody thinks about their sticky header from a keyboard perspective until an auditor mentions it).

Why This Matters Now

Government contracts are specifying WCAG 2.2 in RFPs. We are seeing it regularly. The EU's EN 301 549 is expected to adopt 2.2. Section 508 enforcement trends toward the latest recommendation, which means the question is not "if" but "when."

The new criteria are not obscure technical requirements dreamed up by a standards committee with too much free time. Target sizes, consistent help, not asking people to type their email four times. These are just good software design that finally got written into a specification.

Build to 2.2 now and you are ahead of enforcement. Build to 2.1 and you will be doing this exact same update in 12 months, except under deadline pressure and probably at emergency rates. We know this because we are the ones who get the call when that happens.

Someone had to read the W3C documents and translate them into code. We drew the short straw. Glad we could save you the trip.