All articles Accessibility

WCAG 2.2: what changes and why you should update your audit now

Nine new success criteria, three conformance levels. A practical guide for teams that need to reach AA compliance without rewriting everything from scratch.

WCAG 2.2 became an official W3C recommendation in October 2023, but most product teams have not yet updated their audits. The most common reason I hear: "We did this last year with 2.1 — do we really have to redo it already?" The short answer is yes. The longer answer is: it depends on how exposed your product is to the patterns the new criteria address.

This article is not a list of all the new criteria with abstract explanations. It is a practical guide to understanding which criteria concretely affect the most common products, and how to approach the changes incrementally without blocking your development team.

The nine new criteria at a glance

WCAG 2.2 introduces nine new success criteria compared to version 2.1. Seven are at level A or AA — meaning they are required for standard conformance. Two are at level AAA. The most impactful ones are worth knowing well.

2.4.11 — Focus Not Obscured (AA). When a component receives keyboard focus, it must not be completely hidden by other content — a sticky banner at the top of the page, a notification bar at the bottom. This is the criterion I find violated most often in products with sticky headers.

2.4.13 — Focus Appearance (AA). The most technical and the most underestimated. The focus indicator must have a minimum area equal to the perimeter of the component multiplied by 2px, and a contrast ratio of at least 3:1 between focused and unfocused states. The classic 1px outline is no longer sufficient. You need a visible, thick ring with good contrast.

2.5.7 — Dragging Movements (AA). All functions that require dragging must have an accessible alternative that works with a single pointer. This affects sortable lists, custom sliders, calendars with drag-to-select, and any interface relying on drag gestures.

2.5.8 — Target Size (Minimum) (AA). The minimum clickable target must be at least 24×24 CSS pixels. Many common icon button patterns fall below this threshold.

3.3.7 — Redundant Entry (A). Information already entered in a multi-step process must not be requested again. This affects checkout flows, configuration wizards, and any multi-step form.

Where to look for the most common violations

Not all products are exposed in the same way. The high-risk patterns for WCAG 2.2 are:

  • Navigation with sticky headers — frequent violation of 2.4.11
  • Custom focus outlines removed or minimised — violation of 2.4.13
  • Drag-and-drop without alternatives — violation of 2.5.7
  • Icon buttons smaller than 24px — violation of 2.5.8
  • Multi-step forms that re-ask for data — violation of 3.3.7

How to structure the update audit

There is no need to redo a full audit from scratch. The approach I use is a differential audit: start from the documentation of the existing 2.1 audit and verify specifically the nine new criteria, plus the removal of criterion 4.1.1 (Parsing), which WCAG 2.2 has officially deprecated.

The process follows four phases: inventory of at-risk patterns; manual keyboard testing; touch target measurement on mobile; review of multi-step flows.

Accessibility is not a sprint you do once. It is ongoing maintenance, like security. Every release can introduce new violations.

Focus Appearance in practice: the numbers

Criterion 2.4.13 requires a calculation. The formula: focus indicator area ≥ component perimeter × 2px. For a button measuring 120px×40px, the perimeter is 320px, so the minimum area must be 640px². A 3px outline is comfortably safe. A 1px outline — still the default for many teams — is not.

In practical terms, moving to a 2–3px ring with a contrasting colour is not a rewrite — it is a change to a few lines of CSS in the design system. If you are using a token system, updating the focus tokens globally is all it takes.

The European regulatory context

The European Accessibility Act came into force in June 2025 for digital products and services. The technical reference standard EN 301 549 cites WCAG 2.1 as the minimum baseline, but many national implementations are aligning with 2.2. Teams operating in regulated sectors — healthcare, finance, public administration — face a legal obligation that goes well beyond good design practice.

Updating your audit now is not just the right thing to do. It is also protection against growing legal exposure in a regulatory environment that is tightening fast.

If you need a WCAG 2.2 compliance audit or a plan to integrate accessibility into your team's design process, I am available for an initial conversation.

WCAG 2.2 è diventato una raccomandazione ufficiale del W3C nell'ottobre 2023, ma la maggior parte dei team di prodotto non ha ancora aggiornato i propri audit. La ragione più comune che sento: "L'abbiamo fatto l'anno scorso con la 2.1 — dobbiamo davvero rifarlo già?" La risposta breve è sì. La risposta più lunga è: dipende da quanto il tuo prodotto è esposto ai pattern che i nuovi criteri riguardano.

