Come rendere un sito accessibile: guida pratica secondo WCAG 2.1 + PDF scaricabile

Stai cercando una checklist WCAG 2.1 chiara e operativa per adeguare il tuo sito web all’European Accessibility Act 2025? Sei nel posto giusto.

In questa guida troverai tutto quello che ti serve per rendere un sito accessibile, passo dopo passo: dai requisiti fondamentali delle WCAG 2.1, ai test da fare, fino alle modifiche tecniche da applicare subito (anche su WordPress).

Cosa sono le WCAG 2.1

Le WCAG 2.1 (Web Content Accessibility Guidelines) sono le linee guida internazionali per rendere i contenuti digitali accessibili a tutti, in particolare a persone con disabilità. Sono definite dal W3C (World Wide Web Consortium) e sono il riferimento tecnico per l’adeguamento all’European Accessibility Act 2025.

Applicare la checklist WCAG 2.1 al tuo sito web significa renderlo navigabile, comprensibile e fruibile anche da chi utilizza screen reader, ha difficoltà motorie o problemi visivi.

Principi fondamentali: percepibile, utilizzabile, comprensibile, robusto

Le WCAG si basano su quattro principi fondamentali, noti con l’acronimo POUR:

• Percepibile: le informazioni devono essere presentabili in modo che gli utenti possano percepirle. Es: testo alternativo per le immagini, sottotitoli nei video.

• Utilizzabile (Operable): il sito deve poter essere utilizzato tramite tastiera, mouse o altri dispositivi di input. Es: navigazione da tastiera senza blocchi.

• Comprensibile: il contenuto e l’interfaccia devono essere facili da capire. Es: linguaggio semplice, etichette chiare nei form, messaggi di errore utili.

• Robusto: il codice deve essere scritto in modo tale da funzionare correttamente con le tecnologie assistive presenti e future. Es: uso corretto di HTML semantico e attributi ARIA.

Questi principi non sono solo “buone pratiche”: sono i criteri su cui si basano i test di accessibilità, anche quelli ufficiali.

WCAG 2.1 vs 2.0: cosa cambia

Molti siti web sono ancora fermi alle WCAG 2.0, ma dal 2018 il W3C ha rilasciato la versione 2.1, che amplia i criteri per includere:

• Disabilità cognitive e motorie: nuovi requisiti per input da dispositivi mobili e touchscreen.

• Accessibilità mobile: attenzione a zoom, orientamento schermo, spaziatura e interazione da smartphone.

• Elementi interattivi: miglioramenti per dropdown, toggle, slider e menu complessi.

Adeguarsi alle WCAG 2.1 è essenziale per chi vuole rispettare la normativa EAA, ma anche per offrire un’esperienza utente inclusiva e moderna.

Checklist per l’accessibilità web 2025

Per adeguarti all’European Accessibility Act e rispettare le WCAG 2.1, è fondamentale seguire una checklist tecnica che tocchi tutti gli aspetti critici dell’accessibilità web. Di seguito analizziamo i principali requisiti da verificare e implementare.

Navigazione da tastiera

Un sito accessibile deve poter essere navigato completamente tramite tastiera, senza l’uso del mouse. Questo è essenziale per utenti con disabilità motorie o ipovedenti che utilizzano screen reader o tastiere speciali.

I principali elementi da verificare:

• Tutti i link, pulsanti e campi modulo devono essere focalizzabili (tabindex corretto)

• La sequenza di tabulazione deve essere logica e coerente

• I menu a tendina devono poter essere aperti e gestiti da tastiera

• Il focus visibile deve essere ben definito (bordo, colore o stile)

Verifica manualmente e con strumenti come il navigatore tastiera nativo del browser.

Alternative testuali per immagini

Ogni immagine significativa deve avere un attributo alt descrittivo. Questo aiuta gli screen reader a spiegare il contenuto visivo agli utenti ciechi o ipovedenti.

Cosa considerare:

• Le immagini decorative vanno marcate con alt="" (vuoto)

• Il testo alternativo deve descrivere lo scopo, non solo il contenuto (es. “Pulsante di invio modulo”)

• Evita di inserire nel alt informazioni ridondanti rispetto al testo circostante

Le infografiche complesse richiedono descrizioni lunghe o testi equivalenti nel corpo della pagina.

Contrasto colore testo/sfondo

Il contrasto tra testo e sfondo è fondamentale per la leggibilità, specialmente per utenti con disabilità visive o daltonismo.

Le WCAG 2.1 richiedono:

• Rapporto minimo 4.5:1 per testi normali

• Rapporto 3:1 per testi grandi (oltre 18px bold o 24px regolari)

