Accessibilità dei siti web: normativa, WCAG 2.2 e guida pratica

L’accessibilità dei siti web consiste nel progettare contenuti, funzioni e interfacce che possano essere percepiti, compresi e utilizzati anche dalle persone con disabilità. Riguarda chi naviga con uno screen reader, usa soltanto la tastiera, ingrandisce i contenuti, ha una ridotta percezione dei colori o incontra difficoltà motorie, uditive e cognitive.

Un sito web accessibile non nasce dall’installazione di un componente e non si valuta con un solo punteggio automatico. Richiede scelte corrette durante progettazione, sviluppo, redazione dei contenuti e manutenzione.

In questa guida vedremo che cosa significa accessibilità digitale, quali norme si applicano in Italia, che ruolo hanno le WCAG 2.2, come verificare un sito e quali interventi producono risultati concreti.

Che cos’è l’accessibilità dei siti web

L’accessibilità permette alle persone di accedere alle informazioni e completare le operazioni previste senza essere escluse da barriere tecniche o progettuali. Non riguarda soltanto la cecità: comprende esigenze visive, uditive, motorie, cognitive, neurologiche e legate al linguaggio.

Le difficoltà possono essere permanenti, temporanee o dipendere dal contesto. Un braccio immobilizzato, un ambiente rumoroso, uno schermo esposto al sole o una connessione instabile possono rendere utili soluzioni progettate inizialmente per esigenze specifiche.

Accessibilità e usabilità non sono sinonimi. L’accessibilità rimuove le barriere che impediscono l’uso del servizio; l’usabilità riguarda quanto quel servizio sia semplice ed efficace. I due aspetti si rafforzano, ma un’interfaccia gradevole non è necessariamente accessibile.

Perché progettare un sito accessibile

• Accesso ai servizi: più persone possono informarsi, acquistare, prenotare, compilare moduli e chiedere assistenza.
• Qualità dell’esperienza: navigazione da tastiera, testi leggibili, errori comprensibili e interfacce prevedibili aiutano tutti gli utenti.
• Riduzione del rischio: quando la normativa si applica, l’accessibilità è un requisito da documentare e mantenere, non un miglioramento facoltativo.
• Manutenibilità: HTML semantico, componenti coerenti e controlli definiti rendono più semplice correggere ed evolvere il sito.
• Responsabilità: un servizio digitale non dovrebbe escludere una persona a causa delle modalità con cui interagisce con il web.

Normativa sull’accessibilità web in Italia

Non esiste una sola regola applicabile indistintamente a ogni sito. Gli obblighi dipendono dal soggetto che offre il servizio, dal tipo di attività, dai destinatari e dalle eventuali esenzioni. Il quadro italiano deriva principalmente dalla Legge 4/2004 e dal Decreto legislativo 82/2022, che ha recepito lo European Accessibility Act.

Pubbliche amministrazioni e soggetti della Legge 4/2004

La Legge 4/2004, conosciuta come Legge Stanca, disciplina l’accesso agli strumenti informatici da parte delle persone con disabilità. Gli obblighi riguardano le pubbliche amministrazioni e gli altri soggetti indicati dalla legge. La Direttiva (UE) 2016/2102, recepita in Italia, ha inoltre definito requisiti e attività di monitoraggio per siti web e applicazioni mobili degli enti pubblici.

Il Decreto-legge 76/2020 ha esteso specifici obblighi della Legge 4/2004 anche ai soggetti privati che offrono servizi al pubblico tramite siti web o applicazioni mobili e possiedono un fatturato medio, negli ultimi tre anni di attività, superiore a 500 milioni di euro.

European Accessibility Act e Decreto legislativo 82/2022

La Direttiva (UE) 2019/882, nota come European Accessibility Act, è stata recepita in Italia dal Decreto legislativo 82/2022. Le disposizioni si applicano dal 28 giugno 2025 ai prodotti e ai servizi compresi nel decreto.

Fra i servizi interessati rientrano, nei casi previsti, commercio elettronico, servizi bancari per consumatori, comunicazioni elettroniche, accesso ai media audiovisivi, e-book e software dedicati, oltre ad alcuni servizi digitali legati al trasporto passeggeri.

Il decreto prevede esclusioni e condizioni specifiche, fra cui l’esenzione delle microimprese che forniscono servizi e la valutazione dell’onere sproporzionato o della modifica sostanziale. Nel marzo 2026 AgID ha adottato le Linee guida sull’accessibilità dei servizi per l’attuazione del decreto.

Un normale sito aziendale non è automaticamente soggetto a tutti questi obblighi. Per determinare quali norme si applicano bisogna esaminare l’attività svolta, il servizio offerto, la dimensione dell’impresa e le disposizioni transitorie. Questa sintesi ha finalità informative e non sostituisce una valutazione legale del caso concreto.

