WCAG 2.2 in plain words: a practical accessibility guide

What WCAG is, and which version to use

The Web Content Accessibility Guidelines (WCAG) are the W3C’s standard for making web content usable by people with disabilities. They cover people who are blind or have low vision, who are deaf or hard of hearing, who use a keyboard or switch instead of a mouse, and who have cognitive or learning disabilities.

WCAG 2.2 became a W3C Recommendation on 5 October 2023, and the W3C published an updated version on 12 December 2024. The W3C encourages everyone to use the latest version. WCAG 2.2 has also been approved as the international standard ISO/IEC 40500:2025, which matches the October 2023 text (W3C WCAG overview).

Versions are backwards compatible: content that meets WCAG 2.2 also meets 2.1 and 2.0. Later versions add criteria rather than change existing ones, with one exception covered below.

The four principles: POUR

Every requirement in WCAG sits under one of four principles, broken down into 13 guidelines (WCAG 2.2):

Principle	What it means in practice
Perceivable	People can take in the content with the senses they use: text alternatives for images, captions for video, enough colour contrast, layouts that adapt.
Operable	People can use every control: by keyboard, without strict time limits, without content that flashes dangerously, with clear ways to navigate.
Understandable	Text is readable, pages behave predictably, and forms help people avoid and fix mistakes.
Robust	Content works reliably with browsers and assistive technologies such as screen readers, now and as they change.

Levels A, AA and AAA

Each success criterion has a level. Level A is the minimum, AA builds on it, and AAA is the highest. To conform at AA, a page must meet every A and every AA criterion. Conformance applies to whole pages and complete processes: if one step of a checkout fails, no page in that checkout conforms (WCAG 2.2, Conformance).

AA is the level most laws and policies refer to, and it is the sensible target for most websites and web apps. The W3C itself notes that even AAA conformance will not make content accessible to every person with every disability, so testing with real users still matters.

What’s new in WCAG 2.2

WCAG 2.2 adds nine success criteria (What’s New in WCAG 2.2):

Criterion	Level	In plain words
2.4.11 Focus Not Obscured (Minimum)	AA	A focused control must not be completely hidden by things like sticky headers, cookie banners or chat widgets.
2.4.12 Focus Not Obscured (Enhanced)	AAA	No part of the focused control is hidden.
2.4.13 Focus Appearance	AAA	The focus indicator is at least as large as a 2 CSS pixel outline around the control and changes contrast by at least 3:1.
2.5.7 Dragging Movements	AA	Anything done by dragging (sliders, reordering, maps) can also be done with a single pointer without dragging, unless dragging is essential.
2.5.8 Target Size (Minimum)	AA	Pointer targets are at least 24 by 24 CSS pixels, or have enough spacing, with some exceptions such as links inside a sentence.
3.2.6 Consistent Help	A	If help (contact details, a chat link, a FAQ) repeats across pages, it appears in the same relative order.
3.3.7 Redundant Entry	A	Don’t make people retype information they already gave in the same process; fill it in or let them select it.
3.3.8 Accessible Authentication (Minimum)	AA	Logging in must not depend on a memory or transcription test, unless there’s an alternative or a helping mechanism; supporting password managers and copy and paste are given as examples.
3.3.9 Accessible Authentication (Enhanced)	AAA	A stricter version of 3.3.8: recognising objects or your own images is no longer an allowed exception.

What was removed

Success criterion 4.1.1 Parsing has been removed in WCAG 2.2 as obsolete (What’s New in WCAG 2.2). The W3C explains that browsers now handle markup errors well, assistive technologies rely on the browser’s parsing, and the problems it used to catch now fail other criteria such as 1.3.1 and 4.1.2 (WCAG 2 FAQ). If a contract or policy still names WCAG 2.0 or 2.1, you may still need to test and report on it (WCAG 2.2).

A practical AA checklist

This is a working list, not a replacement for the standard. Criterion numbers and levels are from WCAG 2.2.

Content and structure

Every meaningful image has a text alternative; decorative images are hidden from assistive technology (1.1.1, A).
Pre-recorded video with audio has captions (1.2.2, A).
Headings, lists, tables and form labels are marked up properly, not just styled to look that way (1.3.1, A).
Each page has a descriptive title (2.4.2, A), and headings and labels describe their purpose (2.4.6, AA).
The page language is set in code (3.1.1, A), and passages in another language, such as a Hindi phrase on an English page, are marked (3.1.2, AA).
Link text makes sense on its own or in its immediate context (2.4.4, A).

Visual design

