WCAG 1.2.9: Solo audio (in diretta)

Cosa Significa Questa Regola

Il Criterio di Successo WCAG 1.2.9, Solo audio (dal vivo), rientra nella Linea guida 1.2 (Contenuti basati sul tempo) al Livello AAA. Stabilisce: «È fornita un’alternativa per i contenuti basati sul tempo che presenti informazioni equivalenti per contenuti solo audio dal vivo.» In termini pratici, ciò significa che ogni volta che il tuo sito web o la tua applicazione trasmette o fornisce contenuti audio dal vivo — e tali contenuti non hanno alcuna componente video — agli utenti deve essere fornita un’equivalente testuale in tempo reale che trasmetta fedelmente le stesse informazioni.

Una presentazione solo audio dal vivo è qualsiasi flusso audio trasmesso in tempo reale senza una traccia video sincronizzata. Esempi comuni includono programmi radio in diretta incorporati in una pagina web, commento audio dal vivo durante un evento sportivo, conferenze stampa in diretta trasmesse in formato audio, conference call sugli utili o briefing per investitori in diretta, e podcast o talk show audio dal vivo in cui nessun flusso video accompagna l’audio.

L’alternativa testuale richiesta da questo criterio deve essere equivalente — il che significa che deve catturare non solo le parole pronunciate ma anche le informazioni audio non verbali rilevanti, come rumore della folla, allarmi, effetti sonori o musica che abbiano valore informativo. Una trascrizione parziale o ritardata non soddisfa questo criterio; l’alternativa deve essere aggiornata in modo sincrono (o quasi sincrono) con il flusso dal vivo, in modo che le persone sorde o con ipoacusia possano seguire i contenuti in tempo reale.

Tecniche accettabili per soddisfare questo criterio includono la fornitura di uno stenografo umano che produca testo in tempo reale (CART — Communication Access Realtime Translation), l’incorporazione di sottotitoli dal vivo sincronizzati generati da un servizio di sottitolazione qualificato, o la visualizzazione di un flusso di testo dal vivo che scorra in parallelo con la trasmissione audio. I sottotitoli generati automaticamente da software di riconoscimento vocale possono anch’essi soddisfare il criterio, a condizione che l’accuratezza sia sufficientemente elevata e che l’output sia presentato in tempo quasi reale.

Cosa è considerato conforme: La pagina fornisce un’alternativa testuale visibile e sincrona — chiaramente collegata o visualizzata accanto al lettore audio — che presenta informazioni equivalenti al flusso audio dal vivo man mano che si svolge. L’alternativa deve essere percepibile dalle persone che non possono sentire l’audio.

Cosa è considerato non conforme: Non viene offerta alcuna alternativa testuale; viene fornita un’alternativa testuale ma con un ritardo significativo (ad esempio, una trascrizione pubblicata dopo l’evento); l’alternativa testuale copre solo una parte dell’audio (ad esempio, solo il discorso del presentatore ma non le domande del pubblico); oppure esiste un’alternativa testuale ma non è accessibile alle tecnologie assistive (ad esempio, è resa come elemento canvas non focalizzabile o bloccata all’interno di un widget Flash).

Eccezioni ufficiali: Le WCAG non prevedono eccezioni specifiche per il criterio 1.2.9 oltre al principio generale secondo cui il requisito si applica solo ai contenuti dal vivo solo audio. I contenuti solo audio preregistrati sono coperti dal criterio separato 1.2.1. Non esiste alcuna eccezione per clip audio brevi o annunci di breve durata — se il contenuto è dal vivo e solo audio, il criterio si applica.

Perché È Importante

Circa 466 milioni di persone nel mondo hanno una perdita uditiva disabilitante, secondo l’Organizzazione Mondiale della Sanità, e si prevede che questo numero supererà i 900 milioni entro il 2050. Per queste persone, i contenuti solo audio dal vivo sono completamente inaccessibili senza un equivalente testuale. A differenza dei contenuti preregistrati — per i quali una trascrizione può essere preparata in anticipo e allegata in un secondo momento — l’audio dal vivo presenta una sfida unica perché le informazioni sono sensibili al tempo ed effimere. Una persona sorda non può semplicemente riascoltare un flusso dal vivo in un secondo momento e aspettarsi la stessa esperienza; per definizione, i contenuti dal vivo perdono la loro immediatezza una volta che il momento è passato.

