Una checklist di audit di accessibilita e un documento strutturato che ti guida attraverso ogni passo di verifica necessario per confermare che il tuo sito web funziona per le persone con disabilita. Invece di una vaga promessa di rendere le cose accessibili, una checklist trasforma la conformita in domande concrete si o no. Questa immagine ha un testo alternativo? Un utente da tastiera puo raggiungere ogni elemento interattivo? Il contrasto dei colori rispetta il rapporto 4,5:1? Questa guida fornisce oltre 50 punti di controllo organizzati secondo i quattro principi WCAG. Che tu stia preparando la conformita alla direttiva europea sull'accessibilita (EAA) in vigore da giugno 2025, con sanzioni che in Italia possono includere anche conseguenze penali per violazioni gravi, o che tu stia semplicemente cercando di costruire un prodotto migliore, questa checklist ti da la struttura per farlo.
Perche serve una checklist di audit strutturata
Eseguire un audit di accessibilita senza checklist e come fare un'ispezione edilizia a memoria. Troverai i problemi ovvi e perderai quelli sottili che effettivamente bloccano gli utenti.
Gli strumenti di scansione automatizzata sono un buon punto di partenza, ma rilevano solo circa il 30-40 percento dei problemi WCAG. Il resto richiede giudizio umano.
La dimensione legale si e rafforzata considerevolmente. La direttiva europea sull'accessibilita (EAA) e entrata in vigore il 28 giugno 2025. In Italia, le sanzioni per non conformita possono includere conseguenze penali per violazioni gravi e ripetute, oltre a sanzioni amministrative. In altri paesi UE le multe arrivano fino a 300.000 euro in Spagna e 250.000 euro in Francia.
Oltre ai requisiti legali, c'e un caso commerciale solido. I siti conformi in materia di accessibilita tendono a posizionarsi meglio nei motori di ricerca e a convertire piu utenti.
Prima di iniziare: preparare l'audit
Un buon audit inizia con la definizione dell'ambito. Testare ogni pagina di un sito grande e impraticabile e inutile. Concentrati su queste categorie:
Pagine ad alto traffico: la tua homepage, le principali landing page e le 10 pagine piu visitate.
Flussi utente chiave: registrazione, login, checkout, ricerca e form multi-step.
Template unici: se il tuo sito usa 8 layout diversi, testa almeno una pagina rappresentativa per template.
Pagine ricche di contenuto: articoli del blog, documentazione e knowledge base.
Per un sito aziendale tipico di 50-200 pagine, verificare 10-15 pagine rappresentative copre la grande maggioranza delle variazioni.
Strumenti necessari
Non servono software aziendali costosi per un audit approfondito.
Scanner automatizzato: Usa il nostro verificatore di accessibilita gratuito su web-accessibility-checker.com per un rapporto di conformita WCAG 2.2 istantaneo.
DevTools del browser: Chrome e Firefox includono pannelli di ispezione dell'accessibilita.
Screen reader: NVDA e gratuito su Windows. VoiceOver e integrato in macOS e iOS. TalkBack e integrato in Android.
Tastiera: La tua tastiera fisica. Scollega il mouse e prova a completare i flussi principali usando solo Tab, Shift+Tab, Invio, Spazio e frecce.
Analizzatore di contrasto: Il Colour Contrast Analyser di TPGi e gratuito.
Verificatore PDF: Usa PAC 2024 per verificare l'accessibilita dei documenti PDF.
Principio 1: Percepibile
Il primo principio WCAG chiede: gli utenti possono percepire il contenuto?
Immagini e contenuto non testuale
Ogni immagine informativa deve avere un testo alternativo che trasmetta le stesse informazioni. Le immagini decorative devono avere attributi alt vuoti.
Verifica che le immagini complesse come grafici e infografiche abbiano descrizioni estese.
I CAPTCHA devono fornire alternative.
Contenuto video e audio
I video preregistrati necessitano di sottotitoli sincronizzati. Il contenuto audio preregistrato necessita di una trascrizione testuale. I video preregistrati necessitano di audiodescrizioni per informazioni visive non trasmesse dall'audio esistente.
Testo e leggibilita
Il testo normale necessita di un rapporto di contrasto di almeno 4,5:1 rispetto allo sfondo. Il testo grande necessita di almeno 3:1.
La pagina deve rimanere funzionale e leggibile quando il testo viene ingrandito al 200 percento.
Non usare immagini di testo quando il testo reale puo ottenere lo stesso effetto visivo.
Verifica che il contenuto non si basi solo sul colore per trasmettere informazioni.
Principio 2: Utilizzabile
Gli utenti possono operare l'interfaccia? Ogni funzione deve funzionare per chi usa tastiera, screen reader, comandi vocali o dispositivi di switch.
Accessibilita da tastiera
Ogni elemento interattivo deve essere raggiungibile e utilizzabile solo con la tastiera.
Verifica le trappole da tastiera. Una trappola si verifica quando puoi entrare con Tab in un elemento ma non puoi uscirne.
Verifica che l'ordine di tabulazione segua una sequenza logica di lettura.
Visibilita del focus
Ogni elemento interattivo deve avere un indicatore di focus visibile. Secondo WCAG 2.2 criterio 2.4.11, l'elemento focalizzato non deve essere completamente nascosto dietro header fissi o widget flottanti.
Non rimuovere mai i contorni del focus senza fornire un sostituto altrettanto visibile.
Dimensione target e touch
WCAG 2.2 criterio 2.5.8 richiede che i target interattivi siano di almeno 24 per 24 pixel CSS.
Per funzionalita drag-and-drop, WCAG 2.2 criterio 2.5.7 richiede un'alternativa con puntatore singolo.
Tempistica e movimento
Se il contenuto si muove automaticamente per piu di 5 secondi, gli utenti devono poterlo mettere in pausa o fermarlo.
Nulla nella pagina deve lampeggiare piu di tre volte al secondo.
Se c'e un limite di tempo, gli utenti devono poterlo disattivare, regolare o estendere.
Principio 3: Comprensibile
Gli utenti possono capire il contenuto e come funziona l'interfaccia?
Lingua e leggibilita
La pagina deve dichiarare la sua lingua nell'attributo HTML lang. Per pagine in italiano, usa lang it.
I menu di navigazione devono apparire nella stessa posizione relativa su tutte le pagine.
Verifica che le istruzioni non si basino solo su caratteristiche sensoriali.
Form e gestione errori
Ogni campo del form necessita di un'etichetta visibile associata programmaticamente. Il testo placeholder da solo non e un'etichetta.
Quando l'invio del form produce errori, identifica i campi specifici e descrivi cosa e andato storto.
WCAG 2.2 criterio 3.3.7 richiede che le informazioni gia inserite vengano precompilate se necessarie di nuovo.
Per l'autenticazione, WCAG 2.2 criterio 3.3.8 richiede di non bloccare i gestori di password.
Principio 4: Robusto
Le tecnologie assistive possono interpretare correttamente il contenuto?
HTML semantico e ARIA
Usa elementi HTML semantici: header, nav, main, footer, article, section, aside.
I titoli devono seguire una gerarchia logica. Un H1 per pagina.
Tutti gli elementi interattivi devono avere nomi accessibili.
Usa ruoli e proprieta ARIA solo quando l'HTML nativo non fornisce la semantica necessaria.
Verifica che gli aggiornamenti di contenuto dinamico vengano annunciati agli screen reader tramite regioni aria-live.
La checklist completa: riferimento rapido
Ecco la checklist completa in formato scansionabile.
Percepibile: - Tutte le immagini informative hanno testo alt descrittivo - Le immagini decorative hanno attributi alt vuoti - I video hanno sottotitoli sincronizzati - Il contrasto del testo e 4,5:1 minimo - La pagina e usabile al 200% di zoom - Il contenuto non si basa solo sul colore
Utilizzabile: - Tutti gli elementi interattivi sono raggiungibili da tastiera - Non esistono trappole da tastiera - Indicatori di focus visibili presenti - Target interattivi di 24x24 pixel CSS minimo - Contenuto auto-animato ha controlli pausa - Link di salto navigazione presente
Comprensibile: - Lingua pagina dichiarata nell'attributo lang - Navigazione consistente tra le pagine - Tutti i campi hanno etichette visibili - Messaggi di errore specifici - Autenticazione non blocca gestori di password
Robusto: - Landmark HTML semantici utilizzati - Gerarchia dei titoli logica - Tutti gli elementi interattivi hanno nomi accessibili - ARIA usato correttamente e solo quando necessario
Come dare priorita ai problemi dopo l'audit
I problemi critici bloccano gli utenti completamente. Correggili per primi.
I problemi alti causano difficolta significative ma hanno soluzioni alternative.
I problemi medi influenzano l'usabilita senza impedire il completamento delle attivita.
I problemi bassi sono miglioramenti di best practice.
Documenta ogni risultato con la sua severita, l'URL della pagina interessata, il criterio WCAG pertinente e la correzione consigliata.
Automatizzare il monitoraggio continuo
Un audit e un'istantanea. I siti web cambiano costantemente. Senza monitoraggio continuo, le regressioni di accessibilita si accumulano in settimane.
Configura scansioni automatizzate con un programma regolare. Il nostro verificatore di accessibilita permette scansioni regolari.
Integra verifiche di accessibilita nel tuo workflow di sviluppo con librerie come axe-core.
Pianifica revisioni manuali trimestrali. Forma il tuo team di contenuti.
Requisiti legali da conoscere nel 2026
La direttiva europea sull'accessibilita (EAA) e entrata in vigore il 28 giugno 2025. Si applica alle aziende del settore privato che vendono prodotti o servizi nell'UE. In Italia, la non conformita puo comportare conseguenze penali per violazioni gravi e ripetute, oltre a sanzioni amministrative. Lo standard tecnico e EN 301 549, che riferisce a WCAG 2.1 Livello AA.
In Germania, il BFSG prevede multe fino a 100.000 euro. In Spagna fino a 300.000 euro. In Francia fino a 250.000 euro con penali giornaliere aggiuntive.
ADA Title II negli Stati Uniti richiede ora esplicitamente l'accessibilita web per gli enti governativi, con scadenza aprile 2026.
Mirare a WCAG 2.2 AA nel tuo audit copre i requisiti di tutti questi framework legali.