Conformità audio WCAG 2.2 per WordPress: Guida 2026

L'audio su WordPress deve soddisfare almeno quattro criteri di successo WCAG 2.2: 1.4.2 Audio Control, 2.1.1 Keyboard, 2.5.8 Target Size (nuovo nel 2.2) e 4.1.2 Name, Role, Value. L'European Accessibility Act, in vigore dal 28 giugno 2025, lo rende un obbligo legale per qualsiasi sito che serva clienti nell'UE. Il player audio predefinito di WordPress e la maggior parte dei plugin audio di terze parti non rispettano diversi di questi requisiti senza interventi.

Questa guida è la checklist pratica che usiamo in Mementor quando verifichiamo la conformità WCAG 2.2 dei siti WordPress. Affrontiamo entrambi gli aspetti della questione: l'audio come contenuto con le proprie regole di accessibilità, e l'audio come strumento di accessibilità per i contenuti testuali.

Perché la conformità audio è urgente nel 2026

Nel 2025 si sono allineati tre fattori che rendono questo tema prioritario. L'EAA ha iniziato l'applicazione il 28 giugno 2025. Il rapporto WebAIM Million 2025 ha rilevato che il 96,3% delle homepage presentava violazioni WCAG rilevabili. Il contenzioso ADA negli Stati Uniti ha continuato a crescere, con i siti WordPress protagonisti di oltre 4.000 cause per accessibilità web avviate nel corso dell'anno.

Il pattern che riscontriamo nei nostri audit è sempre lo stesso. I proprietari di siti danno per scontato che il tema gestisca l'accessibilità. Il tema eredita ciò che il plugin audio fornisce. Il plugin audio fornisce pulsanti troppo piccoli, slider che intrappolano gli utenti da tastiera e rapporti di contrasto che non superano il primo controllo manuale.

La checklist WCAG 2.2 completa per l'audio

Otto criteri di successo riguardano direttamente l'audio su un sito WordPress. La tabella seguente descrive cosa significa ciascuno nella pratica, cosa il player audio predefinito di WordPress soddisfa o non soddisfa, e come il player TTSWP gestisce ogni punto. I criteri contrassegnati con NUOVO sono stati introdotti con WCAG 2.2 nell'ottobre 2023.

La pagina Media Accessibility User Requirements del W3C è la fonte ufficiale per questi criteri. Ci concentriamo sugli otto elencati perché si applicano ai player audio in quanto tali. I sottotitoli (1.2.2) e l'audiodescrizione (1.2.3) sono anch'essi rilevanti, ma si applicano ai video, non alla narrazione audio pura.

L'eccezione per l'alternativa multimediale al testo

Ecco la regola che il novantacinque percento degli articoli sulla conformità ignora. Le WCAG definiscono un'alternativa multimediale al testo come un contenuto multimediale che non presenta più informazioni di quelle già presenti nel testo. Quando la narrazione text-to-speech legge un articolo esistente, l'audio è un'alternativa multimediale al testo della pagina. Il testo della pagina stesso è la trascrizione.

Questo significa che la versione audio di un articolo generata da TTS non richiede un file di trascrizione separato. WebAIM lo spiega chiaramente. Il requisito è che l'audio sia chiaramente etichettato come alternativa multimediale, in modo che gli utenti capiscano di non perdere informazioni saltandolo. Un'intestazione come «Ascolta questo articolo» o un player etichettato «Versione audio di questo articolo» è sufficiente.

L'eccezione non si applica se l'audio aggiunge commenti, basi musicali significative o sezioni non presenti nel testo. La pura narrazione del contenuto della pagina si qualifica. Ci basiamo su questo regolarmente quando consigliamo editori preoccupati che aggiungere audio crei nuovi obblighi di trascrizione.

Le novità per l'audio in WCAG 2.2

Tre nuovi criteri di Livello AA riguardano direttamente i player audio.

2.5.8 Target Size (Minimum)

