WCAG 2.2 explained: AA criteria and how to test

What is new in WCAG 2.2, what level AA means, how EN 301 549 fits in, and a method for testing your website and app.

In short

WCAG 2.2 is the current W3C standard for web accessibility, published in October 2023. It adds nine success criteria to 2.1, six of them at level A or AA, and removes one. Level AA means meeting all 55 A and AA criteria. Test it with a defined scope, automated screening, manual keyboard and screen-reader checks, and retesting.

WCAG, the Web Content Accessibility Guidelines, is the reference that most European accessibility law points to, directly or through the standard EN 301 549. This guide is written by Devies, a Gothenburg-based product and engineering consultancy, for product, design and engineering leads who need to know what changed, what level AA asks of their interface, and how to test it without turning the work into a one-off report that nobody uses.

What changed in WCAG 2.2?

Version 2.2 adds nine success criteria to 2.1 and removes one obsolete criterion, so most of the new work concerns focus, pointer targets, forms and login. W3C published it as a Recommendation on 5 October 2023 and summarises the differences in What's New in WCAG 2.2.

The six new criteria at level A and AA are:

2.4.11 · Level AA

Focus Not Obscured (Minimum)

The focused element is not fully hidden by sticky headers, banners or chat widgets.

2.5.7 · Level AA

Dragging Movements

Anything done by dragging can also be done with a single click or tap.

2.5.8 · Level AA

Target Size (Minimum)

Clickable targets are at least 24 by 24 CSS pixels, or have enough space around them.

3.2.6 · Level A

Consistent Help

Help options, such as contact details or chat, appear in the same place across pages.

3.3.7 · Level A

Redundant Entry

Users are not asked to re-enter information they already gave in the same process.

3.3.8 · Level AA

Accessible Authentication (Minimum)

Three more criteria sit at level AAA: Focus Not Obscured (Enhanced), Focus Appearance and Accessible Authentication (Enhanced). The removed criterion is 4.1.1 Parsing, which modern browsers and assistive technologies made unnecessary.

The update is backwards compatible. A site that meets 2.2 AA also meets the equivalent 2.1 level, which matters because much of the law in Europe still refers to the older version.

What does level AA require?

Level AA means that every level A and level AA success criterion is met for the pages and states in scope. In version 2.2 that is 55 criteria: 31 at level A and 24 at level AA. Level AAA is not expected for whole sites, and no European law requires it.

A success criterion is a testable statement, such as "text has a contrast ratio of at least 4.5:1". The criteria are grouped under four principles: content must be perceivable, operable, understandable and robust. In day-to-day product work, the AA set boils down to a handful of recurring themes:

Structure: headings, landmarks, lists and tables marked up so assistive technology can read them.
Keyboard: everything reachable and usable without a mouse, in a logical order, with a visible focus indicator.
Visual design: contrast of 4.5:1 for normal text and 3:1 for large text and interface components, and layouts that reflow at 320 CSS pixels wide.
Forms: visible labels, clear instructions, error messages that explain how to fix the problem.
Media and images: text alternatives, captions for prerecorded video.
Robustness: custom components expose name, role and state to assistive technology.

How EN 301 549 links the guidelines to the law

EN 301 549 is the European standard for accessibility of ICT products and services, and it turns the guidelines into legal requirements. Its clause 9 covers web content and clause 11 covers software, including mobile apps, and both reuse the same success criteria.

As of October 2026, the version cited in the EU's Official Journal is EN 301 549 V3.2.1, which is based on WCAG 2.1 level AA. That is the version Swedish public-sector rules and the European Accessibility Act currently rely on. V4.1.1, published in September 2026, moves to 2.2 AA, but it gives a presumption of conformity only after the Commission cites it. Building to 2.2 AA now meets today's benchmark and the coming one.

How do you test a website or app against WCAG?

A reliable test combines a defined scope, automated screening and manual checks with real assistive technology, then a retest after fixes. Automated tools are fast but cover only part of the criteria; W3C states that knowledgeable human evaluation is required to judge accessibility. Use this method, which follows the structure of W3C's evaluation methodology:

