WCAG 2.2 e accessibilità web — la guida pratica per designer 2026

A partire dal 28 giugno 2025 l'European Accessibility Act è diventato obbligatorio per tutti i servizi digitali offerti ai cittadini dell'UE: e-commerce, banche online, trasporti, e-book, telecomunicazioni. Chi non è conforme rischia sanzioni fino a 40.000 € per violazione — e il framework tecnico di riferimento è uno solo: le Web Content Accessibility Guidelines (WCAG) 2.2.

Se progetti interfacce nel 2026, conoscere le WCAG non è più opzionale: è un requisito di legge. In questa guida trovi tutto quello che un designer deve sapere per essere conforme, scritto come guida operativa — niente linguaggio burocratico, solo esempi concreti di errori e soluzioni.

Cosa imparerai leggendo:

• Cosa sono le WCAG e a chi si applicano nel 2026
• I 4 principi fondamentali (POUR) spiegati con esempi
• La differenza tra i 3 livelli di conformità (A, AA, AAA)
• Le 13 novità di WCAG 2.2 rispetto a WCAG 2.1
• Una checklist operativa per verificare le tue interfacce
• Gli strumenti di test gratuiti da integrare nel workflow

Cosa sono le WCAG

Le Web Content Accessibility Guidelines sono lo standard internazionale per rendere i contenuti web accessibili a persone con disabilità — visive, motorie, uditive, cognitive. Sono pubblicate dal W3C (il consorzio che governa gli standard web) e aggiornate periodicamente.

La versione attuale è WCAG 2.2, pubblicata come Raccomandazione W3C il 5 ottobre 2023. Sostituisce WCAG 2.1 del 2018 aggiungendo 9 nuovi success criteria per affrontare bisogni emersi con la diffusione di dispositivi touch, cognitività e mobilità limitate.

WCAG 2.2 è:

• Retrocompatibile con WCAG 2.1: tutto quello che era valido continua a esserlo
• Verificabile tecnicamente: ogni criterio è scritto come test pass/fail
• Indipendente dalla tecnologia: vale per HTML, PDF, app native, documenti digitali
• Obbligatoria per legge nell'UE dal 28 giugno 2025 per i servizi coperti dall'European Accessibility Act

Le WCAG non sono burocrazia: ogni criterio esiste perché, senza di esso, una categoria di persone non può usare il tuo prodotto. Progettare accessibile non è un favore — è il lavoro ben fatto.

I 4 principi (POUR)

WCAG 2.2 organizza tutti i criteri di accessibilità sotto 4 principi. L'acronimo mnemonico è POUR:

P — Perceivable (Percepibile)

Il contenuto deve essere percepibile da tutti i sensi disponibili.

Esempio concreto: un'immagine senza alt è invisibile a chi usa screen reader. Un video senza sottotitoli è inaccessibile ai sordi. Un testo con contrasto insufficiente è illeggibile a chi ha ipovisione.

Criteri principali:

• Alternativi testuali: ogni immagine informativa ha un alt descrittivo; le immagini decorative hanno alt=""
• Contrasto colore: testo ≥ 4.5:1 (livello AA), grandi titoli ≥ 3:1; per WCAG 2.2 anche i controlli UI non-testuali devono avere contrasto ≥ 3:1
• Ridimensionamento testo: l'utente deve poter ingrandire il testo fino al 200% senza perdita di contenuto o funzionalità
• Audio/video: i video devono avere sottotitoli per tutti i contenuti parlati; l'audio-only deve avere trascrizione

O — Operable (Utilizzabile)

Tutte le funzioni devono essere utilizzabili senza mouse.

Milioni di persone navigano solo con tastiera, con switch assistivi, o con controllo vocale. Se la tua interfaccia richiede hover per accedere al menu, un utente tastiera non può usarla.

Criteri principali:

• Navigabile da tastiera: ogni azione deve essere raggiungibile con Tab, Enter, Space, frecce. Nessun "keyboard trap"
• Focus visibile: l'elemento attivo deve essere evidenziato chiaramente (spesso vietato rimuovere :focus con outline:none)
• Tempo sufficiente: se c'è un timer, l'utente deve poterlo estendere o disabilitare
• Target size (WCAG 2.2): i bottoni e i link cliccabili devono essere almeno 24×24 pixel — un criterio nuovo pensato per chi ha tremori o difficoltà motorie
• No seizures: nessun contenuto lampeggiante più di 3 volte al secondo (rischio epilessia)

U — Understandable (Comprensibile)

Il contenuto e l'interfaccia devono essere comprensibili.

Criteri principali:

• Lingua dichiarata: l'HTML deve avere <html lang="it"> (o la lingua corretta); le parti in altra lingua vanno marcate
• Prevedibile: un elemento non deve cambiare contesto senza che l'utente lo richieda esplicitamente (niente pagine che cambiano al focus)
• Assistenza all'input: i form devono avere label chiare, messaggi di errore specifici, aiuti contestuali
• Suggerimenti di correzione: se l'utente sbaglia un campo, il messaggio di errore deve dire cosa è sbagliato e come correggerlo, non solo "errore"

R — Robust (Robusto)

Il contenuto deve funzionare con qualsiasi tecnologia assistiva, presente e futura.

Criteri principali:

• HTML valido: tag chiusi correttamente, attributi ben formati, nessun parse error
• Nome, ruolo, valore: ogni elemento interattivo deve avere nome (label), ruolo (bottone, link, input) e valore (stato). Questo è il lavoro di ARIA
• Status messages (WCAG 2.1): messaggi di conferma, errore, progresso devono essere annunciati dagli screen reader senza cambiare focus

I 3 livelli di conformità

Ogni criterio WCAG è classificato in uno di tre livelli:

Livello	Quando si applica	Esempio pratico
A	Minimo assoluto — senza, il contenuto è inutilizzabile da alcune persone	Alt text sulle immagini; no keyboard traps
AA	Standard di settore richiesto dalla maggior parte delle normative	Contrasto 4.5:1; target size 24×24px
AAA	Massimo livello, per siti specifici (es. servizi pubblici)	Contrasto 7:1; lingua dei segni per ogni video

Il livello da puntare nel 2026 è AA. È quello richiesto dall'European Accessibility Act, dalla Section 508 americana, dalla normativa canadese AODA. Livello AAA è un bonus per siti con utenti specifici (es. disabilità visive gravi), ma è molto restrittivo e non sempre compatibile con scelte di brand.

Le 13 novità di WCAG 2.2

WCAG 2.2 aggiunge 9 nuovi success criteria (numerati 2.4.11 fino a 3.3.9) più 4 aggiornamenti ai criteri esistenti. I 5 più importanti per un designer:

1. Focus Not Obscured (2.4.11, livello AA)

Quando un elemento riceve il focus da tastiera, deve essere interamente visibile. Non può essere parzialmente o totalmente nascosto da sticky header, cookie banner, chat widget.

Errore comune: una sticky navbar alta 80px che copre il campo form che ha appena ricevuto focus. L'utente tastiera non vede dove sta scrivendo.

Correzione: aggiungere scroll-padding-top: 80px al CSS o gestire lo scroll al focus tramite JS.

2. Target Size (2.5.8, livello AA)

I bottoni e i link cliccabili devono essere almeno 24×24 pixel. Il testo può essere più piccolo ma l'area cliccabile deve coprire 24×24.

Errore comune: icone social in footer a 16×16 pixel. Inaccessibili a chi ha tremori.

Correzione: aumentare il padding dell'elemento cliccabile o usare ::before per ampliare la target area.

3. Consistent Help (3.2.6, livello A)

