Complete Guide to WCAG 2.2 AA
Compliance in 2026

2.4.11 Focus Not Obscured (Minimum)

The Rule:
When an element receives keyboard focus, it must be at least partially visible—not completely hidden by sticky headers, cookie banners, chat widgets, or other overlays.

Why It Matters:
Keyboard users rely entirely on seeing where focus lands to navigate a page. If your sticky header covers the focused element as users tab through the page, they're navigating blind.

Common Failures:

<!-- Fails: Sticky header obscures focused links -->
<header style="position: fixed; top: 0; height: 80px; z-index: 1000;">
  <nav>Logo | Products | Contact</nav>
</header>
<main style="margin-top: 80px;">
  <a href="#skip">Skip to content</a> <!-- Hidden when focused -->
</main>

The Fix:
Use CSS scroll-padding to create safe zones that prevent focused elements from landing behind fixed content:

/* Reserve space for the sticky header */
html {
  scroll-padding-top: 100px; /* Header height + buffer */
}

/* Alternative: Apply to all focusable elements */
a:focus,
button:focus,
input:focus,
[tabindex]:focus {
  scroll-margin-top: 100px;
}

Testing:
Tab through your entire page with a keyboard. At every stop, check if the focused element is fully visible. Pay special attention when tabbing upward through the page, as this is when sticky headers become problematic.

2.5.7 Dragging Movements

The Rule:
Any functionality that requires dragging must also be achievable with single-pointer actions (clicks or taps), unless dragging is essential to the activity.

Why It Matters:
Users with motor impairments, tremors, or those using alternative input devices cannot reliably press, hold, and move a pointer. A drag-only interface locks them out entirely.

Common Failures:

<!-- Fails: Sortable list with drag-only reordering -->
<ul id="task-list">
  <li draggable="true">Task 1</li>
  <li draggable="true">Task 2</li>
  <li draggable="true">Task 3</li>
</ul>

<script>
  // Only drag-and-drop handlers, no alternative
  list.addEventListener('dragstart', handleDragStart);
  list.addEventListener('drop', handleDrop);
</script>

The Fix:
Provide move buttons, dropdown menus, or other single-click alternatives:

<!-- Passes: Sortable list with button alternatives -->
<ul id="task-list">
  <li>
    <span>Task 1</span>
    <button aria-label="Move Task 1 up" onclick="moveUp(0)">↑</button>
    <button aria-label="Move Task 1 down" onclick="moveDown(0)">↓</button>
  </li>
  <li>
    <span>Task 2</span>
    <button aria-label="Move Task 2 up" onclick="moveUp(1)">↑</button>
    <button aria-label="Move Task 2 down" onclick="moveDown(1)">↓</button>
  </li>
</ul>

For sliders, the native <input type="range"> element automatically passes because users can click directly on the track to jump to a value.

Important: A keyboard alternative alone is not sufficient. Mobile users may not have keyboards, so you need a pointer-based single-click option.

2.5.8 Target Size (Minimum)

The Rule:
Interactive targets must be at least 24 × 24 CSS pixels, with exceptions for inline links, user-agent-controlled elements, and elements with adequate spacing.

Why It Matters:
Small tap targets are frustrating for everyone and nearly impossible for users with motor impairments. The average adult fingertip is 10–14mm wide (roughly 40–55 CSS pixels), so a 16-pixel icon button is asking for mis-taps.

Common Failures:

<!-- Fails: 16x16 icon button -->
<button class="icon-btn" aria-label="Delete">
  <svg width="16" height="16">...</svg>
</button>

<style>
.icon-btn {
  padding: 0;
  width: 16px;
  height: 16px;
}
</style>

The Fix:
Add padding to expand the touch target without changing the visual size:

/* Passes: Visual icon stays small, touch target is 24x24+ */
.icon-btn {
  padding: 4px; /* 16px icon + 4px padding × 2 = 24px total */
  min-width: 24px;
  min-height: 24px;
}

/* Better: Follow Apple/Google guidelines of 44-48px */
.icon-btn {
  padding: 14px; /* 16px icon + 14px padding × 2 = 44px total */
}

Spacing Exception: Targets smaller than 24 × 24 pixels can pass if there's enough space between them.

3.3.8 Accessible Authentication (Minimum)

The Rule:
Authentication cannot rely solely on cognitive function tests—memorization, transcription, or puzzle-solving—unless you provide an alternative or a mechanism to assist.

Why It Matters:
Requiring users to remember a password, transcribe a one-time code from another device, or solve a CAPTCHA places a high burden on people with cognitive disabilities, dyslexia, or memory impairments.

The Fix:
Enable password managers and copy/paste:

<!-- Passes: Allows paste, autocomplete, and password managers -->
<label for="username">Email</label>
<input type="email" id="username" name="username" autocomplete="username">

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

Never block copy/paste. The UK's National Cyber Security Centre explicitly recommends allowing password paste for security reasons.