WCAG Explained: What the Standard Requires, Version by Version

WCAG is the document people point to when a contract, an RFP, or an app-store questionnaire says the product must be accessible. The letters stand for Web Content Accessibility Guidelines. The World Wide Web Consortium publishes it. It is a technical standard, not a statute. Laws copy versions of it. Procurement copies those laws. That chain is why the acronym shows up everywhere and why the version number on the page actually matters.

This is a reading of the standard itself: what the four principles demand, how 2.0 / 2.1 / 2.2 relate, what A / AA / AAA mean, what 2.2 added, and what a conformance claim is allowed to say. Enforcement stories sit in a separate article. Mixing the two is how teams end up arguing about lawsuits instead of reading the criteria they signed.

A standard, borrowed by law

W3C is a standards body. WCAG is one of its Recommendations. The current Recommendation for web content is WCAG 2.2, first published 5 October 2023 and updated 12 December 2024. The October 2023 text is also an ISO standard: ISO/IEC 40500:2025. ISO did not rewrite it. The ISO document is the same technical text.

When a government says websites must be accessible, it almost never invents a new checklist. It names WCAG, a version, and a conformance level. The United States Department of Justice, in its Title II rule for state and local government web content and mobile apps, named WCAG 2.1 Level AA. After an Interim Final Rule published 20 April 2026, larger public entities (population 50,000 or more) must meet that bar by 26 April 2027; smaller public entities and special district governments by 26 April 2028. That rule does not, by itself, bind private shops. Courts and contracts still treat WCAG as the measuring stick because it is the only widely shared, testable language.

In the European Union, the European Accessibility Act has applied since 28 June 2025 to many digital products and services sold to consumers. The technical specification those rules lean on is EN 301 549. The harmonised edition still in force for web content, v3.2.1, maps chapter 9 to WCAG 2.1 Level AA. A v4 draft (public as v4.1.0) moves web, documents, and software clauses toward WCAG 2.2 AA. Until the EU Official Journal cites the new edition, the legal presumption of conformity still sits on 2.1. Building to 2.2 now is the cheap way to stay ahead of that citation, because 2.2 is backwards compatible.

None of that makes WCAG itself a court. A lawyer still has to map which statute applies to which product. The engineering job is narrower: pick a version and a level, test the pages in scope, and do not claim more than the tests support.

POUR is the map, not a poster

WCAG 2 organises 13 guidelines under four principles. People remember the acronym POUR. The principles are the only part of the document that is easy to quote. The work lives in the success criteria under them.

Perceivable.If the information is only in one sense, someone who cannot use that sense never gets it. Images without a text alternative, video without captions, text that is 2.1:1 against its background, instructions that say “click the green button” with no other cue: those are perceivable failures. Contrast at Level AA for ordinary text is 4.5:1 (3:1 for large text). Non-text UI components that convey meaning sit at 3:1.

Operable. Every action a mouse can take needs a keyboard path, unless the path depends on a path-shaped gesture that cannot be abstracted (drawing a signature is the usual example). Focus must be visible. Time limits need a way out. Content must not flash in ways that trigger seizures. Sticky headers that cover the focused control fail a 2.2 criterion even if the rest of the page looks fine.

Understandable.The page language is declared. Labels describe the control, not the designer's internal name. Errors name the field and, where it is reasonable, how to fix it. Navigation does not reshuffle itself from page to page without a reason. Login that forbids paste, or that forces the user to type the third and seventh character of a memorised password, is a cognitive trap 2.2 now addresses directly.

Robust. Assistive technology reads the accessibility tree the browser builds from markup and ARIA, not the pixels. Custom widgets that look like buttons but are empty <div>s with a click handler have no name, no role, and no keyboard map. That is 4.1.2 Name, Role, Value: still Level A, still the criterion most component libraries break when they invent a control instead of using a native one.

2.0, 2.1, and 2.2 are all Recommendations

W3C did not withdraw 2.0 or 2.1 when 2.2 shipped. All three remain Recommendations. W3C's advice is still to use the latest. The versions are additive on purpose, so a page that meets 2.2 also meets 2.1 and 2.0 (with the Parsing exception noted below).

WCAG 2.0 (11 December 2008) is the spine: 12 guidelines, the POUR structure, the A/AA/AAA levels, and the conformance model that every later 2.x release still uses. Plenty of older contracts still cite it. Meeting only 2.0 in 2026 leaves out a decade of mobile, low-vision, and cognitive criteria.

WCAG 2.1 (5 June 2018; later edited in 2023, 2024, and 6 May 2025) added a thirteenth guideline and 17 success criteria. Orientation lock, pointer gestures, text spacing, content on hover or focus, status messages, and several low-vision and mobile items land here. This is the version the DOJ Title II rule writes down. EN 301 549 v3.2.1 writes it down for EU web content today.

