WCAG 1.4.7: Audio di sottofondo basso o assente

Cosa Significa Questa Regola

Il Criterio di Successo WCAG 1.4.7 — Audio di sottofondo basso o assente — si applica ai contenuti solo audio preregistrati che contengono parlato in primo piano. Non si applica all’audio che è esso stesso una performance musicale, come una canzone, né all’audio che è principalmente un paesaggio sonoro ambientale senza una componente di parlato prevista. Quando è presente contenuto audio basato sul parlato, il criterio richiede che sia soddisfatta almeno una delle seguenti tre condizioni:

• Nessun audio di sottofondo: La traccia audio contiene parlato senza alcun suono di sottofondo — silenzio dietro la voce.
• Controllo da parte dell’utente: Qualsiasi audio di sottofondo può essere disattivato dall’utente, in modo indipendente dal parlato in primo piano, senza influire sul contenuto del parlato.
• Regola dei 20 dB: I suoni di sottofondo sono almeno 20 decibel più bassi in volume rispetto al parlato in primo piano. Una differenza di 20 dB equivale approssimativamente a un audio di sottofondo quattro volte più silenzioso del parlato, il che rappresenta un divario percettivo significativo per la maggior parte degli ascoltatori.

Si registra un superamento quando una qualsiasi di queste tre condizioni è pienamente soddisfatta. Si registra un fallimento quando il parlato in primo piano compete con un audio di sottofondo che non può essere disattivato e la cui differenza di volume è inferiore a 20 dB rispetto al segnale vocale. Si noti che gli effetti sonori occasionali — come un breve suono di notifica — che durano solo uno o due secondi sono esplicitamente esentati da questo requisito dalle specifiche WCAG.

Questo criterio si applica alla traccia audio indipendentemente dal fatto che l’audio sia fornito come file audio autonomo, come componente audio di un video, o incorporato tramite un lettore di podcast, l’elemento HTML5 <audio> o un widget multimediale di terze parti. Il requisito riguarda la produzione del contenuto audio stesso, non un elemento HTML specifico o un attributo ARIA — motivo per cui gli strumenti di scansione automatica non possono rilevare in modo affidabile le violazioni ed è sempre necessaria una revisione manuale del contenuto audio effettivo.

Perché È Importante

Secondo l’Organizzazione Mondiale della Sanità, circa 1,5 miliardi di persone nel mondo vivono con un certo grado di perdita dell’udito. Anche una perdita uditiva moderata può rendere estremamente difficile — talvolta impossibile — isolare la voce di chi parla quando musica di sottofondo, rumore ambientale o altri elementi audio sono mixati a livelli di volume simili o concorrenti. Per gli utenti che si affidano ad apparecchi acustici o impianti cocleari, le interferenze dell’audio di sottofondo vengono amplificate insieme al parlato, rendendo l’intelligibilità drasticamente peggiore anziché migliore.

Gli utenti con disabilità cognitive, inclusi coloro con disturbi dell’attenzione, disturbi dell’elaborazione uditiva o lesioni cerebrali traumatiche, affrontano anch’essi sfide significative quando le tracce audio contengono suoni concorrenti. Anche quando l’ascoltatore non presenta una perdita uditiva misurabile, il suo cervello può faticare a filtrare i segnali audio irrilevanti e a concentrarsi sul contenuto del parlato, con conseguente affaticamento, mancata comprensione o esclusione totale dal contenuto.

Si consideri uno scenario concreto reale: un’agenzia governativa turca pubblica una registrazione audio esplicativa su come i cittadini possono richiedere un sussidio sociale. La voce del narratore è mixata su una traccia musicale di sottofondo continua a livelli di volume approssimativamente uguali. Un utente con perdita uditiva neurosensoriale moderata visita la pagina utilizzando un apparecchio acustico. Poiché l’apparecchio acustico amplifica tutte le frequenze simultaneamente, la musica compete direttamente con il parlato del narratore. L’utente non riesce a comprendere le istruzioni e perde la scadenza per la domanda di sussidio. Se l’audio fosse stato registrato senza musica di sottofondo, o se fosse stato fornito un controllo del volume per sopprimere in modo indipendente la traccia di sottofondo, l’utente avrebbe avuto pari accesso alle informazioni.

