WCAG 2.2

the accessibility standard this site is held to

What it is

WCAG 2.2, the Web Content Accessibility Guidelines version 2.2, is the W3C standard that spells out, in testable statements, what web content has to do so that people with disabilities can use it. It became a W3C Recommendation in October 2023, and the current edition is dated 12 December 2024. It follows WCAG 2.0 from 2008 and 2.1 from 2018, and in conversation it is usually just WCAG. A WCAG 3 is being developed alongside it as a separate, multi-year effort; 2.2 is the version that contracts and audits work from today.

The document is built in layers. Four principles say content must be perceivable, operable, understandable and robust. Under them sit 13 guidelines, which state goals and are not testable. Under each guideline are the success criteria, the part that counts: each has a number such as 1.4.3, a short name such as Contrast (Minimum), a level, and a sentence that a page either meets or fails. Around this normative text the W3C publishes an Understanding document for every criterion and a library of techniques and documented failures. Those are informative: a page that meets a criterion by another route still meets it.

There are three levels. Level A is the minimum, AA adds the criteria most organisations are asked to meet, and AAA is the strictest. A level is cumulative and met in full or not at all: for Level AA, in the standard’s own words, “the web page satisfies all the Level A and Level AA success criteria, or a Level AA conforming alternate version is provided.” Conformance belongs to full pages, never to part of one, and to complete processes. When a purchase runs across five pages, all five must conform at a level for any of them to.

Version 2.2 added nine criteria and retired one. The additions at Levels A and AA are 2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.2.6 Consistent Help, 3.3.7 Redundant Entry and 3.3.8 Accessible Authentication (Minimum). The other three, 2.4.12, 2.4.13 and 3.3.9, sit at AAA. 4.1.1 Parsing is marked obsolete and removed, because assistive technology no longer parses HTML directly. The rest carries over from 2.1 essentially unchanged, so a site that conforms to 2.2 also conforms to 2.1.

Why it matters

WCAG turns “make it accessible” into a list somebody can check, and the standard names what its testable criteria are for: design specifications, purchasing, regulation and contractual agreements. For a buyer, the decision that matters is one sentence in the contract. “Accessible” can be argued about forever. “WCAG 2.2 Level AA, for these pages, checked this way, with known gaps listed” can be verified, and it tells the supplier what the work includes before the price is set.

The level is a genuine trade-off. Level AA is the one that public-sector rules and procurement documents most often name, and nearly any content can reach it. AAA is another matter: the standard itself advises against making Level AAA a blanket requirement for whole sites, because some content cannot satisfy all of it. Sign-language interpretation of every prerecorded video with sound (1.2.6) is one example; a simpler version of any text that needs reading ability beyond lower-secondary education (3.1.5) is another. The workable pattern is AA everywhere, plus the individual AAA criteria that suit the product: 7:1 contrast for long reading text, say, or a stronger focus indicator for a tool people drive by keyboard.

The version has a clear answer. The working group recommends 2.2 as the target even where an obligation still names an earlier version, and because 2.2 contains 2.1, building to it costs nothing in compatibility. The one wrinkle is 4.1.1: an organisation bound to 2.0 or 2.1 by policy may still have to test and report Parsing.

Cost follows timing. Much of AA is settled by early choices: native HTML controls rather than hand-built ones, a palette measured for contrast, a visible focus style, layouts that reflow at 320 CSS pixels. Made at the start, they cost close to nothing. Found by an audit after launch, each becomes a defect repeated on every page that reused the component.

What it looks like in practice

This site is held to WCAG 2.2 Level AA, and two of its pages describe how. The page on taking WCAG 2.2 Level AA across the site sets a target covering every page, all three languages and both colour themes, with conformance to be defended by checks rather than asserted in a document.

Its central instrument is a conformance record with a row for every criterion, each row naming what satisfies the criterion and what checks it. Two AAA criteria are taken beyond the target, visual presentation in full and focus appearance, and the page says the second is offered rather than claimed. The rule engine runs its best-practice rules as well, a difference of thirty rules, and one of them failed the moment it was enabled: the brand mark sat outside every landmark on every inner page. A slower check covers thirty-two representative pages in two colour schemes and two widths. It proves focus in pixels by pressing the tab key and comparing screenshots, walks each page looking for a keyboard trap, applies the text-spacing overrides and doubles the root font size. The page states its result as conformance claimed at Level AA in three languages and two themes, with two AAA criteria beyond it and one criterion named as an exception.

The credits page writes that exception out for a reader. It describes Level AA as guarded rather than claimed and names 1.4.13 Content on Hover or Focus: the labels that appear when a mark is hovered or focused cannot be dismissed with a key, because that would need a script and the site runs only one. The same page lists an axe-core audit of representative pages, one per template in every language, against WCAG 2.2 A and AA in both colour schemes, inside the quality gate. It adds that a machine finds about a third of what WCAG asks, which is why the record is kept per criterion rather than as a pass mark.

Where it goes wrong

The automated audit is green and a keyboard user is stuck in a date picker. Rule engines read what the markup says, while much of WCAG is judgement about what the page does: whether alt text carries the point, whether focus order follows reading order, whether a widget can be left with the keyboard. Treat the engine as the floor. Walk every template by keyboard alone, at 200 percent text and at 320 CSS pixels wide, and record per criterion who checked it and how.

A sticky header covers the link that has focus. 2.4.11 asks that a focused component is not entirely hidden by author-created content, and fixed headers, cookie banners and chat buttons are the usual cause. Reserve the space with scroll-padding-top set to the header’s height, so the browser scrolls focused elements clear of it, and keep floating panels away from focusable content.

The sign-in step asks people to remember or retype something. 3.3.8 rules out a cognitive function test, such as a password to recall or a puzzle to solve, at any step of authentication unless an alternative, a helping mechanism or one of two narrow exceptions applies. A password field that blocks paste, or a CAPTCHA that asks for transcribed text, is where it usually fails. Allow paste and password managers, offer a passkey or an emailed link, and prefer object recognition to transcription when a test is unavoidable.

A statement says “fully compliant” and the first audit finds a failure. A level is met in full or not at all, so one missed AA criterion makes the whole claim false. Write the claim the standard describes instead: its date, the guidelines’ title, version and URI, the level, the pages it covers and the technologies relied upon. Claim only what every page in scope meets, and name any criterion that falls short by its number, with the reason and the plan, rather than rounding the level up.

Further reading

Glossary