Criteri di successo WCAG · Level A

WCAG 1.4.2: Controllo dell'audio

WCAG 1.4.2 richiede che qualsiasi audio che si avvia automaticamente e dura più di tre secondi offra agli utenti un meccanismo per metterlo in pausa, interromperlo o controllarne il volume in modo indipendente dal volume di sistema. Questo impedisce all’audio di interferire con l’output del lettore di schermo e protegge gli utenti da suoni imprevisti e disorientanti.

Cosa Significa Questa Regola

WCAG 1.4.2 — Controllo dell’audio è un criterio di successo di Livello A sotto il principio Percettibile. Stabilisce: Se un qualsiasi audio in una pagina Web viene riprodotto automaticamente per più di 3 secondi, deve essere disponibile un meccanismo per mettere in pausa o interrompere l’audio, oppure un meccanismo per controllare il volume dell’audio in modo indipendente dal livello di volume complessivo del sistema.

Il criterio è attivato da qualsiasi contenuto audio che inizia a essere riprodotto senza un’azione esplicita dell’utente e continua per più di tre secondi. Questo include musica di sottofondo incorporata in una pagina, video in riproduzione automatica con una traccia audio udibile, annunci audio, effetti sonori in loop e introduzioni vocali che partono al caricamento della pagina. La frase chiave è automaticamente — l’audio avviato deliberatamente dall’utente (cliccando un pulsante di riproduzione, attivando un link) non è soggetto a questa regola.

Per soddisfare questo criterio, deve essere vera almeno una delle seguenti condizioni:

  • All’utente viene fornito un controllo di pausa o stop che interrompe completamente l’audio o lo sospende finché l’utente non lo riprende.
  • All’utente viene fornito un controllo del volume indipendente dal volume principale del sistema operativo, in modo che possa ridurre o disattivare l’audio senza influire su altre applicazioni o sui suoni di sistema.

È accettabile un meccanismo che compare solo nella parte superiore della pagina ed è accessibile da tastiera, ma deve essere raggiungibile e azionabile prima che l’audio diventi di disturbo. Le buone pratiche raccomandano fortemente di posizionare il controllo come primissimo elemento interattivo nell’ordine di focus, così che gli utenti di tastiera e di screen reader lo incontrino immediatamente.

L’unica eccezione ufficiale definita nelle WCAG è l’audio che dura tre secondi o meno. Brevi suoni di notifica o brevi segnali acustici che si interrompono da soli sono esentati. Non esiste alcuna eccezione per audio a basso volume, audio in loop o audio incorporato in widget di terze parti — tutti questi rientrano nella regola se vengono riprodotti automaticamente e superano i tre secondi.

Perché È Importante

L’audio in riproduzione automatica e non controllato crea barriere significative per diversi gruppi di persone con disabilità e causa attrito anche per utenti senza disabilità in ambienti silenziosi o condivisi.

Gli utenti di screen reader sono il gruppo più gravemente colpito. Gli screen reader come JAWS, NVDA e VoiceOver producono output vocale sintetico per trasmettere il contenuto della pagina. Quando una pagina web riproduce contemporaneamente audio di sottofondo o la traccia audio di un video, i due flussi audio si sovrappongono. La voce dello screen reader diventa difficile o impossibile da comprendere, escludendo di fatto l’utente dalla pagina finché non riesce a individuare e attivare un controllo di stop — che non può trovare facilmente perché lo screen reader non riesce a leggere la pagina a causa del rumore. Secondo l’Organizzazione Mondiale della Sanità, circa 2,2 miliardi di persone nel mondo hanno qualche forma di disabilità visiva, e una parte significativa fa affidamento sugli screen reader come principale strumento di navigazione.

Gli utenti con disabilità cognitive e dell’attenzione, inclusi coloro con ADHD, condizioni dello spettro autistico o disturbi d’ansia, possono trovare l’audio inatteso estremamente disorientante o angosciante. L’insorgenza improvvisa di musica o parlato può interrompere la concentrazione, innescare sovraccarico sensoriale o causare confusione sul fatto che il suono faccia parte del contenuto della pagina o sia una notifica esterna.

Gli utenti con disturbi dell’elaborazione uditiva o apparecchi acustici possono sperimentare loop di feedback o distorsioni amplificate quando l’audio viene riprodotto a volumi inattesi attraverso i dispositivi uditivi. Un controllo del volume indipendente consente loro di gestire l’ambiente di ascolto senza modificare le impostazioni a livello di sistema che influiscono su altre applicazioni.

