Accessibilità WordPress: la checklist di audit in 24 controlli

Un audit di accessibilità non è un punteggio. È una lista finita di verifiche che si fanno una per una, con la tastiera in mano e uno screen reader acceso, su un campione di pagine scelto apposta. Il punteggio arriva dopo, e non è quello che ti chiederanno se qualcuno segnala il sito.

Questa checklist raccoglie i 24 controlli con cui verifico l’accessibilità di un sito WordPress. Ogni controllo dice cosa si verifica, come si verifica in concreto — con quale strumento, quale schermata, quale gesto — come si corregge in WordPress e a quale condizione puoi considerarlo superato. I controlli sono indipendenti: puoi percorrerli in ordine o andare al blocco che ti serve.

Una premessa che cambia il modo di leggere tutto il resto: gli strumenti automatici intercettano solo una parte dei problemi — tipicamente le violazioni misurabili sul codice, come il contrasto insufficiente o l’attributo alt mancante. Non sanno dirti se l’alt che c’è descrive l’immagine giusta, se l’ordine di tabulazione ha senso per chi non vede la pagina, se un messaggio di errore spiega davvero cosa correggere. Per questo dei 24 controlli qui sotto solo tre si fanno premendo un pulsante.

Prima di iniziare

Ti servono quattro cose, tutte gratuite: un browser con un’estensione di analisi installata (axe DevTools, WAVE o Accessibility Insights — ne basta una), la tastiera, uno screen reader (NVDA su Windows, VoiceOver è già su macOS e iOS) e un posto dove provare le correzioni che non sia il sito in produzione.

Se le correzioni toccheranno il tema o i template — e su un sito WordPress quasi sempre è così — lavora su un ambiente di staging e non sul live: la guida a installare e configurare WordPress descrive come tenere in piedi un ambiente di prova separato. Se non hai staging, almeno un backup completo prima di toccare qualsiasi file.

L’audit va fatto a browser scoperto, senza plugin di ottimizzazione attivi in quel momento se minificano o accorpano il JavaScript: sono la causa più frequente di differenze fra quello che vedi in locale e quello che vede l’utente.

Blocco A — Perimetro e obblighi

Tre controlli che si fanno prima di aprire il browser. Servono a stabilire due cose che decidono tutto il resto: a che cosa devi essere conforme e su cosa stai facendo l’audit.

1. Sai quale norma si applica al tuo sito

«L’accessibilità è obbligatoria» è vero e inutile: in Italia gli obblighi arrivano da due direzioni diverse, con perimetri diversi, e sapere in quale ricadi cambia sia la scadenza sia chi ti può contestare qualcosa.

Come si verifica: rispondi a due domande. La prima: il sito vende prodotti o servizi a consumatori — commercio elettronico, servizi bancari, e-book, trasporti, comunicazioni elettroniche? Se sì rientri nel perimetro dello European Accessibility Act (direttiva UE 2019/882, recepita in Italia con il D.Lgs. 82/2022), applicabile dal 28 giugno 2025. La seconda: sei una pubblica amministrazione, oppure un soggetto privato con fatturato medio superiore ai 500 milioni di euro negli ultimi tre anni? Se sì rientri nella Legge Stanca (L. 4/2004), che aggiunge l’obbligo di pubblicare una dichiarazione di accessibilità.

Come si corregge: se non ricadi in nessuno dei due perimetri l’audit resta comunque una buona idea, ma cambia la posta in gioco. Se ci ricadi, la prima cosa da capire è se puoi contare sull’esenzione per le microimprese — meno di 10 dipendenti e fatturato o bilancio annuo non superiore a 2 milioni di euro — che però vale per i servizi, non per i prodotti, e non è automatica: va verificata sul caso concreto, e decade se hai ricevuto finanziamenti pubblici destinati proprio all’accessibilità. Le sanzioni esistono e sono proporzionate al perimetro e al fatturato: gli importi aggiornati vanno letti sulla fonte, non su un blog. L’autorità di vigilanza è AgID.

Se il sito è un e-commerce, questo controllo è il primo per un motivo preciso: un negozio WooCommerce è dentro il perimetro dell’EAA per definizione, indipendentemente da quanto è grande il catalogo.

✅ Fatto quando: sai scrivere in una riga quale norma si applica al tuo sito e da quale data.

2. Lo standard di riferimento è fissato — e sai cosa cambia con le WCAG 2.2

Le norme non descrivono i requisiti tecnici: rimandano a uno standard. In Europa lo standard armonizzato è la EN 301 549, che per i contenuti web rimanda a sua volta alle WCAG di livello AA. È lì che stanno i criteri veri, ed è su quelli che si fa l’audit.

Come si verifica: il riferimento richiesto oggi in Italia — anche nelle linee guida AgID sull’accessibilità dei servizi, adottate nel marzo 2026 — sono le WCAG 2.1 livello AA. Le WCAG 2.2 sono però Raccomandazione W3C dall’ottobre 2023 e sono un sovrainsieme: aggiungono nove criteri e ne rendono obsoleto uno (4.1.1 Parsing, che i browser moderni gestiscono da soli). Tutto ciò che è conforme alla 2.2 è conforme alla 2.1, non viceversa.

