WCAG 2.2 Accessibility Implementation Guide for 2026

Web Content Accessibility Guidelines (WCAG) 2.2 — released in October 2023 — is the current international standard for web accessibility. Meeting WCAG 2.2 Level AA is now the legal baseline for government websites in most jurisdictions and increasingly the standard referenced in ADA accessibility lawsuits targeting private businesses. Beyond compliance, accessible design is simply better design — clearer typography, better color contrast, keyboard navigation, and logical structure benefit all users, not just those with disabilities.

The Four Principles: POUR

WCAG 2.2 is organized around four principles. Every success criterion maps to one of these:

• Perceivable: Information must be presentable in ways all users can perceive (not invisible to all senses)
• Operable: Interface components must be operable (not requiring interactions impossible for some users)
• Understandable: Information and operation must be understandable
• Robust: Content must be robust enough to be interpreted by assistive technologies

What's New in WCAG 2.2

WCAG 2.2 added 9 new success criteria compared to 2.1. The most impactful for typical web applications:

• 2.4.11 Focus Not Obscured (Minimum): Keyboard focus indicators must not be completely hidden by sticky headers, overlays, or floating elements
• 2.4.12 Focus Not Obscured (Enhanced): Focus indicator must be fully visible (AA+ level)
• 2.4.13 Focus Appearance: Focus indicators must meet size and contrast requirements
• 2.5.7 Dragging Movements: Any functionality using drag must have a single-pointer alternative
• 2.5.8 Target Size (Minimum): Interactive targets must be at least 24x24 CSS pixels (with exceptions)
• 3.2.6 Consistent Help: Help mechanisms (contact info, chat) must appear in consistent locations across pages
• 3.3.7 Redundant Entry: Don't make users re-enter information already provided in the same process
• 3.3.8 Accessible Authentication: Authentication must not require cognitive tasks unless alternatives are provided

Implementing Perceivable Criteria

Alternative Text for Images

Every meaningful image needs descriptive alt text. Decorative images should use alt="" (empty string — not alt="decorative") so screen readers skip them.

<!-- Informative image -->
<img src="team-photo.jpg" alt="The Open Door Digital team at the 2026 product launch">

<!-- Decorative image -->
<img src="divider-wave.svg" alt="">

<!-- Complex chart -->
<figure>
  <img src="revenue-chart.png" alt="Revenue chart showing 40% growth Q1-Q4 2025">
  <figcaption>Revenue grew from $1.2M in Q1 to $1.68M in Q4 2025</figcaption>
</figure>

Color Contrast Requirements

WCAG 2.2 AA requires:

• Normal text (under 18pt / 14pt bold): minimum 4.5:1 contrast ratio
• Large text (18pt+ or 14pt+ bold): minimum 3:1 contrast ratio
• UI components and graphics: minimum 3:1 contrast ratio against adjacent colors

Check contrast ratios with the WebAIM Contrast Checker or Chrome DevTools' accessibility panel. A common failure: light grey text (#999) on white (#fff) is only 2.85:1 — failing AA at any text size.

Captions and Transcripts

All pre-recorded video must have captions. Live audio/video must have real-time captions at AA level. Audio-only content (podcasts) needs a transcript.

Implementing Operable Criteria

Keyboard Accessibility

Every interactive element must be reachable and operable via keyboard. The Tab key moves focus forward; Shift+Tab moves backward; Enter/Space activates buttons and links.

<!-- Bad: click-only handler on a div -->
<div onclick="openMenu()">Menu</div>

<!-- Good: semantic button, keyboard-accessible by default -->
<button onclick="openMenu()" aria-expanded="false" aria-controls="nav-menu">Menu</button>

<!-- If you must use a div, add role and keyboard handler -->
<div role="button" tabindex="0"
  onclick="openMenu()"
  onkeydown="event.key === 'Enter' && openMenu()">Menu</div>

Focus Indicators (2.4.11, 2.4.13)

Never remove focus outlines without providing a better replacement. The default browser focus ring is often low-contrast. WCAG 2.2 AA requires focus indicators with a 3:1 contrast ratio:

/* Good: custom focus style that meets contrast requirements */
:focus-visible {
  outline: 3px solid #0057D8;
  outline-offset: 2px;
  border-radius: 3px;
}

/* Never do this without a replacement: */
/* :focus { outline: none; } */

Touch Target Size (2.5.8)

Interactive elements need at least 24x24 CSS pixels of target area (with 2.5.5 Enhanced requiring 44x44). For small icons, use padding to increase the clickable area without changing visual size:

.icon-button {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-width: 44px;
  min-height: 44px;
  padding: 10px;
}

Implementing Understandable Criteria

Form Labels and Error Messages

Every form input must have an associated label. Error messages must identify the field and describe the problem specifically:

<!-- Bad: placeholder as label -->
<input type="email" placeholder="Email address">

<!-- Good: explicit label -->
<label for="email">Email address</label>
<input type="email" id="email" aria-describedby="email-error">
<span id="email-error" role="alert">
  Please enter a valid email address (example: name@domain.com)
</span>

Accessible Authentication (3.3.8)

WCAG 2.2's new criterion prohibits requiring users to solve cognitive tests (CAPTCHAs, memory puzzles) as the only authentication method unless alternatives are provided. Allow password managers, provide copy/paste in OTP fields, and offer email magic links as alternatives to CAPTCHAs.

Implementing Robust Criteria

ARIA Landmarks

Use semantic HTML and ARIA landmarks to help screen reader users navigate page structure:

<header role="banner">...</header>
<nav aria-label="Primary navigation">...</nav>
<main>...</main>
<aside aria-label="Related articles">...</aside>
<footer role="contentinfo">...</footer>

Testing for Accessibility

No automated tool catches all accessibility issues — combine automated and manual testing:

• Axe DevTools (browser extension): Catches ~57% of issues automatically
• Lighthouse Accessibility audit: Built into Chrome DevTools
• Screen reader testing: NVDA + Chrome on Windows, VoiceOver + Safari on Mac/iOS
• Keyboard-only navigation: Unplug your mouse and navigate the entire site
• Color contrast checkers: WebAIM, Colour Contrast Analyser

Frequently Asked Questions

Is WCAG 2.2 legally required for private websites?

In the US, the ADA applies to places of public accommodation — and courts have increasingly ruled that websites are included. The DOJ has issued guidance citing WCAG 2.1 AA as the technical standard. Several hundred ADA website accessibility lawsuits are filed each year. WCAG 2.2 AA compliance substantially reduces legal exposure.

What's the difference between Level A, AA, and AAA?

Level A is the minimum — failures at this level completely block access for some users. Level AA (the standard for legal compliance) adds important usability requirements. Level AAA is aspirational and not required or achievable for all content. Target AA for compliance; pursue AAA where feasible.

How do I handle third-party widgets that aren't accessible?

You're responsible for accessibility of all content on your page, including third-party components. Where you can't fix third-party code directly, provide accessible alternatives — a phone number alongside an inaccessible chat widget, or a text-based contact form alongside an inaccessible form builder embed.

How often do I need to re-audit for accessibility?

Audit when you launch a new site, after major redesigns, and whenever new interactive components are added. Integrate automated accessibility testing into your CI/CD pipeline so regressions are caught before deployment.

Related Reading

• User Onboarding Design Guide
• Progressive Disclosure in UX Design
• Micro-Interactions in UX Design
• The Power of White Space in Web Design