Skip to main content
Back to the blog
Guide

WCAG 2.2 AA: the standard you actually have to meet

Level AA is the threshold Norwegian regulation points to and the one the European directive builds on. Here is a practical walkthrough: what is required, what is new in 2.2, and what a realistic programme looks like.

Alnet12 min read

WCAG 2.2 AA is not one task but around fifty success criteria across four principles. That sounds insurmountable. In practice it is manageable, because the criteria largely land on the same components: navigation, forms, media and colour.

What is new in 2.2

Version 2.2 was published in October 2023 and adds nine success criteria. For most websites these are the ones that matter:

  • Focus not obscured

    The element with focus must not be completely covered by sticky headers, chat bubbles or cookie banners.

  • Target size

    Interactive targets should be at least 24 × 24 CSS pixels, unless there is sufficient spacing around them.

  • Consistent help

    Help mechanisms such as a contact link or chat must appear in the same place across pages.

  • Accessible authentication

    Sign-in must not require the user to recall or transcribe something without an alternative — pasting into password fields has to work.

The four principles, translated into tasks

PrincipleTypical tasksWhere they are solved
PerceivableAlt text, captions, contrast, reflow at 320 pxDesign and content
OperableKeyboard, focus order, skip links, target sizesFrontend
UnderstandableLabels, error handling, consistent navigation, languageContent and frontend
RobustValid markup, correct roles and statesFrontend

A realistic path to AA

  1. Week 1: baselineAutomated scan of every template, manual review of the five most important pages, and a screen-reader pass on the main flow.
  2. Week 2: prioritisationEvery finding gets a severity, a scope and an estimate. Anything blocking a purchase or application flow goes to the top.
  3. Weeks 3–6: remediationComponent-level fixes first — they touch the most pages per unit of effort. Page-specific issues after that.
  4. Week 7: verificationA second pass with keyboard and screen reader, plus regression testing of what was fixed.
  5. Week 8: documentationAccessibility statement, an internal routine for new content, and automated checks in the build.

How to document conformance

An accessibility statement should be honest. It is not a marketing document but a status report. It should contain:

  • Which standard and level the solution has been assessed against
  • Which parts do not meet the requirements, and why
  • When the outstanding issues are planned to be fixed
  • How users can report problems, and how quickly they get a response
  • The date of the last assessment and who carried it out

How to hold the standard

  1. Put accessibility in acceptance criteriaA task is not done until it has been tested with a keyboard.
  2. Automate in CIaxe-core in the build stops regressions before they reach production.
  3. Train your editorsMost new issues arise in content, not in code. Alt text and heading levels are editorial responsibilities.
  4. Retest every six monthsNew features, new third-party scripts and new browser versions all change the picture.
  • #WCAG 2.2
  • #Level AA
  • #Conformance
  • #Process