WCAG 2.2: Web Content Accessibility Guidelines A/AA/AAA | OpsBlu Docs

WCAG 2.2: Web Content Accessibility Guidelines A/AA/AAA

WCAG 2.2 perceivable, operable, understandable, and robust principles across A, AA, and AAA conformance levels.

What WCAG Is

WCAG (Web Content Accessibility Guidelines) is a W3C standard that defines how to make web content accessible to people with disabilities. Most accessibility lawsuits, government procurement requirements, and platform policies reference WCAG as the technical standard.

Version Released Key Additions
WCAG 2.0 Dec 2008 Core 4 principles (POUR), 61 success criteria
WCAG 2.1 Jun 2018 Mobile accessibility, cognitive disabilities (17 new criteria)
WCAG 2.2 Oct 2023 Focus appearance, dragging alternatives, consistent help (9 new criteria)

Conformance levels: Level A (minimum), AA (standard target for legal compliance), AAA (enhanced). Most laws and policies require AA conformance.

Who Must Comply

WCAG is not directly enforceable as law, but it is referenced by laws that are:

Law/Standard Jurisdiction WCAG Requirement
ADA (Americans with Disabilities Act) US Courts consistently apply WCAG 2.1 AA as the standard
Section 508 US federal agencies WCAG 2.0 AA (updated via ICT Final Rule)
EN 301 549 EU WCAG 2.1 AA for public sector sites (EU Web Accessibility Directive)
AODA Ontario, Canada WCAG 2.0 AA for organizations with 50+ employees
Equality Act 2010 UK WCAG 2.1 AA for public sector; private sector by case law

ADA litigation volume: Over 4,000 web accessibility lawsuits were filed in the US in 2023. The most common targets are ecommerce sites, restaurant chains, and financial services companies. Settlements typically range from $10,000 to $150,000 for small businesses, with class actions reaching millions.

The Four Principles (POUR)

Every WCAG criterion falls under one of four principles:

1. Perceivable

Users must be able to perceive all content through at least one sense.

Text alternatives (1.1.1 — Level A):

<!-- Good: descriptive alt text -->
<img src="quarterly-chart.png" alt="Q3 revenue chart showing 23% growth from $2.1M to $2.6M">

<!-- Good: decorative image, empty alt -->
<img src="decorative-border.png" alt="">

<!-- Bad: missing or useless alt -->
<img src="quarterly-chart.png">
<img src="quarterly-chart.png" alt="image">
<img src="quarterly-chart.png" alt="chart.png">

Color contrast (1.4.3 — Level AA):

Element Minimum Contrast Ratio
Normal text (under 18px) 4.5:1
Large text (18px+ bold, or 24px+) 3:1
UI components and graphical objects 3:1

Check contrast with browser DevTools: Chrome → Elements → Inspect element → click the color swatch → contrast ratio shown. Or use WebAIM Contrast Checker.

Captions (1.2.2 — Level A) and audio descriptions (1.2.5 — Level AA):

  • Pre-recorded video with audio must have synchronized captions
  • Pre-recorded video must have audio descriptions for visual-only content
  • Live video must have captions (Level AA)
  • Auto-generated captions (YouTube, etc.) do not meet WCAG — they must be reviewed and corrected

2. Operable

Users must be able to operate all interactive elements.

Keyboard accessibility (2.1.1 — Level A):

<!-- Good: native button is keyboard-accessible by default -->
<button

<!-- Bad: div pretending to be a button, not keyboard-accessible -->
<div

<!-- If you must use a div, add keyboard support -->
<div role="button" tabindex="0" ')submitForm()">
  Submit
</div>

No keyboard traps (2.1.2 — Level A): Users must be able to navigate away from any component using only the keyboard. Modal dialogs are the most common trap — always provide a close mechanism that works with Escape key and Tab cycling.

Focus visible (2.4.7 — Level AA):

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

/* Good: custom focus style that's clearly visible */
:focus-visible {
  outline: 3px solid #1a73e8;
  outline-offset: 2px;
}

WCAG 2.2 addition — Focus appearance (2.4.13 — Level AAA): The focus indicator must have a contrast ratio of at least 3:1 against adjacent colors, and the focused area must be at least as large as a 2px perimeter around the component.

3. Understandable

Content and interface behavior must be predictable and readable.

Language of page (3.1.1 — Level A):

<!-- Declare the page language -->
<html lang="en">

<!-- Mark language changes inline -->
<p>The French term <span lang="fr">mise en place</span> means preparation.</p>

Error identification (3.3.1 — Level A):