Oltre alla disabilità, un audio chiaro con rumore di sottofondo minimo migliora la comprensione per tutti gli utenti — coloro che ascoltano in ambienti rumorosi su dispositivi mobili, i non madrelingua della lingua parlata e gli utenti in situazioni di banda limitata in cui la qualità audio può essere già degradata. Esistono anche benefici SEO indiretti: le trascrizioni di audio chiaramente intelligibile producono contenuti testuali di qualità superiore che i motori di ricerca possono indicizzare, migliorando la reperibilità dei tuoi contenuti.

Regole Axe-core Correlate

WCAG 1.4.7 richiede test manuali. Non esiste una regola automatizzata di axe-core che possa rilevare questa violazione, e ciò è intenzionale. Gli scanner di accessibilità automatizzati come axe-core, Lighthouse o IBM Equal Access Checker operano analizzando la struttura del DOM, gli attributi HTML, i ruoli ARIA e gli stili calcolati di una pagina web. Non hanno la capacità di:

• Analizzare il contenuto audio di un file: Gli scanner non possono aprire un file audio o video e misurare i livelli di decibel relativi del parlato in primo piano rispetto all’audio di sottofondo. Farlo richiederebbe un’elaborazione del segnale audio ben oltre l’ambito di un verificatore di accessibilità basato sul DOM.
• Rilevare se esiste un controllo separato per l’audio di sottofondo e se funziona correttamente: Anche se nel DOM è presente un controllo dell’interfaccia utente etichettato “Disattiva musica di sottofondo”, uno scanner non può verificare che effettivamente sopprima la traccia audio di sottofondo senza influire sulla traccia vocale, né può verificare che il controllo funzioni come previsto in tutti i browser.
• Distinguere il parlato dall’audio non vocale: Gli strumenti automatizzati non possono classificare in modo affidabile un file audio come principalmente parlato, principalmente musica o principalmente ambientale, che è la determinazione preliminare necessaria prima che il criterio si applichi.

Poiché tutta la valutazione deve essere effettuata da un revisore umano che ascolta il contenuto e, ove necessario, utilizza software di analisi audio per misurare i livelli in decibel, axe-core contrassegna questo criterio come richiedente revisione manuale. Quando esegui axe DevTools su una pagina contenente elementi <audio> o <video>, lo strumento può mostrare un avviso generale relativo ai media che ti ricorda di valutare manualmente i criteri di qualità audio, ma non produrrà automaticamente un verdetto di superamento o fallimento per 1.4.7.

Come Eseguire i Test

