The Web Content Accessibility Guidelines are the W3C's formal, testable specification for accessible content. Understanding their structure turns accessibility from a vague aspiration into a concrete engineering checklist.
1How WCAG Is Structured
WCAG organizes roughly ninety success criteria under the four POUR principles introduced in the previous lesson. Each criterion sits at one of three conformance levels: A (must-have), AA (should-have, industry standard), or AAA (aspirational, rarely applied wholesale).
Criteria are versioned — WCAG 2.0 (2008), 2.1 (2018, added mobile and cognitive criteria), and 2.2 (2023, added new focus-visibility and drag-alternative criteria) are all still actively referenced, with each version being a strict superset of the previous one. A page conformant with 2.2 AA is automatically conformant with 2.0 AA and 2.1 AA.
2Why Level AA Is The Real-World Target
Level A criteria are non-negotiable baseline requirements — missing them means some users are completely locked out (e.g. no text alternative for images at all). Level AAA includes criteria so strict they're often impractical across an entire site, such as providing sign-language video for every piece of audio content.
Level AA sits in the pragmatic middle and is what nearly every legal accessibility standard worldwide references, including the US ADA (via case law and Section 508), the EU's EN 301 549, and the UK Equality Act. When a project brief says 'must be WCAG compliant' without specifying a level, AA is the safe, industry-default assumption.
3Reading A Success Criterion In The Wild
When an audit tool reports a failure, it cites a criterion like '2.4.7 Focus Visible (AA)'. The first two numbers place it under Principle 2 (Operable), Guideline 4 (Navigable); the third is the criterion itself; the parenthetical is its conformance level.
Every criterion also links to a 'Techniques' document with concrete, technology-specific implementation examples — for HTML, this usually means a specific attribute, element, or ARIA pattern. Learning to trace an audit failure back to its WCAG criterion, and from there to its techniques page, is the single most useful skill for resolving accessibility bugs efficiently.
4Step-by-Step Breakdown
The Standard Behind The Standard. The Web Content Accessibility Guidelines (WCAG), published by the W3C, are the internationally recognized rulebook that every accessibility audit, legal standard, and automated linter ultimately checks against. Knowing its structure turns 'make it accessible' into a concrete, testable checklist.
Conformance Levels: A, AA, AAA. WCAG success criteria are grouped into three conformance levels. Level A covers the bare minimum, without which some users are completely blocked. Level AA is the industry-standard target, referenced by most laws worldwide. Level AAA is the strictest tier, often impractical to apply site-wide.
Conformance Levels. Which WCAG conformance level do the ADA, EN 301 549, and most corporate accessibility policies target?
- →Level A
- →Level AA
- →Level AAA
Success Criteria Are Numbered And Testable. Every WCAG rule has a stable numeric identifier, like 1.4.3 Contrast (Minimum), grouped under one of the four POUR principles. This numbering is what audit tools and legal filings reference directly, making violations unambiguous and reproducible.
Reading Success Criteria. An automated audit flags '1.4.3 Contrast (Minimum) — fail'. What does the '1.4' portion of that identifier tell you?
- →It's the WCAG spec version number
- →It's the guideline group number (here, under Perceivable)
- →It's an arbitrary internal bug-tracker ID
WCAG Is Technology-Agnostic. WCAG describes outcomes, not implementations. It never mandates HTML specifically — 'provide text alternatives for images' applies equally to a native app or a PDF. Techniques documents map each criterion to concrete HTML/ARIA patterns, which is what most developers actually consult day to day.
Outcomes vs Techniques. Why doesn't WCAG itself specify exact HTML attributes to use?
- →Because WCAG predates HTML5
- →Because WCAG defines technology-agnostic outcomes, not one specific markup language
- →It's an oversight the W3C is expected to fix
Guideline Literacy Achieved. You can now read a WCAG success-criterion citation, know which conformance level your team should target, and understand why the guidelines describe outcomes rather than specific markup — setting up every technique-focused lesson that follows.
Declare The Page Language. WCAG 3.1.1 requires every page to declare its language via the lang attribute on <html>.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1WCAG Versions Are Cumulative, Not Replacements
Conforming to WCAG 2.2 AA automatically satisfies 2.1 AA and 2.0 AA, since each new version only adds criteria — teams never need to 'choose' a version, only a level.
2Techniques Documents Bridge Guidelines To Real Markup
Each numbered success criterion links to a 'Sufficient Techniques' page with concrete HTML/ARIA examples, which is the fastest path from an audit failure to a fix.
SEO Implications
- 1
WCAG-Driven Semantic Structure Improves Crawl Comprehension
Criteria like 1.3.1 (Info and Relationships) require real headings, lists, and landmarks instead of purely visual formatting — the same structure search engines use to understand page hierarchy.
- 2
Legal Accessibility Risk Correlates With Brand & Search Trust Signals
Sites facing accessibility litigation often see reputational and engagement metrics decline, which are downstream inputs into how search engines model site quality.
Best Practices
Target WCAG 2.2 Level AA As The Project-Wide Baseline
It is the level referenced by essentially every accessibility law worldwide and is achievable without the impractical constraints of AAA, making it the correct default for production work.
Cite The Criterion Number In Bug Reports And Code Review Comments
Writing '2.4.7 Focus Visible' instead of 'add a focus style' gives reviewers and future maintainers a direct link to the authoritative spec and its accepted techniques.
Frequent Bugs
A design system removes all focus outlines for 'a cleaner look'.
This violates 2.4.7 Focus Visible (AA). Replace, don't remove, the outline — style a custom `:focus-visible` state instead of setting `outline: none`.
A team ships a feature and later gets flagged for '1.3.1 Info and Relationships' failures.
Visual-only formatting (bold text pretending to be a heading, spacing pretending to be a list) doesn't expose structure to assistive technology. Use real `<h2>`, `<ul>`, and table markup.
Real-World Examples
Custom Focus Style Instead Of Removal
A component library needed a design refresh but had to preserve WCAG 2.4.7 compliance.
a:focus { outline: none; }
a:focus-visible {
outline: 3px solid #2563eb;
outline-offset: 2px;
}