Normal text has a contrast ratio of at least 4.5:1; large text (18 point, or 14 point bold) at least 3:1 (1.4.3, AA).
Icons, input borders and focus indicators reach at least 3:1 against what is next to them (1.4.11, AA).
Colour is never the only way information is shown, for example red-only error fields (1.4.1, A).
Text can be resized to 200% without loss of content (1.4.4, AA), and content reflows at a width of 320 CSS pixels without two-way scrolling (1.4.10, AA).
Layout survives user-set text spacing (1.4.12, AA), and tooltips or pop-ups shown on hover or focus can be dismissed and don’t vanish unexpectedly (1.4.13, AA).

Keyboard and pointer

Everything works with a keyboard alone (2.1.1, A), and focus never gets trapped (2.1.2, A).
There’s a way to skip repeated blocks such as navigation (2.4.1, A).
Focus order is logical (2.4.3, A), focus is always visible (2.4.7, AA), and never completely hidden behind sticky elements (2.4.11, AA).
Targets meet the 24 by 24 CSS pixel minimum or spacing rule (2.5.8, AA), and drag actions have a non-drag alternative (2.5.7, AA).

Forms and interaction

Inputs have labels or instructions (3.3.2, A), and inputs that collect personal details expose their purpose so browsers can autofill them (1.3.5, AA).
Errors are identified in text (3.3.1, A), with suggestions for fixing them where known (3.3.3, AA).
Legal, financial and data-changing submissions can be reviewed, corrected or reversed (3.3.4, AA).
Focus or input changes don’t trigger unexpected changes of context (3.2.1 and 3.2.2, A).
Time limits can be turned off, adjusted or extended (2.2.1, A).
Repeated information isn’t requested twice in one process (3.3.7, A), and login works with password managers and paste (3.3.8, AA).
Status messages, such as “Added to cart”, are announced by screen readers without moving focus (4.1.3, AA).

Code

Custom controls expose a correct name, role and state to assistive technology (4.1.2, A). Native HTML elements do most of this for free; custom widgets need careful ARIA.
Nothing flashes more than three times a second (2.3.1, A).

How to test

No single method is enough. The W3C is direct about this: evaluation tools can assist but cannot determine accessibility on their own, and their results can be wrong. A sound approach layers three kinds of testing.

Automated checks. Run a checker in the browser and in your build pipeline. These catch missing alternative text, contrast failures, missing labels and similar issues quickly and repeatably. Treat a clean result as a starting point, not a pass.
Manual review. Unplug the mouse and complete key journeys by keyboard. Zoom to 200% and 400%. Check focus order, visible focus, sticky headers covering focus, target sizes, error handling and whether alternative text is actually meaningful. These are judgement calls a tool cannot make.
Assistive technology and real users. Test with at least one screen reader on desktop and one on mobile, plus voice control or magnification where relevant. The W3C’s evaluation methodology also recommends involving people with disabilities in evaluation (WCAG-EM).

For a formal audit, the W3C’s WCAG-EM methodology sets out five steps: define the scope and target level, explore the site, select a representative sample of pages, evaluate that sample, and report the findings (WCAG-EM).

Accessibility standards in India

Two Indian references are worth knowing.

GIGW 3.0. The Guidelines for Indian Government Websites and Apps apply to government websites and applications at every level, from central ministries to local bodies. The current version ensures conformity with WCAG 2.1 Level AA, up from WCAG 2.0 in GIGW 2.0, and includes a cyber security chapter formulated by CERT-In. GIGW also forms the basis of the STQC Directorate’s Website Quality Certification (GIGW scope and objective). If you build for a government department, plan for GIGW from the start.
IS 17802. The Bureau of Indian Standards publishes Accessibility for the ICT Products and Services in two parts: Part 1: Requirements (2021), which lists ISO/IEC 40500:2012 among its referenced standards (an earlier edition of the ISO standard whose 2025 edition matches WCAG 2.2), and Part 2: Determination of Conformance (2022). It covers ICT products and services broadly, not only websites.

Because GIGW 3.0 is pegged to WCAG 2.1 AA and WCAG 2.2 is backwards compatible, building to WCAG 2.2 AA meets the WCAG 2.1 AA criteria GIGW 3.0 points to (GIGW has its own further checkpoints) and adds the newer criteria on focus, target size and authentication.

Key takeaways

Target WCAG 2.2 Level AA; it is backwards compatible with 2.1 and 2.0.
The new AA criteria most likely to catch existing sites are focus hidden behind sticky elements, small tap targets, drag-only controls and logins that block paste or password managers.
Combine automated checks, manual keyboard and zoom testing, and assistive technology testing; no tool can certify a site alone.
Build accessibility into design tokens, component libraries and acceptance criteria, so it doesn’t need to be retrofitted page by page.

Sources

Facts in this article were checked against the linked sources on 9 October 2026. Rules, prices and standards change; check the source before relying on a detail. This article is general information, not legal or financial advice.