• Evitare combinazioni critiche (es. grigio chiaro su bianco, rosso su verde)

Strumenti come Color Contrast Checker o Lighthouse aiutano a verificare automaticamente i contrasti.

Compatibilità con screen reader

I contenuti devono essere interpretati correttamente dai lettori vocali, come NVDA, JAWS o VoiceOver.

Best practice fondamentali:

• Utilizzare HTML semantico (<header>, <nav>, <main>, <article>, <footer>)

• Usare aria-label, aria-hidden e role solo quando strettamente necessario

• Assicurarsi che il contenuto sia letto in ordine logico

• Fornire etichette testuali ai controlli (<label for> per ogni input)

Testa con almeno uno screen reader gratuito, come NVDA (Windows) o VoiceOver (macOS).

Moduli e interazioni accessibili

I moduli sono una delle aree più critiche in termini di accessibilità. Ogni campo deve essere:

• Etichettato in modo chiaro tramite label associato all’id

• Supportato da messaggi di errore comprensibili e leggibili dagli screen reader

• Accessibile da tastiera e screen reader durante l’interazione dinamica (es. validazioni)

Utilizza il pattern aria-describedby per spiegare campi complessi o messaggi personalizzati.

Evita:

• Placeholder come unica etichetta

• Errori solo visuali (es. campo rosso senza descrizione testuale)

Accessibilità nei contenuti video/audio

I contenuti multimediali devono essere fruibili anche da persone con disabilità uditive o visive.

Cosa implementare:

• Sottotitoli sincronizzati per tutti i video

• Trascrizioni testuali per i contenuti solo audio

• Descrizioni audio per i video complessi (opzionale ma raccomandato)

• Controlli di riproduzione accessibili da tastiera e screen reader

Per i video YouTube incorporati, verifica che i comandi di player siano compatibili con le tecnologie assistive.

Strumenti per testare l’accessibilità di un sito

Una volta applicata la checklist WCAG 2.1, è fondamentale verificare il livello di accessibilità del tuo sito con strumenti affidabili. Esistono diverse soluzioni gratuite (e alcune a pagamento) che analizzano codice, struttura e usabilità da parte di utenti con disabilità. Ecco i tre strumenti più usati per una valutazione rapida ed efficace.

Google Lighthouse

Google Lighthouse è uno strumento integrato in Chrome DevTools che permette di eseguire un audit automatico dell’accessibilità (oltre a performance e SEO).

Caratteristiche principali:

• Analisi automatica del DOM e dei ruoli ARIA

• Punteggio accessibilità su scala 0–100

• Suggerimenti su problemi comuni (es. mancanza di alt, bassa leggibilità, elementi non interattivi)

Come usarlo:

1. Apri il sito in Chrome

2. Premi F12 per aprire gli strumenti per sviluppatori

3. Vai su “Lighthouse”

4. Seleziona “Accessibility” e avvia l’analisi

Lighthouse è ideale per audit rapidi, ma non sostituisce i test manuali.

WAVE WebAIM

WAVE è uno strumento online gratuito sviluppato da WebAIM (Web Accessibility in Mind) pensato specificamente per l’accessibilità.

Caratteristiche:

• Evidenzia problemi direttamente sulla pagina

• Mostra icone e annotazioni visive per ogni elemento problematico

• Fornisce spiegazioni didattiche utili anche ai non sviluppatori

È particolarmente utile per chi lavora su contenuti e layout, e per chi cerca un feedback visivo immediato. Basta inserire l’URL del tuo sito su wave.webaim.org per iniziare.

Axe DevTools

Axe DevTools è una delle estensioni più potenti per Chrome e Firefox, pensata per sviluppatori e tester.

Punti di forza:

• Analisi precisa e personalizzabile del DOM

• Report dettagliati per ogni errore WCAG 2.1

• Modalità di ispezione interattiva per individuare il nodo HTML interessato

• Integrazione con framework come React, Angular e Vue

Versione gratuita sufficiente per la maggior parte dei test; la versione Pro offre simulazioni di utenti reali e test avanzati. Ideale per chi vuole integrare l’accessibilità nei processi di sviluppo continuo (CI/CD).

Come agire: modifiche tecniche e best practice

Conoscere la checklist e usare strumenti di test è solo una parte del lavoro. Per garantire davvero l’accessibilità del tuo sito, servono interventi mirati a livello di codice, CMS e User Experience. In questa sezione trovi le buone pratiche da seguire per sviluppare un sito web accessibile nel concreto.

Sviluppo WordPress accessibile

WordPress è un CMS molto diffuso, ma non sempre accessibile “out of the box”. Alcuni temi e plugin possono introdurre barriere senza che tu te ne accorga.