Se la tua interfaccia ha meccanismi di aiuto (form di contatto, chat widget, link FAQ), devono apparire nella stessa posizione su ogni pagina. L'utente non deve "cercarli" nel layout.

Errore comune: il link "Aiuto" in alto a destra nella home, in basso nel checkout, nascosto nell'hamburger nella pagina prodotto.

4. Redundant Entry (3.3.7, livello A)

Se chiedi all'utente un'informazione che ha già fornito in un passaggio precedente dello stesso flusso, devi precompilarla o offrirla in auto-complete.

Errore comune: un checkout in 3 step che chiede "email" nello step 1, poi "email di fatturazione" nello step 3 senza precompilarla.

5. Accessible Authentication (3.3.8, livello AA)

I processi di login non possono richiedere test di memoria o trascrizione cognitiva all'utente (es. trascrivere caratteri da un'immagine CAPTCHA, ricordare un codice visto 10 secondi prima). Devono esistere alternative: biometria, password manager, email link.

Questo criterio combatte le "cognitive walls" nei login — barriere che escludono persone con difficoltà cognitive o dislessia.

Checklist operativa WCAG 2.2 livello AA

Usa questa checklist prima di rilasciare qualsiasi interfaccia. È la versione operativa, non la versione W3C.

Percepibile:

• Ogni <img> informativa ha alt descrittivo
• Ogni <img> decorativa ha alt=""
• Il contrasto del testo è ≥ 4.5:1 (≥ 3:1 per testo ≥ 18pt)
• I controlli UI (bottoni, campi, icone attive) hanno contrasto ≥ 3:1 col contesto
• Video hanno sottotitoli, audio ha trascrizione
• La pagina è leggibile con zoom 200%

Operabile:

• Tutte le azioni sono completabili con sola tastiera
• L'elemento focused è sempre visibile (:focus-visible custom o default)
• Nessun sticky header nasconde l'elemento focused
• Bottoni e link hanno target ≥ 24×24px
• Nessun contenuto lampeggiante più di 3 Hz
• Skip link "Vai al contenuto" presente in cima a ogni pagina

Comprensibile:

• <html lang="it"> corretto
• Label su tutti gli input (visibili o aria-label)
• Messaggi di errore indicano cosa sbagliare e come correggere
• Link testuali descrivono la destinazione (niente "clicca qui")
• Elementi non cambiano contesto al focus

Robusto:

• HTML valido (passa W3C validator)
• Componenti custom hanno ARIA role, aria-label, stati corretti
• Messaggi dinamici (toast, alert) usano aria-live

Strumenti di test gratuiti

Nessuno strumento automatico cattura il 100% degli issue di accessibilità — studi di Nielsen Norman Group stimano il 30-40% — ma riducono significativamente il lavoro manuale.

• axe DevTools: estensione Chrome/Firefox di Deque. Gratis, zero falsi positivi, è lo standard del mercato. Analizza una pagina e ti dice esattamente dove sono i problemi e come risolverli.
• Lighthouse: integrato in Chrome DevTools. Dà un punteggio di accessibilità da 0 a 100. Meno preciso di axe ma buono come smoke test.
• WAVE: di WebAIM. Visualizza gli errori direttamente sulla pagina in modo grafico. Utile per presentare issue a stakeholder non-tecnici.
• Stark: plugin Figma che controlla il contrasto e simula daltonismi mentre progetti. Eccellente per UI designer.
• Contrast Checker WebAIM: tool web semplice per verificare ratio di contrasto tra due colori.

Per approfondire il tema dei colori accessibili, leggi la nostra guida su design e daltonismo.

Errori comuni di accessibilità nei progetti italiani

Quelli che troviamo più spesso negli audit fatti per clienti:

