- WordPress alimenta il 43% di tutti i siti web: la WordPress accessibilità WCAG è obbligatoria per tutti i soggetti privati B2C dal 28 giugno 2025, ma richiede interventi su più livelli — tema, contenuti, codice, plugin di terze parti — che nessun singolo plugin può coprire integralmente.
- Un tema "accessibility-ready" è un buon punto di partenza ma non garantisce la conformità WCAG 2.1 AA: i test automatici rilevano solo il 30–40% delle violazioni, il resto richiede test manuali con screen reader e navigazione da tastiera.
- I plugin di accessibilità WordPress coprono personalizzazione utente (toolbar) e rilevamento automatico delle violazioni, ma non possono correggere problemi strutturali nel codice del tema, label assenti nei form o componenti JavaScript non accessibili.
- Per WooCommerce, l'accessibilità del checkout è l'area a rischio normativo più alto: form senza label, messaggi di errore solo visivi e navigazione da tastiera non funzionante richiedono un intervento sviluppatore che va oltre la toolbar.
WordPress è la piattaforma CMS più usata al mondo: alimenta circa il 43% di tutti i siti web, dalle piccole attività commerciali alle PMI, dai blog ai negozi WooCommerce. Questa diffusione capillare rende la questione della accessibilità WCAG strategica per chiunque gestisca un sito sulla piattaforma — e obbligatoria per tutti i soggetti privati B2C dal 28 giugno 2025, ai sensi del D.Lgs. 82/2022 (recepimento dell'European Accessibility Act).
La buona notizia è che per WordPress l'accessibilità WCAG è un obiettivo raggiungibile, anche su siti già esistenti. La cattiva notizia è che non basta installare un plugin. Rendere un sito WordPress conforme alle WCAG 2.1 AA richiede interventi su più livelli: il tema, i contenuti, il codice, i plugin di terze parti, i form e — per chi usa WooCommerce — l'intero percorso di acquisto.
Questa guida copre tutto il percorso: dalla scelta del tema accessibility-ready alla installazione della toolbar, dalle violazioni più frequenti ai criteri da controllare prima di pubblicare qualsiasi contenuto.
Cosa significa sito WordPress conforme alle WCAG 2.1 AA
Le WCAG 2.1 (Web Content Accessibility Guidelines) sono le linee guida internazionali per l'accessibilità web, sviluppate dal W3C. Il livello AA — quello richiesto dall'EAA — comprende 50 criteri di successo (30 di livello A più 20 di livello AA) distribuiti su 4 principi: Percepibile, Utilizzabile, Comprensibile, Robusto.
Per un sito WordPress, "conforme alle WCAG 2.1 AA" significa che ogni elemento del sito — pagine, post, immagini, form, menu, bottoni, video — rispetta questi 38 criteri. Non è una certificazione rilasciata da un ente esterno: è un livello tecnico che si raggiunge con interventi sul codice, sui contenuti e sulla struttura del sito, e che si mantiene nel tempo.
Un punto chiave che molti ignorano: le WCAG riguardano anche chi usa il telefono in condizioni di luce intensa o scarsa, chi naviga con un dito rotto, chi ha difficoltà cognitive, chi usa un mouse trackball, chi non riesce a cliccare da smartphone su un bottone con un font troppo piccolo. La stima è che oltre il 20% della popolazione abbia una qualche forma di disabilità che rende i siti inaccessibili un ostacolo reale.
Tema WordPress accessibile: cosa controllare prima di tutto
Il tema è la fondamenta dell'accessibilità su WordPress. Un tema mal costruito — con HTML semantico assente, heading disorganizzati, focus visibile rimosso — crea problemi che nessun plugin può correggere automaticamente. La scelta del tema giusto è il primo passo di qualsiasi strategia di WordPress accessibilità WCAG.
Cosa cercare in un tema accessibility-ready
WordPress ha un tag ufficiale "accessibility-ready" per i temi nel repository. I temi con questo tag hanno superato una serie di criteri base di accessibilità: skip link, focus visibile, uso corretto degli heading, markup semantico. Sono un buon punto di partenza — ma non garantiscono da soli la piena conformità WCAG 2.1 AA.
I criteri da verificare su qualsiasi tema, accessibility-ready o meno:
- HTML semantico: uso corretto di
<header>,<main>,<nav>,<footer>,<article>— non solo<div>e<span> - Focus visibile: il bordo di selezione degli elementi interattivi deve essere chiaramente visibile quando si naviga da tastiera. Il CSS
outline: nonesenza alternativa è una violazione diretta del criterio WCAG 2.4.7 - Skip link: link "Salta al contenuto" accessibile da tastiera che permette di bypassare menu ripetitivi
- Heading H1 unico: ogni pagina deve avere esattamente un H1 che corrisponde al titolo principale
- Contrasto colori: testo e sfondo nel tema base devono rispettare il rapporto 4.5:1 per il testo normale
Page builder: Elementor, Gutenberg e accessibilità
I page builder sono uno dei punti critici dell'accessibilità WordPress. Elementor, Divi e altri builder visuali generano spesso HTML non semantico, aggiungono elementi interattivi senza attributi ARIA corretti e producono heading disorganizzati quando gli utenti li usano per ragioni estetiche invece che strutturali.
Gutenberg (l'editor a blocchi nativo di WordPress) è generalmente più accessibile se usato correttamente, ma anche qui esistono trappole: blocchi con pulsanti senza testo descrittivo, gallerie non navigabili da tastiera, slider senza controlli accessibili.
La regola pratica: qualsiasi blocco o componente aggiunto tramite page builder va testato con Tab da tastiera e con uno screen reader prima della pubblicazione.
Errori comuni di accessibilità nei siti WordPress
Questi sono i problemi di accessibilità WordPress più frequentemente rilevati dagli scanner automatici — e quelli che hanno l'impatto maggiore sugli utenti con disabilità:
| Errore | Criterio WCAG violato | Chi può correggerlo |
|---|---|---|
| Immagini senza alt text o con alt generico | 1.1.1 — A | Editor di contenuto |
| Contrasto colori insufficiente nel tema | 1.4.3 — AA | Designer / Dev CSS |
| Heading disorganizzati (H1 multipli, livelli saltati) | 1.3.1 — A | Editor + sviluppatore |
| Link non descrittivi ("clicca qui", "leggi di più") | 2.4.4 — A | Editor di contenuto |
| Menu di navigazione non accessibile da tastiera | 2.1.1 — A | Sviluppatore front-end |
| Form di contatto senza label associate ai campi | 3.3.2 — A | Sviluppatore front-end |
Focus visibile rimosso con outline:none nel CSS |
2.4.7 — AA | Sviluppatore CSS |
| Popup/modal non chiudibili con Escape | 2.1.2 — A | Sviluppatore front-end |
| Slider non accessibili da tastiera | 2.1.1 — A | Sviluppatore front-end |
| Video senza sottotitoli | 1.2.2 — A | Editor di contenuto |
| PDF non accessibili | 1.1.1 — A | Editor / specialista PDF |
| Pulsanti senza testo descrittivo (solo icona) | 4.1.2 — A | Sviluppatore front-end |
Plugin accessibilità WordPress: cosa possono fare e cosa no
I plugin di accessibilità per WordPress si dividono in due categorie principali: le toolbar frontend (che aggiungono strumenti di personalizzazione per gli utenti) e gli scanner/checker (che rilevano le violazioni WCAG). Capire la differenza è fondamentale per non fare aspettative sbagliate.
Cosa può fare un plugin di accessibilità
- Toolbar utente — contrasto elevato, dimensione testo, spaziatura, font leggibili, sintesi vocale: permettono agli utenti di personalizzare l'esperienza di navigazione in tempo reale
- Scanner automatico — identificare violazioni WCAG rilevabili automaticamente (alt text, contrasto, heading, label form): forniscono un punto di partenza per l'adeguamento
- Report e monitoraggio — tenere traccia delle violazioni nel tempo, ricevere alert quando cambiano
- Supporto alla dichiarazione di accessibilità — generare il documento obbligatorio in formato conforme AgID
Cosa un plugin non può correggere automaticamente
- I problemi semantici nel codice del tema — heading disorganizzati, markup HTML non semantico, attributi ARIA assenti
- La navigazione da tastiera di componenti custom — menu, modal, dropdown costruiti con JavaScript richiedono intervento sviluppatore
- La qualità degli alt text — un plugin può rilevare che mancano, ma non può scrivere descrizioni accurate al posto tuo
- I form senza label — le etichette devono essere aggiunte manualmente nel markup HTML
- I sottotitoli dei video — devono essere prodotti e caricati separatamente
La toolbar MyAccessible su WordPress: installazione in 5 minuti
MyAccessible offre una toolbar frontend con oltre 15 opzioni di personalizzazione accessibilità — contrasto, testo, sintesi vocale, navigazione da tastiera, modalità dislessici, modalità ADHD, filtri per daltonismo — e un sistema di monitoraggio WCAG integrato.
- Si attiva inserendo uno script nell'
<head>del sito, fornito da Ne.W.S. dopo l'acquisto. Una volta installato, la toolbar è immediatamente attiva per gli utenti e il monitoraggio WCAG viene eseguito automaticamente — senza configurazioni aggiuntive.
Compatibilità verificata: Elementor, Divi, Gutenberg, Avada, GeneratePress, WooCommerce, WPML.
WooCommerce e accessibilità WCAG: le aree da presidiare
Se usi WooCommerce, l'accessibilità del tuo shop richiede attenzione specifica su componenti che non esistono in un sito vetrina semplice. Le aree critiche sono le stesse già descritte nell'articolo dedicato agli EAA e-commerce obblighi, ma vale richiamarle nel contesto WordPress:
- Filtri prodotto — dropdown e checkbox devono essere accessibili da tastiera e con screen reader
- Galleria immagini prodotto — navigazione da tastiera tra immagini, alt text su ciascuna foto
- Varianti (taglia, colore) — ogni opzione deve avere
aria-labelassociato - Form di checkout — label su tutti i campi, messaggi di errore testuali, attributo
autocomplete - Form di pagamento — numero carta, scadenza, CVV devono avere label visibili nel markup
- Pulsanti "Aggiungi al carrello" — se il prodotto è esaurito, lo stato deve essere comunicato testualmente
Come verificare se un sito WordPress è conforme alle WCAG 2.1
La verifica della conformità WCAG su un sito WordPress si articola in tre livelli:
Test automatico — rileva il 30–40% delle violazioni
- Scanner MyAccessible — scansione completa del sito, report con criticità per area e livello WCAG, monitoraggio periodico
- axe DevTools — estensione Chrome/Firefox per sviluppatori, test pagina per pagina
- WAVE WebAIM — versione online gratuita, visualizzazione overlay degli errori
- Lighthouse — integrato in Chrome DevTools, include audit accessibilità con punteggio
Test manuale — necessario per la conformità completa
- Navigazione solo da tastiera — Tab, Shift+Tab, Invio, Escape su tutte le pagine critiche
- Screen reader — NVDA (Windows, gratuito) o VoiceOver (macOS/iOS): ascoltare come viene letta ogni pagina
- HeadingsMap — estensione browser per verificare la struttura degli heading
- Test su mobile — Chrome DevTools Device Mode per verificare accessibilità mobile
Audit professionale — per la dichiarazione di accessibilità
Per pubblicare la dichiarazione di accessibilità obbligatoria prevista dall'EAA, è necessario un audit che copra sia i test automatici che quelli manuali. MyAccessible supporta la generazione della dichiarazione in formato conforme AgID a partire dai risultati dell'analisi.
Accessibilità WordPress, SEO e user experience
Rendere un sito WordPress conforme alle WCAG 2.1 AA non migliora solo la compliance normativa: migliora il sito per tutti gli utenti. I benefici sono documentati e misurabili:
- SEO tecnico: alt text descrittivi, struttura heading coerente e HTML semantico sono segnali di qualità positivi per Google. Un sito WordPress accessibile tende ad avere un Lighthouse SEO score più alto
- Mobile usability: i criteri WCAG 2.1 introdotti nel 2018 si sovrappongono esattamente ai segnali di Mobile Usability monitorati da Google Search Console
- Riduzione del bounce rate: una navigazione chiara, con focus visibile e heading gerarchici, trattiene gli utenti più a lungo
- Conversion rate: form accessibili con label corrette e messaggi di errore descrittivi riducono l'abbandono — in WooCommerce questo si traduce direttamente in ordini completati
- Reputazione: l'accessibilità è sempre più monitorata da clienti, partner e stakeholder istituzionali
Checklist pratica: 12 controlli per un sito WordPress conforme alle WCAG
Usa questa checklist come riferimento rapido prima di pubblicare nuovi contenuti o aggiornare il sito:
| Controllo |
|---|
| Ogni immagine ha un alt text descrittivo (non vuoto, non generico) |
| Contrasto testo/sfondo ≥ 4.5:1 per testo normale |
| Un solo H1 per pagina, heading in gerarchia logica (H2 → H3) |
| Link con testo descrittivo (no "clicca qui") |
| Tutto il sito navigabile solo da tastiera (Tab + Invio) |
| Focus visibile su tutti gli elementi interattivi |
| Form con label associate a ogni campo |
| Errori nei form comunicati con testo, non solo colore |
| Modal/popup chiudibili con Escape e focus gestito |
| Video con sottotitoli o trascrizioni disponibili |
Lingua della pagina dichiarata (attributo lang sull'HTML) |
| Dichiarazione di accessibilità pubblicata sul sito |
Inizia oggi: analizza il tuo sito WordPress con lo scanner gratuito
Il modo più rapido per capire dove si trovano le violazioni di accessibilità del tuo sito WordPress è un'analisi automatica. Lo scanner gratuito di MyAccessible scansiona il sito in pochi secondi, rileva le violazioni WCAG 2.1 AA e restituisce un report con le priorità di intervento per area.
Se il report evidenzia violazioni strutturali nel codice del tema, nei form o nei componenti WooCommerce, il passo successivo è un intervento tecnico professionale.
FAQ — Domande frequenti su WordPress accessibilità WCAG
Vuoi trasformare questa analisi in una scelta concreta?
Vai alla pagina dei piani e valuta quale soluzione e piu coerente con traffico, complessita del sito e livello di supporto richiesto.