Come si corregge: imposta l’audit sulle 2.2 AA anche se l’obbligo formale si ferma alla 2.1. I nove criteri aggiunti riguardano cose che sui siti WordPress si rompono spesso — focus coperto da header sticky, bersagli troppo piccoli sul mobile, autenticazione che chiede di ricordare a memoria un codice — e rifare l’audit fra un anno per allinearsi costa più che partire allineati. Nei controlli che seguono i criteri della 2.2 sono segnalati dove compaiono.

✅ Fatto quando: hai scritto nel documento di audit la versione e il livello su cui stai misurando.

3. Il campione di pagine è definito, e non è «il sito»

Auditare «il sito» non vuol dire niente: su WordPress le pagine sono generate da un numero piccolo di template, e i problemi si ripetono identici su migliaia di URL. Il campione serve a coprire i template, non i contenuti.

Come si verifica: elenca i modelli di pagina diversi che il sito produce. Su un sito WordPress tipico sono sei o sette: home, una pagina statica, un articolo del blog, un archivio di categoria, la pagina dei risultati di ricerca, un modulo di contatto, la 404. Se c’è un’area transazionale — carrello, checkout, area riservata, login — quelle contano doppio, perché sono i percorsi in cui un blocco non è un fastidio ma un acquisto perso.

Come si corregge: scegli una pagina reale per ciascun modello, con contenuti veri e non di prova, e congela l’elenco: sarà lo stesso campione da ripassare al prossimo audit, altrimenti i due risultati non sono confrontabili. Aggiungi la pagina con più traffico anche se ripete un modello già presente.

✅ Fatto quando: hai una lista di URL scritta, fra sei e dieci, che copre tutti i template del sito.

Blocco B — Struttura del documento

Tre controlli sulla struttura che sta sotto la grafica. È la parte che gli strumenti automatici coprono meglio, ed è anche quella che il tema decide quasi da solo: se qui trovi un problema, correggerlo una volta lo risolve su tutto il sito.

4. La scansione automatica è stata fatta su tutto il campione

È il primo passaggio perché è veloce e perché sgombra il campo: quello che trova va corretto prima di iniziare le verifiche manuali, altrimenti passerai il tempo a incontrare due volte lo stesso problema.

Come si verifica: apri ogni URL del campione e lancia l’estensione. Annota il numero di violazioni per pagina e per tipo: quasi sempre scoprirai che tre o quattro tipi di errore coprono il 90% del totale, e che si ripetono su tutte le pagine perché nascono dal tema o da un plugin.

Come si corregge: raggruppa per causa, non per pagina. E soprattutto non trattare il punteggio come il risultato: il punteggio accessibilità di Lighthouse misura ciò che è misurabile in automatico, che è una frazione dei criteri WCAG. Un sito con punteggio 100 può essere impossibile da usare con la tastiera. È lo stesso errore che si fa con le metriche di velocità, dove inseguire il punteggio invece della causa è il modo più rapido per lavorare molto e migliorare poco.

✅ Fatto quando: ogni URL del campione ha un report salvato e le violazioni sono raggruppate per causa.

5. I titoli sono una gerarchia, non una scelta grafica

Chi usa uno screen reader naviga saltando di titolo in titolo: la struttura dei titoli è il suo indice. Un H3 usato perché «l’H2 era troppo grande» rompe quell’indice, e succede spesso perché nell’editor a blocchi il livello si sceglie da un menu che sembra una scelta di stile.

Come si verifica: l’estensione di analisi ha una vista che elenca i titoli nell’ordine in cui compaiono nel codice. Cerca tre cose: più di un H1, salti di livello (un H2 seguito da un H4), e titoli che stanno lì solo per la dimensione del carattere. Attenzione ai titoli generati dal tema fuori dal contenuto — widget della sidebar, footer, box «articoli correlati» — che sono la causa più comune degli H1 doppi.

Come si corregge: nell’editor a blocchi, seleziona il blocco Titolo e cambia il livello dalla barra degli strumenti; per la dimensione usa gli stili tipografici, non il livello. Se gli H1 doppi arrivano dal tema, il punto da correggere è il template, non l’articolo. Nei temi a blocchi il responsabile più frequente è il blocco Titolo del sito nell’header, che di suo emette un H1 su ogni pagina. È anche il terzo dei controlli SEO on-page, e non è una coincidenza: la gerarchia dei titoli serve alle stesse due categorie di lettori, le tecnologie assistive e i crawler.

✅ Fatto quando: ogni pagina del campione ha un solo H1 e nessun salto di livello.

6. Landmark, lingua e titolo di pagina sono corretti

Tre cose che stanno nel template, si sistemano una volta sola e cambiano l’esperienza di chi non vede la pagina più di qualunque intervento sul contenuto.

Come si verifica: i landmark sono le regioni della pagina — <header>, <nav>, <main>, <aside>, <footer>: l’estensione ne mostra l’elenco, e devi vederne uno solo di tipo main. Se ci sono due <nav> devono avere etichette diverse (aria-label), altrimenti si annunciano identici. La lingua si controlla nel sorgente: <html lang="it">, e va cambiato attributo su ogni blocco di testo in un’altra lingua. Il titolo di pagina è quello della scheda del browser: deve essere diverso su ogni URL e iniziare dall’informazione specifica.

