L’accessibilità viene quasi sempre trattata come una fase: si costruisce il prodotto e alla fine qualcuno lancia un validatore e apre venti ticket. È proprio quest’ordine a renderla costosa. Quando il focus da tastiera è rotto perché il sistema di componenti non lo ha mai previsto, sistemarlo non è un ticket — è riscrivere il livello di interazione.
Questa guida parla del contrario: quali decisioni prendere mentre costruisci, così che alla fine il validatore non abbia più nulla da dire.
I quattro principi: POUR
WCAG organizza tutto attorno a quattro idee. Non sono categorie burocratiche: sono quattro modi diversi in cui qualcuno può restare fuori dal tuo sito.
Percepibile. Il contenuto deve arrivare da più di un canale. Un’immagine ha bisogno di testo alternativo, un video di sottotitoli, e il colore non può essere l’unico portatore di informazione — se il campo obbligatorio si distingue solo perché è rosso, circa una persona su dodici con vista maschile non lo vedrà.
Utilizzabile. Tutto ciò che si fa col mouse deve potersi fare da tastiera. Senza trappole di focus, senza limiti di tempo impossibili, senza animazioni che scatenino crisi vestibolari.
Comprensibile. Lingua dichiarata, comportamento prevedibile ed errori che spieghino cosa è andato storto e come rimediare. «Errore nel modulo» non è un messaggio: è una resa.
Robusto. Il markup deve essere interpretabile dalle tecnologie assistive. È qui che l’HTML semantico batte sempre i div con onclick.
Livelli A, AA e AAA
Tre livelli di conformità. In pratica ne conta uno solo.
- A è il minimo assoluto. Rispettare solo A lascia fuori molte persone e non soddisfa quasi nessuna normativa.
- AA è lo standard reale. È ciò che richiede la normativa europea, ciò che chiedono i bandi pubblici e ciò che viene verificato.
- AAA è aspirazionale. La stessa W3C afferma che non è realistico pretenderlo per tutti i contenuti di un sito.
Lavora sempre puntando ad AA. Se qualcuno ti chiede «accessibilità» senza specificare il livello, ti sta chiedendo AA.
Cosa aggiunge WCAG 2.2
WCAG 2.2 è Raccomandazione W3C da ottobre 2023. È additiva: mantiene tutto della 2.1 e aggiunge nove criteri (un criterio della 2.1, il 4.1.1 sul parsing, è diventato obsoleto). Sei dei nuovi sono di livello AA. Questi sono quelli che vediamo violati più spesso:
2.4.11 — Focus non oscurato. Navigando con il tabulatore, l’elemento con focus non può finire coperto. Il colpevole abituale è un’intestazione fissa: tabuli, il focus passa a un link che sta proprio sotto l’header sticky, e visivamente sparisce. Si risolve con scroll-margin-top sugli elementi focalizzabili.
2.5.7 — Movimenti di trascinamento. Ogni funzionalità che dipende dal trascinamento ha bisogno di un’alternativa a puntatore singolo. Un riordinatore di liste in drag and drop serve anche di pulsanti su e giù. Uno slider di prezzo serve anche di campi numerici.
2.5.8 — Dimensione del bersaglio (minima). I bersagli tattili devono essere di almeno 24×24 pixel CSS, con eccezioni per i link in linea dentro un testo. Il trasgressore classico è l’icona di chiusura di una modale: 16 pixel, schiacciata nell’angolo.
3.3.8 — Autenticazione accessibile. Non puoi richiedere una prova cognitiva per accedere. Significa consentire di incollare nel campo password, non bloccare i gestori di password e non obbligare a risolvere un puzzle. Un CAPTCHA «seleziona i semafori» senza alternativa viola questo criterio.
3.2.6 — Aiuto coerente e 3.3.7 — Inserimento ridondante. L’accesso all’aiuto deve trovarsi nello stesso posto in tutte le pagine, e non si può chiedere due volte lo stesso dato all’interno di uno stesso processo, salvo che sia indispensabile.
I cinque errori che escono in quasi ogni audit
- Contrasto insufficiente. Testo grigio chiaro su bianco. Il minimo AA è 4,5:1 per il testo normale e 3:1 per il testo grande. Il grigio
#999su bianco dà 2,85:1 — non passa. - Immagini senza alternativa utile.
alt="immagine"è peggio che non mettere nulla. Se l’immagine è decorativa,alt=""è la risposta corretta. - Moduli senza etichetta associata. Il placeholder non è un’etichetta: sparisce appena scrivi e molti screen reader non lo annunciano.
- Focus invisibile. Qualcuno ha messo
outline: nonenel CSS di base e nessuno l’ha ripristinato. Navigare da tastiera diventa indovinare. - Titoli scelti per dimensione. Un
h4scelto perché «stava bene» rompe l’indice con cui chi usa uno screen reader naviga la pagina.
Come verificarlo davvero
Parti dall’automatico perché costa poco: axe DevTools o Lighthouse ti danno in un minuto i problemi di contrasto, gli attributi assenti e la gerarchia. Ma tieni chiaro il limite: gli strumenti automatici individuano circa un terzo dei problemi reali. Non possono sapere se il tuo alt descrive l’immagine o se l’ordine di tabulazione ha senso.
Quello che trova il resto:
- Percorri l’intera pagina col tabulatore. Senza toccare il mouse. Si vede sempre dove sei? Riesci a uscire da tutte le modali? L’ordine segue la lettura visiva?
- Accendi uno screen reader. VoiceOver è incluso in macOS e iOS, NVDA è gratuito su Windows. Mezz’ora a navigare il tuo prodotto alla cieca insegna più di qualunque report.
- Porta lo zoom al 200%. È un criterio AA e rompe più layout di quanto sembri.
L’ordine giusto
L’accessibilità costa poco quando si decide a livello di componenti e molto quando si rattoppa schermata per schermata. Se hai un pulsante, un campo di modulo e una modale risolti bene, hai già risolto l’80% di ogni schermata costruita sopra. È esattamente l’argomento a favore di avere un design system: l’accessibile di default si eredita.
E c’è un motivo in più per non rimandarlo alla fine: da giugno 2025 buona parte del commercio e dei servizi digitali nell’UE è obbligata per legge. Lo European Accessibility Act fissa la soglia e rimanda alla norma EN 301 549, che a sua volta punta a WCAG livello AA — lo stesso livello di cui parla questo articolo.
Vuoi sapere a che punto è il tuo sito? Nello sviluppo web trattiamo l’accessibilità come parte del processo, non come un audit dell’ultimo minuto.