Tema WordPress Accessibility: Checklist Prima dell’Acquisto

Perché l’accessibilità del tema è fondamentale

Nel 2026, l’accessibilità web non è più opzionale. Con l’European Accessibility Act in vigore e normative sempre più stringenti, scegliere un tema WordPress inaccessibile significa partire con un debito tecnico che costerà caro ai tuoi clienti.

Un tema accessibile non è solo una questione di conformità legale: significa raggiungere il 15-20% di utenti con disabilità permanenti o temporanee, migliorare la SEO (Google premia i siti accessibili dal 2023), e ridurre i costi di manutenzione. Un tema costruito male richiederà interventi custom costosi, mentre uno accessibility-ready ti fa risparmiare decine di ore di sviluppo.

Come agenzia, la scelta del tema è il primo punto critico. Un errore qui si ripercuote su tutti i progetti futuri che useranno quel tema. Questa checklist tecnica ti permette di valutare oggettivamente l’accessibilità prima di investire tempo e denaro.

Standard di riferimento: WCAG 2.2

Le Web Content Accessibility Guidelines (WCAG) 2.2, pubblicate nel 2023, sono lo standard de facto per l’accessibilità web. I temi WordPress dovrebbero mirare almeno al livello AA, che copre la maggior parte dei requisiti legali europei e italiani.

Le WCAG si articolano su quattro principi fondamentali:

• Percepibile: le informazioni devono essere presentabili agli utenti in modi che possano percepire (testo alternativo per immagini, contrasti sufficienti, contenuti non solo visivi)
• Utilizzabile: i componenti dell’interfaccia devono essere operabili (navigazione da tastiera, tempo sufficiente per leggere, nessun contenuto che causa convulsioni)
• Comprensibile: le informazioni e l’interfaccia devono essere comprensibili (testo leggibile, comportamento prevedibile, assistenza nell’input)
• Robusto: il contenuto deve essere interpretabile da un’ampia varietà di user agent, incluse le tecnologie assistive (markup valido, ARIA quando necessario)

I livelli di conformità sono tre:

• A: requisiti minimi, rimuove le barriere più gravi
• AA: standard target per la maggior parte dei siti, richiesto dalla legge in molti paesi (livello minimo per enti pubblici in Italia)
• AAA: massimo livello, difficile da raggiungere per tutti i contenuti

Un tema WordPress serio dovrebbe dichiarare esplicitamente il livello WCAG supportato. Diffida di temi che parlano genericamente di “accessibilità” senza riferimenti precisi agli standard.

Controlli preliminari sulla documentazione

Prima ancora di installare il tema in un ambiente di test, esamina la documentazione e la pagina di vendita. Questi elementi ti danno indicazioni immediate sulla serietà dell’approccio all’accessibilità:

Dichiarazioni di conformità

Cerca una dichiarazione esplicita di conformità WCAG. Un buon tema specifica:

• Livello WCAG raggiunto (es. “WCAG 2.2 Level AA compliant”)
• Data dell’ultimo audit di accessibilità
• Eventuali eccezioni o limitazioni note
• Strumenti utilizzati per il testing (es. “testato con NVDA, JAWS, VoiceOver”)

I temi nel repository ufficiale di WordPress possono avere il tag “accessibility-ready”, ma questo non garantisce conformità totale WCAG 2.2. È un punto di partenza, non un certificato.

Documentazione tecnica

La documentazione dovrebbe includere:

• Sezione dedicata all’accessibilità con best practice per gli utenti
• Indicazioni su come mantenere l’accessibilità quando si personalizza il tema
• Liste di plugin testati per compatibilità con tecnologie assistive
• Shortcode o builder page compatibili

Se la documentazione non menziona mai l’accessibilità, è un red flag immediato. L’accessibilità deve essere considerata dal primo giorno di sviluppo, non aggiunta dopo.

Changelog e aggiornamenti

Verifica il changelog delle ultime versioni. Un tema attivamente mantenuto dovrebbe includere fix di accessibilità nei changelog:

• Correzioni di contrasti
• Miglioramenti alla navigazione da tastiera
• Aggiornamenti degli attributi ARIA
• Compatibilità con nuove versioni di screen reader

Un tema fermo da più di 12 mesi è problematico sia per sicurezza che per accessibilità, dato che gli standard e le tecnologie assistive evolvono continuamente.

Test tecnici da eseguire prima dell’acquisto

