WCAG 2.2 — what's new and what do you need to do?

What's new in WCAG 2.2?

Six new criteria at levels A and AA — the levels the legal requirements build on:

• 2.4.11 Focus not obscured, minimum (level AA) — the element holding keyboard focus must not be completely hidden by sticky headers, banners or other layers on top of the page. We cover this criterion in detail on our page about keyboard navigation and visible focus.
• 2.5.7 Dragging movements (level AA) — functionality that requires a dragging gesture, such as sliders, drag and drop and drag-to-sort, must also be operable with simple clicks or taps. Not everyone can press, hold and drag with precision.
• 2.5.8 Target size, minimum (level AA) — click targets must be at least 24×24 CSS pixels. There are exceptions: sufficient spacing to neighbouring targets, an equivalent alternative elsewhere, targets in running text, or the size being essential to the function.
• 3.2.6 Consistent help (level A) — if help features such as contact details, chat or an FAQ appear on multiple pages, they must sit in the same place on all of them. The requirement is about consistency — it doesn't force you to offer help.
• 3.3.7 Redundant entry (level A) — information the user has already provided in a flow must not have to be entered again. Autofill, pre-filled or selectable is enough; exceptions apply to security-critical fields, among others.
• 3.3.8 Accessible authentication, minimum (level AA) — logging in must not require cognitive tests such as memorising or transcribing something, unless there is an alternative or assistance. Support for password managers is often enough; object recognition is exempt.

At the same time one criterion disappeared: 4.1.1 Parsing was removed in 2.2, as it was considered obsolete. Three new AAA-level criteria were also added (2.4.12, 2.4.13 and 3.3.9), but AAA sits above the legal requirement level and won't concern most sites.

Is WCAG 2.2 a legal requirement today?

Honest answer: not formally — yet. The Swedish Act on Accessibility to Digital Public Service (DOS-lagen) for the public sector and the Swedish Accessibility Act (2023:254), which since 28 June 2025 applies to covered private businesses, both point to the European standard EN 301 549. That standard currently references WCAG 2.1 at level AA — not 2.2.

But that is where the standard is heading. WCAG 2.2 is today's W3C Recommendation, and since the version is backwards compatible, a website that meets 2.2 automatically covers 2.1 as well. Working towards 2.2 now costs nothing extra relative to the legal requirements — it gives you margin for the day the standard is updated.

Common issues we see

• Click targets that are too small — icon buttons, pagination and social media links ending up below 24×24 pixels, often packed so tightly that the spacing exception doesn't save them either.
• Sliders and sortable lists that only work with a dragging gesture — no button or arrow as an alternative for those who can't press, hold and drag.
• Help that moves around — the chat bubble sits bottom right on the start page but somewhere else, or is missing entirely, on the subpages.
• Checkouts and form flows asking for the same information twice — the delivery address has to be typed in again as the billing address in the next step, with no pre-fill or "same as above".
• Logins that block pasting or lack support for password managers — in practice a memory test, which 3.3.8 doesn't allow without an alternative.
• Focused elements ending up behind sticky headers — you tab to a link but can't see it.

How CompliantHQ tests this

We test against WCAG 2.2 at levels A and AA — the full list of 55 criteria is disclosed openly, including which ones require manual review. The new 2.2 criteria are handled differently, depending on what can actually be determined programmatically:

• Target size (2.5.8) is measured automatically — the scanner measures the geometry of the page's click targets and flags targets too small to hit reliably. The check is included in the base scan and the trial as well.
• Focus not obscured (2.4.11) is tested automatically in the deep suite, included in the paid plans — where the scanner tabs through the pages and checks that the focused element isn't hidden by sticky layers.
• Dragging movements (2.5.7), consistent help (3.2.6), redundant entry (3.3.7) and accessible authentication (3.3.8) require human judgement in context — only you know what your slider does and what your login flow looks like. We openly mark them as manual checks, and our AI advisor guides you through what to check and how.

The AI's conclusions are always reported as assessments, never as confirmed violations — you see the reasoning and judge for yourself.

How to fix it

• Give click targets at least 24×24 CSS pixels — or sufficient spacing to neighbouring targets. Icon buttons, pagination and footer links are the most common offenders.
• Complement every dragging gesture with a click alternative: arrow buttons next to the slider, up/down buttons next to the sortable list.
• Place help features — contact details, chat, FAQ link — in the same spot on every page, for example in the header or footer.
• Pre-fill information the user has already provided in the flow, or make it selectable — a "same as delivery address" checkbox is enough.
• Let password managers do the work: don't block pasting in login fields and use the right autocomplete attributes.
• Make sure focused elements don't end up behind sticky headers — scroll margin via scroll-padding solves most of it.

Common questions

More deep dives

• Contrast requirements
• Alt text
• Keyboard & focus
• Accessible PDFs