<!-- Good: error clearly identifies the problem -->
<label for="email">Email address</label>
<input type="email" id="email" aria-describedby="email-error" aria-invalid="true">
<span id="email-error" role="alert">Enter a valid email address (e.g., user@example.com)</span>

<!-- Bad: generic error with no guidance -->
<span class="error">Invalid input</span>

4. Robust

Content must work with current and future assistive technologies.

Valid HTML (4.1.1 — Level A, removed in WCAG 2.2): While removed as a formal criterion, valid HTML with proper nesting is still the foundation of accessible markup. Screen readers rely on the DOM structure.

Name, role, value (4.1.2 — Level A): Every UI component must expose its name (label), role (button, link, checkbox), and state (checked, expanded, selected) to assistive technology.

<!-- Accessible accordion -->
<button aria-expanded="false" aria-controls="section1-content">
  Section 1
</button>
<div id="section1-content" role="region" hidden>
  Content here...
</div>

Common WCAG Failures by Category

These are the most frequently failed criteria, based on the WebAIM Million report analyzing 1,000,000 home pages:

Rank Issue WCAG Criterion % of Pages Failing
1 Low contrast text 1.4.3 83%
2 Missing alt text 1.1.1 55%
3 Missing form labels 1.3.1 / 4.1.2 46%
4 Empty links 2.4.4 44%
5 Missing document language 3.1.1 18%
6 Empty buttons 4.1.2 27%

Testing Your Site

Automated Tools

Automated tools catch approximately 30-40% of WCAG issues. They're good for low-contrast, missing alt text, missing labels, and structural problems. They cannot evaluate whether alt text is meaningful, whether focus order is logical, or whether content is understandable.

Tool Type What It Catches
axe DevTools Browser extension 57 WCAG rules, zero false positives
WAVE Browser extension / web Visual overlay of errors on your page
Lighthouse Built into Chrome DevTools Subset of axe rules with a score
Pa11y CLI / CI pipeline HTML CodeSniffer rules, good for CI
IBM Equal Access Browser extension IBM's accessibility checker

Manual Testing Checklist

Automated tools miss most operable and understandable criteria. Test these manually:

  1. Keyboard navigation: Tab through the entire page. Can you reach and operate every interactive element? Can you always see where focus is? Can you escape modals and dropdowns?
  2. Screen reader: Test with VoiceOver (Mac: Cmd+F5), NVDA (Windows, free), or JAWS (Windows, paid). Listen to the page — does it make sense when read linearly?
  3. Zoom to 200%: Ctrl/Cmd + to 200% zoom. Does content reflow without horizontal scrolling? Are all elements still visible and functional?
  4. Color only: Look for information conveyed only through color (red/green status indicators, required field markers). Add text labels or patterns.
  5. Motion: Check for auto-playing animations, carousels, or video. Users must be able to pause, stop, or hide motion (2.2.2).

CI/CD Integration

Run accessibility checks in your build pipeline:

# axe-core with Playwright
npm install @axe-core/playwright

# Pa11y in CI
npx pa11y https://your-site.com --standard WCAG2AA --reporter json

WCAG 2.2 New Criteria (October 2023)

Criterion Level What Changed
3.2.6 Consistent Help A Help mechanisms (chat, phone, FAQ) must appear in the same relative location across pages
3.3.7 Redundant Entry A Don't ask users to re-enter information they've already provided in the same process
3.3.8 Accessible Authentication (Minimum) AA Login must not require cognitive function tests (CAPTCHAs) unless alternatives are provided
2.4.11 Focus Not Obscured (Minimum) AA Focused element must not be entirely hidden by sticky headers, cookie banners, or chat widgets
2.4.13 Focus Appearance AAA Focus indicator must meet specific size and contrast requirements
2.5.7 Dragging Movements AA Any operation that uses dragging must also work with a single pointer (click alternative)
2.5.8 Target Size (Minimum) AA Interactive targets must be at least 24×24 CSS pixels (with spacing exceptions)

What OpsBlu Tests

OpsBlu's automated accessibility audit (powered by axe-core) checks for the most impactful WCAG violations:

  • Color contrast ratio failures (1.4.3)
  • Missing image alt text (1.1.1)
  • Missing form input labels (1.3.1, 4.1.2)
  • Empty links and buttons (2.4.4, 4.1.2)
  • Missing document language (3.1.1)
  • Heading hierarchy issues (1.3.1)
  • Missing landmark regions (1.3.1)
  • ARIA attribute misuse (4.1.2)
  • Duplicate IDs (4.1.1)
  • Missing page titles (2.4.2)

The audit report groups findings by severity (critical, serious, moderate, minor) and provides fix-it guidance for each issue.

Next Steps

返回顶部