WCAG 2.2: principi, livelli e criteri

Le Web Content Accessibility Guidelines sono lo standard tecnico internazionale sviluppato dal W3C. La versione più recente e stabile della serie WCAG 2 è la WCAG 2.2, che estende i criteri delle versioni precedenti.

Le WCAG organizzano i requisiti secondo quattro principi, spesso riassunti dall’acronimo inglese POUR:

1. Percepibile: informazioni e componenti devono poter essere percepiti in forme differenti, per esempio attraverso alternative testuali, sottotitoli e contrasto adeguato.
2. Utilizzabile: funzioni e navigazione devono poter essere azionate anche tramite tastiera, con focus visibile e senza interazioni che richiedano esclusivamente gesti complessi.
3. Comprensibile: contenuti, istruzioni, moduli ed errori devono essere chiari e il comportamento dell’interfaccia deve essere prevedibile.
4. Robusto: il codice deve consentire a browser e tecnologie assistive di interpretare correttamente ruoli, nomi, stati e relazioni.

I criteri di successo sono suddivisi nei livelli A, AA e AAA. Il livello AA è il riferimento adottato più spesso nelle politiche e nei requisiti tecnici, ma la conformità effettivamente richiesta va verificata nella norma applicabile.

La WCAG 2.2 aggiunge criteri dedicati, fra gli altri, a focus non oscurato, dimensione minima dei bersagli, alternative ai movimenti di trascinamento, aiuto coerente, inserimento ridondante dei dati e autenticazione accessibile. La WCAG 3 è ancora in fase di sviluppo e non sostituisce la WCAG 2.2 come standard di riferimento.

Come rendere accessibile un sito web

Struttura semantica e navigazione

Usa titoli gerarchici, landmark ed elementi HTML coerenti con la loro funzione. Ogni pagina dovrebbe avere un titolo riconoscibile, una lingua dichiarata, collegamenti descrittivi e meccanismi di navigazione ripetuti in modo coerente.

La struttura del sito web deve aiutare le persone a comprendere dove si trovano e come raggiungere le informazioni, senza dipendere esclusivamente dall’aspetto visivo.

Tastiera e gestione del focus

Tutte le funzioni essenziali devono essere utilizzabili senza mouse. L’ordine di tabulazione deve essere logico, il focus deve essere visibile e non dovrebbe venire nascosto da header fissi, finestre sovrapposte o banner.

Menu, finestre modali e componenti interattivi devono gestire correttamente apertura, chiusura e ritorno del focus. Non devono esistere trappole da tastiera dalle quali sia impossibile uscire.

Contrasto, colore e ingrandimento

Testo e componenti devono mantenere un contrasto sufficiente. Il colore non può essere l’unico mezzo per comunicare uno stato, un errore o una scelta. I contenuti devono rimanere leggibili quando vengono ingranditi o visualizzati su schermi stretti, senza perdita di informazioni o funzioni.

Moduli, istruzioni ed errori

Ogni campo deve avere un’etichetta associata e istruzioni comprensibili. Gli errori vanno identificati in modo testuale, spiegando come correggerli. Quando possibile, evita di richiedere più volte le stesse informazioni e usa gli attributi di autocompletamento appropriati.

CAPTCHA e autenticazione non dovrebbero dipendere soltanto da prove visive, memorizzazione o trascrizione di codici. Devono esistere alternative accessibili e compatibili con i gestori di password.

Immagini, audio e video

Le immagini informative richiedono un’alternativa testuale adeguata al contesto; quelle puramente decorative devono avere un attributo alt vuoto, così da poter essere ignorate dalle tecnologie assistive. La guida sul testo alternativo delle immagini approfondisce criteri ed esempi.

I video preregistrati richiedono sottotitoli quando contengono informazioni audio, mentre contenuti e requisiti applicabili possono rendere necessarie trascrizioni o audiodescrizioni. I controlli del player devono essere accessibili da tastiera e possedere nomi comprensibili.

HTML nativo e ARIA

Preferisci gli elementi HTML nativi: un vero pulsante offre già comportamenti da tastiera e informazioni semantiche che un elemento generico deve invece ricostruire. Usa ARIA soltanto quando l’HTML non esprime il comportamento necessario e verifica nomi, ruoli, stati e relazioni con tecnologie assistive.

Animazioni e contenuti in movimento

Evita lampeggiamenti pericolosi e permetti di interrompere o nascondere contenuti che si muovono automaticamente. Rispetta, quando possibile, la preferenza di sistema per la riduzione del movimento e non imporre limiti di tempo non necessari.

