The Web Content Accessibility Guidelines (WCAG) are the foundation of digital accessibility worldwide. Developed by the World Wide Web Consortium (W3C), WCAG provides the technical standards that define what it means for web content to be accessible to people with disabilities.
Whether you're a developer, designer, content creator, or accessibility professional, understanding WCAG is essential. These guidelines don't just represent best practices—they're referenced by accessibility laws in dozens of countries and form the basis of virtually every digital accessibility requirement.
What is WCAG?
WCAG (Web Content Accessibility Guidelines) is an international standard that provides testable criteria for making web content accessible to people with disabilities. "Web content" includes:
- Text, images, and multimedia on websites
- Web applications and interactive features
- Mobile applications (when based on web technologies)
- Documents delivered via the web (PDFs, Office files)
- Code and markup that defines content structure and presentation
WCAG is developed through the W3C process in cooperation with individuals and organizations around the world. The goal is to provide a single shared standard that meets the needs of individuals, organizations, and governments internationally.
WCAG defines what accessible content should achieve, not how to achieve it with specific technologies. This means WCAG can be applied to any web technology—HTML, CSS, JavaScript, ARIA, PDF, and future technologies not yet invented.
The POUR Principles
All WCAG guidelines and success criteria are organized under four foundational principles, known by the acronym POUR. These principles represent the essential requirements for anyone to access and use web content:
Information and user interface components must be presentable to users in ways they can perceive. This means content cannot be invisible to all of their senses—if someone can't see, they must be able to hear or feel the information; if they can't hear, they must be able to see it.
Examples: Alt text for images, captions for videos, sufficient color contrast, text resizing
User interface components and navigation must be operable. This means users must be able to operate the interface—it cannot require interaction that a user cannot perform. If someone can't use a mouse, all functionality must be available via keyboard.
Examples: Keyboard accessibility, skip navigation links, no seizure-inducing content, sufficient time limits
Information and the operation of user interface must be understandable. This means users must be able to understand the information as well as how to use the interface—the content or operation cannot be beyond their understanding.
Examples: Readable text, predictable navigation, clear error messages, input assistance
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. As technologies evolve, content should remain accessible—users should be able to choose their own technologies to access content.
Examples: Valid HTML, proper use of ARIA, name/role/value for custom controls, status messages
Conformance Levels: A, AA, AAA
WCAG success criteria are organized into three levels of conformance, representing increasing degrees of accessibility:
The minimum level. Level A addresses the most fundamental accessibility barriers that completely prevent some users from accessing content. Sites that don't meet Level A contain critical issues that block access entirely.
Example requirements: All images have alt text, all functionality is keyboard accessible, no flashing content above 3 times per second
The recommended level. Level AA addresses significant barriers that affect the widest range of users. This is the level referenced by most accessibility laws worldwide and is considered the standard for accessibility.
Example requirements: Color contrast of at least 4.5:1, captions for live video, consistent navigation, visible focus indicators
The enhanced level. Level AAA provides the highest level of accessibility but may not be achievable for all content types. W3C does not recommend AAA as a general requirement for entire sites.
Example requirements: Color contrast of at least 7:1, sign language interpretation, extended audio descriptions, no timing limits
To claim Level AA conformance, you must meet all Level A and all Level AA success criteria. You cannot skip Level A requirements. Similarly, Level AAA includes all requirements from A and AA.
WCAG Versions: 2.0 → 2.1 → 2.2
WCAG has evolved over time to address new technologies and better serve users with diverse disabilities:
WCAG versions are backward compatible. Content that meets WCAG 2.2 also meets WCAG 2.1 and 2.0. This means organizations can adopt the latest version while maintaining compliance with laws that reference older versions.
The 13 Guidelines
WCAG 2.2 contains 13 guidelines organized under the four POUR principles. Each guideline contains multiple testable success criteria:
- 1.1 Text Alternatives — Provide text alternatives for non-text content
- 1.2 Time-based Media — Provide alternatives for audio and video
- 1.3 Adaptable — Create content that can be presented in different ways
- 1.4 Distinguishable — Make it easy to see and hear content
- 2.1 Keyboard Accessible — Make all functionality available from keyboard
- 2.2 Enough Time — Provide users enough time to read and use content
- 2.3 Seizures and Physical Reactions — Do not design content that causes seizures
- 2.4 Navigable — Provide ways to help users navigate and find content
- 2.5 Input Modalities — Make it easier for users to operate through various inputs
- 3.1 Readable — Make text content readable and understandable
- 3.2 Predictable — Make pages appear and operate in predictable ways
- 3.3 Input Assistance — Help users avoid and correct mistakes
- 4.1 Compatible — Maximize compatibility with current and future user agents
What's New in WCAG 2.2
WCAG 2.2 introduced 9 new success criteria focusing on usability improvements for keyboard navigation, touch targets, cognitive accessibility, and authentication. One criterion (4.1.1 Parsing) was removed as obsolete.
Level A (2 New Criteria)
When an element receives keyboard focus, it must be at least partially visible—not completely hidden by other content like sticky headers, chat widgets, or modal overlays.
Information previously entered by the user in the same process must be auto-populated or available for selection, rather than requiring the user to re-enter it. Helps users with cognitive and memory difficulties.
Level AA (4 New Criteria)
Stricter version of 2.4.11—the focused element must be fully visible, not just partially visible. No part of the component can be hidden by author-created content.
Any functionality that requires dragging must have a single-pointer alternative (like click or tap). Benefits users with motor impairments who cannot perform drag operations.
Touch targets must be at least 24×24 CSS pixels, OR have sufficient spacing from adjacent targets. A more achievable version of the existing AAA criterion (44×44 pixels).
If help mechanisms (contact info, chat, FAQs) are repeated across pages, they must appear in the same relative order. Helps users with cognitive disabilities find help consistently.
Authentication cannot require cognitive function tests (memory, puzzles, transcription) unless alternatives are provided—like password managers, copy-paste, or biometrics. Critical for users with cognitive disabilities.
Level AAA (3 New Criteria)
Focus indicators must be at least 2 CSS pixels thick around the element's perimeter AND have a 3:1 contrast ratio between focused and unfocused states.
Stricter version—authentication cannot require cognitive tests even for object recognition or personal content identification.
Removed: 4.1.1 Parsing
The success criterion 4.1.1 Parsing has been removed from WCAG 2.2 because modern browsers now handle HTML parsing consistently, making the requirement obsolete. Any remaining parsing issues that affect users are covered by other success criteria like 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value.
Key Success Criteria to Know
While all success criteria matter, these are among the most commonly tested and most frequently failed:
| Criterion | Level | Requirement |
|---|---|---|
| 1.1.1 Non-text Content | A | All images, icons, and non-text content have text alternatives |
| 1.4.3 Contrast (Minimum) | AA | Text has at least 4.5:1 contrast ratio; large text 3:1 |
| 2.1.1 Keyboard | A | All functionality available via keyboard |
| 2.4.4 Link Purpose (In Context) | A | The purpose of each link can be determined from link text or context |
| 2.4.7 Focus Visible | AA | Keyboard focus indicator is visible |
| 3.1.1 Language of Page | A | The default language of the page is programmatically determined |
| 3.3.2 Labels or Instructions | A | Labels or instructions provided when content requires user input |
| 4.1.2 Name, Role, Value | A | Custom controls have accessible names, roles, and states |
WCAG and the Law
WCAG is referenced by accessibility laws and regulations worldwide. Understanding which version and level applies is critical for compliance:
| Law/Regulation | Jurisdiction | WCAG Reference |
|---|---|---|
| ADA Title II (2024 Rule) | United States | WCAG 2.1 AA |
| Section 508 | United States (Federal) | WCAG 2.0 AA |
| European Accessibility Act | European Union | EN 301 549 (WCAG 2.1 AA) |
| EU Web Accessibility Directive | European Union (Public Sector) | EN 301 549 (WCAG 2.1 AA) |
| AODA | Ontario, Canada | WCAG 2.0 AA |
| UK Public Sector Regulations | United Kingdom | WCAG 2.1 AA (updating to 2.2) |
Even if your legal requirement references WCAG 2.1 or 2.0, targeting WCAG 2.2 AA ensures you're prepared for future regulatory updates. EN 301 549 (the EAA standard) is expected to adopt WCAG 2.2 in 2026, and other regulations will follow.
Testing for WCAG Compliance
WCAG testing requires a combination of automated tools and manual evaluation:
Automated Testing
Automated tools can quickly identify many common issues but only catch approximately 30-40% of WCAG failures. Popular tools include:
- axe DevTools — Browser extension for Chrome/Firefox
- WAVE — Free web-based accessibility checker
- Lighthouse — Built into Chrome DevTools
- IBM Equal Access — Comprehensive automated scanner
- Pa11y — Command-line and CI/CD integration
Manual Testing
Human evaluation is essential for criteria that cannot be automated:
- Keyboard testing: Navigate using only Tab, Enter, Arrow keys, Escape
- Screen reader testing: Test with NVDA, JAWS, VoiceOver, or TalkBack
- Zoom testing: Test at 200% and 400% zoom levels
- Content review: Check alt text quality, heading structure, link text
- Color/contrast: Verify information isn't conveyed by color alone
User Testing
Testing with actual users with disabilities provides insights that technical testing cannot. Include users with diverse disabilities in your testing process whenever possible.
WCAG and the CPACC Exam
WCAG is a significant component of the CPACC exam, primarily covered in Domain III: Standards, Laws, and Management Strategies. Key topics include:
- Understanding the POUR principles and how they apply to accessibility
- Knowing the three conformance levels and their purposes
- Understanding how WCAG relates to various accessibility laws
- Recognizing key success criteria and their requirements
- Understanding the relationship between WCAG, EN 301 549, and Section 508
The CPACC exam tests conceptual understanding rather than technical implementation. You should know what WCAG requires and why, but not necessarily how to write code that meets each criterion.
Memorize the POUR acronym and what each letter represents. Know that Level AA is the most commonly referenced legal standard. Understand that WCAG is technology-agnostic—it defines outcomes, not implementations. These foundational concepts appear frequently on the exam.
Test Your WCAG Knowledge
Our CPACC practice tests include comprehensive coverage of WCAG concepts—POUR principles, conformance levels, key success criteria, and how WCAG applies to accessibility laws.
Start CPACC Practice Test →