Come si corregge: nei temi a blocchi i landmark si impostano dai template di sito; nei temi classici stanno in header.php, footer.php e nei file di contenuto — la struttura dei template file di un tema WordPress spiega quale file genera cosa. La lingua si imposta in Impostazioni > Generali e viene stampata da language_attributes(): se manca, manca quella chiamata nel tema.

✅ Fatto quando: un solo main per pagina, nav multipli etichettati, lang corretto e titoli di pagina unici.

Blocco C — Colore, testo e adattabilità

Quattro controlli su come il testo si comporta quando l’utente cambia le condizioni: ingrandisce, allarga la spaziatura, arriva da uno schermo stretto. Riguardano quasi tutti il tema e i suoi stili globali, non i contenuti.

7. Il contrasto arriva a 4.5:1 — e non solo sul testo

È la violazione più diffusa in assoluto e anche la più facile da correggere, perché non richiede di toccare il markup. I minimi WCAG sono 4.5:1 per il testo normale e 3:1 per il testo grande (da 24px, o da 18.7px se in grassetto).

Come si verifica: l’estensione segnala i rapporti insufficienti sul testo, e il Contrast Checker di WebAIM serve a provare una coppia di colori prima di adottarla. Quello che non segnala sempre, e che va guardato a mano, è il criterio separato che chiede 3:1 sui componenti non testuali: bordi dei campi di un modulo, icone che veicolano un’informazione, la parte piena di una barra di avanzamento. Sono i punti dove un tema chiaro e minimale sbaglia quasi sempre — un campo input con il bordo grigio chiarissimo su fondo bianco non si vede, e non è un problema estetico.

Controlla anche i due stati che nessuno guarda: il testo sopra le immagini (dove il contrasto cambia da immagine a immagine, e va garantito nel caso peggiore, non nel migliore) e il testo dei placeholder nei moduli, che i temi rendono deliberatamente pallido.

Come si corregge: se il tema espone gli stili globali, la palette si corregge in un punto solo e si propaga ovunque — gli stili globali e theme.json valgono anche in un tema classico. Correggere la palette una volta è preferibile a inseguire i singoli elementi con CSS aggiuntivo, che è il modo in cui i fogli di stile diventano ingestibili.

✅ Fatto quando: nessun rapporto sotto 4.5:1 sul testo, sotto 3:1 su bordi e icone informative, verificato anche su hover e focus.

8. Il colore non è mai l’unico veicolo dell’informazione

Un campo obbligatorio segnalato solo con il bordo rosso, un link distinto dal testo solo perché è blu, una legenda di grafico che funziona solo se distingui le tinte: per chi non percepisce quel contrasto cromatico l’informazione semplicemente non c’è.

Come si verifica: è un controllo manuale, e il modo più rapido è guardare la pagina in scala di grigi — Chrome DevTools, pannello Rendering, Emulate vision deficiencies. Tutto quello che smette di essere comprensibile in scala di grigi è un problema. I punti tipici su WordPress sono tre: i link dentro il testo, gli stati di errore dei moduli e i badge di stato.

Come si corregge: aggiungi un secondo segnale, non sostituire il primo. Sottolineatura sui link nel corpo del testo (l’unico posto in cui toglierla è quasi sempre un errore), un’icona o la parola «Errore» accanto al campo, un pattern oltre al colore nei grafici. Un errore di modulo che si vede solo dal bordo rosso non esiste nemmeno per chi usa uno screen reader, indipendentemente dal colore.

✅ Fatto quando: la pagina in scala di grigi resta comprensibile in ogni sua parte.

9. Zoom al 200%, reflow a 320px e spaziatura forzata

Tre prove diverse che si fanno di seguito sulla stessa pagina, perché falliscono per la stessa causa: dimensioni fissate in pixel dove servivano unità relative.

Come si verifica: lo zoom con Ctrl/⌘ + fino al 200%: il testo deve ingrandirsi senza che nulla venga tagliato o si sovrapponga. Il reflow restringendo la finestra fino a 320 CSS pixel di larghezza: il contenuto deve incolonnarsi, e non deve comparire una barra di scorrimento orizzontale — la tabella e il blocco di codice sono le due eccezioni ammesse. La spaziatura del testo applicando via DevTools interlinea 1.5, spaziatura fra paragrafi 2em, fra lettere 0.12em e fra parole 0.16em: nessun testo deve sparire o uscire dal suo contenitore.

Come si corregge: le cause sono quasi sempre tre, e stanno nel CSS del tema: altezze fisse su contenitori che contengono testo (height invece di min-height), overflow: hidden messo per nascondere un problema di layout, e dimensioni del carattere in px dove servivano rem. Il menu principale e i box con sfondo colorato sono i due elementi che si rompono per primi.

✅ Fatto quando: le tre prove passano su ogni pagina del campione senza perdita di contenuto né scorrimento orizzontale.

10. Niente si muove, lampeggia o parte da solo senza che si possa fermarlo