1. Inventariare tutti i contenuti audio sulla pagina. Carica la pagina e identifica ogni elemento <audio>, ogni elemento <video> con una traccia audio, ogni podcast o lettore multimediale incorporato e qualsiasi audio di sottofondo che venga riprodotto automaticamente. Determina se ciascun contenuto audio è preregistrato e contiene parlato in primo piano. Se si tratta di una traccia di pura musica o di suono ambientale senza parlato, 1.4.7 non si applica.
2. Esegui una scansione automatizzata per problemi di base. Usa axe DevTools, Lighthouse o l’audit integrato del widget Accsible per analizzare la pagina. Sebbene questi strumenti non valutino la qualità audio, possono segnalare didascalie mancanti, attributi controls assenti sugli elementi <audio> o problemi correlati all’accessibilità dei media. Risolvi eventuali problemi segnalati prima di procedere alla valutazione audio manuale.
3. Ascolta ogni traccia audio idonea nella sua interezza. Usa il lettore integrato nella pagina o scarica il file e aprilo in un lettore multimediale. Ascolta in particolare musica di sottofondo, suono ambientale o altro audio non vocale che venga riprodotto simultaneamente al parlato in primo piano.
4. Valuta se l’audio di sottofondo può essere disattivato in modo indipendente. Se il lettore fornisce un controllo separato per disattivare o abbassare la musica di sottofondo senza influire sulla traccia vocale, verifica che questo controllo funzioni come previsto su Chrome, Firefox e Safari. Esegui test con la sola tastiera per confermare che il controllo sia accessibile.
5. Misura i livelli in decibel se è presente audio di sottofondo e non può essere disattivato. Importa il file audio in un editor audio gratuito come Audacity. Usa la visualizzazione integrata della forma d’onda o dello spettrogramma e lo strumento “Analyze > Contrast” (o equivalente) per misurare il livello RMS medio dei segmenti di parlato rispetto al livello RMS medio dei segmenti di audio di sottofondo. Conferma che la differenza sia almeno di 20 dB. Se non hai accesso a software di analisi audio, usa il tuo giudizio professionale come ascoltatore esperto: se una persona tipica con lieve perdita uditiva troverebbe l’audio di sottofondo distraente o oscurante, trattalo come un probabile fallimento.
6. Testa con tecnologie assistive. Utilizzando NVDA con Firefox, VoiceOver con Safari su macOS e JAWS con Chrome, naviga fino a ciascun lettore audio. Conferma che tutti i controlli — incluso qualsiasi interruttore separato per l’audio di sottofondo — siano raggiungibili tramite tastiera (Tab/Shift+Tab), annunciati correttamente dallo screen reader e azionabili con Invio o Barra spaziatrice. Questo non testa direttamente la qualità audio, ma conferma che eventuali controlli di correzione che hai aggiunto siano accessibili.
7. Documenta i risultati. Registra quali file audio superano (nessun audio di sottofondo, controllo utente disponibile o differenza di 20 dB confermata), quali falliscono e quali sono esenti (effetti sonori brevi inferiori a 2 secondi o audio che è principalmente musica piuttosto che parlato).

Come Correggere

Scenario 1: Musica di sottofondo mixata troppo forte — Non corretto

<!-- Audio file contains a narrator speaking over background music
     mixed at roughly equal volume levels. No separate control exists.
     This fails WCAG 1.4.7 because background audio is not 20 dB below speech
     and cannot be turned off independently. -->
<audio controls src='product-explainer.mp3'>
  Your browser does not support the audio element.
</audio>

Scenario 1: Musica di sottofondo mixata troppo forte — Corretto

<!-- The audio file has been re-exported with no background music.
     If background music is desired for branding, produce two separate
     audio tracks: one speech-only and one with music. Offer the
     speech-only version as the default accessible option. -->
<audio controls src='product-explainer-speech-only.mp3'>
  Your browser does not support the audio element.
</audio>
<p>
  <a href='product-explainer-with-music.mp3'>
    Listen to version with background music (may be harder to follow for some users)
  </a>
</p>

Scenario 2: Audio di sottofondo con un controllo di disattivazione indipendente — Non corretto

<!-- A custom player claims to offer background audio control,
     but the button is not keyboard-accessible and has no accessible name.
     Sighted mouse users can click it, but screen reader users and
     keyboard-only users cannot reach or operate the control. -->
<div class='player'>
  <audio id='main-audio' src='lecture-with-ambience.mp3'></audio>
  <button onclick='document.getElementById("main-audio").play()'>Play</button>
  <div onclick='toggleBackground()' style='cursor:pointer'>
    <img src='music-icon.png'>
  </div>
</div>

Scenario 2: Audio di sottofondo con un controllo di disattivazione indipendente — Corretto

<!-- The background audio toggle is now a proper <button> element with
     an accessible name, keyboard focus, and an aria-pressed state so
     screen readers announce whether background audio is on or off. -->
<div class='player'>
  <audio id='main-audio' src='lecture-with-ambience.mp3'></audio>
  <audio id='bg-audio' src='background-ambience.mp3' loop></audio>
  <button onclick='document.getElementById("main-audio").play()'>Play lecture</button>
  <button
    id='bg-toggle'
    aria-pressed='true'
    onclick='toggleBackground()'
  >
    Background audio: on
  </button>