Come verificare l’accessibilità di un sito

Nessuno strumento automatico può certificare da solo che un sito sia accessibile. Lighthouse, axe DevTools, WAVE e Accessibility Insights aiutano a individuare errori rilevabili automaticamente, ma molti criteri richiedono interpretazione e prove manuali.

Controlli automatici

• assenza di alternative testuali o etichette;
• contrasti insufficienti rilevabili;
• ID duplicati e alcuni errori ARIA;
• strutture semantiche mancanti o incoerenti;
• problemi ricorrenti presenti nei template.

Controlli manuali

• naviga tutte le funzioni usando soltanto la tastiera;
• verifica ordine e visibilità del focus;
• prova zoom, ridisposizione dei contenuti e orientamenti differenti;
• controlla moduli, errori, finestre modali e componenti dinamici;
• usa almeno uno screen reader, come NVDA o VoiceOver, nei flussi principali;
• verifica che testi alternativi, link e istruzioni abbiano senso nel contesto.

Il campione deve comprendere template, pagine più visitate, funzioni essenziali, stati di errore e passaggi che portano a una conversione. I test con persone con disabilità permettono di scoprire barriere che una checklist tecnica può non evidenziare.

Accessibilità e WordPress

WordPress può offrire una base valida, ma il risultato dipende da tema, plugin, contenuti e personalizzazioni. La dichiarazione “accessibility-ready” di un tema non garantisce che il sito finito sia conforme: page builder, moduli, cookie banner, menu, popup e contenuti redazionali possono introdurre nuove barriere. La guida per creare un sito con WordPress integra questi controlli nel processo complessivo.

• scegli temi e plugin mantenuti e verifica i componenti prima di adottarli;
• non usare paragrafi in grassetto al posto delle intestazioni;
• controlla menu, ricerca, moduli, checkout e area riservata;
• assegna correttamente titoli, testi dei link e alternative alle immagini;
• ripeti i test dopo aggiornamenti del tema, dei plugin e dei contenuti.

Un plugin o un overlay non corregge automaticamente il codice, i contenuti e i processi. Può offrire funzioni aggiuntive, ma non sostituisce la rimozione delle barriere alla fonte né una verifica di conformità.

Accessibilità e SEO: qual è il rapporto reale

L’accessibilità non deve essere presentata come un singolo fattore capace di migliorare automaticamente il posizionamento. Alcuni interventi producono però benefici condivisi: testi alternativi contestuali aiutano a comprendere le immagini, link descrittivi e contenuti chiari migliorano l’esperienza, mentre una struttura ordinata facilita navigazione e manutenzione.

Queste convergenze non trasformano la conformità WCAG in una scorciatoia SEO. La priorità deve restare la possibilità per le persone di usare il servizio. La guida sul posizionamento SEO approfondisce i segnali e le attività che incidono sulla visibilità organica.

Errori frequenti

• Affidarsi soltanto a un punteggio automatico: un valore elevato non dimostra la conformità dell’intero sito.
• Aggiungere ARIA ovunque: attributi errati possono peggiorare un componente già comprensibile con HTML nativo.
• Rimuovere il focus visibile: chi usa la tastiera perde il riferimento della propria posizione.
• Scrivere alt text per ogni immagine: gli elementi decorativi devono poter essere ignorati.
• Controllare soltanto la homepage: moduli, checkout, ricerca e aree riservate contengono spesso le barriere più gravi.
• Considerare concluso il lavoro: nuovi contenuti e aggiornamenti possono reintrodurre problemi già risolti.

Checklist essenziale per un sito accessibile

1. definisci il quadro normativo e il livello di conformità applicabile;
2. mappa pagine, template, componenti e flussi essenziali;
3. correggi struttura semantica, tastiera, focus e contrasto;
4. rendi accessibili moduli, messaggi di errore e autenticazione;
5. prepara alternative per immagini, audio e video;
6. combina strumenti automatici, verifiche manuali e test con utenti;
7. documenta problemi, priorità, responsabilità e verifiche;
8. integra l’accessibilità nel processo editoriale e nei rilasci futuri.

L’accessibilità è un processo continuo

Un sito accessibile non è il risultato di una correzione eseguita una volta sola. È necessario progettare componenti corretti, formare chi pubblica contenuti, verificare le funzioni più importanti e controllare ogni modifica nel tempo.

Se devi progettare o ripensare un sito professionale, l’accessibilità dovrebbe entrare fin dall’inizio nel servizio di realizzazione del sito web. Intervenire sui requisiti durante architettura, design e sviluppo è più efficace che correggere le barriere quando il progetto è già online.