WCAG overview

Why it matters

WCAG is the foundational technical standard for web and ICT accessibility worldwide. National laws in the US, EU, UK, Canada, Australia, and dozens of other countries either directly reference WCAG or adopt equivalent requirements. Every CPACC candidate must know who publishes WCAG, what the POUR framework is, and what conformance levels mean. (BoK p. 39)

What is WCAG and who publishes it?

The Web Content Accessibility Guidelines (WCAG) are published by the World Wide Web Consortium (W3C) through its Web Accessibility Initiative (WAI). The W3C is the primary international standards body for web technologies, and WCAG is its technical specification for accessible web content. (BoK p. 39)

WCAG has evolved through several versions:

• WCAG 1.0 (1999): the first version, now obsolete.
• WCAG 2.0 (2008): introduced the POUR framework and technology-neutral success criteria.
• WCAG 2.1 (2018): added 17 new success criteria covering mobile accessibility, low vision, and cognitive accessibility.
• WCAG 2.2 (2023): added 9 more success criteria.
• WCAG 3.0: in active development; uses a different scoring model.

Most legal and regulatory requirements worldwide — including the US Section 508, the EU Web Accessibility Directive, and EN 301 549 — reference WCAG 2.1 Level AA as the required standard. WCAG 2.1 AA is the professional default.

The POUR principles

WCAG organizes all its requirements around four principles, known by the acronym POUR: (BoK p. 39)

Perceivable

All information and user interface components must be presented in ways that users can perceive. Users who cannot see images need text alternatives; users who cannot hear audio need captions or transcripts. Content must not rely on a single sensory channel — it must be available through multiple channels so that users who lack one channel can access it through another. (BoK p. 39)

Operable

Users must be able to operate all UI components and navigation. This principle covers keyboard accessibility (all functions must be operable without a mouse), sufficient time limits (users must have enough time to read and complete tasks), avoidance of content that can trigger seizures, and clear navigation and wayfinding. (BoK p. 39)

Understandable

Content and UI behavior must be understandable. Text must be readable — using language that can be programmatically identified and presented appropriately. Interfaces must behave predictably — pages with the same purpose must work the same way. Input assistance must help users avoid and recover from errors — with clear error identification and suggestions for correction. (BoK p. 40)

Robust

Content must be robust enough to be reliably interpreted by current and future assistive technologies. This means using valid, well-formed markup; ensuring that name, role, and value are programmatically exposed for all UI components; and following platform and framework conventions so that AT can parse content correctly as both technologies evolve. (BoK p. 40)

Success criteria and conformance levels

WCAG implements its principles through guidelines and success criteria — specific, testable statements about what content must do or avoid. Each success criterion is assigned a conformance level: (BoK p. 40)

• Level A — the most basic requirements. Failing these criteria creates severe barriers that make content unusable for some people with disabilities. Examples: providing text alternatives for images, ensuring keyboard access for all functions.
• Level AA — the standard level for legal and regulatory compliance worldwide. Adds requirements for captions on live audio, minimum color contrast ratios, and accessible form inputs.
• Level AAA — the most stringent requirements. Not required for entire websites because some AAA criteria cannot feasibly be met for all content types. Examples: sign language interpretation for prerecorded audio, extended audio description.

Real-world example

An e-commerce platform is undergoing an accessibility audit against WCAG 2.1 AA. The auditor uses the POUR framework to organize findings: all product images need alt text and all decorative images need empty alt attributes (Perceivable); the checkout flow must be completable using only a keyboard with visible focus indicators (Operable); error messages in the payment form must name the field and describe the fix (Understandable); the custom dropdown menus must expose their state to screen readers via ARIA (Robust). The POUR framework turns an abstract standard into a structured audit checklist.