Se possibile, installa il tema in un ambiente di staging o usa la demo live fornita dal vendor. Esegui questi test tecnici specifici.

Validazione HTML e semantica

Un markup valido è la base dell’accessibilità. Usa il validator W3C (validator.w3.org) sulla demo del tema:

• Zero errori di validazione HTML5 è l’ideale, pochi warning accettabili
• Controlla che gli elementi semantici siano usati correttamente: <header>, <nav>, <main>, <article>, <aside>, <footer>
• Verifica la gerarchia dei titoli: un solo <h1> per pagina, ordine logico senza salti (h1 → h2 → h3, mai h1 → h3)
• Gli elenchi devono usare <ul>, <ol>, non div stilizzati

Usa l’estensione HeadingsMap per Chrome/Firefox per visualizzare rapidamente la struttura dei titoli. Una buona architettura dei titoli è essenziale per gli screen reader.

Contrasto colori

Il contrasto insufficiente è tra i problemi di accessibilità più comuni. WCAG 2.2 Level AA richiede:

• Rapporto minimo 4.5:1 per testo normale (sotto 18pt o 14pt bold)
• Rapporto minimo 3:1 per testo grande (18pt+ o 14pt+ bold)
• Rapporto minimo 3:1 per componenti UI e grafici

Strumenti per testare:

• WebAIM Contrast Checker: tool online rapido per verifiche spot
• Colour Contrast Analyser: app desktop per controlli approfonditi
• axe DevTools: estensione browser che scansiona automaticamente tutta la pagina

Testa il contrasto su tutti gli stati degli elementi: default, hover, focus, active. Molti temi falliscono sul contrasto dei link o dei pulsanti in stato hover.

Verifica anche le modalità alternative se il tema le offre (dark mode): devono mantenere contrasti adeguati.

Navigazione da tastiera

Disconnetti il mouse e naviga il sito usando solo la tastiera:

• Tab: deve navigare tutti gli elementi interattivi in ordine logico
• Shift+Tab: navigazione all’indietro
• Enter: attiva link e pulsanti
• Spazio: attiva pulsanti, scrolla pagina
• Esc: chiude modali e menu
• Frecce: navigano all’interno di widget complessi (menu, tab, slider)

Controlli specifici:

• Il focus indicator è sempre visibile e distinguibile (non outline: none senza alternativa)
• L’ordine di tabulazione segue l’ordine visivo e logico del contenuto
• Non ci sono trappole da tastiera (focus bloccato in un elemento)
• Menu dropdown e megamenu sono navigabili da tastiera
• Modali e overlay possono essere chiusi con Esc
• Skip link funzionante (“Salta al contenuto principale”) visibile al primo Tab

Un tema accessibility-ready include sempre uno skip link ben implementato, con focus management corretto.

Test con screen reader

Non serve essere esperti di screen reader per fare test base. Installa NVDA (Windows, gratuito) o usa VoiceOver (macOS, integrato) e verifica:

• Tutti gli elementi interattivi sono annunciati correttamente con il loro ruolo
• Le immagini hanno attributi alt significativi (non “image123.jpg”)
• Le immagini decorative hanno alt vuoto (alt="") o sono CSS background
• I form hanno label associate correttamente, non placeholder come unica indicazione
• Messaggi di errore e successo nei form sono annunciati
• I landmark ARIA sono presenti e corretti (role="navigation", role="main", ecc.)
• Il contenuto dinamico che cambia (es. risultati ricerca live) usa ARIA live regions

Focus particolare sui componenti JavaScript: slider, carousel, accordion, tab. Questi sono spesso inaccessibili nei temi commerciali. Devono avere:

• Attributi ARIA corretti (aria-expanded, aria-hidden, aria-selected)
• Gestione tastiera completa
• Focus management quando il contenuto cambia

Test automatici

Gli strumenti automatici catturano circa il 30-40% dei problemi di accessibilità, ma sono veloci e riproducibili:

• axe DevTools: estensione browser, trova problemi comuni con spiegazioni chiare
• WAVE: tool visivo che evidenzia problemi direttamente sulla pagina
• Lighthouse: integrato in Chrome DevTools, include sezione Accessibility
• pa11y: strumento CLI per test automatici ripetibili, utile per CI/CD

Esegui questi test su almeno 5 pagine tipo:

• Homepage
• Pagina interna con contenuto testuale
• Pagina archivio (blog, portfolio)
• Pagina singola post/progetto
• Pagina con form contatti

Zero errori critici è il requisito minimo. Warning vanno valutati caso per caso, ma non devono essere più di una manciata per pagina.

Controllo componenti critici

Alcuni componenti ricorrono in quasi tutti i temi e sono spesso fonte di problemi. Controlla specificamente questi elementi.

Menu di navigazione

Il menu principale deve essere accessibile sia da mouse che da tastiera e screen reader:

• Tag <nav> con aria-label descrittivo se ci sono più menu
• Submenu navigabili da tastiera (frecce o Tab, dipende dal pattern)
• Indicatori visivi e ARIA per voci con submenu (aria-haspopup="true", aria-expanded)
• Menu mobile con hamburger button accessibile (ruolo button, stato expanded/collapsed)
• Menu mobile implementato con aria-hidden quando chiuso, non solo display: none

Molti temi usano JavaScript complesso per i menu. Verifica che funzioni con JS disabilitato (fallback CSS) o almeno che sia robusto agli errori.

Form di contatto e ricerca

I form sono interazioni critiche, devono essere completamente accessibili:

• Ogni input ha <label> associato con attributo for, non solo placeholder
• Campi obbligatori indicati con required e aria-required="true"
• Messaggi di errore associati al campo con aria-describedby
• Focus automatico sul primo errore dopo submit fallito
• Pulsanti di submit con testo chiaro, non solo icone
• Validazione client-side accessibile (errori annunciati)

Il form di ricerca deve avere role="search" sul contenitore e label visibile o aria-label sul campo input.

Slider e carousel

Gli slider sono notoriamente problematici per l’accessibilità. Un buon slider deve avere:

• Controlli play/pause facilmente accessibili
• Pausa automatica quando utente naviga da tastiera
• Indicatori di slide corrente accessibili (non solo pallini colorati)
• Navigazione da tastiera tra le slide
• Annuncio vocale del cambio slide per screen reader (ARIA live region)
• Rispetto di prefers-reduced-motion per utenti con disturbi vestibolari

Meglio ancora: verifica se il tema permette di disabilitare lo slider e usare un layout statico. Non tutti i contenuti devono essere in carousel.

Immagini e media

Il tema deve gestire correttamente gli attributi di accessibilità per media:

• Campo alt text obbligatorio nel media manager (non saltabile)
• Supporto per figcaption accessibile con tag <figure>
• Video con controlli accessibili e supporto per sottotitoli/trascrizioni
• Audio con trascrizioni disponibili
• Icone decorative (social icons, etc.) con aria-hidden="true"

Per le immagini responsive, verifica che il tema usi correttamente srcset senza compromettere l’attributo alt.

Tabelle

Se il tema include stili per tabelle, devono essere accessibili:

• Uso di <th> per header con scope="col" o scope="row"
• Caption descrittivo con <caption>
• Struttura semplice (no celle unite complesse)
• Responsive con tecniche accessibili (no scroll orizzontale infinito)

Molti page builder generano tabelle inaccessibili. Se il tema si integra con builder, testa anche quelli.

Compatibilità con plugin essenziali

Un tema WordPress raramente vive da solo. Verifica la compatibilità dichiarata con plugin fondamentali, prestando attenzione all’accessibilità:

Page builder

Se il tema funziona con Elementor, WPBakery, Gutenberg o altri builder:

• I widget/blocchi custom del tema sono accessibili
• La documentazione spiega come mantenere l’accessibilità usando il builder
• Sono disponibili controlli per alt text, ARIA labels, heading levels

Gutenberg è generalmente più accessibile dei builder drag-and-drop. Se hai clienti con requisiti di accessibilità stringenti, preferisci temi Gutenberg-first.

WooCommerce

Per temi e-commerce, l’accessibilità è critica (escludere utenti = perdere vendite):

• Form checkout completamente accessibili
• Filtri prodotti navigabili da tastiera
• Immagini prodotto con alt text gestibili
• Messaggi carrello e checkout annunciati correttamente
• Processo di pagamento senza trappole da tastiera

WooCommerce stesso ha migliorato molto l’accessibilità dalla versione 6.0 (2022), ma i temi possono sovrascrivere template in modo inaccessibile. Testa sempre il flow completo.

Plugin multilingual

WPML, Polylang e simili richiedono attributi specifici per l’accessibilità:

• Attributo lang corretto su <html> per ogni lingua
• Cambio lingua accessibile da tastiera
• Annuncio della lingua corrente per screen reader

Performance e accessibilità

Performance e accessibilità sono correlate. Un sito lento è inaccessibile per utenti con connessioni limitate o dispositivi datati:

• Core Web Vitals: LCP sotto 2.5s, FID sotto 100ms, CLS sotto 0.1
• Peso pagina: homepage sotto 2MB è un buon target
• JavaScript: il tema funziona con JS disabilitato o degrada gracefully?
• Font web: usa font-display: swap per evitare FOIT (Flash Of Invisible Text)

Testa con Lighthouse e WebPageTest. Un tema con performance scarse richiederà ottimizzazioni extra, aumentando i costi.

Verifica supporto e community

Anche il miglior tema avrà problemi di accessibilità da fixare nel tempo. Valuta:

• Supporto dedicato: il vendor risponde a richieste di fix per accessibilità?
• Community: ci sono discussioni attive su accessibilità nei forum?
• Tempistiche: quanto velocemente vengono corretti i bug segnalati?
• Expertise: il team di sviluppo ha competenze dimostrabili su accessibilità?

Cerca nel supporto parole chiave come “WCAG”, “screen reader”, “keyboard navigation”. Se non trovi discussioni, o il tema è perfetto (improbabile) o nessuno si preoccupa di accessibilità (probabile).

Red flags da evitare

Alcuni segnali indicano che il tema avrà problemi di accessibilità seri:

• Uso eccessivo di div e span invece di HTML semantico
• outline: none senza stili alternativi per focus
• JavaScript che manipola DOM senza aggiornare ARIA
• Attributi ARIA usati a caso (peggio che non usarli)
• Immagini di testo invece di testo vero
• Contenuto che appare solo hover (no focus alternativo)
• CAPTCHA inaccessibili senza alternative
• Autoplay video/audio senza controlli immediati
• Animazioni aggressive senza rispetto prefers-reduced-motion
• Popup e modali che appaiono senza interazione utente

Se trovi più di 2-3 di questi problemi nella demo, passa oltre. Correggerli costerà più che partire da un tema migliore.

Casi d’uso specifici per agenzie

Siti enti pubblici

Per PA italiana, i requisiti sono stringenti (Legge Stanca, AgID):

• WCAG 2.1 Level AA minimo (meglio 2.2)
• Dichiarazione di accessibilità obbligatoria
• Audit periodici richiesti

Usa solo temi con track record dimostrato su progetti PA. Il repository WordPress.org con tag “accessibility-ready” è un buon punto di partenza, ma verifica comunque.

E-commerce medio-grande

L’accessibilità in e-commerce impatta direttamente conversion rate:

• Focus su form checkout e navigazione prodotti
• Compatibilità con screen reader testata su flow completo acquisto
• Filtri e ordinamenti accessibili da tastiera

Considera che il 71% degli utenti con disabilità abbandona siti inaccessibili (studio WebAIM 2023). È ROI diretto.

Siti corporate e portfolio

Anche se non obbligatorio per legge, l’accessibilità è brand reputation:

• Clienti enterprise richiedono sempre più accessibilità nei vendor
• Portfolio inaccessibile esclude potenziali clienti
• SEO migliorato con markup accessibile

Checklist finale prima dell’acquisto

Riassumendo, prima di acquistare un tema verifica che:

1. Dichiari esplicitamente conformità WCAG 2.2 Level AA (o almeno 2.1)
2. Passi validazione HTML5 senza errori critici
3. Abbia contrasti colore sufficienti su tutti gli elementi (4.5:1 minimo)
4. Sia completamente navigabile da tastiera con focus visibile
5. Funzioni correttamente con almeno uno screen reader (NVDA o VoiceOver)
6. Non produca errori in axe DevTools o altri tool automatici
7. Abbia documentazione dedicata all’accessibilità
8. Sia aggiornato regolarmente con fix di accessibilità nel changelog
9. Abbia supporto responsive che non comprometta accessibilità
10. Rispetti prefers-reduced-motion e altre preferenze utente

Salva questa checklist e applicala sistematicamente. Ti farà risparmiare settimane di refactoring e possibili contestazioni legali per i tuoi clienti.

Strumenti e risorse

Risorse utili per approfondire e testare:

