What Is WCAG? A Plain-English Guide to 2.0, 2.1 and 2.2

WCAG doesn't have to be intimidating

If you've ever looked into web accessibility, you've probably encountered the acronym WCAG - and then promptly felt overwhelmed. The Web Content Accessibility Guidelines are the global standard for accessible web design, referenced by laws and regulations in dozens of countries. But reading the actual specification can feel like deciphering legal code written by engineers.

The good news? You don't need to memorize every success criterion. Once you understand the structure and principles behind WCAG, the standard becomes a practical tool rather than an intimidating document. This post breaks it all down in plain language.

What is WCAG?

The Web Content Accessibility Guidelines (WCAG) are a set of recommendations for making web content more accessible to people with disabilities. They're developed and maintained by the Web Accessibility Initiative (WAI), which is part of the World Wide Web Consortium (W3C) - the same organization that develops HTML, CSS, and other core web standards.

WCAG has evolved through several versions:

• WCAG 1.0 (1999) - The original guidelines, now largely obsolete. They were tied to specific HTML techniques and didn't age well.
• WCAG 2.0 (2008) - A major rewrite that introduced technology-agnostic principles. Still widely referenced and forms the foundation of most accessibility laws.
• WCAG 2.1 (2018) - Added 17 new success criteria addressing mobile accessibility, low vision, and cognitive disabilities. This is the version most commonly required today.
• WCAG 2.2 (2023) - The latest release, adding 9 new criteria focused on users with cognitive disabilities, low vision, and mobile devices.

Each new version builds on the previous one - all WCAG 2.0 criteria still apply in 2.1, and all 2.1 criteria still apply in 2.2. Think of it as additive, not replacing.

The four principles: POUR

At its heart, WCAG is organized around four principles. Every success criterion falls under one of these. They spell out the acronym POUR, and they answer a simple question: what does a user need from web content?

1. Perceivable

Users must be able to perceive the information being presented. Content can't be invisible to all of a user's senses.

In practice, this means:

• Images need alt text so screen reader users know what they depict
• Videos need captions so deaf and hard-of-hearing users can follow along
• Text needs sufficient color contrast against its background so low-vision users can read it
• Content shouldn't rely on color alone to convey meaning (e.g., "fields marked in red are required" fails if someone can't see red)

The key idea: if someone can't perceive your content through at least one sense, it doesn't exist for them.

2. Operable

Users must be able to operate the interface. Every interactive element must be usable regardless of how someone navigates.

In practice, this means:

• Everything that works with a mouse must also work with a keyboard
• Users must have enough time to read and interact with content - no auto-advancing carousels that move too fast
• Content should not flash in ways that could trigger seizures
• Users need clear navigation mechanisms - skip links, descriptive page titles, logical focus order

The key idea: a beautiful interface is useless if someone can't actually use it.

3. Understandable

Users must be able to understand both the information and how the interface works. Content should be readable, and the site should behave predictably.

In practice, this means:

• The language of the page is identified in the HTML (so screen readers use the correct pronunciation)
• Navigation is consistent across pages
• Form inputs have clear labels and error messages that explain what went wrong and how to fix it
• Unusual words or abbreviations are defined

The key idea: clarity isn't just good writing - it's an accessibility requirement.

4. Robust

Content must be robust enough to be interpreted reliably by a wide range of technologies, including assistive technologies like screen readers.

In practice, this means:

• HTML is well-formed and valid - proper opening and closing tags, unique IDs
• Custom components use appropriate ARIA roles and properties so assistive technologies can understand them
• Status messages are programmatically communicated without requiring focus changes

The key idea: your content should work not just in today's browsers, but with the assistive technologies your users actually rely on.

Conformance levels: A, AA, and AAA

Each WCAG success criterion is assigned one of three conformance levels. These indicate the impact and difficulty of meeting the requirement:

Level A - The baseline

These are the most fundamental requirements. Failing Level A means your site has serious barriers that will completely block some users. Examples include providing alt text for images and ensuring all functionality is available via keyboard.

Level AA - The practical standard

Level AA addresses the most common barriers people with disabilities encounter. This is the level referenced by most laws and regulations worldwide - including the ADA, the European Accessibility Act, and Section 508. Examples include meeting minimum color contrast ratios (4.5:1 for normal text) and providing visible focus indicators.

If you're aiming for one level, aim for AA. It's the sweet spot between meaningful impact and practical feasibility.

Level AAA - The gold standard

Level AAA represents the highest level of accessibility. These criteria are often difficult to achieve for all types of content - for example, requiring a contrast ratio of 7:1 or providing sign language interpretation for all video. W3C itself states that it's not recommended to require AAA conformance as a general policy, because it's not always possible.

That said, meeting individual AAA criteria where feasible (like enhanced contrast) is excellent practice.

How to read a success criterion

Each WCAG success criterion follows a consistent structure. Let's break down a real example:

1.4.3 Contrast (Minimum) - Level AA

Here's what each part tells you:

• 1 - The principle (1 = Perceivable)
• 4 - The guideline within that principle (1.4 = Distinguishable)
• 3 - The specific success criterion number
• Contrast (Minimum) - The human-readable name
• Level AA - The conformance level

The criterion itself states: "The visual presentation of text and images of text has a contrast ratio of at least 4.5:1" (with exceptions for large text, incidental text, and logotypes).

Beyond the criterion text, WCAG provides techniques - specific implementation approaches that satisfy the requirement. Techniques are categorized as "sufficient" (guaranteed to pass), "advisory" (recommended but not required), and "failures" (guaranteed to fail). This layered structure means you can understand both what to achieve and how to achieve it.

WCAG 2.1 vs. 2.2: What changed?

If you're already working toward WCAG 2.1 compliance, you're in good shape. WCAG 2.2 adds a targeted set of improvements, mostly benefiting users with cognitive disabilities, low vision, and mobile device users:

Key additions in WCAG 2.2

• Focus Appearance (2.4.13, AA) - Focus indicators must meet minimum size and contrast requirements, ending the era of invisible or barely-visible outlines
• Dragging Movements (2.5.7, AA) - Any action that requires dragging must also have a non-dragging alternative (like click-to-move), helping users with motor impairments
• Accessible Authentication (3.3.8, AA) - Login flows cannot require cognitive function tests (like remembering a password or solving a puzzle) without providing alternatives like password managers or biometric options
• Consistent Help (3.2.6, A) - If a help mechanism (like a chat widget or contact link) appears on multiple pages, it must be in the same relative location
• Redundant Entry (3.3.7, A) - Information a user has already entered in a process should be auto-populated or available to select, rather than requiring them to re-enter it

One notable change: 4.1.1 Parsing was removed in WCAG 2.2. Modern browsers and assistive technologies have become robust enough at handling markup errors that this criterion is no longer considered necessary.

How AccessGuard maps to WCAG

Understanding WCAG is valuable, but manually checking your site against dozens of success criteria is time-consuming and error-prone. This is where automated scanning becomes essential.

AccessGuard scans your website and maps every issue it finds to a specific WCAG success criterion. Each issue includes:

• The criterion number and name (e.g., 1.4.3 Contrast Minimum)
• The conformance level (A, AA, or AAA)
• A severity rating - error, warning, or notice - so you can prioritize what to fix first
• AI-powered fix suggestions that explain exactly what to change in your code

This means you don't need to cross-reference the WCAG specification yourself. AccessGuard connects the dots between the issue on your page and the standard it violates, then tells you how to fix it.

Now that you understand the structure behind WCAG, you can read your scan results with confidence - and make informed decisions about which issues to address first.