WCAG Overview

The Web Content Accessibility Guidelines (WCAG) are the internationally recognized standard for making web content accessible to people with disabilities. Published by the World Wide Web Consortium (W3C) through the Web Accessibility Initiative (WAI), WCAG provides a shared framework that developers, designers, and organizations use to evaluate and improve the accessibility of their websites and applications.

Understanding WCAG is the foundation of all accessibility work. Whether you are running automated scans, performing manual audits, or defending your organization against legal claims, WCAG is the benchmark against which your work will be measured.

WCAG Versions: 2.1 and 2.2

WCAG has evolved through several versions. The most widely referenced versions today are:

• WCAG 2.0 (December 2008) — The foundational version that established the POUR principles and three conformance levels. Still referenced in many legal frameworks.
• WCAG 2.1 (June 2018) — Extended WCAG 2.0 with 17 new success criteria addressing mobile accessibility, low vision, and cognitive disabilities. Added guidelines for orientation, reflow, text spacing, and more.
• WCAG 2.2 (October 2023) — The latest version, adding 9 new success criteria focused on users with cognitive or learning disabilities, users of mobile devices, and users with low vision. Notable additions include focus appearance requirements, dragging movements alternatives, and consistent help mechanisms.

The Four POUR Principles

WCAG is organized around four fundamental principles, known by the acronym POUR. Every success criterion in WCAG maps to one of these principles:

1. Perceivable

Information and user interface components must be presentable to users in ways they can perceive. This means content cannot be invisible to all of a user's senses.

• Provide text alternatives for non-text content (images, icons, charts)
• Provide captions and transcripts for audio and video content
• Create content that can be presented in different ways without losing meaning (e.g., a simpler layout)
• Make it easier for users to see and hear content, including separating foreground from background

2. Operable

User interface components and navigation must be operable. Users must be able to interact with all controls and navigation using their preferred input method.

• Make all functionality available from a keyboard
• Give users enough time to read and use content
• Do not design content in a way that is known to cause seizures or physical reactions
• Provide ways to help users navigate, find content, and determine where they are
• Make it easier to use inputs other than keyboard (touch, voice, pointer devices)

3. Understandable

Information and the operation of the user interface must be understandable. Users must be able to comprehend both the content and how the interface works.

• Make text readable and understandable
• Make web pages appear and operate in predictable ways
• Help users avoid and correct mistakes (especially in forms)

4. Robust

Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

• Maximize compatibility with current and future user agents, including assistive technologies
• Use valid, semantic HTML
• Ensure custom components communicate their name, role, and value to assistive technologies
• Provide status messages that can be programmatically determined without receiving focus

Conformance Levels: A, AA, AAA

Each WCAG success criterion is assigned one of three conformance levels, indicating the impact and difficulty of implementation:

• Level A — The minimum level of accessibility. Failure to meet Level A criteria means some users will find it impossible to use the site. Examples: providing alt text for images (1.1.1), making content keyboard accessible (2.1.1), not using content that flashes more than three times per second (2.3.1).
• Level AA — The standard target for most organizations and the level referenced by most laws and regulations. Addresses the most common barriers for the widest range of disabilities. Examples: minimum color contrast ratios (1.4.3), content reflow at 320px width (1.4.10), visible focus indicators (2.4.7).
• Level AAA — The highest level of accessibility. While desirable, full AAA conformance across an entire site is not usually achievable or required. Examples: enhanced contrast ratio of 7:1 (1.4.6), sign language interpretation for video (1.2.6), limiting reading level to lower secondary education (3.1.5).

Key Success Criteria with Examples

WCAG 2.2 contains 87 success criteria in total (30 at Level A, 24 at Level AA, and 33 at Level AAA). Here are some of the most impactful ones:

Perceivable

• 1.1.1 Non-text Content (A) — All images, icons, and non-text elements need text alternatives. Example: an <img> tag must have a meaningful alt attribute.
• 1.4.3 Contrast (Minimum) (AA) — Text must have at least a 4.5:1 contrast ratio against its background (3:1 for large text).
• 1.4.10 Reflow (AA) — Content must reflow without horizontal scrolling at 320 CSS pixels wide (equivalent to 400% zoom on a 1280px viewport).

Operable

• 2.1.1 Keyboard (A) — All functionality must be operable through a keyboard interface without requiring specific timings for individual keystrokes.
• 2.4.7 Focus Visible (AA) — Any keyboard-operable user interface must have a visible focus indicator.
• 2.5.8 Target Size (Minimum) (AA) — New in WCAG 2.2. Interactive targets must be at least 24x24 CSS pixels, with certain exceptions.

Understandable

• 3.1.1 Language of Page (A) — The default language of the page must be programmatically determinable (using the lang attribute on the <html> element).
• 3.3.2 Labels or Instructions (A) — Labels or instructions are provided when content requires user input.
• 3.3.8 Accessible Authentication (Minimum) (AA) — New in WCAG 2.2. Cognitive function tests (like remembering a password) must not be required unless alternatives are provided.

Robust

• 4.1.2 Name, Role, Value (A) — For all user interface components, the name and role can be programmatically determined; states, properties, and values can be programmatically set.
• 4.1.3 Status Messages (AA) — Status messages (like form validation errors or search results counts) can be programmatically determined by assistive technologies without receiving focus.

How WCAG Maps to Real User Needs

WCAG success criteria are not arbitrary technical requirements — they map directly to the needs of real people with disabilities:

• Blind users rely on screen readers, which need proper alt text, semantic HTML, ARIA labels, and heading structures to convey page content.
• Low-vision users depend on zoom, reflow, and sufficient color contrast to read content.
• Deaf and hard-of-hearing users need captions and transcripts for audio and video content.
• Motor-impaired users navigate with keyboards, switches, or voice commands — all of which require proper keyboard accessibility and adequate target sizes.
• Cognitively disabled users benefit from clear language, consistent navigation, error prevention, and accessible authentication.
• Users with seizure disorders are protected by guidelines limiting flashing content.

Getting Started with WCAG

If you are new to WCAG, here is a practical approach to getting started:

1. Start with Level A — Ensure all Level A criteria are met first. These are the most critical barriers.
2. Progress to Level AA — Work through Level AA criteria systematically. This is where most legal requirements live.
3. Use the WCAG Quick Reference — The W3C provides a filterable quick reference at w3.org/WAI/WCAG22/quickref that lets you browse criteria by level, technology, and guideline.
4. Run automated scans early and often — Tools like axe-core (which CodeFrog uses) catch the low-hanging fruit automatically.
5. Test manually with keyboard and screen readers — Dedicate time to testing with real assistive technologies. The later lessons in this topic walk you through exactly how.