Due settimane fa un cliente mi ha mandato il tema che aveva appena comprato: 900€, agenzia seria, demo bellissima. Al primo test con la tastiera da sola il menu si è rivelato una trappola: il focus spariva, i sottomenù non si aprivano, e lo skimmer di PayPal restava fuori portata a chi naviga con lo screen reader. Quattordici problemi numerati dopo l'audit, nove sistemabili in un pomeriggio. La sensazione che ho provato è la stessa che racconta Jessica Lyschik nel suo intervento a WordCamp Europe 2026, ripreso nell'episodio 226 del podcast di WP Tavern: l'accessibilità nei temi WordPress fa paura da lontano e si smonta facilmente da vicino. In questa guida la smonto io, con la checklist che uso in audit e la mia opinione su dove conviene investire il tempo.
Contenuto articolo
Perché il tema è il posto giusto per iniziare
Il tema decide la struttura: heading, markup dei menu, contrasto di default, markup dei form. Se la base è solida, plugin e contenuti si innestano su fondamenta accessibili. Se la base è fragile, ogni pagina del sito nasce sbagliata e voi lo scoprite quando il cliente riceve la prima segnalazione — o peggio, quando arriva una causa ADA, negli Stati Uniti una realtà concreta per chi vende lì. Jessica lo dice chiaramente nel podcast: i requisiti delle linee guida WordPress sembrano un muro, ma i frutti più bassi si colgono con sforzo contenuto, sia nei temi classici che nei block theme.
L'argomento economico vale più di quello etico, purtroppo, e lo uso in negoziazione: sistemare l'accessibilità a tema finito costa tre o quattro volte rispetto a farlo nascere accessibile. Retrofit su ventidue template o cura al momento della scrittura: la seconda strada è più corta, sempre.
La checklist che porta all'80%
Questi sono gli otto punti che controllo in ogni audit, in ordine di impatto. Non è una lista simmetrica da manuale: i primi tre coprono la maggior parte dei problemi che incontro davvero.
- Navigazione da tastiera: tab attraverso header, menu, footer. Se il focus scompare o l'ordine è caotico, è la prima cosa da sistemare. Il menu mobile e gli accordion sono i candidati classici.
- Skip to content: un link «salta al contenuto» come primo elemento cliccabile. Mezz'ora di lavoro, beneficio immediato per chi usa lo screen reader su ogni pagina.
- HTML semantico e heading in ordine: un solo H1, H2 e H3 che raccontano la pagina, nav/main/footer come tag e non come div. Il tema li eredita: se li sbaglia, correggere i template.
- Contrasto reale: 4.5:1 per il testo normale, 3:1 per i titoli grandi. I grigi eleganti su bianco sono il vizio più diffuso nei temi premium; misurare, non fidarsi dell'occhio.
- Alt text sulle immagini: il tema deve dare il campo e i contenuti devono riempirlo. Se la media gallery è piena di alt vuoti, parte un lavoro di contenuto a parte.
- Stati di focus visibili: outline personalizzati o di default, mai `outline: none` senza alternativa. Chi naviga da tastiera deve sempre vedere dov'è.
- Form con etichette e messaggi d'errore leggibili: label associati, errori annunciati, niente placeholder usati al posto dell'etichetta. Checkout e form di contatto prima di tutto.
- Aria dove serve, solo dove serve: ARIA corretto sui componenti interattivi custom. ARIA sparso ovunque peggiora le cose: prima il markup nativo, poi ARIA.
Nei block theme una fetta di questo lavoro arriva gratis: il markup dei blocchi core è semantico e testato, e la responsabilità scivola verso chi compone le pagine. È il motivo per cui su progetti nuovi spingo verso i block theme anche per questioni di accessibilità, non solo per il futuro dell'editor.
Il test automatico da 5 minuti
Prima di qualsiasi audit manuale, faccio girare axe-core su tre pagine campione: home, un articolo, una pagina con form. Non sostituisce l'audit umano — becca in genere un terzo dei problemi — ma è gratis e mette in fila le cose evidenti:
# test automatico accessibilità su una pagina live: lista violazioni con gravità
npx @axe-core/cli https://www.mrtux.it/assistenza-wordpress --exitPoi il test che nessun tool automatico fa per voi: staccate il mouse e navigate la home con la tastiera, finendo fino al footer. Dieci minuti che valgono più di tre report PDF. E chi vuole spingersi oltre trova in questo sito una guida completa sugli audit automatici WCAG con l'AI.
Il caso del tema da 900€, con i numeri
Torniamo all'apertura perché i numeri raccontano meglio della teoria. L'audit del tema premium ha prodotto quattordici problemi: nove risolti in un pomeriggio (focus visibili, skip link, alt mancanti, ordine heading, due contrasti), tre richiesti mezza giornata di sviluppo (menu keyboard-accessible, aria sugli accordion, form di checkout), due erano decisioni di design da negoziare con chi aveva scelto il grigio elegante. Risultato: i percorsi critici — menu, form, checkout — reggono il livello WCAG AA, zero euro di licenze nuove, e i ticket di supporto sono calati da subito perché anche l'usabilità generale ha beneficiato. Il tema non l'ho cambiato: l'ho sistemato. Teme premium e accessibilità non sono nemici, solo richiedono l'audit che il vendor non include.
Block theme o classic: cambia qualcosa per l'accessibilità?
La domanda arriva in ogni audit, e la risposta di Jessica nel podcast coincide con quella che do io: dipende, ma nei block theme una fetta del lavoro arriva gratis. Il markup dei blocchi core — navigazione, immagini, quote — è semantico, testato dalla community e aggiornato con le release. In un classic theme la stessa struttura dipende da come il vendor ha scritto i template PHP, e lì le qualità variano molto di più da tema a tema. In compenso un classic ben fatto con hook e markup pulito resta perfettamente accessibile: non è una guerra di religioni, è una questione di base di partenza. Nei progetti nuovi parto dai block theme proprio per questo, oltre che per la longevità: ereditate markup corretto di default, e i vostri errori si concentrano sui contenuti, non sull'ossatura.
L'eccezione da conoscere è la navigazione: il blocco navigation core è migliorato molto, ma i menu complessi con mega-dropdown restano più semplici da gestire in un classic theme con un JS controllato. Se il vostro progetto ha una navigazione complessa, verificate quel componente per primo, qualunque sia il tipo di tema.
Dove l'AI aiuta davvero (e dove no)
Nell'intervista Jessica nota un punto che condivido: gli agenti AI stanno mettendo l'accessibilità sotto i riflettori, perché la query «controlla l'accessibilità del mio tema» ora produce report concreti in pochi minuti. Li uso nei miei audit come prima passata. Ma il limite rimane: un agente vede il markup, non vede il focus che sparisce a metà animazione, né il contrasto che cambia allo scroll, né l'esperienza di chi naviga con lo screen reader a una mano. Automazione per il volume, umano per il giudizio: è l'unica combinazione che ho visto reggere. Se volete vedere il metodo per esteso, l'audit AI dei template è raccontato passo passo nell'articolo già citato.
Che cosa fare questa settimana
Se gestite un sito per conto di qualcuno — il vostro o di un cliente — la sequenza è questa: test axe sulle tre pagine chiave, navigazione da tastiera completa, correzione dei frutti bassi, audit approfondito solo se emergono problemi strutturali. Chi non ha tempo o team interno può appoggiarsi a chi lo fa per mestiere: il servizio di assistenza WordPress include l'audit periodico e le correzioni, e la routine di manutenzione mensile tiene sotto controllo gli aggiornamenti che altrimenti rompono quanto sistemato. La scusa «il tema è nuovo, sicuramente accessibile» ho smesso di sentirla come risposta: dopo il tema da 900€, verifico sempre.
Lascia un commento