Gli utenti con disabilità motorie che navigano tramite tastiera o accesso a sensore hanno bisogno che il controllo di stop/pausa sia raggiungibile da tastiera e posizionato logicamente all’inizio della struttura della pagina. Se il controllo è azionabile solo con il mouse o è nascosto in fondo all’ordine di tabulazione, non offre alcun sollievo pratico nel tempo necessario per raggiungerlo.

Consideriamo uno scenario concreto: una persona cieca in cerca di lavoro visita la pagina “carriere” di un’azienda che riproduce automaticamente un video promozionale con musica vivace. L’utente attiva il proprio screen reader, che inizia immediatamente a leggere il titolo della pagina e la navigazione. La musica copre completamente la sintesi vocale. Il pulsante di stop è un <div> stilizzato senza focus da tastiera, posizionato visivamente nel lettore video al centro della pagina. L’utente non può raggiungerlo con la tastiera, non riesce a sentire lo screen reader abbastanza bene da navigare in modo efficiente e alla fine abbandona la pagina. L’azienda perde una candidata o un candidato qualificato e si espone a potenziali rischi legali.

Dal punto di vista dell’usabilità e della SEO, le pagine con audio in riproduzione automatica registrano spesso tassi di rimbalzo elevati, poiché molti utenti — con o senza disabilità — chiudono immediatamente le schede quando inizia un suono inatteso. I motori di ricerca interpretano tassi di rimbalzo elevati come un segnale di qualità negativo, danneggiando indirettamente la visibilità.

Regole Axe-core Correlate

WCAG 1.4.2 richiede test manuali. Nessuna regola automatizzata di axe-core mappa direttamente a questo criterio. Il motivo per cui gli strumenti automatizzati non possono rilevare questa violazione è fondamentale per il modo in cui funzionano browser e JavaScript:

  • Avvio dinamico dell’audio: L’audio può essere attivato da timer JavaScript, listener di eventi o script di terze parti che vengono eseguiti dopo l’analisi iniziale del DOM. Uno scanner automatizzato che ispeziona il DOM statico non può determinare in modo affidabile se l’audio verrà riprodotto automaticamente, per quanto tempo o se un controllo è funzionalmente collegato a quella specifica sorgente audio.
  • Presenza e operatività dei controlli: Uno slider del volume o un pulsante di pausa possono esistere nel DOM ma essere non funzionanti, nascosti fuori dallo schermo o inaccessibili agli utenti di tastiera. Gli strumenti automatizzati possono rilevare la presenza di un elemento ma non possono verificare che la sua attivazione interrompa effettivamente l’audio senza eseguire l’interazione e ascoltare un risultato — un compito che richiede un giudizio uditivo umano.
  • Soglia temporale: Determinare se l’audio viene riprodotto per più di tre secondi richiede una valutazione basata sul tempo durante il caricamento della pagina, che è al di fuori dell’ambito degli strumenti di analisi del DOM statici o anche runtime.
  • Contenuti incorporati di terze parti: L’audio incorporato tramite iframe, SDK di terze parti o reti pubblicitarie potrebbe non essere ispezionabile dal sandbox JavaScript dello strumento di test, rendendo impossibile il rilevamento in modo programmatico.

A causa di queste limitazioni, gli auditor devono visitare personalmente le pagine, ascoltare l’eventuale audio in riproduzione automatica e verificare manualmente che i controlli di pausa/stop/volume esistano, siano raggiungibili da tastiera e funzionino correttamente.