Ogni controllo interattivo deve avere un target di almeno 24x24 pixel CSS. È il criterio che mette in difficoltà più plugin audio WordPress. Nei nostri audit di siti WordPress con plugin audio di terze parti, i pulsanti di avanzamento e ritorno rapido risultano sistematicamente al di sotto della soglia. I designer li hanno ottimizzati per la compattezza prima che WCAG 2.2 introducesse la regola dei 24 pixel, e pochi sviluppatori di plugin si sono adeguati. Gli stili del tema predefinito a volte riducono ulteriormente i target.

La soluzione è solitamente il padding, non la dimensione dell'icona. Un'icona SVG da 16 pixel all'interno di un pulsante con 4 pixel di padding su ogni lato raggiunge la soglia dei 24 pixel senza cambiare l'aspetto visivo.

2.4.11 Focus Not Obscured

Le barre audio fisse in fondo alla pagina coprono l'elemento su cui è posizionato il focus dell'utente da tastiera. Se un link in focus si trova dietro la barra, il criterio non è soddisfatto. La soluzione è rendere la barra chiudibile, lasciare spazio sopra l'elemento in focus, oppure usare scroll-padding-bottom sul documento affinché gli elementi in focus rimangano visibili.

2.5.7 Dragging Movements

Le barre di avanzamento e gli slider del volume che funzionano solo con il trascinamento non soddisfano questo criterio. Ogni interazione con trascinamento necessita di un'alternativa a puntatore singolo. Il clic sulla posizione nella barra di avanzamento è sufficiente. Lo è anche il controllo con i tasti freccia su un role="slider" correttamente implementato.

Errori audio WordPress più comuni dagli audit reali

Gli stessi schemi si ripetono sui siti dei clienti. Quattro problemi sono quelli che incontriamo più spesso.

Il blocco <audio> predefinito di WordPress mostra il player nativo del browser. I controlli audio nativi hanno una lunga storia di comportamenti incoerenti con gli screen reader, e il controllo della posizione di riproduzione con i tasti freccia varia tra Chrome, Firefox e Safari. Gli utenti di NVDA o JAWS spesso sentono i timestamp ma non riescono a spostare la posizione in modo affidabile con la tastiera. La soluzione è racchiudere l'audio in un player personalizzato che esponga role="slider" con gli attributi ARIA corretti.

I player dei plugin hanno pulsanti al di sotto della soglia dei 24 pixel. Il designer li ha ottimizzati per la compattezza prima che WCAG 2.2 introducesse la regola. I temi poi sovrascrivono gli stili del plugin, a volte peggiorando le cose, a volte migliorandole.

Le barre audio fisse nascondono il contenuto in focus. Lo abbiamo riscontrato su ogni sito che usa un player fisso nel footer senza testare la navigazione da tastiera.

Il contrasto delle forme d'onda è costantemente inferiore a 4,5:1. I designer adorano l'onda grigio chiaro su sfondo bianco. Gli screen reader non se ne preoccupano, ma gli utenti con visione ridotta sì, e il criterio 1.4.3 non viene rispettato.

Costruire un player audio conforme: la checklist tecnica

1. Racchiudi il player in un role="region" con un aria-label descrittivo.
2. Usa un vero elemento <button> per play, pausa, avanzamento e silenziamento. Mai un <div> con un gestore di clic.
3. Imposta aria-pressed sul pulsante play per esporre lo stato di attivazione.
4. Dai a ogni controllo un target minimo di 24x24 pixel CSS usando il padding.
5. Usa role="slider" con aria-valuemin, aria-valuemax e aria-valuenow per la barra di avanzamento e il volume, e rispondi ai tasti freccia.
6. Fornisci il clic sulla posizione nella barra di avanzamento come alternativa al trascinamento.
7. Verifica il contrasto su ogni elemento di testo e icona significativa con un minimo di 4,5:1.
8. Assicurati che gli indicatori di focus siano visibili e mai tagliati dalle regole di overflow.
9. Se il player è fisso, lascia spazio per il focus sopra di esso o rendilo chiudibile.
10. Etichetta i player di narrazione TTS come «Versione audio di questo articolo» affinché l'eccezione per l'alternativa multimediale si applichi correttamente.

Un pulsante play accessibile minimale ha questa struttura.