Slider che ruotano da soli, video di sfondo in autoplay, contatori animati, notifiche che scorrono: per una parte degli utenti non sono un dettaglio estetico ma un motivo per chiudere la pagina, e in alcuni casi un rischio concreto.

Come si verifica: apri la pagina e non fare niente per un minuto. Tutto ciò che si muove da solo per più di cinque secondi deve avere un comando visibile per metterlo in pausa. Verifica poi la stessa pagina con Riduci movimento attivo nelle preferenze del sistema operativo: le animazioni devono ridursi o sparire. Nessun contenuto deve lampeggiare più di tre volte al secondo.

Come si corregge: nella maggior parte dei casi la correzione è togliere l’autoplay dalle impostazioni del blocco o del plugin, non scrivere codice. Se il tema è tuo, la query CSS prefers-reduced-motion disattiva le transizioni per chi ha espresso quella preferenza, e costa poche righe. Le immagini che entrano in ritardo e spostano il contenuto sotto sono un problema imparentato, che si vede anche quando si configura il lazy loading: riservare lo spazio con width e height risolve entrambi i lati.

✅ Fatto quando: ogni elemento in movimento ha un comando di pausa, e Riduci movimento ha un effetto reale.

Blocco D — Tastiera e focus

Quattro controlli che si fanno con il mouse staccato. È il blocco che gli strumenti automatici coprono peggio e quello che scopre più problemi: se hai poco tempo, parti da qui.

11. Tutto quello che si fa con il mouse si fa con la tastiera

È il criterio più elementare delle WCAG ed è quello che fallisce più spesso, perché basta un componente costruito con <div> al posto di <button> per rendere irraggiungibile una funzione.

Come si verifica: percorri l’intera pagina premendo solo Tab, e prova ad attivare ogni cosa con Invio o Spazio. Annota tutto quello che il mouse raggiunge e la tastiera no: menu a scomparsa che si aprono solo in hover, tab dei contenuti, filtri, gallerie, il pulsante di chiusura dei banner.

Come si corregge: la correzione giusta quasi mai è aggiungere tabindex: è sostituire l’elemento sbagliato con quello nativo. Un <button> è raggiungibile, attivabile e annunciato correttamente senza che tu scriva una riga di JavaScript. La guida all’accessibilità da tastiera in WordPress percorre il test passo per passo e mostra le correzioni per i casi che restano.

✅ Fatto quando: hai completato ogni percorso principale del sito — navigazione, ricerca, invio di un modulo — senza toccare il mouse.

12. Il focus è sempre visibile, e non finisce coperto

Molti temi tolgono l’outline del browser perché «non è bello». Il risultato è che chi naviga con la tastiera non sa dove si trova: la pagina funziona ma è inutilizzabile.

Come si verifica: ripeti il giro con Tab guardando solo dove si trova il focus. Deve essere sempre evidente e con contrasto sufficiente rispetto allo sfondo. Poi la verifica che sfugge quasi a tutti, ed è un criterio aggiunto dalle WCAG 2.2: scorri la pagina a metà e continua a tabulare — l’elemento a fuoco non deve finire sotto un header o una barra dei cookie appiccicati in alto. Sui temi con header sticky succede sistematicamente, e vale allo stesso modo per una barra di annunci fissa in alto.

Come si corregge: ripristina un indicatore di focus esplicito nel CSS del tema (un outline di 2-3px con outline-offset, mai outline: none senza sostituto). Per il focus coperto, la correzione è dare all’elemento in cima un’altezza nota e usare scroll-padding-top sull’elemento radice.

✅ Fatto quando: il focus è visibile su ogni elemento interattivo, anche a metà pagina con l’header fisso attivo.

13. Nessuna trappola: modali, menu e slider restituiscono il focus

Una finestra modale che cattura il focus e non lo lascia più andare è la barriera peggiore che un sito possa avere: l’utente non può né procedere né tornare indietro se non ricaricando la pagina.

Come si verifica: apri con la tastiera ogni componente che si sovrappone alla pagina — modale, popup di newsletter, banner dei cookie, menu mobile, lightbox della galleria — e controlla tre cose: che il focus entri dentro il componente quando si apre, che tabulando resti dentro finché è aperto, e che Esc lo chiuda riportando il focus sull’elemento che l’aveva aperto. Il banner dei cookie è il caso da provare per primo, perché è la prima cosa che l’utente incontra.

Come si corregge: se il componente è di un plugin, la strada più veloce è verificare se ha un’opzione di accessibilità nelle impostazioni e, se non ce l’ha, cambiarlo. Se è codice tuo servono role="dialog", aria-modal="true", la gestione del focus all’apertura e alla chiusura: come si correggono le trappole del focus nelle modali mostra le correzioni applicate su un tema reale.

✅ Fatto quando: ogni componente sovrapposto si apre, trattiene il focus, si chiude con Esc e lo restituisce al punto di partenza.

14. C’è uno skip link, e i bersagli sono almeno 24×24 pixel

Due correzioni piccole che pesano molto: la prima risparmia decine di pressioni di Tab a ogni cambio pagina, la seconda riguarda chiunque abbia poca precisione nel puntamento — quindi molte più persone di quante ci si aspetti.