</div>
<script>
  function toggleBackground() {
    var bg = document.getElementById('bg-audio');
    var btn = document.getElementById('bg-toggle');
    if (bg.paused) {
      bg.play();
      btn.setAttribute('aria-pressed', 'true');
      btn.textContent = 'Background audio: on';
    } else {
      bg.pause();
      btn.setAttribute('aria-pressed', 'false');
      btn.textContent = 'Background audio: off';
    }
  }
</script>

Scenario 3: Audio di sottofondo in autoplay al caricamento della pagina — Non corretto

<!-- Background audio autoplays when the page loads and there is
     no way to turn it off. If a narrator audio also plays, the
     background audio will compete with it and cannot be suppressed. -->
<audio autoplay loop src='ambient-background.mp3'></audio>
<audio controls src='welcome-message.mp3'></audio>

Scenario 3: Audio di sottofondo in autoplay al caricamento della pagina — Corretto

<!-- Background audio does not autoplay. A clearly labeled, keyboard-
     accessible button allows the user to opt in if desired. The speech
     audio is presented independently and cleanly without competition. -->
<audio id='bg' loop src='ambient-background.mp3'></audio>
<button onclick='document.getElementById("bg").play()'>
  Play background music (optional)
</button>
<audio controls src='welcome-message.mp3'>
  Your browser does not support the audio element.
</audio>

Errori Comuni

• Mixare la musica di sottofondo a -10 dB invece che al richiesto -20 dB: I produttori spesso applicano una riduzione di volume modesta alla musica di sottofondo e presumono che sia sufficiente. Lo standard WCAG richiede una differenza completa di 20 dB (circa quattro volte più silenziosa), non solo una riduzione percepibile. Verifica sempre con uno strumento di analisi audio invece di fare affidamento solo sul giudizio soggettivo.
• Confondere il controllo del volume complessivo del lettore con un controllo indipendente dell’audio di sottofondo: Un cursore del volume principale che abbassa simultaneamente parlato e audio di sottofondo non soddisfa la condizione “l’utente può disattivare l’audio di sottofondo”. Il controllo deve sopprimere solo l’audio di sottofondo senza influire sul parlato in primo piano.
• Supporre che il criterio si applichi solo ai file audio autonomi: Molti sviluppatori trascurano il fatto che la traccia audio di un elemento video è ugualmente soggetta a 1.4.7. Un video esplicativo con musica di sottofondo alta mixata nella traccia audio non soddisfa il criterio proprio come accadrebbe con un file podcast.
• Trattare tutti i suoni brevi come esenti: L’esenzione WCAG per brevi effetti sonori si applica solo ai suoni che durano due secondi o meno. Un breve jingle ricorrente che si ripete ogni pochi secondi, o un loop di suoni brevi di sottofondo, non rientra in questa esenzione e deve comunque essere conforme.
• Non testare l’interruttore dell’audio di sottofondo con la sola tastiera: I team spesso implementano un pulsante di disattivazione visivamente accattivante usando un elemento non interattivo come un <div> o uno <span>, che non è raggiungibile con il tasto Tab e non è azionabile con Invio o Barra spaziatrice. Usa un elemento nativo <button> in modo che il supporto per tastiera e tecnologie assistive sia integrato.
• Dimenticare di aggiungere aria-pressed o uno stato equivalente ai pulsanti di attivazione/disattivazione dell’audio di sottofondo: Senza un indicatore di stato, gli utenti di screen reader possono azionare il pulsante ma non possono sapere se l’audio di sottofondo è attualmente attivo o disattivato. Rifletti sempre lo stato corrente nel nome accessibile del pulsante o tramite aria-pressed.
• Produrre un solo file audio mixato invece di offrire tracce separate: Quando l’audio di sottofondo è parte integrante dell’intento creativo, i team spesso esportano un unico file mixato invece di offrire un’alternativa solo parlato. Fornire una versione separata solo parlato richiede pochissimo sforzo di produzione aggiuntivo ed elimina completamente il rischio di non conformità.
• Applicare 1.4.7 ai flussi audio in diretta: Il criterio copre esplicitamente solo l’audio preregistrato. Le trasmissioni audio in diretta non sono soggette a questa regola specifica, sebbene altri criteri come 1.4.4 (Ridimensionare il testo) e i requisiti di sottotitolazione possano comunque applicarsi al contenuto associato.
• Trascurare di controllare i lettori incorporati di terze parti: Quando il contenuto è incorporato da piattaforme esterne (host di podcast, CDN video, servizi di condivisione audio), i team spesso presumono che la conformità sia responsabilità della piattaforma. Tuttavia, il proprietario della pagina è responsabile dell’accessibilità di tutti i contenuti sulle proprie pagine, inclusi i media incorporati. Verifica che il lettore di terze parti soddisfi i requisiti di qualità audio o offra i controlli necessari.
• Misurare i livelli di picco invece dei livelli RMS medi quando si verifica il requisito dei 20 dB: La soglia di 20 dB in WCAG 1.4.7 si riferisce alla sonorità percettiva dell’audio, meglio approssimata dai livelli RMS (Root Mean Square) medi, non dai livelli di picco istantanei. L’uso di misurazioni dei livelli di picco può produrre letture ingannevolmente favorevoli che non riflettono l’esperienza di ascolto reale.

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à digitale per un’ampia gamma di enti pubblici e privati che operano in Turchia. La Circolare adotta WCAG 2.2 come standard tecnico normativo e definisce specifici obblighi di conformità in base al tipo di organizzazione.