Considera uno scenario concreto reale: una società quotata in borsa organizza una conference call sugli utili trasmessa in diretta come solo audio sulla propria pagina di relazioni con gli investitori. Analisti, giornalisti e investitori retail sordi o con ipoacusia non possono partecipare — o nemmeno seguire passivamente — la call senza un flusso di testo in tempo reale. Importanti comunicazioni finanziarie, aggiornamenti sulle previsioni e risposte alle domande degli analisti vengono comunicate in tempo reale, e qualsiasi ritardo nel ricevere tali informazioni pone queste persone in un significativo svantaggio informativo. Nei settori regolamentati, ciò può persino sollevare questioni di equo accesso alle informazioni pubbliche.

Oltre alla sordità, questo criterio avvantaggia una popolazione più ampia. Le persone con disturbi dell’elaborazione uditiva possono sentire l’audio ma faticare a decodificare il parlato abbastanza rapidamente da seguire un flusso dal vivo; un flusso di testo sincronizzato consente loro di leggere al proprio ritmo di comprensione mentre l’audio viene riprodotto. Le persone in ambienti sensibili al rumore — come uffici open space, biblioteche o mezzi di trasporto pubblico — che non possono riprodurre l’audio ad alta voce traggono beneficio da un’alternativa testuale. Le persone per le quali la lingua della trasmissione è una seconda lingua trovano inoltre le alternative testuali più facili da seguire rispetto a un parlato dal vivo a ritmo sostenuto.

Dal punto di vista della SEO e della reperibilità dei contenuti, una trascrizione testuale dal vivo o un flusso di sottotitoli crea testo indicizzabile che i motori di ricerca possono analizzare. Gli eventi dal vivo che generano testo in tempo reale hanno maggiori probabilità di emergere nei risultati di ricerca e negli aggregatori di notizie, ampliando la portata del pubblico ben oltre la finestra di trasmissione originale.

Per le organizzazioni che operano in settori regolamentati — servizi finanziari, sanità, pubblica amministrazione — fornire un accesso equo alle informazioni audio dal vivo è sempre più un’aspettativa piuttosto che una cortesia. Il mancato rispetto di questo criterio può esporre le organizzazioni a reclami, rischi reputazionali e, in alcune giurisdizioni, a responsabilità legale.

Regole Axe-core Correlate

WCAG 1.2.9 richiede test manuali; nessuna regola automatizzata di axe-core può rilevare in modo affidabile se un flusso solo audio dal vivo dispone di un’alternativa testuale sincrona. Le ragioni di questa limitazione sono fondamentali per la natura stessa del criterio:

• Perché l’automazione non può rilevare questa violazione: Strumenti automatizzati come axe-core operano su snapshot statici del DOM o su stati della pagina in un singolo momento. Possono rilevare la presenza di un elemento <audio> o di un lettore multimediale, ma non possono determinare se il contenuto associato è dal vivo o preregistrato, se un’area di testo visibile sulla pagina si aggiorna realmente in sincronia con un flusso audio, se il contenuto testuale è semanticamente equivalente all’audio (coprendo tutte le informazioni vocali e non vocali), o se un eventuale servizio di sottotitolazione esterno collegato è effettivamente attivo e accurato. Tutti questi giudizi richiedono una revisione umana della trasmissione dal vivo stessa.
• Cosa deve verificare un auditor manuale: L’auditor deve accedere alla pagina mentre il flusso audio dal vivo è attivo, identificare come (o se) viene presentata un’alternativa testuale, confermare che l’alternativa testuale si aggiorna in tempo reale man mano che l’audio procede, verificare che il testo copra tutti i contenuti audio significativi, inclusa l’identificazione dei parlanti, i suoni non vocali e le transizioni, e confermare che l’alternativa testuale sia accessibile alle tecnologie assistive — ad esempio, che una regione dal vivo che utilizza aria-live='polite' o aria-live='assertive' annunci correttamente gli aggiornamenti alle persone che usano screen reader.
• Segnali di automazione parziale: Sebbene axe-core non possa segnalare direttamente la mancanza di un’alternativa testuale dal vivo, gli auditor dovrebbero notare che axe-core segnalerà problemi correlati che aggravano il problema — ad esempio, se esiste un’area di trascrizione testuale ma è nascosta con display:none, o se un lettore multimediale è privo di controlli accessibili. Questi avvisi costituiscono punti di partenza utili durante una revisione manuale.

Come Eseguire i Test