<div role="region" aria-label="Article audio player">
  <button type="button"
          aria-pressed="false"
          aria-label="Play article narration"
          style="min-width:24px;min-height:24px;padding:8px">
    <svg aria-hidden="true" width="16" height="16">...</svg>
  </button>
  <input type="range"
         aria-label="Playback position"
         min="0" max="100" value="0">
</div>

Questa è la struttura base. Puoi stilizzare il pulsante e nascondere i controlli nativi del range se vuoi una barra personalizzata, ma mantieni la semantica sottostante.

Come la narrazione TTS migliora la conformità WCAG complessiva

L'audio non è solo contenuto da rendere accessibile. È esso stesso uno strumento di accessibilità. L'Organizzazione Mondiale della Sanità stima che 1,3 miliardi di persone, circa il 16% della popolazione mondiale, vivano con una disabilità significativa. Molte di loro traggono beneficio dall'accesso multimodale ai contenuti testuali: persone con dislessia, ADHD, visione ridotta e varie disabilità cognitive leggono con più facilità se l'audio accompagna il testo.

Aggiungere la narrazione text-to-speech è uno dei pochi investimenti in accessibilità che aiuta gli utenti prima ancora di soddisfare un audit. Aggiungere il TTS a WordPress richiede meno di 15 minuti con il plugin Text to Speech – TTSWP. Il player è fornito con impostazioni predefinite conformi a WCAG 2.1 AA, target da 24 pixel o più, supporto da tastiera e ruoli ARIA corretti.

Il payload runtime minimo è di circa 35-40 KB compressi (151 KB non minificati), che comprende sia la logica JavaScript del player che i CSS condivisi. Abbiamo eseguito GTmetrix su un articolo pubblicato con il player attivo e abbiamo ottenuto Grade A con 93% di Performance, 99% di Structure, Largest Contentful Paint a 1,3 secondi, Total Blocking Time a 46 millisecondi e Cumulative Layout Shift a zero. Il bundle si carica in modo lazy solo sulle pagine che contengono il player, quindi le pagine statiche senza audio non subiscono alcun impatto sulle prestazioni.

La documentazione sull'accessibilità è disponibile nella nostra pagina dedicata all'accessibilità. La narrazione usa il motore generativo di ElevenLabs, che migliora la prosodia al punto che gli ascoltatori finiscono davvero gli articoli invece di abbandonarli per via di una voce robotica.

L'European Accessibility Act nella pratica

L'EAA è diventato applicabile il 28 giugno 2025. I nuovi servizi digitali immessi sul mercato UE dopo quella data devono essere conformi fin da subito. I servizi esistenti hanno tempo fino al 28 giugno 2030 per adeguarsi. La direttiva si applica a qualsiasi azienda che serva clienti nell'UE, indipendentemente da dove ha sede.

Lo standard tecnico a cui fa riferimento l'EAA è la EN 301 549. La versione armonizzata attuale (V3.2.1, agosto 2021) si basa su WCAG 2.1 Livello AA. La bozza V4.1.0 pubblicata a novembre 2025 aggiorna le clausole 9, 10 e 11 per allinearle a WCAG 2.2, con la pubblicazione definitiva attesa nel corso del 2026. Fino a quando questo aggiornamento non sarà citato nella Gazzetta Ufficiale dell'UE, WCAG 2.1 AA rimane il minimo legalmente vincolante, ma consigliamo di puntare già ora a WCAG 2.2 visto che la transizione è questione di mesi, non di anni.

Le sanzioni variano da paese a paese. Germania e Francia dispongono delle infrastrutture di controllo più attive, con autorità nazionali per l'accessibilità autorizzate a indagare sui reclami e comminare multe. Abbiamo visto clienti tedeschi e nordici ricevere reclami formali da parte di utenti finali nel giro di pochi mesi dall'entrata in vigore, di solito riguardanti componenti audio e moduli. I reclami arrivano prima delle sanzioni, quindi una finestra di trenta giorni per intervenire è di solito raggiungibile se il team è preparato.

Come verificare la conformità

