Skip to main content

Guides

WCAG 2.1 and 2.2 Level AA requirements, explained

What WCAG 2.1 and 2.2 Level AA actually require, what changed in 2.2, how Norway applies 48 vs 35 success criteria, and which checks a scanner can verify versus what needs human review.

By Eivind Pihl Martinsen, Synli.aiLast updated June 5, 2026

The Web Content Accessibility Guidelines (WCAG) are the technical backbone of almost every accessibility law in Europe. Level AA is the conformance target named by the EU Web Accessibility Directive, the European Accessibility Act's supporting standard, and Norwegian regulation. This guide explains what AA actually requires, what changed between WCAG 2.1 and 2.2, and where automated scanning ends and human judgement begins.

How WCAG is structured

WCAG is organised under four principles: content must be Perceivable, Operable, Understandable, and Robust (POUR). Each principle holds guidelines, and each guideline holds testable success criteria graded at three conformance levels: A (essential), AA (the legal target almost everywhere), and AAA (enhanced).

From principle to testable criterion
  1. 4 principlesPerceivable, Operable, Understandable, Robust
  2. 13 guidelinesBroad goals under each principle
  3. Success criteriaTestable statements, graded A / AA / AAA
  4. ConformanceAA = meet all A and AA criteria that apply

WCAG 2.0 to 2.1 to 2.2: what changed

  • WCAG 2.0 (December 2008) established 12 guidelines and the A/AA/AAA model.
  • WCAG 2.1 (5 June 2018) added 17 success criteria, focused on mobile, low vision, and cognitive needs. This is the version most current EU and Norwegian law references.
  • WCAG 2.2 (5 October 2023, updated 12 December 2024) added 9 success criteria and removed one: 4.1.1 Parsing is now obsolete because modern browsers handle markup errors natively.
  • WCAG 2.2 is backward compatible: content conforming to 2.2 also conforms to 2.1 and 2.0. WCAG 2.2 is also published as ISO/IEC 40500:2025.

The new Level A and AA criteria in WCAG 2.2

  • 2.4.11 Focus Not Obscured (Minimum) — AA: the keyboard focus indicator must not be fully hidden by sticky headers or overlays.
  • 2.5.7 Dragging Movements — AA: any drag action needs a single-pointer alternative (for example, a tap or button).
  • 2.5.8 Target Size (Minimum) — AA: interactive targets must be at least 24 by 24 CSS pixels, with spacing exceptions.
  • 3.2.6 Consistent Help — A: help mechanisms (contact, FAQ) appear in a consistent order across pages.
  • 3.3.7 Redundant Entry — A: do not force users to re-enter information they already provided in the same process.
  • 3.3.8 Accessible Authentication (Minimum) — AA: do not require a cognitive function test (like solving a puzzle or transcribing characters) as the only way to log in.

Because 2.2 only adds criteria, building to 2.2 today is the safe choice: it keeps you conformant with any law that still cites 2.1, and it future-proofs against the standards update already in progress (see the EAA guide).

Norway: why 48 for public sector and 35 for private

WCAG 2.1 has 78 testable success criteria in total. Norwegian law does not require all of them. The legal basis is section 17 of the Equality and Anti-Discrimination Act, with technical detail in the regulation on universal design of ICT, supervised by the Authority for Universal Design of ICT (Uutilsynet).

  • Private sector: a minimum of 35 success criteria at Level A and AA, excluding 1.2.3, 1.2.4 and 1.2.5 (audio description and live captions).
  • Public sector: 48 of the 78 criteria — the 35 private-sector criteria plus 12 additional A/AA criteria introduced with the EU Web Accessibility Directive, in force since 1 February 2023.
  • Public sector bodies must additionally publish an accessibility statement (tilgjengelighetserklæring) for every website and app.

What a scanner can verify, and what it cannot

Automated testing is essential but partial. Industry studies and our own methodology put the share of WCAG issues a tool can reliably detect at roughly 30 to 40 percent. Machines are excellent at deterministic checks and unreliable at judgement calls.

Automated detection versus human review
  1. Machine-verifiableMissing alt attribute, colour contrast ratios, form labels, language attributes, ARIA misuse
  2. Needs a humanWhether alt text is meaningful, logical reading order, link text in context, error-recovery quality
  3. Honest reportingMark each finding as verified by the tool or needing a human check — never inflate a score
A Synli finding detail panel: one WCAG success criterion linked to a code snippet, an impact label, and a confidence indicator.
Each finding links a WCAG criterion to the code location, impact, and a confidence level.

Synli runs an automated rule pass and then layers AI vision analysis on top — for example, judging whether an image's alt text actually describes the image rather than just confirming an attribute exists. Every item is labelled as tool-verified or needs-human-review, so the report is honest about its own limits.

A practical order of work

  1. Confirm which rule set applies to you (private vs public sector, website vs app).
  2. Run an automated scan to clear the deterministic failures first — contrast, labels, names, roles.
  3. Build to WCAG 2.2 AA so you are covered as standards update.
  4. Schedule human review for the judgement-based criteria a scanner flags as needs-review.
  5. Record the result in an accessibility statement if you are a public body.

Sources