WCAG 2.2 added nine success criteria and marked 4.1.1 Parsing obsolete. Six of the nine sit at A or AA, so they belong in any AA programme. Three sit at AAA. UK public-sector accessibility regulations moved the expected bar to 2.2 AA in late 2024. Teams that still see 2.1 in a US public-sector clause are not wrong; they are reading a different statute. Shipping 2.2 AA still satisfies a 2.1 AA obligation.

A, AA, and AAA are not scores

Level A is the floor. Fail it and some people cannot complete the task at all: no keyboard path, no text alternative, no captions on the only explanation of the product. Level AA adds the criteria most policies stop at: contrast, headings and labels, visible focus, resize, status messages, and the 2.2 AA set. Level AAA is a further set. Sign language interpretation of all prerecorded video, a reading level cap, and enhanced focus appearance live there. W3C states plainly that AAA should not be required as a general policy for whole sites, because some AAA criteria cannot be met for some content.

Levels are cumulative. AA means every A criterion and every AA criterion. There is no such thing as “AA except for forms.” Conformance is defined for a full web page. If a cookie banner, a chat widget, or a payment iframe is on the page, it is in the page. Authors who do not control a third-party slice can use a statement of partial conformance. That statement has a prescribed form. It is not a synonym for “we tried.”

A conformance claim is optional. Pages can meet WCAG without publishing a claim. If a claim is published, WCAG requires at least: the date, the guidelines title and version, the URI of the specification, the conformance level, and a list of the pages (or a description that unambiguously identifies them). A logo without those pieces is still a claim, and an incomplete claim is a problem of its own.

Nine additions in 2.2, in the order they actually bite

The new criteria were written for people with motor impairments, low vision, and cognitive disabilities, including on phones. They are numbered at the end of their parent guideline so that 2.0/2.1 numbers did not shift.

Focus that a sticky bar can steal (2.4.11 AA, 2.4.12 AAA)

When a user tabs, the focused control must not be hidden behind author-created content: cookie strips, floating help buttons, sticky nav. 2.4.11 (minimum) allows a sliver of the component to remain visible. 2.4.12 (enhanced) wants the whole component unobscured. The failure shows up most often in marketing sites that pin a banner and never account for keyboard users.

Dragging is not the only way (2.5.7 AA)

If a task uses a drag, there must be a single-pointer alternative: buttons to reorder, a dropdown to set a value, click-to-place. Slider handles, kanban boards, and map pins are the usual failures. A person who cannot perform a drag still has to complete the same task.

Targets that a thumb can hit (2.5.8 AA)

Interactive targets need at least 24 by 24 CSS pixels, with listed exceptions (inline links, user-agent controls, essential layout, equivalent larger control, sufficient spacing). This is not the older AAA 44 by 44 criterion (2.5.5). Icon-only controls in dense toolbars are where teams miss it.

Help that stays in the same place (3.2.6 A)

If a process offers human contact, a help mechanism, or a self-help option, that option has to appear in the same relative place across the steps. Moving “Contact support” from the header to a footer between checkout steps is the kind of inconsistency this criterion exists to stop.

Do not make people retype what they already gave you (3.3.7 A)

Information entered earlier in a process must be auto-filled or available to select, unless re-entry is essential (password confirmation is the usual essential case) or the information is no longer valid. Multi-step checkouts that ask for the same address twice fail this even when the design felt “careful.”

Login without a memory test (3.3.8 AA, 3.3.9 AAA)

3.3.8 forbids requiring a cognitive function test as a step of authentication: recalling a password from memory, transcribing a one-time code by hand, solving a puzzle, unless an alternative exists. Allowing a password manager to fill the field (no paste block, no “type characters 2, 5, and 8”) is the usual way sites meet it. Object recognition (pick your own photos) is allowed at the minimum level and removed at the enhanced AAA level. Cognitive load at login is now a first-class AA issue, not a usability nicety.

Focus appearance (2.4.13 AAA)

The enhanced focus indicator: a minimum area and contrast against adjacent colours. Most AA programmes will not require it. Teams that already restyle :focus-visible often meet a large part of it without trying.

The criterion that vanished

4.1.1 Parsing required well-formed markup: matching tags, unique IDs, no duplicate attributes. It was written when assistive technology parsed HTML itself. Browsers now expose an accessibility tree. Duplicate IDs and broken nesting still cause bugs, but they show up under Name, Role, Value and under ordinary quality control. W3C removed the criterion from 2.2 so teams would stop treating HTML validation as a WCAG 2.2 AA gate. Policies that still cite 2.0 or 2.1 may still want a 4.1.1 line in the report. That is a reporting detail, not a reason to avoid 2.2.

WCAG 3 is not the next ticket in the sprint