1. Scansione automatizzata come base: Esegui axe DevTools o Lighthouse sulla pagina che ospita il flusso audio dal vivo. Prendi nota di eventuali problemi segnalati relativi a elementi multimediali, etichette mancanti o controlli inaccessibili. Sebbene nessuno dei due strumenti segnalerà direttamente la mancanza di un’alternativa testuale dal vivo, potrebbero emergere barriere correlate — come un lettore audio senza nome accessibile o un contenitore di trascrizione nascosto dall’albero di accessibilità. Documenta questi risultati e considerali parte della valutazione complessiva dell’accessibilità.
2. Identifica il contenuto audio dal vivo: Mentre la trasmissione dal vivo è attiva, conferma che il flusso audio è dal vivo (non una registrazione) e che non ha alcuna traccia video. Controlla il sorgente della pagina e le richieste di rete per indizi — i flussi dal vivo utilizzano tipicamente HLS (.m3u8), MPEG-DASH o distribuzione basata su WebSocket. Conferma che il contenuto è solo audio.
3. Verifica la presenza di un’alternativa testuale: Cerca un’area di testo visibile, una sovrimpressione di sottotitoli o un flusso di trascrizione chiaramente etichettato sulla pagina o immediatamente collegato dalla pagina. L’alternativa deve essere messa in evidenza — non nascosta in un menu impostazioni o disponibile solo su richiesta. Se non è visibile alcuna alternativa testuale, il criterio è immediatamente non soddisfatto.
4. Verifica la sincronia: Con l’alternativa testuale dal vivo visibile, ascolta il flusso audio e leggi contemporaneamente il flusso di testo. Conferma che il testo si aggiorna con un ritardo ragionevole (tipicamente non più di pochi secondi per servizi CART o di sottitolazione professionale). Un flusso di testo che si aggiorna ogni diversi minuti o solo dopo la fine della trasmissione non soddisfa il criterio.
5. Verifica l’equivalenza: Conferma che l’alternativa testuale cattura tutti i contenuti audio significativi: parole pronunciate, identificazione dei parlanti quando sono presenti più voci, audio non vocale rilevante (ad esempio, «[applausi]», «[suono di allarme]», «[musica in riproduzione]») e qualsiasi annuncio o interruzione in onda.
6. Test con screen reader — NVDA + Firefox: Apri la pagina con NVDA attivo. Naviga fino alla regione di testo dal vivo. Se la regione utilizza aria-live, NVDA dovrebbe annunciare automaticamente le nuove inserzioni di testo. Se si tratta di un’area di testo a scorrimento, verifica che sia possibile portarvi il focus e che il contenuto sia leggibile. Controlla che i controlli del lettore audio siano anch’essi utilizzabili tramite tastiera.
7. Test con screen reader — VoiceOver + Safari (macOS/iOS): Attiva VoiceOver e naviga fino alla regione di testo dal vivo. Conferma che VoiceOver legga il nuovo testo man mano che appare. Su iOS, verifica anche l’esperienza su mobile — gli eventi dal vivo sono spesso fruiti tramite browser mobili.
8. Test con screen reader — JAWS + Chrome: Con JAWS attivo, naviga nella pagina e conferma che gli annunci della regione dal vivo funzionino. JAWS gestisce aria-live='polite' e aria-live='assertive' in modo diverso; conferma che l’impostazione di verbosità sia appropriata per il tipo di contenuto (un flusso di sottotitoli a ritmo sostenuto può essere più adatto a assertive per evitare ritardi in coda).
9. Test su mobile e a banda ridotta: Se il sito serve un pubblico mobile, testa l’alternativa testuale dal vivo su un dispositivo Android di fascia media con connessione limitata. Conferma che il flusso di testo rimanga sincronizzato e accessibile anche in condizioni di rete difficili.

Come Correggere

Scenario 1: Lettore audio dal vivo senza alternativa testuale — Non corretto

<!-- Live radio stream embedded with no accompanying text alternative -->
<section>
  <h2>Live Broadcast</h2>
  <audio controls src='https://stream.example.com/live'>
    Your browser does not support the audio element.
  </audio>
</section>

Scenario 1: Lettore audio dal vivo con trascrizione in regione ARIA live — Corretto

<!-- Live radio stream with a synchronous ARIA live region for real-time captions -->
<section>
  <h2>Live Broadcast</h2>
  <audio controls src='https://stream.example.com/live'
         aria-describedby='live-caption-feed'>
    Your browser does not support the audio element.
  </audio>
  <!-- aria-live='assertive' ensures screen readers announce new text immediately -->
  <!-- aria-atomic='false' allows incremental updates rather than re-reading the whole block -->
  <div id='live-caption-feed'
       role='region'
       aria-label='Live captions'
       aria-live='assertive'
       aria-atomic='false'
       tabindex='0'>
    <!-- Caption text is injected here by the captioning service JavaScript -->
  </div>
