♿ Accessibilità dei siti web WordPress: una guida completa 2026

Quando un utente non riesce a leggere il testo, cliccare un pulsante o semplicemente capire dove porta un link, se ne va. Non perché il contenuto sia scadente. Perché il sito non gli parla.

Da giugno 2025, l'European Accessibility Act (EAA) è diventato obbligatorio. In Germania, il suo corrispettivo nazionale è il Barrierefreiheitsstärkungsgesetz (BFSG). Multe, ordini di conformità, pubblico perso. Ma dietro la pressione legale c'è una verità semplice: secondo l'OMS, circa il 16% della popolazione mondiale, una persona su sei, convive con una qualche forma di disabilità. Ignorarle significa perdere un visitatore su sei.

WordPress non è né un'eccezione né una condanna a morte in questo contesto. Il CMS fornisce una base solida, ma l'accessibilità reale è il risultato di azioni deliberate da parte dello sviluppatore o del proprietario del sito. Questa guida è un'analisi passo dopo passo: dalla struttura delle intestazioni alla navigazione da tastiera, dalla scelta del tema ai controlli automatizzati. Niente fronzoli, solo ciò che puoi applicare da oggi. 💡 Panoramica rapida:

• Verifica la percepibilità: testo alternativo significativo per ogni immagine, aria-label per le icone, testo di ancoraggio chiaro per ogni link.
• Raggiungi un rapporto di contrasto di 4,5:1 per il testo normale e 3:1 per il testo grande usando il WebAIM Contrast Checker.
• Costruisci una gerarchia di intestazioni: un H1 per pagina, poi H2 e H3 senza saltare livelli.
• Garantisci l'accessibilità da tastiera: tutto ciò che è cliccabile con il mouse deve funzionare con Tab e Invio.
• Controlla i form: un'etichetta esplicita per ogni campo di input; un placeholder non sostituisce una descrizione.
• Esegui WAVE o Lighthouse: un audit automatizzato troverà la maggior parte dei problemi in mezzo minuto.

Cos'è l'accessibilità web e perché è obbligatoria nel 2026

L'accessibilità web è la pratica di progettare e sviluppare siti web utilizzabili da persone con qualsiasi capacità fisica e cognitiva. Lettori di schermo per utenti non vedenti, navigazione da tastiera per persone con disabilità motorie, contrasto sufficiente per utenti ipovedenti, sottotitoli per utenti non udenti.