In parallel, the Accessibility Guidelines Working Group is writing W3C Accessibility Guidelines (WCAG) 3.0. The name dropped “Web Content” on purpose: the draft aims at a wider set of outcomes than HTML pages. The latest Working Draft is dated 3 March 2026. Working Draft means the text will change. The group has said the draft still has years of work. Candidate Recommendation is not a 2026 event. Building a product against a moving draft is how teams ship criteria that later disappear.

Until WCAG 3 is a Recommendation and until a law names it, the deliverable remains WCAG 2.2 Level AA, with 2.1 AA as the floor wherever a statute has not moved yet.

What a scan is, and what it is not

Automated tools catch missing alt attributes, missing form labels, empty buttons, contrast failures that are in the computed style, and missing document language. They do not know whether the alt text describes the image. They do not know whether a custom dropdown is operable from the keyboard. They do not know whether a video's captions match the dialogue. WebAIM's Million study keeps repeating the same automated errors on homepages; that is a useful smoke test and a terrible definition of done.

A serious test plan names the pages, the assistive technology and browsers in scope, and the success criteria. Keyboard-only passes, screen reader passes (at least one of NVDA, VoiceOver, or TalkBack, plus the browser that team actually supports), zoom to 200%, and a form that can be completed without a mouse. PDFs and native apps are adjacent standards (PDF/UA, platform accessibility APIs). Calling a PDF “WCAG 2.2 AA” without a method that maps those criteria to the document is a category error.

Overlay widgets that inject a toolbar do not rewrite your DOM into conforming content. They are not a success criterion. They are not a substitute for 1.1.1, 1.3.1, 2.1.1, or 4.1.2. Treat them as unrelated to a WCAG claim.

How a success criterion is actually written

Each criterion in the Recommendation is short, normative, and testable. Around it sit two other W3C documents that are not the law of the standard: Understanding (intent, examples, benefits) and How to Meet/ Techniques (sufficient techniques, advisory techniques, documented failures). Meeting a sufficient technique is a proven path. It is not the only path. Inventing a different method is allowed if the criterion is still satisfied. Copying a technique and missing the criterion is a common audit finding: the team implemented “G94” on photographs and left icon-only buttons silent.

Failures listed by W3C are documented ways to fail, not an exhaustive list of every bad page. Absence of a listed failure does not mean pass. The criterion text is the test.

The 13 guidelines under POUR are the grouping, not extra levels. Perceivable covers text alternatives, time-based media, adaptable structure, and distinguishable contrast. Operable covers keyboard, enough time, seizures, navigable structure, and input modalities. Understandable covers readable language, predictable behaviour, and input assistance. Robust is the compatibility guideline. Auditors cite success criterion numbers (1.4.3, 2.4.7, 3.3.8), not guideline titles. Put those numbers in tickets or the work gets restated as taste.

Accessibility supported, and the other WCAG family

WCAG conformance only counts uses of technology that are accessibility supported: user agents and assistive technologies actually exist that can handle that method. An ARIA pattern that no supported screen reader exposes is not a conforming method, even if the spec file looks complete. That is why “we used ARIA” is not a claim. The combination of browser, OS, and AT in the test plan has to be named.

A conforming alternate version is allowed: a page can fail WCAG if another version that does meet it is as free to use, as easy to find, and provides the same information and function. Serving a stripped “text only” site that is missing checkout is not an alternate version. Hiding the accessible version behind a separate URL that keyboard users never reach is not either.

WCAG is the content document. Two siblings appear in serious procurement and are easy to confuse with it. ATAG (Authoring Tool Accessibility Guidelines) covers the CMS or design tool that authors use. UAAG (User Agent Accessibility Guidelines) covers browsers and media players. WCAG2ICTis a W3C Note on applying WCAG 2 to non-web documents and software. EN 301 549 uses that idea in chapters 10 and 11. A native iOS app is not “WCAG 2.2 AA” in the HTML sense; it is platform accessibility APIs mapped through those ICT rules. Using the wrong name in a statement is how reviews bounce.

Buyers who ask for a VPAT or ACR want a completed ITI template that reports support against a chosen standard (often WCAG 2.2 plus Section 508 or EN 301 549). That report is not a certificate. It is a vendor's structured claim. Empty “supports” columns with no remarks are as weak as a homepage badge.

Where this lands in a real build

Most failures are not exotic. They are headings used for size, buttons that are not buttons, labels that are placeholders, colour as the only error signal, and focus styles removed because they “clashed with the brand.” Those are decisions in interface design and in front-end implementation. Fixing them after launch means touching every template. Putting native controls, visible focus, and labelled fields in the design system costs far less than a remediation sprint.

Pick a written target: WCAG 2.2 Level AA, full pages in the release scope. Keep 2.1 AA in the test notes if a named statute still says 2.1. Do not wait for WCAG 3. Do not put a conformance logo on a homepage that was never in the sample. The standard is readable. The expensive part is pretending a score from a homepage crawler is the same thing.