Define scope and target. Name the version and level (2.2 AA), the browsers and devices, and the journeys: for example registration, search, checkout and account settings.
Pick a representative sample. Include each template, each type of component and every state that matters: open menus, error messages, modals, empty and loading states.
Run an automated scan. Use it to catch missing alternative text, contrast failures and missing labels across many pages quickly.
Test with the keyboard only. Tab through every journey. Check order, visible focus, that nothing traps focus and that sticky elements never hide it.
Test with a screen reader. Use NVDA or JAWS on Windows, VoiceOver on macOS and iOS, and TalkBack on Android. Check that names, roles, states and error messages are announced.
Test zoom and reflow. Zoom to 200 percent and to a 320-pixel viewport. Content should reflow without horizontal scrolling or loss of function.
Run the 2.2 checks. Measure target sizes, find drag-only interactions, try pasting into login fields and look for repeated data entry.
Report, fix, retest. Record each finding with location, steps to reproduce, the criterion and user impact. Retest fixed items in the same environment.

Apps need the same method on real devices. Platform settings such as larger text, reduced motion and high contrast should be respected, which EN 301 549 also requires for software.

What is an accessibility statement and when do you need one?

An accessibility statement is a public page that explains how well a website or app meets the accessibility requirements, lists known gaps and tells users how to report problems. In Sweden it is called a tillgänglighetsredogörelse, and under the law on digital public services it is mandatory for every covered public-sector website and app.

DIGG's guidance says the statement must describe how well the service meets the requirements and include a way to report deficiencies. A useful statement contains:

the standard and level tested against, and the date of the latest review;
how the review was done: self-assessment or third party, and the scope;
known deficiencies, with the affected criterion and a plan or date for fixing them;
a contact route for reporting barriers and requesting content in another format;
a reference to the supervisory authority.

Private companies covered by the European Accessibility Act do not publish a tillgänglighetsredogörelse in that formal sense. They must instead publish information on how their service meets the requirements. The same test results feed both documents, so keep findings, dates and scope in one place from the start.

Devies

How Devies can help

Devies, a Gothenburg-based product and engineering consultancy, helps product teams find what blocks users today, fix it in the right order and keep it fixed release after release. Tell us where you are and we will suggest a sensible first step.

Talk to Devies

Frequently asked questions

What is the difference between WCAG 2.1 and WCAG 2.2?

Version 2.2 keeps all of 2.1 except the Parsing criterion and adds nine new success criteria, six of them at level A or AA. The new A and AA criteria cover focus hidden by sticky elements, drag-only interactions, target size, consistent placement of help, repeated data entry and login that relies on memory. A site that meets 2.2 AA also meets 2.1 AA, so building to the newer version covers both.

Is WCAG 2.2 a legal requirement in Sweden?

Not directly, as of October 2026. Swedish law refers to EN 301 549, and the version currently cited, V3.2.1, is based on 2.1 AA. EN 301 549 V4.1.1, published in September 2026, is based on 2.2 AA and becomes the legal benchmark once the European Commission cites it in the Official Journal. Most organisations therefore build and test to 2.2 AA now to avoid a second round of work.

Can an automated tool tell us if our site meets WCAG?

No. Automated tools reliably find issues such as missing alternative text, low contrast and empty labels, but many success criteria need human judgement: logical focus order, meaningful link text, understandable error messages and screen-reader behaviour. Use a scanner for fast, repeatable screening and regression checks, and combine it with manual keyboard and assistive technology testing before you claim conformance.

How often should we test for accessibility?

Test fully when you launch or redesign, and retest at least the affected journeys at every major release. Add automated checks to the build pipeline to catch regressions early, and review the accessibility statement or compliance information at least once a year. Public-sector statements in Sweden must show the date of the latest review, so a regular cycle also keeps that document honest.

More questions about the guidelines themselves? Read the WCAG FAQ.

WCAG 2.2 in practice: the criteria and how to test