The Web Content Accessibility Guidelines, known as WCAG, are the technical yardstick most organizations use to judge whether a website or app can be used by people with disabilities. This article explains how the current version, WCAG 2.2, is organized, what it added, and where its limits lie.
What is WCAG and who writes it?
WCAG is published by the World Wide Web Consortium (W3C), the standards body behind HTML and many other web technologies. Its Web Accessibility Initiative develops the guidelines. The document is a set of testable statements, called success criteria, that describe what a page must do so that people who use screen readers, keyboards, voice control, magnification or other assistive tools are not shut out.
Versions build on one another. According to the W3C, WCAG 2.0 was published on December 11, 2008, and WCAG 2.1 on June 5, 2018. WCAG 2.2 was published on October 5, 2023, and received an update on December 12, 2024, which is the version carrying the W3C Recommendation status, the consortium’s term for a finished standard. The W3C says later versions add criteria without changing existing ones, with one exception covered below, and that content meeting 2.2 also meets 2.1 and 2.0. It encourages people to use the latest version.
How is the standard organized?
Every criterion sits under one of four principles:
- Perceivable: information must be presentable in ways users can sense, such as text alternatives for images.
- Operable: interface components and navigation must work with a range of inputs, not only a mouse.
- Understandable: content and operation must be predictable and clear.
- Robust: content must work reliably with current and future user tools, including assistive technology.
Under those principles are 13 guidelines, according to the W3C. Each criterion is also assigned a conformance level:
| Level | Meaning in practice |
|---|---|
| A | The baseline; failing these creates the most severe barriers |
| AA | The middle tier, often the target in policies and contracts |
| AAA | The highest level; the W3C does not expect it for every site |
Which level and version a given law or contract requires depends on the jurisdiction and the organization, and WCAG itself is a technical standard rather than a law.
What did WCAG 2.2 add?
The W3C lists nine new success criteria compared with WCAG 2.1. They cover keyboard focus, pointer use, help and forms, and sign-in.
| Criterion | Level | Plain-language summary |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | A keyboard-focused element must not be entirely hidden by author-created content |
| 2.4.12 Focus Not Obscured (Enhanced) | AAA | No part of the focused element may be hidden |
| 2.4.13 Focus Appearance | AAA | The focus indicator must be at least a 2 CSS pixel perimeter with 3:1 contrast between focused and unfocused states |
| 2.5.7 Dragging Movements | AA | Anything done by dragging must also work with a single pointer without dragging |
| 2.5.8 Target Size (Minimum) | AA | Pointer targets must be at least 24 by 24 CSS pixels, with exceptions |
| 3.2.6 Consistent Help | A | Repeated help options must appear in the same relative order across pages |
| 3.3.7 Redundant Entry | A | Information already entered in a process must be auto-filled or selectable |
| 3.3.8 Accessible Authentication (Minimum) | AA | Login cannot depend on a cognitive function test without an alternative |
| 3.3.9 Accessible Authentication (Enhanced) | AAA | The same, with fewer exceptions |
A CSS pixel is a layout unit that browsers scale for screen density and zoom, so 24 CSS pixels is a size in the page’s own coordinate system rather than a count of physical screen dots.
Why does keyboard focus get so much attention?
Many people navigate by pressing the Tab key rather than clicking. The “focus” is the element currently selected, normally shown with an outline. Sticky headers, cookie banners and chat widgets can slide over the focused element so that a keyboard user is, in effect, working blind. The minimum criterion at Level AA says a focused element must not be entirely hidden by content the site author created. The W3C notes an exception: content the user opens can cover it if the user can reveal the focused element without moving focus.
The two AAA criteria go further. One removes the partial-hiding allowance. The other, Focus Appearance, sets a measurable size and contrast for the outline itself. Because they are Level AAA, they are aspirational for most sites.
How big does a button have to be?
The target size criterion, 2.5.8, is the one developers often notice first. At Level AA, pointer targets must be at least 24 by 24 CSS pixels. Small tap or click targets are hard for people with tremors, limited dexterity or who use a stylus or head pointer, and for anyone on a moving train.
The W3C lists five exceptions:
- Spacing: an undersized target passes if a 24 CSS pixel circle centered on it does not intersect another target.
- Equivalent: the same function is available through another control that does meet the size.
- Inline: the target sits within a sentence or is constrained by the line height of surrounding text.
- User agent control: the browser decides the size and the author does not change it.
- Essential: a particular presentation is essential or legally required.
Worked example: the spacing exception
Take two square icon buttons, each 16 CSS pixels wide, sitting side by side. A 24-pixel circle has a 12-pixel radius. Measured from the center of a 16-pixel button, the button edge is 8 pixels away, so the circle extends 12 − 8 = 4 pixels beyond the edge. Under this simplified, illustrative arithmetic, the neighboring button would need to begin more than about 4 pixels away to stay outside the circle. Real layouts also involve diagonal neighbors and rounded shapes, so the formal test in the standard is the reference.
Does dragging or login count as an accessibility issue?
Yes, and WCAG 2.2 now says so directly. Dragging Movements requires that a function using dragging, such as reordering a list or moving a slider, can also be done with a single pointer action without dragging. Exceptions apply where dragging is essential or where the browser controls the behavior.
Accessible Authentication is closely tied to how people sign in. The Level AA criterion says a login step cannot require a cognitive function test, such as remembering a password or solving a puzzle, unless the site offers an alternative, a helping mechanism, or the test involves object recognition or personal content. The Level AAA version drops the last exception. In practice, the criteria are why password managers that can fill fields, copy-and-paste support, and alternatives to puzzle-style challenges matter. Passwordless sign-in is relevant here too, and the earlier explainer on passkeys and how they replace passwords covers how that approach works.
What about consistent help and repeated forms?
Two Level A criteria address friction that hits people with memory or attention difficulties hardest. Consistent Help says that if help options such as contact details, a self-help page or an automated chat repeat across a set of pages, they must appear in the same relative order unless the user changes it. Redundant Entry says that information a person has already typed during a process should be auto-populated or offered for selection rather than requested again. The W3C lists exceptions where re-entry is essential, needed for security, or when the earlier information is no longer valid.
What was removed, and how does WCAG 2.2 relate to the ISO standard?
WCAG 2.2 removed one criterion: 4.1.1 Parsing. The W3C describes it as obsolete. The W3C notes that authors who are required to conform to WCAG 2.0 or 2.1 may still need to test and report on it.
There is also an international standards track. According to the W3C, WCAG 2.2 is an approved ISO standard, ISO/IEC 40500:2025, which is identical to the October 2023 version. The W3C expects the December 2024 version to become ISO/IEC 40500:2026 by late 2026. The W3C describes WCAG 3, a separate effort once nicknamed “Silver,” as an early draft, so it is not something sites can be assessed against today.
What does conformance leave out?
Meeting WCAG is necessary for many accessibility goals but does not guarantee a good experience for every user. Automated scanners can detect only a portion of failures, since judging whether alt text is meaningful or a reading order is sensible takes human review and testing with people who use assistive tools. WCAG also applies to individual pages and flows, while apps built as single-page applications or through progressive web apps still have to meet the same standards as ordinary pages. Third-party widgets, embedded video and ad code can undermine an otherwise conforming site.
Two points remain open to interpretation. The W3C does not state a total count of success criteria on the pages reviewed, so figures quoted elsewhere should be checked against the current document. And which version a given law or contract demands varies, so organizations need to confirm which edition applies to them.
Conclusion: a living checklist, not a one-time audit
WCAG 2.2 keeps the structure of earlier versions while tightening the rules in areas where real users struggle: keyboard focus, small targets, dragging, repeated forms and login. Because it is backwards compatible, moving up from 2.1 means adding the nine criteria, not starting over. The practical lesson for builders and readers alike is that accessibility is a property of how a service keeps working as it changes, much like the open standards that underpin the web, discussed in the HTTP/3 and QUIC explainer.
This article is general information and not a substitute for professional accessibility, legal or compliance advice.
Sources: World Wide Web Consortium
