Filippo Tinnirello
Torna alle risorse
Qualità tecnicaAccessibilitàRisorsaAggiornato 17 giugno 2026

Accessibilità WordPress per agenzie: quello che si implementa davvero.

L'accessibilità non è uno strato opzionale da aggiungere a fine progetto. Quando si costruisce un sito WordPress che deve rispettare le linee guida WCAG, le scelte che contano si fanno in fase di sviluppo, non durante un audit post-lancio.

1. Perché l'accessibilità conta in un progetto agenzia

In molti contesti è un requisito di legge, non solo una buona pratica. Siti per pubblica amministrazione, istituzioni, università e aziende di una certa dimensione devono rispettare le linee guida WCAG 2.1 o 2.2 in base alla normativa europea (EN 301 549).

Al di là degli obblighi, un sito accessibile è spesso tecnicamente più solido: HTML semantico, navigazione chiara, testi alternativi coerenti. Sono interventi che migliorano anche la leggibilità per i motori di ricerca e la manutenibilità del codice nel tempo.

2. HTML semantico: la base che cambia tutto

La maggior parte dei problemi di accessibilità nasce da HTML che usa elementi generici dove servirebbe semantica specifica. Un div cliccabile non è un button. Un h3 scelto per il font-size non è un heading.

Elementi che fanno la differenza:

  • button per tutti gli elementi interattivi (non div o span con onclick).
  • nav, main, footer, aside, article per la struttura della pagina.
  • h1...h6 in ordine gerarchico, scelti per il significato non per le dimensioni visive.
  • label collegato correttamente a ogni campo di modulo.
  • alt text descrittivo sulle immagini informative, vuoto (alt='') su quelle puramente decorative.

3. Navigazione da tastiera e gestione del focus

Un sito accessibile si naviga completamente da tastiera. Ogni elemento interattivo — link, pulsante, campo di modulo, menu — deve essere raggiungibile e azionabile con Tab e Enter.

Cosa verificare in concreto:

  • L'ordine del focus segue l'ordine logico della pagina, non la posizione visiva degli elementi nel CSS.
  • Il focus visivo (outline) è visibile su tutti gli elementi interattivi. Non va mai rimosso con outline: 0 senza una sostituzione ugualmente visibile.
  • I pannelli e i modal che si aprono trappano correttamente il focus: Tab non deve poter uscire dal modal finché è aperto.
  • Dopo la chiusura di un modal il focus torna all'elemento che lo ha aperto.

4. Contrasto, ARIA e immagini

Contrasto: il testo su sfondo deve avere almeno 4.5:1 per testo normale e 3:1 per testo grande (sopra 18pt o 14pt grassetto). Pulsanti e icone interattive seguono lo stesso criterio.

ARIA si usa con moderazione. Gli attributi role, aria-label, aria-describedby e aria-expanded servono dove l'HTML semantico non basta. Aggiungere ARIA su markup già sbagliato peggiora la situazione invece di migliorarla.

Un caso concreto: un pulsante che apre un pannello deve avere aria-expanded='true' o 'false' per comunicare il suo stato agli screen reader. Senza quell'attributo, chi usa uno screen reader non sa se il pannello è aperto o chiuso.

5. Come si testa l'accessibilità in un progetto WordPress

Gli strumenti automatici (axe, Lighthouse, WAVE) trovano una parte dei problemi — stimata tra il 30 e il 40% del totale. Il resto richiede verifica manuale.

Un test minimo ragionevole per un progetto agenzia:

  • Navigazione completa da tastiera: nessun elemento raggiungibile solo con il mouse.
  • Verifica del contrasto con uno strumento dedicato (Colour Contrast Analyser o l'inspector del browser).
  • Test con NVDA su Windows o VoiceOver su Mac/iOS sui flussi principali: homepage, modulo di contatto, navigazione.
  • Revisione del markup con un validator e un'analisi strutturale degli heading.

Domande frequenti

I builder WordPress sono accessibili?

Dipende da come vengono usati. Il markup che generano non è sempre ottimale, ma con attenzione all'output HTML e alle impostazioni ARIA disponibili è possibile raggiungere un buon livello di conformità.

WCAG 2.2 è obbligatoria in Italia?

Per enti pubblici e concessionari di servizi pubblici, la normativa EN 301 549 richiede conformità AA. Per siti privati non c'è ancora un obbligo generalizzato, ma le direttive europee stanno progressivamente allargando il perimetro dei soggetti obbligati.

L'accessibilità rallenta i tempi di sviluppo?

Quando è integrata nel processo fin dall'inizio, molto meno di quanto si pensi. I problemi più costosi emergono quando l'accessibilità viene affrontata come un audit separato a progetto finito, non quando è parte dello sviluppo ordinario.

Prossimo passo

Hai un progetto WordPress con requisiti di accessibilità?

Posso valutare il livello attuale e affiancare il team nelle modifiche necessarie, integrandole nel processo di sviluppo.

Parliamo del progetto