</section>

Scenario 2: Trascrizione pubblicata solo dopo la fine dell’evento — Non corretto

<!-- Transcript link appears but only resolves after the broadcast -->
<div>
  <audio controls src='https://stream.example.com/press-conference'></audio>
  <p>A full transcript will be available after the press conference concludes.</p>
</div>

Scenario 2: Flusso CART in tempo reale collegato accanto al lettore — Corretto

<!-- Real-time CART captions are displayed inline during the live event -->
<div>
  <audio controls src='https://stream.example.com/press-conference'
         aria-describedby='cart-feed'></audio>
  <!-- The CART feed is an iframe served by a professional captioning provider -->
  <!-- The iframe must itself be accessible with an appropriate title -->
  <iframe
    id='cart-feed'
    src='https://cart-provider.example.com/feed/press-conference-2025'
    title='Real-time captions for live press conference'
    width='100%'
    height='200'>
  </iframe>
  <p>A full transcript will also be published after the event concludes.</p>
</div>

Scenario 3: Sottotitoli generati automaticamente nascosti dietro un toggle nelle impostazioni — Non corretto

<!-- Captions exist but are hidden by default and require multiple steps to enable -->
<div class='player-wrapper'>
  <audio controls src='https://stream.example.com/webinar'></audio>
  <button onclick='toggleSettings()'>Settings</button>
  <div id='settings-panel' hidden>
    <button onclick='enableCaptions()'>Enable Captions</button>
  </div>
</div>

Scenario 3: Sottotitoli attivati per impostazione predefinita con un toggle chiaro — Corretto

<!-- Captions are ON by default; a prominent toggle lets users turn them off if preferred -->
<div class='player-wrapper'>
  <audio controls src='https://stream.example.com/webinar'
         aria-describedby='webinar-captions'></audio>
  <!-- Default state is captions-on; aria-pressed reflects current state -->
  <button id='caption-toggle'
          aria-pressed='true'
          onclick='toggleCaptions(this)'>
    Live Captions: On
  </button>
  <div id='webinar-captions'
       role='region'
       aria-label='Live webinar captions'
       aria-live='polite'
       aria-atomic='false'
       tabindex='0'>
    <!-- Caption text injected here in real time -->
  </div>
</div>

Errori Comuni

• Pubblicare una trascrizione dopo l’evento e sostenere che soddisfi il criterio 1.2.9: Una trascrizione pubblicata ore o giorni dopo una trasmissione dal vivo non è un’alternativa testuale in tempo reale. WCAG 1.2.9 richiede specificamente che l’alternativa sia disponibile contemporaneamente all’audio dal vivo, non retroattivamente.
• Usare aria-live='polite' per un flusso di sottotitoli a ritmo sostenuto: Le regioni dal vivo “polite” attendono che la persona termini l’interazione prima di annunciare nuovi contenuti. Per sottotitoli che si aggiornano rapidamente, ciò fa sì che le persone che usano screen reader perdano annunci. Usa aria-live='assertive' per flussi di sottotitoli dal vivo in cui ogni aggiornamento è critico dal punto di vista temporale.
• Iniettare l’intera cronologia dei sottotitoli a ogni aggiornamento invece del solo contenuto nuovo: Quando aria-atomic='true' è impostato e l’intero blocco di testo viene sostituito a ogni aggiornamento, gli screen reader tentano di rileggere l’intera regione, causando un’esperienza disturbante. Usa aria-atomic='false' e aggiungi nuovi nodi di testo in coda, in modo che venga annunciata solo la parte nuova.
• Incorporare il flusso di sottotitoli in un elemento <canvas> o come grafica sovrapposta al video: Il testo dei sottotitoli reso come pixel su un canvas o “bruciato” in un fotogramma video è invisibile alle tecnologie assistive. Le alternative testuali devono essere fornite come veri nodi di testo nel DOM.
• Posizionare la regione di sottotitoli dal vivo fuori dallo schermo con position:absolute; left:-9999px: Sebbene nascondere visivamente i contenuti in questo modo li mantenga nell’albero di accessibilità, nega alle persone vedenti con perdita uditiva la possibilità di leggere i sottotitoli. L’alternativa testuale deve essere visivamente disponibile a tutte le persone, non solo a chi usa screen reader.
• Non identificare i parlanti in trasmissioni con più voci: Un flusso di sottotitoli che trascrive il parlato senza attribuirlo a specifici parlanti (ad esempio, «[Moderatore]:», «[CEO]:», «[Partecipante del pubblico]:») non è pienamente equivalente. L’identificazione dei parlanti è essenziale affinché le persone possano seguire la struttura conversazionale di un evento dal vivo.
• Omettere le informazioni audio non vocali dall’alternativa testuale: Suoni rilevanti come applausi, interruzioni tecniche, musica di sottofondo, allarmi o risate hanno contenuto informativo e devono essere descritti nel flusso di testo (ad esempio, «[applausi]», «[problemi tecnici — audio interrotto]»).
• Fornire l’alternativa testuale solo tramite un URL di terze parti separato senza incorporarla nella stessa pagina: Richiedere alle persone di aprire una scheda o finestra del browser separata per accedere ai sottotitoli mentre l’audio viene riprodotto sulla pagina originale crea una barriera di usabilità significativa, in particolare per chi usa screen reader e per chi usa solo la tastiera e deve cambiare contesto.
• Dare per scontato che i sottotitoli generati automaticamente soddisfino sempre la soglia di equivalenza: I sottotitoli generati dall’IA possono avere tassi di errore elevati con parlato accentato, vocabolario tecnico, nomi propri e parlato veloce. L’uso di sottotitoli generati automaticamente non corretti per un evento dal vivo ad alto impatto (ad esempio, un briefing medico o una comunicazione finanziaria) può non soddisfare lo standard di equivalenza, anche se tecnicamente è presente un flusso di sottotitoli.
• Non testare la regione di testo dal vivo con screen reader reali durante una trasmissione dal vivo: Molti team testano il lettore e il contenitore dei sottotitoli in isolamento usando testo statico di esempio, ma non testano mai il comportamento dinamico durante un vero flusso dal vivo. Bug nel JavaScript che inietta gli aggiornamenti dei sottotitoli — come osservatori di mutazioni del DOM che falliscono silenziosamente — emergono solo durante i test in diretta.