Tra i soggetti tenuti alla conformità obbligatoria ai sensi della Circolare figurano istituzioni pubbliche e agenzie governative a tutti i livelli, piattaforme di e-commerce, banche e fornitori di servizi finanziari, ospedali e istituzioni sanitarie, operatori di telecomunicazioni con 200.000 o più abbonati, agenzie di viaggio autorizzate, società di trasporto private e scuole private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE). Queste organizzazioni sono tenute a soddisfare almeno WCAG 2.2 Livello A e Livello AA.

WCAG 1.4.7 — Audio di sottofondo basso o assente — è un criterio di Livello AAA. Ciò significa che non rientra tra i criteri che i soggetti interessati sono legalmente obbligati a soddisfare ai sensi dei requisiti di base della Circolare 2025/10. Tuttavia, si applicano diverse considerazioni importanti. In primo luogo, le organizzazioni che si impegnano volontariamente alla conformità AAA — o che servono popolazioni con alte concentrazioni di utenti con disabilità uditive, come ospedali, cliniche di audiologia o agenzie di servizi sociali — dovrebbero considerare 1.4.7 come di fatto obbligatorio nel loro contesto. In secondo luogo, qualsiasi ente i cui servizi digitali includano contenuti audio didattici, registrazioni di assistenza clienti, moduli di e-learning o trasmissioni informative rivolte al pubblico scoprirà che il rispetto di 1.4.7 migliora in modo sostanziale l’usabilità reale di tali servizi per i cittadini turchi con disabilità uditive.

La Turchia ha una popolazione significativa di persone con disabilità uditive, e la Circolare riflette l’impegno del governo a garantire una partecipazione digitale paritaria. Sebbene i criteri AAA siano presentati come aspirazionali nello standard tecnico, le istituzioni pubbliche turche in particolare sono incoraggiate a superare i requisiti minimi ovunque i loro contenuti e le loro risorse lo consentano. Dimostrare la conformità a 1.4.7 segnala maturità organizzativa, riduce il rischio legale e reputazionale e posiziona i servizi digitali turchi come leader nel design inclusivo sia a livello nazionale sia nei mercati internazionali in cui la conformità AAA può essere richiesta contrattualmente.