Ecco cosa fare:

• Scegli un tema accessibile: verifica che sia dichiarato “accessibility-ready” nel repository ufficiale. Evita temi con slider, effetti visivi eccessivi o menu complessi non gestibili da tastiera.

• Evita builder visivi non conformi: molti page builder generano markup complesso e poco semantico. Gutenberg, se usato correttamente, è un’opzione migliore.

• Controlla i plugin: alcuni plugin aggiungono elementi interattivi (moduli, lightbox, tab, caroselli) non accessibili. Testali con Lighthouse e WAVE.

• Aggiungi ARIA solo quando serve: WordPress genera già HTML abbastanza semantico. Non esagerare con gli aria-*.

Puoi anche usare plugin dedicati all’accessibilità per piccoli miglioramenti (es. skip link, contrasto, dimensione del testo), ma non sostituiscono un lavoro tecnico completo.

Ruolo di HTML semantico e ARIA

Una struttura semantica chiara è la base dell’accessibilità. Il tuo codice deve comunicare alle tecnologie assistive cosa rappresentano gli elementi, non solo come appaiono.

Buone pratiche:

• Usa i tag corretti: main, header, nav, section, article, aside, footer

• I heading (h1, h2, h3) devono seguire un ordine logico, senza salti

• I link devono essere descrittivi (evita “clicca qui”)

• I pulsanti devono essere <button>, non div con onclick

ARIA (Accessible Rich Internet Applications) è utile per:

• Etichettare elementi non testuali (aria-label, aria-labelledby)

• Gestire dinamiche complesse (aria-expanded, aria-hidden)

• Definire ruoli (role="dialog", role="alert")

Attenzione però: l’uso scorretto di ARIA può peggiorare l’accessibilità. Segui la regola: “prima l’HTML nativo, poi eventualmente ARIA”.

Performance e UX inclusive

Accessibilità non significa solo rispettare le linee guida WCAG, ma anche offrire un’esperienza fluida e inclusiva per ogni utente, indipendentemente da dispositivo o capacità.

Cosa considerare:

• Velocità di caricamento: utenti con tecnologie assistive subiscono fortemente i rallentamenti. Ottimizza CSS, JS e immagini.

• Layout responsivo: il sito deve funzionare perfettamente anche su mobile e in modalità zoom fino al 400%.

• Feedback visivo e testuale: ogni azione dell’utente deve produrre un segnale (es. conferma invio modulo, cambio stato pulsante).

• Evita contenuti che si muovono automaticamente: caroselli, autoplay video e animazioni complesse sono spesso un problema. Se usati, devono poter essere pausati, fermati o nascosti.

Un sito accessibile è anche più usabile, più veloce e spesso meglio indicizzato da Google.

Risorse e template utili

Per aiutarti a implementare in modo efficace la checklist WCAG 2.1 e prepararti all’adeguamento previsto dall’European Accessibility Act, abbiamo raccolto una serie di risorse pronte all’uso. Queste fonti ti permettono di approfondire, documentarti e lavorare in modo più strutturato.

Scarica la checklist PDF

Abbiamo preparato una checklist PDF stampabile con tutti i punti principali dell’accessibilità web secondo le WCAG 2.1. È pensata per:

• Sviluppatori e web agency che vogliono tracciare l’avanzamento degli interventi

• Project manager che gestiscono l’adeguamento di più siti

• Clienti finali che vogliono avere una panoramica chiara delle attività da svolgere

Il file include anche una colonna per segnare le priorità e una per i test effettuati.

Scarica qui la checklist WCAG 2.1 in PDF per l’adeguamento all’European Accessibility Act 2025

Link a WCAG ufficiali (W3C)

Il riferimento tecnico completo e ufficiale per l’accessibilità è il sito del W3C (World Wide Web Consortium), che pubblica le WCAG nelle diverse versioni.

• WCAG 2.1 – Linee guida complete (W3C)

• WCAG 2.1 – Quick Reference in italiano (WAI)

Queste risorse sono ideali per i team tecnici, ma anche per chi vuole comprendere nel dettaglio i principi e i criteri di successo della normativa.

Guida WAI-ARIA per sviluppatori

Per i siti che includono componenti interattivi complessi (modali, tab, menù dinamici), l’uso di WAI-ARIA può essere necessario. Il W3C fornisce una guida dettagliata pensata per gli sviluppatori.

• ARIA Authoring Practices Guide (APG)

• ARIA roles, states and properties

Qui trovi pattern già pronti da riutilizzare e spiegazioni su come migliorare l’interazione con le tecnologie assistive.

FAQ e Domande comuni