Come Testare

  1. Pre-scansione automatizzata: Esegui axe DevTools o Google Lighthouse sulla pagina. Sebbene nessuno dei due strumenti segnalerà direttamente una violazione di 1.4.2, evidenzieranno problemi correlati come assenza di focus da tastiera sui controlli, elementi del lettore multimediale inaccessibili o etichette ARIA mancanti su widget audio personalizzati. Risolvi questi problemi prima di iniziare i test manuali, così da non confondere questioni distinte.
  2. Rilevamento manuale dell’audio: Carica la pagina con altoparlanti o cuffie attivi. Nota se qualche audio inizia a essere riprodotto entro i primi secondi senza alcuna interazione dell’utente. In caso affermativo, usa un timer per confermare che venga riprodotto per più di tre secondi. Controlla tutti i principali tipi di pagina: homepage, landing page, pagine prodotto e qualsiasi pagina nota per contenere contenuti multimediali incorporati o spazi pubblicitari.
  3. Individua il controllo di stop/pausa/volume: Senza usare il mouse, premi Tab immediatamente dopo il caricamento della pagina. Conta quanti stop di tabulazione si verificano prima di raggiungere il controllo audio. Verifica che il controllo riceva un indicatore di focus visibile. Premi Invio o Barra spaziatrice per attivarlo e conferma che l’audio si interrompe o che il suo volume può essere regolato in modo indipendente.
  4. Test con screen reader usando NVDA e Firefox: Avvia NVDA, apri Firefox e naviga alla pagina. Lascia che l’audio inizi. Prova a usare i comandi di lettura di NVDA (tasti freccia, cursore virtuale) per individuare e attivare il controllo audio. Conferma che NVDA annunci correttamente il ruolo e l’etichetta del controllo (ad esempio, “Pausa audio, pulsante”) e che la sua attivazione silenzi l’audio concorrente.
  5. Test con screen reader usando VoiceOver e Safari (macOS/iOS): Abilita VoiceOver con Command + F5. Naviga alla pagina e scorri o usa i tasti freccia per trovare il controllo audio. Verifica che VoiceOver pronunci un’etichetta significativa e che il controllo funzioni come previsto. Su iOS, testa anche il comportamento di riproduzione automatica, poiché i browser mobili gestiscono i permessi audio in modo diverso.
  6. Test con screen reader usando JAWS e Chrome: Con JAWS attivo, carica la pagina in Chrome. Usa il tasto Tab e l’elenco dei controlli modulo di JAWS (Insert + F5) per individuare gli elementi interattivi. Conferma che il controllo audio compaia nell’elenco e sia azionabile.
  7. Verifica dei contenuti di terze parti: Se la pagina contiene video di social media incorporati, unità pubblicitarie o contenuti in iframe, caricali separatamente quando possibile e verifica che siano anch’essi conformi, oppure che la pagina ospite fornisca un controllo di override.
  8. Verifica dell’indipendenza del volume: Se la pagina offre un controllo del volume invece di un controllo di pausa/stop, verifica che la regolazione del controllo del volume della pagina non modifichi il volume principale del sistema operativo. Apri un’altra applicazione (ad esempio, un lettore multimediale locale) e conferma che il suo volume non sia influenzato dopo l’uso del controllo della pagina.

Come Correggere

Audio di sottofondo in riproduzione automatica senza controlli — Non corretto

<!-- Audio avviato automaticamente senza controllo visibile o accessibile da tastiera -->
<audio src='background-music.mp3' autoplay loop></audio>

Audio di sottofondo in riproduzione automatica con controllo di pausa accessibile — Corretto

<!-- Il controllo è il primo elemento focalizzabile, annunciato correttamente dagli screen reader -->
<button id='audio-toggle' aria-label='Pause background music' aria-pressed='true' onclick='toggleAudio()'>
  Pause Music
</button>

<audio id='bg-audio' src='background-music.mp3' autoplay loop></audio>

<script>
  function toggleAudio() {
    var audio = document.getElementById('bg-audio');
    var btn = document.getElementById('audio-toggle');
    if (audio.paused) {
      audio.play();
      btn.setAttribute('aria-pressed', 'true');
      btn.setAttribute('aria-label', 'Pause background music');
      btn.textContent = 'Pause Music';
    } else {
      audio.pause();
      btn.setAttribute('aria-pressed', 'false');
      btn.setAttribute('aria-label', 'Play background music');
      btn.textContent = 'Play Music';
    }
  }
</script>

<!-- L’elemento <button> nativo è accessibile da tastiera per impostazione predefinita.
     aria-pressed comunica lo stato di attivazione agli screen reader.
     aria-label si aggiorna dinamicamente per riflettere l’azione corrente. -->

Video in riproduzione automatica con colonna sonora e nessun controllo di stop accessibile da tastiera — Non corretto

<!-- Il video parte automaticamente con audio; l’unico controllo di stop è un overlay utilizzabile solo col mouse -->
<div class='hero-video-wrapper'>
  <video src='promo.mp4' autoplay loop></video>
  <div class='stop-btn' onclick='stopVideo()'>Stop</div>
