47 controlli su WCAG 2.1, normativa AGID e Legge Stanca. Una guida pratica per sviluppatori e agenzie web che lavorano su siti istituzionali italiani.
Il quadro normativo italiano sull’accessibilità web
In Italia, i siti della pubblica amministrazione non sono soggetti solo alle WCAG generiche. C’è un insieme di obblighi normativi specifici che molti sviluppatori non conoscono bene, e che espongono gli enti a rischi concreti.
La Legge 4/2004 (Legge Stanca) obbliga le PA a garantire l’accessibilità di siti web e applicazioni mobili. L’aggiornamento del 2018 ha recepito la Direttiva UE 2016/2102, introducendo tra i requisiti formali la dichiarazione di accessibilità, aggiornata annualmente secondo il modello AGID.
Le Linee guida AGID definiscono i criteri tecnici di conformità, allineandosi alle WCAG 2.1 con il Livello AA come standard minimo obbligatorio. Il Livello AAA è raccomandato dove applicabile, in particolare per servizi rivolti a categorie vulnerabili.
In caso di non conformità, i cittadini possono attivare il meccanismo di feedback previsto dalla normativa. L’AGID conduce campagne di monitoraggio periodiche sui siti istituzionali.
Questa checklist assume WCAG 2.1 Livello AA come standard minimo, che corrisponde al requisito legale per i siti PA italiani. I controlli contrassegnati come “Critico” corrispondono a criteri di successo il cui mancato rispetto costituisce non conformità diretta.
Perché i siti pa hanno esigenze diverse dagli altri
La maggior parte delle guide sull’accessibilità web disponibili online è scritta per contesti generici o mercati anglofoni. Non trattano la dichiarazione di accessibilità secondo il modello AGID, non parlano del validatore AGID, non considerano Bootstrap Italia e non affrontano i problemi specifici delle configurazioni WordPress multisite usate nei portali istituzionali.
A questo si aggiunge che l’utenza dei siti PA è per definizione eterogenea: anziani, persone con disabilità visive o motorie, utenti con bassa alfabetizzazione digitale.
Come usare questa checklist
Il modo più efficace è eseguire i controlli in tre momenti: durante lo sviluppo in staging, nella fase di pre-lancio, e annualmente come parte dei contratti di manutenzione.
I controlli sono divisi per gravità
- Critico: non conformità diretta alla normativa
- Alto: impatto significativo sull’usabilità
- Medio: best practice raccomandate
Sezione 1 — percepibilità
Immagini e contenuti multimediali
- Ogni immagine non decorativa ha alt descrittivo CRITICO
- Immagini decorative usano alt=”” ALTO
- Immagini complesse hanno descrizione lunga o tabella equivalente ALTO
- I video hanno sottotitoli sincronizzati (non auto-generati) CRITICO
- I contenuti solo audio hanno trascrizione testuale ALTO
Colore e contrasto
- Contrasto testo almeno 4,5:1 CRITICO
- Testo grande almeno 3:1 ALTO
- Informazioni non trasmesse solo tramite colore CRITICO
- Componenti UI e icone almeno 3:1 ALTO
Struttura e semantica
- Unico H1 descrittivo per pagina CRITICO
- Gerarchia titoli logica, nessun salto ALTO
- Elenchi con tag ul/ol/dl corretti MEDIO
- Tabelle con th e caption corretti ALTO
- lang=”it” sull’elemento html CRITICO
Sezione 2 — utilizzabilità
Navigazione da tastiera
- Tutti gli elementi interattivi raggiungibili da tastiera CRITICO
- Ordine focus logico e sequenziale CRITICO
- Focus mai intrappolato senza via di uscita CRITICO
- Indicatore focus visibile con contrasto 3:1 (verificare outline: none nel CSS) CRITICO
- Link “Vai al contenuto principale” come primo elemento focalizzabile ALTO
Link e bottoni
- Testo link descrittivo, no “clicca qui” senza contesto CRITICO
- Link nuova scheda comunicano apertura in anticipo ALTO
- Bottoni usano elemento button nativo ALTO
- Bottoni icona-only hanno aria-label CRITICO
Tempi e animazioni
- Timeout avvisano 20 secondi prima ALTO
- Caroselli auto-play possono essere fermati ALTO
- Animazioni rispettano prefers-reduced-motion MEDIO
Sezione 3 — comprensibilità
Form (Contact Form 7 default non supera almeno 4 di questi controlli):
- Ogni campo ha etichetta visibile persistente, non placeholder CRITICO
- Etichette associate programmaticamente con for/id o aria-labelledby CRITICO
- Campi obbligatori marcati non solo con colore ALTO
- Errori identificano campo e spiegano correzione CRITICO
- Errori annunciati agli screen reader con role=”alert” o aria-live CRITICO
- Form importanti hanno passaggio di revisione ALTO
Navigazione e coerenza
- Navigazione coerente tra pagine ALTO
- Title tag univoco e descrittivo per ogni pagina ALTO
- Breadcrumb con markup nav e aria-label corretti MEDIO
- Livello di lettura adeguato al pubblico generico MEDIO
Sezione 4 — solidità del codice
- HTML valido senza errori critici (W3C validator) ALTO
- Ruoli ARIA usati correttamente ALTO
- Nessun aria-hidden=”true” su elementi focalizzabili CRITICO
- Componenti custom implementano pattern ARIA corretti ALTO
- Sito funziona con JavaScript disabilitato per contenuti principali MEDIO
- Testato con almeno uno screen reader CRITICO
- PDF collegati sono taggati con ordine di lettura ALTO
Sezione 5 — requisiti agid specifici
- Dichiarazione di Accessibilità pubblicata, aggiornata annualmente secondo modello AGID CRITICO
- Dichiarazione raggiungibile dal footer di ogni pagina CRITICO
- Meccanismo di feedback per segnalare barriere (modulo o email) ALTO
- Bootstrap Italia aggiornato e personalizzazioni non compromettono semantica ALTO
Gli errori più comuni che si trovano in audit
Il più frequente riguarda i form. Contact Form 7 nella configurazione predefinita non gestisce correttamente l’associazione tra etichette e campi, non annuncia gli errori agli screen reader e non ha un meccanismo di revisione prima dell’invio.
Il secondo problema più comune è l’indicatore di focus rimosso nel CSS reset del tema con outline: none o outline: 0. Invisibile nei test visivi, critico per chi naviga da tastiera.
La Dichiarazione di Accessibilità è il requisito formale più spesso assente o non aggiornato. Obbligatoria per legge, ma trascurata in una quota significativa dei siti istituzionali attivi.
Gli strumenti automatici rilevano circa il 30% dei problemi di accessibilità. Il resto richiede verifica manuale.
Strumenti consigliati
- axe DevTools: estensione browser per scansione automatica
- NVDA con Chrome: screen reader open source per Windows
- VoiceOver con Safari: per macOS e iOS
- Validatore AGID: per conformità normativa italiana
- Lighthouse: integrato in Chrome DevTools
- Colour Contrast Analyser: per verifiche contrasto su qualsiasi elemento
Nessuno di questi strumenti usato da solo è sufficiente. Il testing con screen reader reale rimane insostituibile, in particolare per verificare le interazioni form e il comportamento dei componenti JavaScript personalizzati.
Questa checklist viene aggiornata ogni trimestre. Se trovate controlli mancanti o imprecisioni, potete segnalarlo tramite i contatti su agencypilot.it.