Come si verifica: ricarica la pagina e premi Tab una volta sola: la prima cosa che riceve il focus dovrebbe essere un link «Vai al contenuto» che compare a schermo e porta a <main>. Per i bersagli, misura in DevTools i pulsanti più piccoli — icone social, frecce dello slider, chiusura dei banner, paginazione: il minimo richiesto dalle WCAG 2.2 è 24×24 CSS pixel, salvo eccezioni come i link dentro un blocco di testo.

Come si corregge: lo skip link è un link nascosto in cima al markup che diventa visibile in :focus: molti temi ce l’hanno già ma lo rendono inoperante puntando a un ID che non esiste più, quindi vale la pena provarlo anche se sei sicuro che ci sia. I bersagli si allargano con il padding, non con la dimensione dell’icona: l’aspetto resta identico e l’area cliccabile cresce.

Già che sei sulla navigazione: il criterio 2.4.5 Multiple Ways (livello AA) chiede che ci sia più di un modo per trovare una pagina, e fra le tecniche che il W3C riconosce ci sono il menu, la ricerca e la mappa del sito prevista dalla tecnica G63 — se il menu è l’unico percorso, è il punto da sistemare.

✅ Fatto quando: lo skip link compare, funziona e porta al contenuto; nessun bersaglio interattivo è sotto i 24×24 pixel.

Blocco E — Contenuti, media e moduli

Cinque controlli sulla parte che non dipende dal tema ma da chi pubblica. Sono anche gli unici che si degradano da soli: un sito corretto oggi torna scorretto fra sei mesi se chi scrive non sa cosa controllare.

15. Ogni immagine ha l’alt giusto — o l’alt vuoto, di proposito

Lo strumento automatico ti dice se l’attributo alt c’è. Non ti dice se dice la cosa giusta, e questa è la parte che conta.

Come si verifica: apri la libreria media ed elenca le immagini usate nelle pagine del campione. Poi giudica ciascuna con una domanda sola: se questa immagine non ci fosse, cosa perderebbe il lettore? Se la risposta è «niente, è decorativa», l’alt deve essere vuoto (alt="") — non assente, non «immagine decorativa»: vuoto, così le tecnologie assistive la saltano. Se l’immagine porta informazione, l’alt la deve contenere. Se è un grafico o uno schema, l’alt non basta e serve la stessa informazione nel testo.

I due errori più frequenti su WordPress sono speculari: il nome del file lasciato come alt (IMG_4471.jpg) e la descrizione che ripete la didascalia già visibile, che a chi ascolta arriva due volte. Un terzo caso da cercare: i loghi cliccabili, dove l’alt deve dire dove porta il link, non descrivere il logo.

Come si corregge: il campo Testo alternativo nelle impostazioni del blocco Immagine. Attenzione: modificarlo nella libreria media cambia il valore predefinito per gli inserimenti futuri, non quelli già pubblicati. Questo è anche uno dei quindici controlli SEO on-page, con lo stesso criterio: descrivere l’immagine, non infilarci parole chiave.

✅ Fatto quando: ogni immagine del campione ha un alt informativo o deliberatamente vuoto, e nessuna contiene il nome del file.

16. Link e pulsanti si capiscono fuori contesto

Gli screen reader permettono di estrarre l’elenco dei link di una pagina e scorrerlo. In quell’elenco, dodici voci che dicono «Leggi tutto» sono dodici voci identiche e inutili.

Come si verifica: l’estensione di analisi ha una vista che elenca i link con il loro testo. Cerca tre cose: testi generici ripetuti («clicca qui», «leggi tutto», «scopri di più»), link diversi con lo stesso testo che portano a destinazioni diverse, e link il cui testo è l’URL nudo — che uno screen reader legge un carattere alla volta.

Come si corregge: nel contenuto, riscrivi l’anchor in modo che dica dove porta. Nei riepiloghi generati dal tema il testo non lo scrivi tu ma il template: il «Leggi tutto» degli archivi si personalizza dove il template genera l’estratto, e nei template di archivio e nel loop è il punto in cui aggiungere il titolo dell’articolo dentro il link, o almeno un’etichetta accessibile. Il modo peggiore di risolvere è aggiungere un title sul link: non lo legge quasi nessuna tecnologia assistiva.

✅ Fatto quando: nell’elenco dei link della pagina ogni voce si capisce da sola, senza il testo attorno.

17. Video e audio hanno sottotitoli o trascrizione

È il controllo più costoso della lista, ed è il motivo per cui va deciso prima di pubblicare contenuti multimediali, non dopo.

Come si verifica: elenca i contenuti audio e video del sito, inclusi quelli incorporati da piattaforme esterne, e verifica per ciascuno: un video con parlato ha bisogno di sottotitoli; un audio da solo ha bisogno di una trascrizione testuale; un video in cui succedono cose importanti che non vengono dette a voce ha bisogno anche di una descrizione audio. I sottotitoli generati automaticamente dalla piattaforma non bastano finché non li hai riletti: sui nomi propri e sui termini tecnici sbagliano quasi sempre.