</div>
<!-- Problema: <div> non è focalizzabile da tastiera e non ha ruolo o etichetta -->

Video in riproduzione automatica con controllo di stop accessibile — Corretto

<div class='hero-video-wrapper'>
  <!-- Il controllo di stop compare per primo nel DOM e nell’ordine di focus -->
  <button
    id='video-stop-btn'
    aria-label='Stop promotional video'
    onclick='stopVideo()'
  >
    Stop Video
  </button>

  <video id='promo-video' src='promo.mp4' autoplay loop muted='false'></video>
</div>

<script>
  function stopVideo() {
    var video = document.getElementById('promo-video');
    var btn = document.getElementById('video-stop-btn');
    video.pause();
    video.currentTime = 0;
    btn.disabled = true;
    btn.textContent = 'Video Stopped';
  }
</script>

<!-- L’uso di un <button> nativo garantisce l’accesso da tastiera senza ARIA aggiuntivo.
     Posizionare il pulsante prima del video nell’ordine DOM lo colloca all’inizio della sequenza di tabulazione. -->

Widget audio di terze parti incorporato con controllo del volume indipendente — Corretto

<!-- Quando un widget di terze parti riproduce automaticamente, fornisci un controllo di disattivazione audio a livello di pagina ospite -->
<button
  id='mute-widget-audio'
  aria-label='Mute podcast player'
  aria-pressed='false'
  onclick='muteWidget()'
>
  Mute Podcast
</button>

<iframe
  id='podcast-frame'
  src='https://embed.example.com/podcast/ep42?autoplay=1'
  title='Episode 42: Web Accessibility Deep Dive'
  allow='autoplay'
></iframe>

<script>
  function muteWidget() {
    <!-- API postMessage usata per comunicare con il player nell’iframe cross-origin -->
    var frame = document.getElementById('podcast-frame');
    var btn = document.getElementById('mute-widget-audio');
    var isMuted = btn.getAttribute('aria-pressed') === 'true';
    frame.contentWindow.postMessage({ action: isMuted ? 'unmute' : 'mute' }, 'https://embed.example.com');
    btn.setAttribute('aria-pressed', String(!isMuted));
    btn.setAttribute('aria-label', isMuted ? 'Mute podcast player' : 'Unmute podcast player');
  }
</script>

<!-- Nota: un controllo di volume/mute a livello di pagina ospite soddisfa 1.4.2 quando
     i controlli del player nell’iframe potrebbero essere inaccessibili. -->

Errori Comuni

  • Usare un <div> o un <span> come pulsante di stop dell’audio senza aggiungere tabindex='0', un role='button' e gestori di eventi da tastiera. Tali elementi sono invisibili alla navigazione da tastiera e agli screen reader, rendendo il controllo inutile proprio per gli utenti che ne hanno più bisogno.
  • Posizionare il controllo audio dopo il contenuto principale nel DOM, così che gli utenti di tastiera debbano scorrere con Tab decine di link e campi modulo prima di raggiungerlo — quando l’audio è già in riproduzione da un minuto o più. Il controllo dovrebbe essere il primo o il secondo elemento focalizzabile nella pagina.
  • Disattivare l’audio con l’attributo HTML muted per impostazione predefinita e considerarlo conforme. Un elemento audio in riproduzione automatica ma silenziato non è un controllo azionabile dall’utente; l’utente non ha modo di sapere che l’audio esiste o di scegliere la propria preferenza di volume.
  • Fornire uno slider del volume che richiama window.AudioContext.destination.gain e modifica i livelli audio di sistema, invece di regolare solo la proprietà .volume del singolo elemento multimediale. Questo non soddisfa il requisito di indipendenza.
  • Dare per scontato che i browser mobili blocchino la riproduzione automatica e quindi che non sia necessario alcun controllo. Molti browser mobili consentono la riproduzione automatica quando l’audio è incorporato in un elemento video o quando l’utente ha già interagito con il dominio. Implementa sempre i controlli, indipendentemente dal comportamento presunto del browser.
  • Non aggiornare l’etichetta accessibile del pulsante quando il suo stato cambia. Un pulsante etichettato “Pause” che ora riprende l’audio dovrebbe aggiornare il proprio aria-label a “Play” — altrimenti gli utenti di screen reader sentono un annuncio errato e potrebbero attivare l’azione sbagliata.
  • Fare affidamento esclusivo sui controlli multimediali nativi del browser (attributo controls) senza verificare che compaiano prima che l’audio in riproduzione automatica diventi invasivo. I controlli nativi vengono visualizzati sotto l’elemento multimediale, che può trovarsi sotto la piega, rendendoli irraggiungibili da tastiera prima che si verifichi un’interruzione significativa.
  • Non testare con annunci pubblicitari audio serviti tramite reti pubblicitarie. Gli spazi pubblicitari iniettati dinamicamente dopo il caricamento della pagina fanno parte dell’esperienza della pagina e sono soggetti a 1.4.2. Se la rete pubblicitaria non può garantire la conformità, fornisci un controllo di disattivazione audio globale per la pagina.
  • Trattare l’esenzione dei tre secondi come una scappatoia dividendo una traccia audio continua in segmenti inferiori a tre secondi ciascuno. L’intento delle WCAG è chiaro: l’audio che viene riprodotto in modo continuo o in loop è soggetto al criterio indipendentemente da come è tecnicamente suddiviso.
  • Non fornire un indicatore di focus visibile sul controllo audio. Anche se il controllo è raggiungibile da tastiera, gli utenti vedenti che usano la tastiera non possono trovarlo se non c’è un anello di focus, violando sia l’intento di usabilità di questo criterio sia WCAG 2.4.7 (Focus Visibile).

