A practical migration plan for WCAG 2.2

WCAG 2.2 extends rather than replaces the existing accessibility baseline. A controlled migration maps the new criteria to components, journeys, evidence and owners before changing a conformance statement.

Establish the current baseline

Confirm which WCAG 2.1 level, browser and assistive-technology combinations the service currently tests. Carry unresolved findings forward and separate them from new 2.2 work so the programme does not describe existing defects as migration tasks.

Map the new criteria to real components

Review focus not obscured, dragging movements, target size and accessible authentication against sticky headers, dialogs, drag-and-drop controls, compact toolbars and sign-in journeys. Test repeated help and redundant entry through complete processes rather than isolated fields.

Change design-system acceptance

Add examples, failure states and test instructions to each affected component. A 24 by 24 CSS-pixel target exception, for example, needs an explicit rationale; it should not become the default interpretation for every small control.

Update automated and manual checks

Automation can identify some target dimensions and labels but cannot establish whether focus is obscured or whether a cognitive test blocks authentication. Add keyboard, zoom, reflow and journey tests to the release evidence.

Publish an evidence-led statement

Revise the accessibility statement only after representative templates and critical journeys have been assessed. State known failures and planned remediation clearly, retain dated evidence and repeat tests when shared navigation or authentication changes.