What Is WCAG? The Web Accessibility Standard, Explained Plainly

Almost every web accessibility law in the world has the same shape. The law says a website must be accessible to people with disabilities, and then, rather than describing what that means in legal language, it points at a technical document written by a standards body. That document is nearly always the Web Content Accessibility Guidelines — WCAG.

Understanding WCAG is therefore not an academic exercise. It is the difference between knowing what a regulator, a court or a procurement officer will actually measure your site against, and guessing.

Who writes WCAG, and why that matters

WCAG is published by the World Wide Web Consortium (W3C), the same standards body behind HTML and CSS, through its Web Accessibility Initiative. It is developed in public by a working group of browser vendors, assistive technology makers, accessibility practitioners and disabled people, and it goes through a formal process before it becomes a W3C Recommendation — the W3C's term for a finished standard.

That provenance is the reason lawmakers lean on it. A government does not want to define "accessible website" from scratch, argue about it for a decade, and then watch the definition rot as technology changes. Pointing at WCAG borrows an internationally recognised, testable definition that is maintained by people who do this full time. WCAG 2.2 has also been adopted as an international standard in its own right, published as ISO/IEC 40500:2025.

The four principles: POUR

WCAG organises everything around four principles. Content must be:

• Perceivable — people must be able to perceive the information. If your only version of a message is a colour, an image with no description, or audio with no transcript, some people cannot perceive it at all.
• Operable — people must be able to operate the interface. If something only works with a mouse, or a carousel moves faster than someone can read, it is not operable for everyone.
• Understandable — content and interface behaviour must be comprehensible. Unlabelled form fields, unexplained errors and pages that change unexpectedly under you fail here.
• Robust — content must work reliably with assistive technologies, now and as those technologies evolve.

Underneath the four principles sit guidelines, and underneath those sit the actual testable requirements, called success criteria. When a tester says a page "fails 1.4.3", they are naming a specific success criterion — in that case, Contrast (Minimum).

A, AA and AAA

Every success criterion carries a conformance level.

Level A is the floor. These are the criteria whose absence blocks people outright: content with no text alternative, functionality that cannot be reached by keyboard, video with no captions at all.

Level AA is the working standard. This is the level referenced by essentially every accessibility law that names one, and it is the level any sensible organisation aims at. It adds requirements like minimum colour contrast, resizable text that reflows without horizontal scrolling, visible focus indicators and consistent navigation.

Level AAA is the enhanced level — higher contrast, sign language interpretation for video, extended audio description, reading-level limits. The W3C explicitly states that AAA conformance is not recommended as a general policy for entire sites, because it is not possible to satisfy all Level AAA criteria for some content. The right posture is AA as the target, with individual AAA criteria adopted where they make sense for your audience.

WCAG 2.2 contains 86 testable success criteria: 31 at Level A, 24 at AA and 31 at AAA. Meeting Level AA means meeting all 31 A criteria *and* all 24 AA criteria — the levels are cumulative, not alternatives.

The versions, and which one applies to you

This is where most confusion lives, because the standard has moved on faster than the laws that cite it.

WCAG 2.0 was published in December 2008 with 61 success criteria. It is old, but it is not obsolete — the United States' Section 508 standard, which governs federal agencies, still references WCAG 2.0 Level A and AA.

WCAG 2.1 arrived in June 2018, adding 17 success criteria aimed at three groups the 2008 standard served poorly: mobile users, people with low vision, and people with cognitive and learning disabilities. It brought in requirements like Reflow, Non-text Contrast, Text Spacing and Pointer Gestures.

WCAG 2.2 was published on 5 October 2023 and revised on 12 December 2024. It adds nine new success criteria and formally removes one. We cover what changed in WCAG 2.2 in detail separately.

The versions are backward compatible: content that conforms to 2.2 at a given level also conforms to 2.1 and 2.0 at that level. So building to WCAG 2.2 AA satisfies a law that names 2.1 AA.

WCAG 3.0 exists, and you will see it referenced in vendor marketing. Be sceptical. As of this writing it is a W3C Working Draft — the most recent published on 3 March 2026 — and the W3C's own language is unambiguous: it "is years away from being completed", many parts "are in an exploratory or developing phase and will change substantially", and WCAG 2 will remain the standard to build against for years after WCAG 3 is finished. Anyone selling you WCAG 3 readiness today is selling you a draft.

What conformance actually requires

Here is the part that most "we meet WCAG AA" claims quietly skip. WCAG defines five conformance requirements, and a claim is only valid if all five hold.

1. Conformance level. One full level is satisfied — every criterion at that level and every level below it. There is no partial conformance in WCAG 2.x, and no percentage-based conformance. "We meet 94% of AA" is not a conformance claim; it is a progress report.
2. Full pages. Conformance is claimed for complete pages. You cannot carve out the third-party widget in the footer and claim the rest.
3. Complete processes. If a page is one step in a process — checkout, registration, an application form — every page in that process must conform, or none of them can be claimed.
4. Only accessibility-supported ways of using technologies. Anything relied on for conformance has to work with the assistive technologies people actually use.
5. Non-interference. Even content you are *not* claiming conformance for must not block access to the rest of the page. Four criteria apply regardless: audio control, no keyboard trap, three flashes or below, and pause/stop/hide.

Requirement 3 is the one that catches commercial sites most often. A retailer can have an immaculate product page and still be unable to claim conformance, because the payment step three clicks later has an unlabelled field. Accessibility is measured along the path a person actually takes, not on the pages you chose to test.

Why "we ran a scanner and it was clean" is not conformance

Automated testing is genuinely useful — it is fast, repeatable, and it catches the highest-volume problems. But it cannot evaluate most of WCAG. Deque, who build the widely used axe-core engine, published research finding that their automated tests produced results for 16 of the 50 WCAG 2.1 Level AA success criteria: roughly a third by criteria count. When the UK's Government Digital Service built a test page seeded with 143 deliberate accessibility barriers and ran ten automated tools at it, the best single tool found 41% of them, and 29% of the barriers were missed by every tool tested.

That is not an argument against automation. It is an argument for knowing what it measures. A clean automated scan means the machine-detectable failures are gone, which is a real and worthwhile result. It does not mean a screen reader user can complete your checkout. Our guide to automated versus manual accessibility testing sets out which parts of WCAG belong to which method.

Where to start

If you have never assessed your site, do not begin by reading all 86 success criteria. Begin with the failures that are both most common and most mechanical, because that is where the volume is. WebAIM's annual analysis of a million home pages consistently finds the same short list dominating: low contrast text, missing alternative text, missing form input labels, empty links, empty buttons and missing document language. Fixing those categories will not make you conformant, but it will remove most of the detected errors on a typical site and clear the ground so that the harder, human-judgement work is visible.

From there, the practical sequence is: check your colour contrast, fix your alt text, test the whole site with a keyboard, and run a structured audit to find what the scanners cannot see.

*WCAG success criteria and conformance requirements referenced here are from the W3C's published Web Content Accessibility Guidelines 2.2. Automated coverage figures are from Deque Systems' Automated Accessibility Coverage Report and the UK Government Digital Service's 2017 tool comparison. ChecksTrue is not affiliated with or endorsed by the W3C or Deque Systems.*