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:
- 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?
- 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?
- Zoom to 200%: Ctrl/Cmd + to 200% zoom. Does content reflow without horizontal scrolling? Are all elements still visible and functional?
- Color only: Look for information conveyed only through color (red/green status indicators, required field markers). Add text labels or patterns.
- 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
- WAI-ARIA Standards — roles, states, and properties for dynamic content
- Section 508 Compliance — US federal accessibility requirements
- ADA Compliance — Americans with Disabilities Act web accessibility
- WCAG 2.2 Quick Reference — filterable list of all success criteria
- WebAIM Million — annual analysis of accessibility across 1M home pages