Questo articolo non è un elenco di tutti i nuovi criteri con spiegazioni astratte. È una guida pratica per capire quali criteri impattano concretamente i prodotti più comuni, e come affrontare le modifiche in modo incrementale senza bloccare il team di sviluppo.

I nove nuovi criteri in sintesi

WCAG 2.2 introduce nove nuovi criteri di successo rispetto alla versione 2.1. Sette sono al livello A o AA — il che significa che sono obbligatori per la conformità standard. Due sono al livello AAA. Quelli più impattanti vale la pena conoscere bene.

2.4.11 — Focus non oscurato (AA). Quando un componente riceve il focus da tastiera, non deve essere completamente nascosto da altri contenuti — un banner fisso in cima alla pagina, una barra di notifiche in basso. Questo è il criterio che trovo violato più spesso nei prodotti con header fissi.

2.4.13 — Aspetto del focus (AA). Il più tecnico e il più sottovalutato. L'indicatore di focus deve avere un'area minima pari al perimetro del componente moltiplicato per 2px, e un rapporto di contrasto di almeno 3:1 tra lo stato con focus e quello senza. Il classico outline di 1px non è più sufficiente. Serve un anello visibile, spesso, con buon contrasto.

2.5.7 — Movimenti di trascinamento (AA). Tutte le funzioni che richiedono un'azione di trascinamento devono avere un'alternativa accessibile che funzioni con un singolo puntatore. Questo impatta liste ordinabili, slider personalizzati, calendari con selezione a trascinamento e qualsiasi interfaccia che si basi su gesture drag.

2.5.8 — Dimensione dell'obiettivo (minima) (AA). L'area cliccabile minima deve essere di almeno 24×24 pixel CSS. Molti pattern comuni di pulsanti icon-only scendono sotto questa soglia.

3.3.7 — Inserimento ridondante (A). Le informazioni già inserite in un processo multi-step non devono essere richieste di nuovo. Questo impatta i flussi di checkout, i wizard di configurazione e qualsiasi form multi-step.

Dove cercare le violazioni più comuni

Non tutti i prodotti sono esposti allo stesso modo. I pattern ad alto rischio per WCAG 2.2 sono:

  • Navigazione con header fissi — violazione frequente del 2.4.11
  • Outline di focus rimossi o ridotti al minimo — violazione del 2.4.13
  • Drag-and-drop senza alternative — violazione del 2.5.7
  • Pulsanti icona più piccoli di 24px — violazione del 2.5.8
  • Form multi-step che richiedono di nuovo dati già inseriti — violazione del 3.3.7

Come strutturare l'audit di aggiornamento

Non è necessario rifare un audit completo da zero. L'approccio che uso è un audit differenziale: si parte dalla documentazione dell'audit 2.1 esistente e si verificano specificamente i nove nuovi criteri, più la rimozione del criterio 4.1.1 (Parsing), che WCAG 2.2 ha ufficialmente deprecato.

Il processo segue quattro fasi: inventario dei pattern a rischio; test manuale da tastiera; misurazione degli obiettivi touch su mobile; revisione dei flussi multi-step.

L'accessibilità non è uno sprint che si fa una volta sola. È manutenzione continua, come la sicurezza. Ogni release può introdurre nuove violazioni.

Focus Appearance in pratica: i numeri

Il criterio 2.4.13 richiede un calcolo. La formula: area dell'indicatore di focus ≥ perimetro del componente × 2px. Per un pulsante di 120px×40px, il perimetro è 320px, quindi l'area minima deve essere 640px². Un outline da 3px è ampiamente sicuro. Un outline da 1px — ancora il default per molti team — non lo è.

In termini pratici, passare a un anello da 2–3px con un colore contrastante non è una riscrittura — è una modifica a poche righe di CSS nel design system. Se stai usando un sistema di token, aggiornare globalmente i token del focus è sufficiente.

Il contesto normativo europeo

L'European Accessibility Act è entrato in vigore nel giugno 2025 per i prodotti e servizi digitali. Lo standard tecnico di riferimento EN 301 549 cita WCAG 2.1 come baseline minima, ma molte implementazioni nazionali si stanno allineando alla 2.2. I team che operano in settori regolamentati — sanità, finanza, pubblica amministrazione — hanno un obbligo legale che va ben oltre la buona pratica di design.

Aggiornare il proprio audit adesso non è solo la cosa giusta da fare. È anche una protezione contro una crescente esposizione legale in un contesto normativo che si sta stringendo rapidamente.

Se hai bisogno di un audit di conformità WCAG 2.2 o di un piano per integrare l'accessibilità nel processo di design del tuo team, sono disponibile per una prima conversazione.

Keep reading