Lo standard de facto sono le WCAG 2.2 (Web Content Accessibility Guidelines) del consorzio W3C. Tre livelli: A (minimo), AA (l'obiettivo per la maggior parte) e AAA (massimo). La legislazione UE e statunitense richiede il livello AA.

L'European Accessibility Act (Direttiva UE 2019/882) è entrato in vigore il 28 giugno 2025 e copre e-commerce, banche, trasporti e media. In Germania si applica parallelamente il BFSG. Le sanzioni variano: fino a 100.000 € in Germania, fino a 250.000 € in Francia. I siti WordPress di aziende commerciali ricadono direttamente sotto questa normativa.

Percepibilità: come rendere i contenuti comprensibili ai lettori di schermo

Il punto di partenza per l'accessibilità: le informazioni devono essere presentate in modo che l'utente possa percepirle attraverso almeno un canale: vista, udito, tatto.

Immagini e testo alternativo. Ogni tag img deve avere un attributo alt. Per le immagini significative, una descrizione di ciò che vi accade (5-8 parole, senza "immagine" o "foto"). Per le immagini decorative, alt="" (vuoto, ma presente). Il lettore di schermo salta un alt vuoto e non distrae l'utente.

1
/* functions.php — forced alt for post thumbnails */
2
add_filter('wp_get_attachment_image_attributes', function($attr, $attachment) {
3
    if (empty($attr['alt'])) {
4
        $attr['alt'] = get_the_title($attachment->ID);
5
    }
6
    return $attr;
7
}, 10, 2);

Link e pulsanti vuoti. Un'icona a forma di lente di ingrandimento senza testo è un mistero per un lettore di schermo. Aggiungi sempre aria-label ai pulsanti icona:

1
<button aria-label="Open search">
2
    <span class="dashicons dashicons-search"></span>
3
</button>

Attributi Title. Utili per un contesto aggiuntivo, ma non duplicare al loro interno il testo del link; il lettore di schermo leggerebbe la stessa cosa due volte. WordPress di default duplica il testo del link nel title; questa funzione andrebbe disabilitata.

Contrasto cromatico: valori di base e strumenti di verifica

Un contrasto insufficiente tra testo e sfondo è il problema più diffuso. Secondo il WebAIM Million 2025, un contrasto basso è stato rilevato sull'81% dei siti scansionati.

Requisiti minimi WCAG 2.2 AA:

• Testo normale (inferiore a 18pt): contrasto 4,5:1
• Testo grande (18pt e oltre o 14pt in grassetto): contrasto 3:1
• Icone ed elementi UI: contrasto 3:1

Verificalo in un minuto usando il WebAIM Contrast Checker: inserisci i colori del testo e dello sfondo in HEX e ottieni un verdetto: Superato / Non superato per ogni livello.

Aree problematiche tipiche in WordPress: testo grigio su sfondo bianco nel footer, pulsanti chiari con etichette bianche, testo su foto senza una sovrapposizione scurente. Si risolve modificando i CSS, il più delle volte scurrendo il testo di un paio di tonalità.

Struttura delle intestazioni: una gerarchia che tutti comprendono

I lettori di schermo costruiscono un "indice" della pagina a partire dalle intestazioni; l'utente salta tra H2 e H3, aggirando la navigazione. Se la gerarchia è interrotta, la navigazione si rompe.

Regole:

• Un solo H1 per pagina, tipicamente il titolo dell'articolo
• H2 per le sezioni principali, H3 per le sottosezioni all'interno di un H2
• Le intestazioni non saltano: H2 → H4 (saltando H3) è un errore
• Non usare i tag h* solo per la dimensione del font; usa i CSS per quello

Un problema tipico in WordPress: plugin e temi che inseriscono H2/H3 per i propri blocchi (slider con un titolo, un modulo di iscrizione, widget della sidebar). Tre soluzioni: trovare l'impostazione del tag nel plugin, personalizzare l'output tramite un filtro o passare a un plugin più attento. Accettare una gerarchia rotta "perché esteticamente gradevole" non è un'opzione.

Navigazione e landmark: segnali per il lettore di schermo

I landmark HTML5 forniscono al lettore di schermo una mappa della pagina. Quattro tag chiave: header per l'intestazione, nav per la navigazione, main per il contenuto principale e footer per il piè di pagina. L'utente preme una scorciatoia da tastiera e salta direttamente al contenuto principale.

1
<header role="banner">
2
<nav role="navigation">
3
<main role="main">
4
<footer role="contentinfo">

Il ruolo role="main" deve comparire esattamente una volta per pagina. La maggior parte dei temi WordPress moderni utilizza questi tag in modo nativo; verifica con WAVE: la sezione "Structure" mostrerà tutti i landmark.

Un altro elemento obbligatorio, "Salta al contenuto", è un link invisibile posizionato come primo elemento della pagina che consente agli utenti di saltare il menu e andare direttamente al contenuto. In WordPress si aggiunge tramite un filtro o un plugin per l'accessibilità.

Form senza barriere

Modulo di contatto, iscrizione alla newsletter, checkout: ogni campo deve essere etichettato e raggiungibile via tastiera.

*Ogni input ha bisogno del proprio label (esplicito o tramite aria-label):*

1
<label for="user-email">Email</label>
2
<input id="user-email" name="email" type="email">

Un placeholder non sostituisce un'etichetta; scompare quando si inizia a digitare ed è letto male dagli screen reader. Usa placeholder solo come suggerimento sul formato, non come nome del campo.

Raggruppamento: racchiudi i pulsanti radio e le caselle di controllo in un <fieldset> con un <legend>. Campi obbligatori: contrassegnali con il testo "(obbligatorio)", non solo con un asterisco o un colore.

Navigazione da tastiera: la tua pagina senza mouse

Alcuni utenti non usano mai il mouse: tremore, spasticità, paralisi. Ogni elemento deve funzionare con Tab, Shift+Tab, Invio, Esc e i tasti freccia.

Test rapido: apri la pagina e navigala usando solo il tasto Tab. Ogni elemento interattivo deve ricevere un indicatore di focus visibile. Una modale deve chiudersi con Esc. Un menu a tendina deve espandersi con Invio.

Errori tipici dei siti WordPress:

• Menu a tendina personalizzati senza tabindex e aria-expanded
• outline: none nel CSS (rimuove l'indicatore di focus; non farlo)
• Trappola del focus infinita nei popup
• Slider non utilizzabili da tastiera

Non disabilitare mai completamente lo stile predefinito :focus. Se non ti piace il contorno del browser, sostituiscilo con uno stile :focus-visible personalizzato che abbia un anello ad alto contrasto.

Zoom: non impedire agli utenti di ingrandire il testo

Molte versioni mobile di siti WordPress bloccano il pinch-zoom tramite un meta tag:

1
<!-- INCORRECT — do not do this -->
2
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
3
 
4
<!-- CORRECT -->
5
<meta name="viewport" content="width=device-width, initial-scale=1">

Le WCAG 2.2 richiedono la possibilità di zoomare al 200% senza perdita di contenuto o funzionalità; questo è il Criterio di successo 1.4.4. Verifica che il testo non venga tagliato o si sovrapponga ad altri blocchi quando si effettua lo zoom.

Temi WordPress e accessibilità: cosa cercare nella scelta

Nessun tema è «completamente accessibile così com’è», troppo dipende dai contenuti e dalle impostazioni. Ma la base di partenza conta.

Quando scegli un tema, presta attenzione a:

• La descrizione riporta «accessibility ready», è un tag su WordPress.org che indica una conformità di base ai requisiti
• Struttura HTML5 corretta con i landmark
• Menu di navigazione, <nav> nativo con <ul>, non una costruzione a div con JS
• Presenza degli stili :focus per link e pulsanti
• Assenza di maximum-scale=1.0 nel viewport

I temi standard di WordPress (Twenty Twenty-Four, Twenty Twenty-Five) sono un punto di partenza decente. I temi commerciali con i visual builder sono una zona a rischio: più «magia» visiva c’è, più alta è la probabilità di un’accessibilità compromessa.

Strumenti per l’audit: da un controllo rapido al test professionale

WAVE Evaluation Tool. Un’estensione per browser, WAVE di WebAIM, sovrappone icone direttamente sulla pagina: rosso per gli errori, giallo per gli avvisi, verde per ciò che va bene. Ideale per un primo audit. Mostra contrasto, testi alternativi, struttura delle intestazioni, attributi ARIA.

Google Lighthouse. Integrato in Chrome DevTools (F12 → Lighthouse → Accessibility). Restituisce un punteggio numerico da 0 a 100 e un elenco di elementi specifici da correggere. Comodo per un monitoraggio regolare.

Accessibility Checker (Equalize Digital). Un plugin per WordPress, Accessibility Checker verifica i contenuti direttamente nell’editor (Gutenberg e Classic). La versione gratuita scansiona un articolo prima della pubblicazione, la versione Pro aggiunge un audit completo del sito.

WP Accessibility. Un veterano tra i plugin per l’accessibilità, WP Accessibility di Joe Dolson. Aggiunge skip link, landmark ARIA, rimuove gli attributi title duplicati nei link, sistema gli stili :focus, rimuove tabindex dai form e target dai link. Non è la bacchetta magica, ma risolve una dozzina di problemi tipici in un colpo solo.

One Click Accessibility. Un plugin con una toolbar, One Click Accessibility permette all’utente di cambiare contrasto, aumentare la dimensione del carattere e sottolineare i link in autonomia. Non sostituisce l’accessibilità nativa, ma è un livello aggiuntivo per chi ha bisogno di impostazioni specifiche.

NVDA. Uno screen reader gratuito per Windows, NVDA. Naviga il tuo sito a monitor spento. Sentirai ciò che sente un utente non vedente. VoiceOver (integrato in macOS/iOS) è l’equivalente per l’ecosistema Apple.

Dieci passi per un sito WordPress accessibile

Ecco il concentrato pratico dell’intera guida, una checklist. Seguila dopo ogni redesign o lancio di un nuovo progetto.

• Scrivi il testo alternativo per ogni immagine. Nella libreria media di WordPress, compila il campo «Testo alternativo». Per le immagini decorative, usa alt="".

• Descrivi i link. Il testo del link deve comunicare dove porta. «Clicca qui» e «Leggi tutto» sono ancore deboli. «Scarica il plugin Accessibility Checker» è un’ancora efficace.

• Disponi le intestazioni in ordine. Un solo H1, poi H2, e H3 dentro H2. Verifica in WAVE: Structure → Heading Outline.

• Porta il contrasto a 4,5:1. Passa i colori principali del tema nel WebAIM Contrast Checker: testo, intestazioni, pulsanti, link, footer.

• Attiva il focus visibile. Assicurati che :focus non sia impostato su outline: none senza un’alternativa. Il focus personalizzato si realizza con :focus-visible.

• Verifica la navigazione da tastiera. Tab su tutti i link e pulsanti, Invio per attivare, Esc per chiudere le modali. Se ti blocchi, è un bug.

• Etichetta i form. Ogni campo ha bisogno del proprio <label>. I campi obbligatori richiedono un’indicazione testuale. I gruppi vanno in un <fieldset>.

• Non bloccare lo zoom. Viewport senza maximum-scale e user-scalable=no. Verifica allo zoom 200%, il contenuto non deve essere tagliato.

• Aggiungi uno skip link. Un link «Vai al contenuto» come primo elemento del <body>. WP Accessibility lo fa in automatico.

• Esegui WAVE o Lighthouse. Un audit automatico non sostituisce il test manuale, ma trova la stragrande maggioranza dei problemi in un minuto.

⁉️🤔 Domande frequenti

Il mio sito WordPress deve essere conforme alle WCAG?

Se il tuo sito rappresenta un'azienda nell'UE, sì, a partire da giugno 2025. L'European Accessibility Act riguarda e-commerce, finanza, trasporti e media. Negli Stati Uniti si applicano requisiti analoghi: ADA e Section 508 per le agenzie governative e i loro fornitori. Un blog personale non è formalmente obbligato a conformarsi, ma una quota significativa di utenti ha disabilità, un forte argomento commerciale.

Sì, i siti commerciali nell'UE devono essere conformi alle WCAG 2.2 AA a partire dal 28 giugno 2025 in base all'European Accessibility Act. Le sanzioni sono stabilite dagli Stati membri: gli importi possono raggiungere centinaia di migliaia di euro a seconda della giurisdizione. Negli Stati Uniti si applicano requisiti analoghi tramite l'ADA e la Section 508. Per i blog personali non commerciali non c'è un obbligo legale, ma l'accessibilità amplia il pubblico.

Installare un plugin come One Click Accessibility è sufficiente?

Un plugin toolbar è un livello assistivo, non una soluzione. Permette all'utente di cambiare contrasto o dimensione del font, ma non risolve la mancanza di testi alternativi, una gerarchia delle intestazioni scorretta o popup inaccessibili da tastiera. Inizia dall'accessibilità nativa nel codice e nei contenuti, aggiungi la toolbar come tocco finale.

No. Una toolbar (One Click Accessibility, UserWay) è solo un "overlay" aggiuntivo. Non sostituisce l'accessibilità nativa: non risolve testi alternativi, gerarchia delle intestazioni, trappole per tastiera o campi form senza etichetta. Inizia correggendo codice e contenuti, la toolbar è l'ultimo tocco.

Come posso testare un sito senza acquistare strumenti costosi?

Un ciclo completo con strumenti gratuiti: WAVE Extension (prima scansione rapida) → Google Lighthouse (punteggio numerico ed elenco dei problemi) → walkthrough manuale da tastiera (Tab/Invio/Escape) → NVDA su Windows o VoiceOver su Mac (navigare il sito con il monitor spento). Questo è sufficiente per affrontare la grande maggioranza dei problemi.

Ciclo gratuito: WAVE Extension per il browser → Google Lighthouse in Chrome DevTools → walkthrough manuale da tastiera → NVDA (Windows) o VoiceOver (macOS/iOS) per il test con screen reader. Questi quattro strumenti coprono il 90% delle attività. I servizi a pagamento servono solo per audit regolari su grandi progetti.

Un sito costruito con un visual builder (Elementor, WPBakery) può essere reso accessibile?

Si può fare, ma è più difficile. I builder generano HTML dinamicamente e alcuni widget rompono la gerarchia delle intestazioni o inseriscono div wrapper senza semantica. Controlla ogni blocco singolarmente con WAVE. Elementor Pro versione 3.15+ ha aggiunto impostazioni per gli attributi aria sui widget, usale.

Si può fare, ma richiederà più lavoro manuale. I visual builder tendono a rompere la gerarchia delle intestazioni e a generare div wrapper eccessivi. Controlla il risultato con WAVE dopo ogni modifica. Elementor Pro (3.15+) permette di impostare gli attributi ARIA per i widget, il che risolve parzialmente il problema.

Ogni quanto dovrei ricontrollare l'accessibilità di un sito?

Dopo ogni aggiornamento significativo: un nuovo tema, un nuovo plugin, un redesign, una pubblicazione importante di contenuti. Ciclo minimo: esegui Lighthouse e naviga le pagine chiave con la tastiera una volta al trimestre. Il monitoraggio automatico tramite Accessibility Checker Pro è giustificato per siti con contenuti regolari.

Come minimo, dopo ogni modifica importante (cambio tema, nuovo plugin, redesign) e trimestralmente come misura preventiva. Per siti con pubblicazioni regolari, il monitoraggio automatico tramite Accessibility Checker Pro è giustificato. Un test con screen reader è sufficiente una volta ogni sei mesi se il codice non è cambiato.

Cosa fare subito per l'accessibilità del sito WordPress

Non aspettare il momento perfetto. La WCAG 2.2 AAA è un obiettivo, non un punto di partenza. Inizia oggi con tre azioni:

• Lancia WAVE sulla tua homepage. Correggi gli errori in rosso (di solito 5-10), eliminano le barriere più gravi.
• Naviga il sito con la tastiera. Tab, Tab, Tab. Se ti blocchi, correggi. Se il focus non è visibile, aggiungi :focus-visible.
• Verifica il contrasto di tre colori: colore del testo, colore dei pulsanti, colore dei link. Portali a 4.5:1.

Tre passaggi, mezz'ora di lavoro e la parte del leone del risultato. Il resto, plugin, screen reader, ARIA, affrontalo gradualmente.

Se il sito è commerciale e opera nell'UE, non rimandare. L'EAA conferisce alle autorità di vigilanza una leva reale a partire dal 2025. Meglio affrontare un audit con un punteggio Lighthouse verde che con una lettera di un'autorità di controllo.