What is WCAG?

WCAG stands for the Web Content Accessibility Guidelines, and it's the closest thing the web has to an agreed definition of what "accessible" means in practice. It provides specific, testable rules for making content work for people with disabilities.

It's published by the World Wide Web Consortium (W3C), the body that maintains most of the foundational web standards you're building with. The accessibility-specific work happens through a sub-group called the Web Accessibility Initiative (WAI), which has been publishing accessibility guidance since 1997.[1]

WCAG isn't a law in and of itself, but several laws point to it. The American Disabilities Act, Section 508, the EU Web Accessibility Directive, and the UK Equality Act all define "accessible" by referencing WCAG or a standard derived from it.[2] "WCAG compliant" has become shorthand for "accessible" in legal and organizational contexts. It's that well recognized.

The current version is WCAG 2.2, published in October 2023.[3]

There's a new WCAG 3.0 in working draft right now, but it's years from finalization and isn't a usable compliance target yet. It's a significant structural departure from 2.x — different scoring model, different terminology, broader scope — but it's not what is referenced currently by any accessibility tools or documentation.[4] If you're starting a site today, stick to 2.2.

What does compliance look like?

WCAG organizes its requirements into three compliance levels. The levels stack. To conform at AA you must meet all A and AA criteria.

Level A
The floor. These are the requirements with the broadest impact. If you get these wrong, it creates serious barriers for a lot of people. But level A alone isn't generally considered sufficient. Think of it as "not actively hostile" rather than "actually accessible." If your site fails a level A criterion, fix that first.
Level AA
The general goal. This is what most legal and organizational requirements mean when they say "WCAG compliant." These make the site accessible to most people and are what you should build toward.
Level AAA
The highest level. W3C itself says conforming to AAA across an entire site isn't a realistic blanket requirement.[5] That's not a dismissal of the criteria; some of them are really worth implementing where they fit. But it's not the bar you're expected to clear everywhere, and sometimes there is good reason not to meet AAA level compliance.

How WCAG is structured

Everything in WCAG fits into a three-tier hierarchy.

At the top are four Principles: Perceivable, Operable, Understandable, and Robust. Every requirement in the standard belongs to one of these four. They're often shortened to POUR.

Under each principle are Guidelines — 13 in WCAG 2.2, each covering a more specific area like "Keyboard Accessible" or "Readable." Guidelines don't have conformance levels. They're organizational containers.

Under each guideline are Success Criteria: the actual testable rules. WCAG 2.2 has 87 of them, each with a conformance level (A, AA, or AAA) and wording precise enough to evaluate as a clear pass or fail. These are what audits check, what legal requirements cite, and what automated tools test against.

That's a lot of words, but in practice, the numbering helps you pinpoint the exact criteria you need to address. So when someone says "your image is failing 1.1.1," that refers to: Success Criterion 1.1.1 (Non-text Content, Level A), under Guideline 1.1 (Text Alternatives), under Principle 1 (Perceivable). The structure becomes readable fast and provides universal reference numbers everyone can use.

The four principles (POUR)

Perceivable

Content must be perceivable — users need to be able to access it through at least one of their senses. If information only exists visually, users who can't see it are excluded. If it only exists as audio, users who can't hear it are excluded. Alt text, captions, audio descriptions, and color contrast all help ensure information can be perceived, so their requirements all live here.

This doesn't mean every user has to be able to access content in every way. It means you can't lock information behind a single modality.

Perceivable in depth →

Operable

The interface of your site must be operable without a mouse. That means keyboard navigation primarily, but keyboard support tends to unlock a range of other input methods too: switch controls, voice navigation, and so on. Seizure safety also lives here.

Operable in depth →

Understandable

The content and interface of your site should be readable, predictable, and forgiving of errors. This covers things like setting the page language so screen readers use the right pronunciation engine, keeping navigation consistent across pages, and giving users useful error messages.

Understandable in depth →

Robust

Content should work reliably across browsers and assistive technologies, and keep working as those tools evolve. In practice this mostly comes down to writing valid, standards-compliant HTML and using ARIA correctly. Assistive technologies are built to interpret proper HTML. The more yours looks like proper HTML, the less extra work Robust requires.

Robust in depth →

Going Deeper

The full specifications of WCAG are dense by design. It's written to be unambiguous, not immediately readable. These companion resources are useful starting points for learning more:

Sources

  1. W3C Web Accessibility Initiative. "About W3C WAI." https://www.w3.org/WAI/about/ (accessed May 2026) ↩
  2. W3C WAI. "Web Accessibility Laws and Policies." https://www.w3.org/WAI/policies/ (accessed May 2026) ↩
  3. W3C. "Web Content Accessibility Guidelines (WCAG) 2.2." Published 5 October 2023. https://www.w3.org/TR/WCAG22/ ↩
  4. W3C. "W3C Accessibility Guidelines (WCAG) 3.0." Working Draft. https://www.w3.org/TR/wcag-3.0/ ↩
  5. W3C. "WCAG 2.2, Section 5: Conformance." https://www.w3.org/TR/WCAG22/#conformance (accessed May 2026) ↩