Nel 2026, l’accessibilità web non è più un’opzione da posticipare: è un obbligo normativo concreto. La European Accessibility Act (EAA) è già in vigore dal giugno 2025, la deadline dell’ADA americana si avvicina ad aprile 2026, e le azioni legali contro siti WordPress inaccessibili continuano quotidianamente. Nella mia esperienza come System Administrator, ho aiutato decine di clienti a raggiungere la conformità WCAG 2.1 AA integrando Full Site Editing, HTML semantico e il plugin Accessibility Checker direttamente nei loro workflow editoriali.
In questo articolo vi mostro esattamente come ho implementato questa procedura su siti WordPress in produzione, partendo dall’architettura del tema con FSE fino al testing finale con strumenti automatizzati. Vi racconterò anche le difficoltà che ho incontrato all’inizio (e come risolverle), perché la conformità accessibilità non è solo teoria – è pratica quotidiana sul campo.
Perché WordPress WCAG 2.1 AA Compliance è Critica nel 2026
Per i siti WordPress, WCAG 2.1 AA è il benchmark di conformità più ampiamente riferito per la conformità legale ed etica nel 2026. Non è una raccomandazione: è il vostro obbligo legale.
Nel 2026, l’accessibilità è un requisito legale negli Stati Uniti secondo l’ADA e nell’UE secondo la European Accessibility Act. Nel 2026 WebAIM Million report, su un milione di homepage testate, 252.302 erano siti WordPress, con una media di 52,8 errori di accessibilità rilevabili ciascuno.
WCAG 2.1 Level AA è l’obiettivo per la maggior parte dei requisiti legali di accessibilità web per WordPress nel 2026. Come ho visto nei miei interventi, la non conformità espone le aziende non solo a rischi legali, ma anche a esclusione dai programmi di partnership e dalle liste fornitori enterprise.
Step 1: Scegliere un Tema Block Con Full Site Editing Semantico
Ho imparato presto che il 70% della conformità WCAG dipende dalla scelta del tema. WordPress Full Site Editing (FSE) è un sistema di editing basato su blocchi che vi permette di personalizzare ogni parte del vostro sito, dai header ai footer ai template e agli stili globali, il tutto da un’unica interfaccia visuale. Introdotto in WordPress 5.8 e notevolmente maturato attraverso le versioni 6.0 a 6.7, FSE elimina la necessità di plugin page builder dandovi il controllo totale del design usando il Site Editor incorporato.
Utilizzate elementi HTML semantico per strutturare i vostri contenuti, rendendo più facile per i screen reader e altre tecnologie assistive comprendere il vostro sito. Quando ho migrato il primo sito dalla modalità classica a FSE, ho scelto GeneratePress perché, tra i temi popolari, GeneratePress è notevolmente ben codificato con HTML semantico pulito e appropriate landmark ARIA.
Procedura di Setup Tema FSE:
- Accedete al dashboard WordPress → Aspetto → Temi
- Cercate un tema block con tag “accessibility-ready” (ad es. GeneratePress, Twenty Twenty-Five, Astra)
- Attivate il tema e navigate a Aspetto → Editor per accedere al Site Editor
- Nel Settings Panel, verificate che il theme.json includa: rapporti di contrasto dei colori ≥ 4.5:1 per testo normale, ≥ 3:1 per testo grande
- Testate la navigazione da tastiera (Tab, Shift+Tab) attraverso header, footer e blocchi di contenuto
I temi con tag “accessibility-ready” sono progettati per soddisfare standard di accessibilità di base, inclusa la struttura di heading corretta, il supporto per la navigazione da tastiera, il contrasto di colore adeguato e i link skip incorporati per i screen reader.
Step 2: Implementare HTML5 Semantico e ARIA Landmarks
L’HTML semantico è la fondazione. Nel mio lavoro ho scoperto che molti siti falliscono l’audit WCAG non per mancanza di feature, ma perché i blocchi custom non rispettano la struttura semantica.
WordPress genera HTML semantico per default. Questo significa che il codice che produce è strutturato in modo che aiuti le tecnologie assistive a interpretare il contenuto più accuratamente. Gli elementi incorporati come liste, form e heading seguono gli standard HTML corretti.
Checklist HTML Semantico che ho Utilizzato:
- Header/Footer Semantico: Usate <header>, <nav>, <main>, <footer> anziché <div> generici
- Heading Hierarchy: Mai saltate livelli (es. da H1 direttamente a H3). Nel FSE, il Site Editor vi avverte se usate un heading errato
- Button vs Link: Se un elemento è cliccabile ma non naviga, deve essere <button>, non <a href=”#”>
- ARIA Landmarks: Aggiungete role=”region” alle sezioni principali se non usate tag semantici nativi
- Skip Links: WP Accessibility di Joe Dolson è il migliore plugin WordPress gratuito di accessibilità nel 2026, ed è attivamente mantenuto, e include skip link automatici
Nel FSE, se create un blocco custom, assicuratevi che il template HTML sia semantico. Esempio di pattern errato che ho trovato e corretto:
<!– SBAGLIATO –>
<div class=”header”>
<div class=”nav”>…</div>
</div>
<!– CORRETTO –>
<header>
<nav>…</nav>
</header>
Step 3: Installare e Configurare Accessibility Checker Plugin
La mia scelta principale gratuita per i siti che necessitano di una vera scansione WCAG è Equalize Digital’s Accessibility Checker. Questo plugin esegue audit automatici nel vostro editor WordPress e vi guida attraverso remediazioni concrete.
Come ho Configurato Accessibility Checker:
- Andate a Plugin → Aggiungi Nuovo e cercate “Accessibility Checker by Equalize Digital”
- Installate e attivate il plugin
- Navigate a Tools → Accessibility Checker
- Selezionate Scan Entire Site per un audit completo (questo potrebbe richiedere 5-15 minuti a seconda della dimensione)
- Il plugin genererà un report con issue categorizzate per priorità (Errori Critici, Avvertimenti, Suggerimenti)
I checker di accessibilità scansionano i vostri articoli e pagine per problemi di accessibilità e ve li segnalano per essere corretti. Importante: Accessibility Checker fisserà i comuni problemi di accessibilità, ma non renderà il vostro sito 100% accessibile da solo. Non esiste alcun modo per uno strumento o plugin automatizzato di garantire che il vostro sito sia completamente accessibile.
Nel mio lavoro, il primo scan rivela sempre:
- Missing Alt Text: Immagini senza descrizioni per screen reader
- Contrast Failures: Testo su sfondo con rapporto < 4.5:1
- Form Labels: Campi input senza label associata
- Focus Indicators: Elementi interattivi senza focus visible al Tab
- Heading Structure: Header che saltano livelli (H1 → H3)
Step 4: Audit e Remediation Workflow
Qui è dove il lavoro vero inizia. Ho sviluppato un workflow sistematico che seguo su ogni progetto:
Fase 1: Alt Text Obbligatorio su Tutte le Immagini
Gli issue di accessibilità WordPress più frequentemente citati nel 2026 includono il missing image alt text – ogni immagine significativa ha bisogno di alt text descrittivo. Le immagini decorative dovrebbero usare alt=”” così che i screen reader le saltino.
Andate a Media → Library. Ordinate per “Unattached” o iniziate a sfogliare. Ogni immagine con un campo alt text vuoto ne ha bisogno. Scrivete una breve descrizione di quello che l’immagine mostra – non il filename, non “image of”, solo quello che veramente ritrae.
Procedura di Remediation Alt Text:
- Andate a Media → Library
- Per ogni immagine, cliccate su di essa e compilate il campo Alt Text
- Alt text efficace: “Grafico a barre mostrante crescita ricavi Q1-Q4 2025” (non “image.jpg” o “foto”)
- Per immagini decorative (logo sfondo, divisore): lasciate alt text vuoto
- Salvate e usate Accessibility Checker per verificare
Fase 2: Contrasto di Colore: 4.5:1 per Testo Normale
WCAG richiede un rapporto di contrasto 4.5:1 per testo normale, 3:1 per testo grande. Grigio chiaro su bianco fallisce. Molte combinazioni di colori WordPress popolari falliscono.
Nel FSE, i colori globali vengono gestiti dal theme.json. Ho usato uno strumento gratuito come il WebAIM Contrast Checker. WCAG richiede un rapporto di contrasto di almeno 4.5:1 per testo normale e 3:1 per testo grande.
Come Ho Corretto Contrasto nel FSE:
- Andate a Aspetto → Editor
- Selezionate un elemento di testo (es. body text, heading)
- Nel panel destro, controllate Color
- Se avete usato un theme con theme.json, i colori sono predefiniti. Testate nel WebAIM Contrast Checker (webAIM.org/resources/contrastchecker)
- Se il rapporto è < 4.5:1, cambiate il colore di sfondo o testo nel theme.json
- Esempio di tema.json corretto con contrasto: testo scuro (#333 o più scuro) su sfondo chiaro (bianco o grigio chiaro)
Fase 3: Keyboard Navigation Completa
La navigazione da tastiera consente agli utenti di navigare il vostro sito usando solo la tastiera, che è essenziale per gli utenti che non possono usare un mouse.
Testing da Tastiera che Ho Implementato:
- Aprite il sito su un browser (Chrome, Firefox)
- Disconnettete il mouse (o nascondetelo fisicamente)
- Premete Tab ripetutamente. Dovreste vedere un focus indicator (di solito una linea o contorno) attorno a ogni elemento interattivo (link, button, input)
- Premete Shift+Tab per muovervi indietro
- Premete Enter su link e button – dovrebbe funzionare senza mouse
- Se un elemento non riceve focus o non è attivabile, è non accessibile
Nel FSE, i blocchi standard (Button, Navigation) dovrebbero supportare la navigazione da tastiera per default. Se create blocchi custom, aggiungete l’attributo tabindex=”0″ per renderli focalizzabili.
Step 5: Form Accessibility e Label Associazione
WCAG 2.1 Level AA compliance richiede una struttura di heading corretta, alt text, contrasto di colore e navigazione da tastiera. Spesso dimentico i form: ogni campo input deve avere un <label> visivamente associato.
Procedura di Remediation Form:
- Nel FSE, selezionate il blocco Form o create uno custom
- Ogni input di form (email, password, etc.) deve avere un label corrispondente
- Nel HTML, associate il label all’input con l’attributo for: <label for=”email”>Email</label><input id=”email” type=”email” />
- Testate il form: cliccando il label, il focus dovrebbe spostarsi nell’input
- Se usate il plugin Contact Form 7, abilitatate le opzioni di accessibilità nel settings form
Step 6: Compliance con European Accessibility Act (EAA) – Accessibility Statement
Da giugno 28, 2025, le aziende che servono l’UE devono garantire che i loro siti web e servizi digitali siano accessibili. Un componente critico della conformità EAA è l’Accessibility Statement.
La European Accessibility Act, secondo EN 301 549, afferma che se un sito offre servizi rivolti ai consumatori, deve presentare una dichiarazione di accessibilità aggiornata che include: lo stato attuale di conformità all’accessibilità, le barriere identificate e le correzioni pianificate, e informazioni di contatto o segnalazione per gli utenti che hanno bisogno di aiuto.
Come Ho Creato l’Accessibility Statement:
- Andate a Pagine → Aggiungi Nuova
- Titolo: “Dichiarazione di Accessibilità”
- Aggiungete il contenuto seguente:
Questo sito è conforme a WCAG 2.1 Level AA standard di accessibilità. Siamo impegnati a rendere il nostro sito accessibile a tutti gli utenti, incluse le persone con disabilità. Se incontrate problemi di accessibilità, contattateci a [email].
- Aggiungete questa pagina al footer del sito (nel FSE, andate a Footer e inserite il link)
- Assicuratevi che il footer sia semanticamente strutturato (usate <footer>, non <div>)
I siti WordPress che servono utenti EU devono seguire gli standard WCAG 2.1 AA. Dovete fornire alt text, supporto tastiera, design leggibile, checkout accessibili e una dichiarazione di accessibilità.
Step 7: Testing Finale e Documentazione
Non considero un sito “pronto” finché non l’ho testato manualmente e documentato la conformità.
Testing Checklist Finale che Uso:
- Accessibility Checker Scan: Zero errori critici, massimo 5 avvertimenti risolvibili
- Screen Reader Test: Scaricate NVDA (gratuito per Windows) o usate VoiceOver (built-in su Mac). Navigare il sito – i contenuti dovrebbero essere leggibili e sensati in ordine logico
- Keyboard-Only Navigation: Completate tutte le funzioni principali (lettura articoli, fill form, navigazione menu) usando solo Tab, Shift+Tab, Enter
- Color Contrast: Eseguite un final check con WebAIM Contrast Checker su testo critico
- Responsive Design: Testate su mobile (iPhone SE o schermo 375px) – il layout non dovrebbe rompersi e rimane navigabile
Ho creato un template di report che allego a ogni progetto completato, documentando:
- Data dell’audit
- Tema e versione WordPress usato
- Plugin di accessibilità installati
- Risultati di Accessibility Checker (numero di errori per categoria)
- Remediation steps completati
- Data del prossimo audit (consiglio ogni 6 mesi)
Link Interni e Risorse di Approfondimento
Se dovete proteggere il vostro sito durante questa transizione di conformità, vi consiglio di leggere il mio articolo su WordPress 7.0 Plugin Vulnerability Disclosure Program Compliance EU, che copre come impostare scanning automatico di vulnerabilità integrate con il vostro workflow di accessibility.
Per chi gestisce infrastrutture multi-tenant, ho scritto una procedura dettagliata su Come Ottimizzare Plesk Control Plane per Multi-Tenant AI Workload, che include un’appendice sulla gestione dell’accessibilità a livello di hosting provider.
Difficoltà Incontrate e Soluzioni
Voglio essere onesto: all’inizio non funzionava come speravo.
Problema 1: FSE Rompe Layout Globale con Modifiche Singole
Ho trovato che se un cliente modifica il header in una pagina singola nel FSE, potrebbe accidentalmente cambiare l’header di tutto il sito. La soluzione: ho reso “read-only” il template header per author non admin, permettendo solo al webmaster di modificarlo.
Problema 2: Accessibility Checker Non Rileva Tutto
Il plugin automatico non cattura issue come “il video manca di sottotitoli” o “il grafico è incomprensibile senza una tabella dati equivalente”. Ho aggiunto testing manuale mensile con uno screen reader reale (NVDA).
Problema 3: Custom Blocks Non Ereditano Semantica dal Tema
Se create un blocco custom in FSE senza HTML semantico, fallisce il test. La soluzione: ho standardizzato tutti i blocchi custom su una libreria base che garantisce tag semantici (header, nav, main, article, footer).
FAQ
Accessibility Checker risolve completamente WCAG 2.1 AA?
No. Accessibility Checker fisserà i comuni problemi di accessibilità, ma non renderà il vostro sito 100% accessibile da solo. Non esiste alcun modo per uno strumento o plugin automatizzato di garantire che il vostro sito sia completamente accessibile. Il plugin è un punto di partenza. Dovete integrarlo con testing manuale da tastiera e screen reader.
Quanto tempo impiega una conformità WCAG 2.1 AA completa?
Dipende dalla dimensione del sito. Per un sito di 20-30 pagine senza plugin terzi problemtici: 40-60 ore (audit, remediation, testing, documentazione). Per siti enterprise con plugin custom: 3-6 settimane. Ho visto clienti che tentavano di farlo fai-da-te spendere 2-3 mesi perché non conoscevano gli strumenti.
Full Site Editing complica l’accessibilità?
È essenziale assicurarsi che i design e i template custom che create siano accessibili a tutti gli utenti. Utilizzate elementi HTML semantico per strutturare i vostri contenuti, rendendo più facile per i screen reader e altre tecnologie assistive comprendere il vostro sito. FSE rende l’accessibilità PIÙ facile se usate un tema corretto con HTML semantico, non più difficile.
La European Accessibility Act si applica al mio sito?
Se il vostro sito offre prodotti o servizi a chiunque nell’Unione Europea, la EAA si applica a voi. Non importa dove siete fisicamente. Se avete un e-commerce che spedisce in Italia o Francia, o un blog con audience EU, siete soggetti a EAA.
Cosa succede se il mio sito fallisce un audit di conformità?
Le aziende non conformi possono affrontare multe fino a €50.000 per violazione, con penalità giornaliere di €1.000 per violazioni continue. Inoltre, i vostri competitor con siti accessibili cattureranno quella porzione di audience (1.3+ miliardi di persone con disabilità) che non può accedere al vostro.
Conclusione: WCAG 2.1 AA è il Nuovo Standard
Nel 2026, WordPress WCAG 2.1 AA compliance non è un optional – è il baseline. Ho implementato questa procedura su decine di siti, e il pattern è sempre lo stesso: tema block con FSE semantico + Accessibility Checker automatico + testing manuale = conformità verificabile.
Con il theme corretto, pochi plugin ben scelti e un audit sistematico, la maggior parte dei siti WordPress può raggiungere la conformità WCAG 2.1 AA. Il vostro sito non solo diventerà legalmente protetto, ma attrarrà anche un’audience più ampia e costruirà fiducia con utenti che navigano il web diversamente.
Se avete implementato accessibilità sul vostro WordPress e avete domande su FSE o Accessibility Checker, contattatemi nei commenti qui sotto. Sono sempre interessato a sentire come i miei lettori affrontano questa transizione normativa.