• WCAG 2.2 Spec: w3.org/WAI/WCAG22/quickref/ – guida interattiva completa
• WordPress Accessibility Handbook: make.wordpress.org/accessibility/handbook/
• WebAIM: webaim.org – articoli, guide, tool di testing
• A11y Project: a11yproject.com – checklist e pattern accessibili
• Deque University: dequeuniversity.com – corsi (alcuni gratuiti)

Tool essenziali per il tuo workflow:

• axe DevTools: estensione browser (versione free sufficiente)
• WAVE: estensione browser, molto visuale
• HeadingsMap: visualizza gerarchia heading
• Colour Contrast Analyser: desktop app per contrasti
• NVDA: screen reader Windows gratuito
• Pa11y CI: per integrare test accessibilità in pipeline

Se gestisci molti siti client, considera un piano AgencyPilot per monitorare problemi di accessibilità su tutti i siti da un’unica dashboard, con alert automatici quando aggiornamenti temi introducono regressioni.

FAQ

Un tema “accessibility-ready” nel repository WordPress è sempre conforme WCAG?

No. Il tag “accessibility-ready” nel repository WordPress.org indica che il tema ha passato una review di accessibilità di base, ma non garantisce conformità completa WCAG 2.2 Level AA. È un buon punto di partenza, ma devi comunque testare il tema specificamente per i tuoi requisiti. Il tag copre principalmente: navigazione da tastiera, skip links, gerarchia heading, contrasti di base. Non copre necessariamente tutti i criteri WCAG, specialmente per componenti JavaScript complessi o integrazioni con plugin.

È possibile rendere accessibile un tema che nasce inaccessibile?

Tecnicamente sì, ma raramente è economicamente sensato. Correggere un tema con problemi strutturali di accessibilità (HTML non semantico, JavaScript inaccessibile, mancanza di ARIA) può richiedere decine di ore di sviluppo. Questi fix vanno poi mantenuti ad ogni aggiornamento del tema, creando debito tecnico permanente. È sempre più conveniente investire qualche ora in più nella scelta iniziale di un tema ben costruito. Eccezione: se hai già molti siti su quel tema, un child theme con fix centralizzati può avere senso, ma valuta bene il ROI.

I page builder come Elementor sono compatibili con l’accessibilità?

Dipende molto dall’implementazione. Elementor ha migliorato significativamente l’accessibilità dalla versione 3.0 (2020), aggiungendo controlli per heading level, alt text, ARIA labels. Tuttavia, molti widget e template di terze parti restano inaccessibili. Gutenberg (l’editor a blocchi nativo di WordPress) è generalmente più accessibile per design, avendo l’accessibilità come requisito core dal progetto. Se l’accessibilità è prioritaria, preferisci temi Gutenberg-first o, se usi Elementor, testa approfonditamente ogni widget che intendi usare e fornisci ai clienti linee guida chiare su come mantenere l’accessibilità.

Quanto incide l’accessibilità sulla SEO nel 2026?

Molto. Dal 2023 Google considera fattori di accessibilità come segnali di ranking diretto: gerarchia heading corretta, markup semantico, contrasti sufficienti (impattano Core Web Vitals), e mobile usability sono tutti fattori confermati. Inoltre, HTML accessibile è più facilmente interpretabile dai crawler, migliorando la comprensione del contenuto. Studi del 2025 mostrano che siti WCAG AA conformi hanno in media un 12% di traffico organico in più rispetto a competitor non accessibili, a parità di altri fattori. Non è il fattore principale, ma è un vantaggio competitivo reale e misurabile.

Come gestire richieste di accessibilità da clienti che non vogliono investire budget?

L’accessibilità deve essere parte del preventivo base, non un extra. Comunicalo chiaramente: “Il sito sarà conforme agli standard di accessibilità WCAG 2.1 Level AA”. Se il cliente chiede di rimuovere questa voce per ridurre costi, spiega i rischi concreti: esposizione legale (multe fino a 5000€ per PA in Italia, cause civili per privati), esclusione di 15-20% di potenziali utenti, penalizzazioni SEO, danneggiamento reputazione. Mostra casi studio di aziende multate o finite sui giornali per siti inaccessibili. Se il cliente insiste, valuta se vuoi il rischio reputazionale di associare il tuo nome a un sito non conforme. Nel 2026, costruire siti intenzionalmente inaccessibili è come costruirli senza HTTPS: tecnicamente possibile, professionalmente discutibile.