• Placeholder al posto di label: i placeholder spariscono appena l'utente inizia a scrivere, e gli screen reader li leggono in modo incoerente. Usa <label> esplicite, sempre.
• Icone senza testo: un'icona hamburger senza aria-label="Menu" è invisibile allo screen reader. Due righe di CSS non bastano: serve il nome accessibile.
• Carousel non fermabili: slideshow che si muovono automaticamente senza bottone "pausa". Inaccessibili a chi ha difficoltà cognitive, che necessita di più tempo per leggere.
• Dropdown custom: componenti costruiti da zero con <div> invece di <select> nativo. Quasi sempre rotti con screen reader. Se non sei esperto di ARIA, usa elementi HTML nativi.
• Testo sull'immagine senza contrasto: banner hero con testo bianco su foto colorata. Basta una fascia scura semitrasparente dietro il testo per risolvere.

Domande frequenti

WCAG 2.2 è obbligatoria in Italia?

Sì, dal 28 giugno 2025 è obbligatoria per tutti i servizi coperti dall'European Accessibility Act: e-commerce, banche online, trasporti, telecomunicazioni, e-book, servizi di media audiovisivi. Per la pubblica amministrazione l'Italia già dal 2018 impone l'accessibilità WCAG 2.1 AA (Legge Stanca). Chi non rispetta le norme rischia sanzioni fino a 40.000 € per violazione.

Qual è la differenza tra WCAG 2.1 e WCAG 2.2?

WCAG 2.2 aggiunge 9 nuovi success criteria (numerati da 2.4.11 a 3.3.9) senza rimuovere o modificare quelli precedenti. Se eri conforme a 2.1, per passare a 2.2 devi verificare solo i 9 nuovi. I più impattanti sono Focus Not Obscured, Target Size (minimo 24×24px), Dragging Movements e Accessible Authentication.

Quanto costa rendere accessibile un sito esistente?

Dipende dallo stato di partenza e dalla dimensione. Un audit iniziale costa 2.000-5.000 € e identifica le correzioni necessarie. L'implementazione delle correzioni va da 5.000 € (piccolo sito statico) a 50.000+ € (e-commerce complesso). È sempre più economico progettare accessibile dall'inizio: aggiungere accessibilità a posteriori può costare 10 volte di più.

Un designer senza skill tecniche può lavorare sull'accessibilità?

Sì, anzi è fondamentale. L'80% dei problemi di accessibilità sono problemi di design: contrasto, dimensione del testo, gerarchia, chiarezza del copy, naming dei componenti. Il designer decide queste cose prima che lo sviluppatore scriva codice. Uno UX designer che conosce WCAG previene l'80% dei problemi a monte, lasciando al dev solo l'implementazione corretta del codice.

Come imparo WCAG a fondo?

La documentazione ufficiale del W3C è completa ma densa. Per un approccio operativo, leggi la guida pratica di WebAIM (inglese) e il sito italiano di AgID sulle linee guida accessibilità. Il libro "Inclusive Design Patterns" di Heydon Pickering è il miglior manuale in inglese. Se vuoi un percorso guidato italiano, il nostro corso di UX Design ha un modulo dedicato di 8 ore con esercizi pratici su componenti reali.

Prossimi passi

L'accessibilità è la skill che più distingue un designer senior nel 2026. Con l'entrata in vigore dell'European Accessibility Act, le aziende italiane stanno cercando designer con esperienza in WCAG pagando premium salariali significativi — soprattutto in finance, sanità e pubblica amministrazione.

Il corso completo di UX Design di CorsoUX include un modulo verticale sull'accessibilità: teoria WCAG 2.2 applicata, esercitazioni di audit su progetti reali, integrazione con Figma, e un case study finale di redesign di una landing page non conforme. Al termine hai uno dei pochi certificati italiani con focus specifico su WCAG 2.2 + European Accessibility Act.

Intanto, per partire subito:

• Design e daltonismo: come progettare pensando al colore — la parte visiva dell'accessibilità
• Le 10 euristiche di Nielsen — principi fondamentali che anticipano WCAG
• La guida al Design Thinking — come integrare l'accessibilità nel processo di design