Gli strumenti automatizzati individuano circa il 30-40% dei problemi. Il test manuale è necessario per il resto, in particolare per l'interazione da tastiera e il contrasto significativo negli stati dinamici.

• NVDA su Windows con Chrome e Firefox. Gratuito.
• JAWS su Windows per i requisiti dei clienti enterprise.
• VoiceOver su macOS e iOS. Integrato nel sistema.
• TalkBack su Android. Integrato nel sistema.
• axe DevTools come estensione del browser per scansioni automatizzate.
• Lighthouse in Chrome DevTools per controlli rapidi.
• Navigazione solo da tastiera. Scollega il mouse e usa ogni controllo del player.

La navigazione solo da tastiera è il test con il miglior rapporto sforzo-risultato. Se il player funziona senza mouse, la maggior parte di WCAG 2.2 è già soddisfatta.

Domande frequenti

WCAG 2.2 richiede i sottotitoli per i podcast audio?

No. I sottotitoli (1.2.2) si applicano ai video preregistrati con audio sincronizzato. Per i contenuti solo audio come i podcast, il criterio pertinente è 1.2.1, che richiede un'alternativa testuale come una trascrizione o un riassunto dettagliato. Sottotitoli e trascrizioni servono a scopi diversi. Un podcast ha bisogno della trascrizione. Un tutorial video ha bisogno sia dei sottotitoli che dell'audiodescrizione per le informazioni visive.

La riproduzione automatica dell'audio è vietata dall'EAA?

Non è vietata, ma è soggetta a restrizioni. Il criterio WCAG 1.4.2 Audio Control, a cui l'EAA fa riferimento tramite EN 301 549, richiede che qualsiasi audio riprodotto automaticamente per più di tre secondi offra un controllo di pausa, stop o volume indipendente. La riproduzione automatica senza quel controllo non supera il Livello A e costituisce una non conformità. La maggior parte degli organi di controllo la tratta come una violazione chiara, non come un caso limite.

Ho bisogno di una trascrizione se ho una versione audio del mio articolo?

Di solito no. Quando l'audio è una narrazione diretta del testo dell'articolo e non aggiunge nuove informazioni, il testo dell'articolo stesso è la trascrizione secondo la definizione WCAG di «alternativa multimediale al testo». Etichetta chiaramente il player come versione audio dell'articolo e l'eccezione si applica. Se l'audio include commenti, musica significativa o sezioni non presenti nel testo, è necessaria una trascrizione separata.

Qual è la dimensione minima dei pulsanti per i player audio in WCAG 2.2?

I target interattivi devono essere di almeno 24x24 pixel CSS secondo il criterio di successo 2.5.8 Target Size (Minimum) di Livello AA. Il target include il padding, quindi un'icona da 16 pixel con 4 pixel di padding su ogni lato soddisfa il requisito. Esistono eccezioni per i link inline nel testo e per i controlli determinati dallo user agent, ma i pulsanti di un player indipendente non beneficiano di eccezioni e devono raggiungere la soglia.

WCAG 2.2 si applica ai siti ospitati su WordPress.com?

Sì. Le WCAG si applicano a qualsiasi contenuto web indipendentemente dalla piattaforma di hosting. I siti WordPress.com hanno la stessa esposizione legale ai sensi dell'EAA, dell'ADA e delle leggi nazionali equivalenti dei siti WordPress self-hosted. Il modello di hosting non cambia l'obbligo. Ciò che cambia è il controllo che il proprietario del sito ha sul markup del player. I piani Business e Commerce di WordPress.com consentono plugin personalizzati, i piani inferiori no.

Da dove iniziare

Scegli un articolo del tuo sito, fai una navigazione solo da tastiera del player audio e controlla ogni pulsante rispetto alla regola dei 24 pixel. Quell'unico audit rivela se la tua configurazione attuale è vicina alla conformità WCAG 2.2 o lontana da essa. Da lì, la scelta è tra correggere il player esistente o sostituirlo con uno che rispetta i requisiti per impostazione predefinita. La nostra documentazione sull'accessibilità descrive la configurazione che consigliamo ai siti sotto pressione EAA.