Come si corregge: la trascrizione è la soluzione più economica e serve a più persone di quante immagini — è anche testo indicizzabile, che un video non è. Pubblicala nella stessa pagina, in un blocco richiudibile se occupa troppo. Per i video incorporati, verifica che il player esposto sia navigabile da tastiera: diversi plugin di galleria video sostituiscono il player nativo con uno che non lo è.

✅ Fatto quando: ogni contenuto audio o video del sito ha la sua alternativa testuale, riletta.

18. Ogni campo ha una label vera, e gli errori dicono cosa fare

I moduli sono il punto in cui l’accessibilità smette di essere un tema astratto: se il modulo di contatto non è utilizzabile, la conseguenza è una richiesta persa, misurabile.

Come si verifica: per ogni campo, clicca sull’etichetta: se il cursore entra nel campo, la <label> è collegata correttamente. Il placeholder non è una label: sparisce appena scrivi, ha contrasto basso e non viene annunciato in modo affidabile. Poi invia il modulo vuoto e guarda gli errori: devono essere associati al campo, raggiungibili da tastiera e devono dire come correggere («Il formato dell’email non è valido, manca la @»), non solo che c’è un errore. Verifica infine che i campi anagrafici abbiano autocomplete, così il browser li può compilare da solo.

Come si corregge: quasi tutti i plugin di moduli generano markup corretto se compili il campo etichetta invece di usare solo il placeholder: nella maggior parte dei casi la correzione è nella configurazione, non nel codice. Attenzione a un punto di attrito reale: i CAPTCHA visivi sono barriere, e le WCAG 2.2 hanno aggiunto un criterio proprio su questo. Se hai bisogno di protezione anti-bot, fra le opzioni di hardening dei moduli conviene scegliere quelle che non chiedono all’utente di risolvere un test.

✅ Fatto quando: ogni campo ha una label collegata, gli errori sono descrittivi e nessun passaggio richiede di superare un test visivo.

19. I documenti allegati fanno parte dell’audit

Il PDF del listino, il modulo da compilare, la brochure: sono contenuti del sito a tutti gli effetti e rientrano negli stessi obblighi, ma nessuno strumento di scansione web li guarda.

Come si verifica: elenca i documenti raggiungibili dalle pagine del campione. Per ciascuno controlla il minimo: che il testo sia selezionabile (una scansione è un’immagine, e per una tecnologia assistiva è una pagina vuota), che ci sia una struttura di titoli e non solo testo formattato in grande, che le immagini abbiano una descrizione e che il documento dichiari la lingua.

Come si corregge: nell’ordine: la soluzione migliore è quasi sempre pubblicare il contenuto come pagina HTML invece che come PDF — costa meno che rendere accessibile il PDF, è indicizzabile e funziona sul telefono. Se il documento deve restare tale, va rifatto dal file sorgente con gli stili di titolo, non ritoccato a valle. Se stai facendo ordine nella libreria media, è il momento giusto: la pulizia dei file caricati e non più usati riduce anche l’elenco dei documenti da verificare.

✅ Fatto quando: ogni documento linkato ha testo selezionabile e struttura, oppure è stato sostituito da una pagina.

Blocco F — Verifica assistiva e livello WordPress

Gli ultimi cinque controlli. I primi due verificano il risultato dal punto di vista di chi usa il sito con una tecnologia assistiva; gli altri tre riguardano il software che genera il markup — cioè il punto in cui, su WordPress, i problemi nascono o si ripetono.

20. Hai percorso una pagina e un modulo con uno screen reader

È il controllo che nessuno fa e quello che cambia il giudizio su tutti gli altri. Non serve saperlo usare bene: bastano venti minuti e la disponibilità a scoprire che una pagina che sembrava a posto non si capisce.

Come si verifica: attiva VoiceOver (⌘ + F5 su macOS) o NVDA su Windows, chiudi gli occhi o spegni il monitor e prova a fare due cose: capire di cosa parla la pagina partendo dall’elenco dei titoli, e compilare e inviare il modulo di contatto. Annota ogni punto in cui ti sei perso, ogni elemento annunciato come «pulsante» senza dire cosa fa, ogni immagine letta come «immagine» e basta.

Come si corregge: quasi tutto quello che trovi qui rimanda a un controllo già fatto — titoli, alt, label, testo dei link. Il valore di questo passaggio è che ti dice quali di quei problemi contano davvero, e in quale ordine risolverli.

✅ Fatto quando: hai completato una pagina e un invio di modulo con lo schermo spento, e hai la lista di dove ti sei bloccato.

21. ARIA compare solo dove il markup nativo non bastava

La prima regola di ARIA è non usare ARIA: un <div role="button"> è sempre peggio di un <button>, e ARIA applicata male peggiora l’esperienza rispetto a non averla affatto, perché sovrascrive quello che il browser avrebbe annunciato correttamente da solo.

Come si verifica: cerca nel sorgente gli attributi role, aria-label e aria-hidden. Per ciascuno chiediti se esiste un elemento HTML che farebbe la stessa cosa senza attributi. I due errori gravi da cercare: aria-hidden="true" su qualcosa che contiene elementi raggiungibili da tastiera (l’utente ci arriva col Tab ma lo screen reader non lo annuncia), e un aria-label che dice una cosa diversa dal testo visibile del pulsante — chi usa il comando vocale pronuncia quello che vede e non succede niente.