Relazione con le Normative Sull’Accessibilità della Turchia

La Circolare Presidenziale 2025/10 della Turchia, pubblicata nella Gazzetta Ufficiale n. 32933 il 21 giugno 2025, stabilisce obblighi vincolanti in materia di accessibilità web per un’ampia gamma di organizzazioni che operano in Turchia. La Circolare impone la conformità alle WCAG 2.2 a livello AA come standard di base. Le tipologie di soggetti coperti includono istituzioni e agenzie pubbliche, piattaforme di e-commerce, banche e istituzioni finanziarie, ospedali e strutture sanitarie private, società 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).

WCAG 1.2.9 è un criterio di Livello AAA, il che significa che non rientra tra i requisiti di conformità imposti dalla Circolare come baseline AA. Le organizzazioni coperte dalla Circolare Presidenziale 2025/10 non sono legalmente obbligate a implementare alternative testuali per contenuti solo audio dal vivo, a meno che non si siano impegnate separatamente a una piena conformità alle WCAG 2.2 a livello AAA.

Tuttavia, diverse considerazioni pratiche rendono il criterio 1.2.9 altamente rilevante per le organizzazioni turche anche oltre il minimo legale. I fornitori di telecomunicazioni, le istituzioni finanziarie e gli emittenti pubblici forniscono frequentemente contenuti audio dal vivo — call con investitori, annunci pubblici, trasmissioni di assistenza clienti in diretta — dai quali dipendono le persone sorde e con ipoacusia in Turchia. Dimostrare una conformità a livello AAA segnala un impegno per l’accessibilità di prim’ordine e riduce significativamente il rischio di reclami per discriminazione nell’ambito del più ampio quadro dei diritti delle persone con disabilità in Turchia, inclusa la Legge sulle Persone con Disabilità n. 5378 e i relativi regolamenti attuativi.

Per le organizzazioni che perseguono volontariamente la conformità alle WCAG 2.2 a livello AAA — sia per differenziare la propria posizione in materia di accessibilità, sia per servire mercati internazionali con requisiti più severi, sia per allinearsi a criteri di procurement che richiedono il livello AAA — l’implementazione corretta del criterio 1.2.9 è essenziale. Accsible raccomanda che le organizzazioni turche nei settori regolamentati valutino proattivamente i propri contenuti audio dal vivo e l’eventuale integrazione di servizi CART o di sottotitolazione in tempo reale ad alta accuratezza, in particolare per gli eventi dal vivo rivolti al pubblico in cui l’equità dell’informazione è un’aspettativa concreta delle parti interessate.