Relazione con le Normative di Accessibilità della Turchia

La Circolare Presidenziale 2025/10 della Turchia, pubblicata nella Gazzetta Ufficiale n. 32933 il 21 giugno 2025, stabilisce requisiti obbligatori di accessibilità web allineati a WCAG 2.2 per un’ampia gamma di soggetti pubblici e privati che operano in Turchia. WCAG 1.4.2 — Controllo dell’audio è un criterio di Livello A, collocandolo nel livello più fondamentale dei requisiti. La non conformità ai criteri di Livello A costituisce un fallimento di base ai sensi della Circolare.

La Circolare stabilisce le tempistiche di conformità come segue: le istituzioni pubbliche devono raggiungere la piena conformità al Livello A entro un anno dalla data di pubblicazione della Circolare, mentre i soggetti del settore privato coperti dalla regolamentazione hanno due anni per conformarsi.

I seguenti tipi di soggetti sono esplicitamente coperti dalla Circolare Presidenziale e sono quindi tenuti a soddisfare WCAG 1.4.2:

  • Istituzioni pubbliche e organismi governativi a tutti i livelli, inclusi ministeri, municipalità e agenzie collegate allo Stato i cui servizi digitali sono accessibili al pubblico.
  • Piattaforme di e-commerce operanti in Turchia, inclusi operatori di marketplace e rivenditori online diretti al consumatore.
  • Banche e istituzioni finanziarie regolamentate dalla legge bancaria turca, inclusi i loro portali di online banking, interfacce web mobili e pagine di prodotti digitali.
  • Ospedali e fornitori di servizi sanitari, inclusi gruppi ospedalieri privati e portali di sanità pubblica in cui i pazienti prenotano appuntamenti, accedono alle cartelle o ricevono informazioni sanitarie.
  • Società di telecomunicazioni con 200,000 o più abbonati, i cui siti web rivolti ai clienti, portali self-service e pagine promozionali devono essere conformi.
  • Agenzie di viaggio e piattaforme di viaggio online che servono i consumatori in Turchia, inclusi motori di prenotazione e pagine di contenuti sulle destinazioni.
  • Società di trasporto private che forniscono servizi di biglietteria e informazioni ai passeggeri online.
  • Scuole private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE), inclusi i loro portali di iscrizione, sistemi di gestione dell’apprendimento e siti web informativi.

Per tutti questi soggetti, una pagina che riproduce automaticamente audio — che si tratti di un video promozionale sulla homepage di una banca, di una colonna sonora di sottofondo su una pagina prodotto di e-commerce o di una clip di notizie incorporata su un portale governativo — senza fornire un controllo di pausa o volume accessibile e raggiungibile da tastiera rappresenta una violazione diretta sia di WCAG 1.4.2 sia degli obblighi imposti dalla Circolare Presidenziale 2025/10. I soggetti interessati sono fortemente invitati a verificare tutti i template di pagina per contenuti multimediali in riproduzione automatica e a implementare controlli conformi ben prima della scadenza applicabile, per evitare rilievi regolatori e servire equamente tutti gli utenti.