Come si corregge: togliere, più che aggiungere. Vale la pena distinguere due cose che spesso si confondono: i dati strutturati schema.org descrivono il contenuto ai motori di ricerca e non hanno alcun effetto sulle tecnologie assistive; ARIA descrive il comportamento dell’interfaccia alle tecnologie assistive e non ha alcun effetto sulla SERP. Sono due strati diversi e non si sostituiscono a vicenda.

✅ Fatto quando: ogni attributo ARIA rimasto ha una ragione che sai spiegare, e nessuno nasconde elementi raggiungibili.

22. Il tema è stato valutato, e sai cosa il tag «accessibility-ready» non garantisce

Il tema decide da solo una buona metà dei controlli di questa checklist: landmark, focus, skip link, contrasto degli stili predefiniti, comportamento del menu. Sceglierlo bene è il singolo intervento con il rapporto migliore fra sforzo e risultato.

Come si verifica: nella directory ufficiale dei temi esiste il filtro accessibility-ready, assegnato dopo una revisione manuale del team Accessibility di WordPress. È un buon punto di partenza, con due avvertenze da tenere a mente. La prima: il tag certifica il tema, non il tuo sito — i contenuti, i plugin e le personalizzazioni restano tuoi. La seconda: i requisiti del tag sono stati irrigiditi nel 2026 (fra le aggiunte: reflow e spaziatura del testo, nessun cambio di contesto inatteso, contenuti su hover accessibili) e i temi hanno tempo fino al 30 giugno 2026 per adeguarsi o rinunciare al tag: un tema che lo espone da anni non è detto soddisfi i requisiti aggiornati.

Come si corregge: se stai partendo da zero, scegli dentro quel filtro e verifica comunque i controlli 11-14 sulla demo prima di adottarlo. Se il tema è già in produzione e fallisce su poche cose, correggere è più economico di migrare. Se lo scrivi tu, questi requisiti si mettono in piedi all’inizio e costano quasi niente: skip link, landmark e focus visibile si scrivono nel tema fin dai primi file e non si toccano più.

✅ Fatto quando: sai se il tuo tema espone il tag, quando è stato aggiornato l’ultima volta e quali controlli di questa lista fallisce.

23. Sai quali plugin generano il markup che stai correggendo

Su un sito WordPress il markup non lo scrive solo il tema: lo scrivono anche il costruttore di pagine, il plugin dei moduli, la galleria, il banner dei cookie, il cursore in home. Correggere il sintomo dentro il contenuto senza sapere chi lo genera significa rifare lo stesso lavoro al prossimo aggiornamento.

Come si verifica: prendi le violazioni raggruppate al controllo 4 e risali all’origine di ciascuna ispezionando l’elemento: il nome della classe CSS o del wrapper quasi sempre contiene il nome del plugin. Fai poi la prova che chiude il discorso: disattiva il plugin sospetto in staging e riscansiona.

Come si corregge: nell’ordine — impostazioni del plugin (spesso l’opzione c’è), poi correzione via CSS o filtro se il markup è recuperabile, poi sostituzione. Quando valuti un’alternativa, i criteri sono gli stessi con cui si valuta un plugin prima di installarlo: data dell’ultimo aggiornamento, manutentore, risposte nel forum di supporto. Un plugin abbandonato non riceverà mai le correzioni di accessibilità che gli mancano.

✅ Fatto quando: ogni violazione ricorrente ha un responsabile noto — tema, un plugin preciso, o il contenuto.

24. La dichiarazione di accessibilità è pubblicata e il prossimo audit ha una data

Un audit senza una data di ripetizione è una fotografia. Il sito cambia ogni settimana, e ogni articolo pubblicato può reintrodurre un problema che avevi risolto.

Come si verifica: se rientri fra i soggetti obbligati (controllo 1), la dichiarazione di accessibilità va redatta secondo il modello AgID, pubblicata in un punto raggiungibile dal sito e aggiornata entro il 23 settembre di ogni anno. Deve dichiarare il livello di conformità reale — conforme, parzialmente conforme, non conforme — e indicare i contenuti non accessibili con la motivazione: una dichiarazione che afferma una conformità che il sito non ha è peggio dell’assenza della dichiarazione.

Come si corregge: anche se non sei obbligato, tieni traccia dell’audit: la lista dei 24 controlli con esito e data, il campione di URL congelato, i punti rimasti aperti. Poi fissa il prossimo giro. La frequenza sensata è annuale, con un controllo rapido dopo tre eventi: cambio di tema, aggiunta di un plugin che genera markup, rifacimento di un modulo. È lo stesso principio della manutenzione ricorrente di un sito WordPress, e conviene mettere l’accessibilità nella stessa agenda invece di trattarla come un progetto una tantum.

✅ Fatto quando: l’esito dell’audit è scritto da qualche parte e il prossimo controllo ha una data in calendario.

Il widget di accessibilità: perché non chiude l’audit

Prima o poi, facendo questo lavoro, incontri l’offerta che promette di saltarlo: una riga di JavaScript da incollare nel sito, un pannellino con i comandi per ingrandire il testo e aumentare il contrasto, e la conformità che arriva da sola. Vale la pena spiegare perché non funziona, perché è la domanda più frequente che ricevo sull’argomento.

Una premessa onesta: una versione precedente di questo articolo consigliava un widget di questo tipo come strumento principale per l’accessibilità di un sito WordPress. Era un consiglio sbagliato, e lo correggo qui invece di limitarmi a toglierlo.

Il problema è nel meccanismo, non nel fornitore. Un overlay è uno script che gira dopo che la pagina è stata costruita e prova a rimediare a valle. Può fare bene alcune cose che dipendono dalle preferenze dell’utente — ingrandire il testo, cambiare i colori, evidenziare i link. Non può fare le altre: non sa quale sia l’alt giusto per una fotografia, non può riordinare il flusso di lettura di un layout costruito male, non può trasformare un <div> in un pulsante che si comporta da pulsante, e non può riscrivere il messaggio di errore di un modulo perché spieghi cosa correggere. Sono esattamente i controlli 11-20 di questa checklist, cioè la maggior parte del lavoro.

C’è di più: chi già usa una tecnologia assistiva ha il proprio strumento configurato come vuole, e un overlay che interviene sulla pagina può entrarci in conflitto. Nelle rilevazioni condotte fra utenti di screen reader la valutazione di questi strumenti è in larga maggioranza negativa, e l’Overlay Fact Sheet — il documento sottoscritto da diverse centinaia di professionisti del settore — nasce proprio da lì.

La questione non è più solo tecnica. Nel gennaio 2025 la Federal Trade Commission statunitense ha chiuso con una sanzione da un milione di dollari il procedimento contro un fornitore di questi widget, contestando proprio la promessa che il prodotto rendesse automaticamente un sito conforme alle WCAG 2.1 AA. L’ordine finale gli vieta di ripetere quella affermazione senza prove a supporto. È il motivo per cui oggi i fornitori seri, nelle proprie condizioni, scrivono che il widget non garantisce la conformità: leggerle prima di firmare è un buon esercizio.

La conclusione operativa è semplice. Un widget può stare su un sito come comodità aggiuntiva, dopo che i 24 controlli sono passati. Non può sostituirli, non copre gli obblighi normativi del controllo 1, e installarlo al posto dell’audit lascia il sito nello stesso stato di prima con in più una riga di JavaScript e una fattura.

I 24 controlli in breve

Il riepilogo da tenere aperto mentre lavori. La colonna «Dove si corregge» dice se l’intervento è sul contenuto, sul tema o su un plugin: è l’informazione che decide chi deve metterci mano.

Quali strumenti coprono quali controlli

Sono tutti gratuiti e ne servono quattro. Nessuno di questi strumenti «fa l’audit»: il più completo dei quattro copre da solo meno di un terzo dei controlli, ed è il motivo per cui la colonna più affollata è l’ultima.

Domande frequenti

Da qui in avanti

L’accessibilità non è uno stato che raggiungi e poi mantieni: è una proprietà che si consuma. Ogni articolo pubblicato può portare un’immagine senza alt, ogni plugin aggiunto può iniettare markup che nessuno ha guardato, ogni restyling può cancellare il focus visibile per motivi estetici. Per questo i controlli 15-19 vanno consegnati a chi scrive, non tenuti in un audit, e gli altri vanno ripercorsi con una cadenza — la stessa in cui rientrano gli altri controlli periodici su un sito WordPress.

Il primo blocco da cui ripartire è quasi sempre il D: testare e correggere la navigazione da tastiera risolve da solo la quota più grossa delle barriere reali, e non richiede di toccare il contenuto. Vale la pena leggerlo anche se il tuo audit sul blocco D è passato: contiene il test manuale nel dettaglio e le correzioni per i componenti costruiti male.

Se questo formato ti è utile, applico lo stesso metodo — controlli indipendenti, verificabili uno per uno — al posizionamento nella checklist SEO on-page per WordPress e alla protezione del sito nella checklist di sicurezza WordPress. Diversi controlli si sovrappongono: la gerarchia dei titoli, il testo dei link e il peso delle immagini valgono per tutte e tre.

Un’ultima nota sul contesto: il lavoro sull’accessibilità dell’editor a blocchi va avanti a ogni rilascio, e diverse cose che qui vanno corrette a mano sono migliorate da sole nelle versioni recenti. WordPress 7.1, per dire, ha aggiunto al core due funzioni per i tooltip accessibili e ha migliorato il supporto agli screen reader nelle tabelle di elenco dei post; la 6.9 aveva portato oltre trenta correzioni di accessibilità e la 6.7 altre sessantacinque. Cosa ha portato ogni release di WordPress è il modo più rapido per sapere se un problema che stai per correggere a mano è già stato risolto a monte.

Se preferisci che questi ventiquattro controlli li faccia io sul tuo sito — audit completo sul campione, correzione di quello che non passa e consegna del documento con gli esiti — scrivimi e ne parliamo.