WCAG 3.1.6: Pronuncia

Cosa Significa Questa Regola

WCAG 3.1.6 Pronuncia è un criterio di successo di livello AAA sotto il principio Comprensibile. Esso afferma: «È disponibile un meccanismo per identificare la pronuncia specifica delle parole quando il significato delle parole, nel contesto, è ambiguo senza conoscere la pronuncia.»

Il requisito fondamentale è che quando il significato di una parola dipende interamente da come viene pronunciata — e tale pronuncia non può essere determinata dal contesto circostante — gli autori devono fornire agli utenti un modo per scoprire la pronuncia corretta. Questo è diverso dal semplice fornire una definizione; il criterio riguarda specificamente la pronuncia fonetica che risolve l’ambiguità semantica.

Il criterio prende di mira le situazioni in cui la stessa sequenza di caratteri può essere letta in più modi, ognuno dei quali produce un significato diverso. Esempi classici in inglese includono la parola "read" (presente, rima con "reed") rispetto a "read" (passato, rima con "red"), oppure "wind" (vento, rima con "sinned") rispetto a "wind" (avvolgere, rima con "find"). In lingue con sistemi di scrittura più complessi o distinzioni tonali — come il giapponese, il cinese o l’arabo — il problema è ancora più diffuso e rilevante.

Il turco, pur essendo in gran parte foneticamente regolare rispetto a molte altre lingue, ha comunque parole e prestiti linguistici la cui pronuncia può non essere chiara in contesti specializzati, tecnici o formali, in particolare per gli utenti di screen reader il cui motore di sintesi vocale può accentare in modo errato o pronunciare male terminologia non familiare o prestiti linguistici stranieri.

Cosa è considerato conforme: Una pagina è conforme se, ovunque una parola sia ambigua senza conoscerne la pronuncia, è presente almeno uno dei seguenti meccanismi:

• Una guida fonetica in linea immediatamente adiacente alla parola (ad esempio, usando l’elemento HTML <ruby> e i relativi tag <rt> e <rp> per gli script dell’Asia orientale, oppure una chiave di pronuncia tra parentesi in IPA o in un altro sistema di notazione riconosciuto).
• Un link a una voce di glossario o a una guida alla pronuncia che tratti esplicitamente la parola ambigua.
• Una clip audio con la pronuncia associata alla parola.
• Testo in linea immediatamente prima o dopo la parola che descrive la sua pronuncia in modo interpretabile dal lettore (ad esempio, «La parola "bass" qui si riferisce al pesce — pronunciata come "mass"»).

Cosa è considerato non conforme: Una pagina non è conforme se il significato di una parola è realmente ambiguo senza sentirla pronunciata, e non esiste alcun meccanismo per risolvere tale ambiguità tramite informazioni sulla pronuncia. Fornire semplicemente una definizione testuale che non chiarisce la pronuncia è insufficiente se il significato non può essere ricavato dalla sola definizione senza sapere come suona la parola. Si noti che se il contesto — come la frase circostante, l’intestazione o l’immagine — rende già chiara la pronuncia, il criterio è soddisfatto senza alcun meccanismo aggiuntivo.

Eccezioni ufficiali: La specifica WCAG limita esplicitamente questo criterio ai casi in cui l’ambiguità esiste senza conoscere la pronuncia. Se il testo circostante, gli elementi visivi o la struttura semantica risolvono già l’ambiguità in modo inequivocabile, non è richiesto alcun meccanismo di pronuncia aggiuntivo. Il criterio non richiede annotazioni fonetiche per ogni parola su ogni pagina — solo per quelle il cui significato dipende realmente da una pronuncia che non può essere dedotta dal contesto.

Perché È Importante

L’ambiguità di pronuncia crea barriere significative per diversi gruppi di utenti distinti, e l’impatto è particolarmente acuto per coloro che non possono fare affidamento su indizi visivi o uditivi al di fuori del testo principale.

Utenti ciechi e ipovedenti che si affidano agli screen reader sono il gruppo più direttamente interessato. Gli screen reader convertono il testo in voce sintetizzata e, quando una parola ha più pronunce valide con significati diversi, il motore di sintesi vocale deve fare una scelta — e spesso sceglie in modo errato. Un utente che ascolta un articolo finanziario sull’"interesse composto" può sentire "compound" pronunciato in modo identico alla sua forma come sostantivo (un’area recintata), creando confusione momentanea o prolungata. Per gli utenti che non possono dare rapidamente un’occhiata al contesto visivo circostante, risolvere questa confusione richiede di rileggere i passaggi o cercare chiarimenti altrove. Secondo l’Organizzazione Mondiale della Sanità, circa 2,2 miliardi di persone nel mondo hanno una qualche forma di disabilità visiva, una quota significativa delle quali utilizza la tecnologia di lettura dello schermo come principale mezzo di accesso ai contenuti digitali.

Utenti con disabilità cognitive e di apprendimento, inclusi coloro con dislessia o disturbi dell’elaborazione del linguaggio, spesso si affidano a strumenti di sintesi vocale anche quando hanno una vista funzionale. Per questi utenti, ascoltare una pronuncia errata di un omografo può interrompere la comprensione in modi difficili da recuperare, in particolare quando il passaggio è tecnico o non familiare.

Utenti sordi e con ipoacusia che utilizzano le lingue dei segni come lingua principale possono imbattersi in testo scritto in una seconda o terza lingua. Per loro, vedere una rappresentazione fonetica di una parola — anche se non possono sentirla — può collegare la forma scritta a un concetto noto in modo più affidabile rispetto a una semplice definizione testuale.

Parlanti non nativi e studenti di lingua traggono enormi benefici dalle indicazioni di pronuncia. Una persona che studia il turco e incontra un termine medico o legale specializzato, o un termine tecnico straniero reso in traslitterazione turca, può non sapere se l’accento cade sulla prima o sulla seconda sillaba, cosa che può cambiare il significato o semplicemente ostacolare la comprensione.

Uno scenario concreto reale: Si consideri un portale sanitario turco che descrive una procedura che coinvolge la parola "ileum" (una sezione dell’intestino tenue) insieme a contenuti che fanno anche riferimento all’ilium (un osso pelvico). In inglese, queste parole suonano identiche in molti dialetti. Su una pagina letta ad alta voce da uno screen reader, un paziente che si prepara a un intervento chirurgico e che è cieco o ipovedente non avrebbe modo di distinguere tra i due termini dal solo audio, a meno che non venga fornita una pronuncia o un contesto fonetico. Questo non è un caso limite ipotetico — la documentazione medica è un ambito ad alto rischio in cui tali ambiguità possono causare danni reali.

Esistono anche benefici in termini di SEO e usabilità. Le guide alla pronuncia incoraggiano l’uso di una terminologia precisa e ben definita. I glossari con annotazioni fonetiche migliorano le metriche di permanenza sulla pagina e riducono la frustrazione degli utenti. I contenuti strutturati ricchi che spiegano la terminologia tendono ad attirare più link in ingresso e segnalano autorevolezza in materia ai motori di ricerca.

Regole Axe-core Correlate

WCAG 3.1.6 richiede solo test manuali. Non esistono regole automatizzate di axe-core che mappino direttamente a questo criterio. La seguente spiegazione chiarisce perché l’automazione non può rilevare in modo affidabile le violazioni e cosa devono cercare manualmente i tester.

• Non esiste alcuna regola automatizzata per l’ambiguità di pronuncia. I motori di test di accessibilità automatizzati come axe-core operano scansionando il DOM alla ricerca di pattern strutturali, attributi mancanti, ruoli non validi e altre condizioni basate su regole. Determinare se una specifica parola è ambigua senza conoscerne la pronuncia richiede una comprensione semantica e linguistica del contenuto — un giudizio che dipende da vocabolario, lingua, contesto di dominio e background del lettore. Nessun attuale motore di analisi statica può determinare in modo affidabile che la parola "read" in una data frase sia ambigua nella pronuncia senza l’interpretazione umana del significato circostante. Per questo motivo le stesse WCAG riconoscono che questo criterio è difficile da testare in modo programmato e lo collocano al livello AAA.
• Cosa devono verificare i tester manuali: I tester devono leggere il contenuto della pagina con conoscenza del dominio delle lingue utilizzate e segnalare qualsiasi parola in cui (a) esistono due o più pronunce valide, (b) ogni pronuncia corrisponde a un significato diverso e (c) il contesto circostante non risolve in modo inequivocabile quale significato è inteso. Per ogni parola segnalata, il tester deve quindi verificare che sia presente un meccanismo di pronuncia — guida fonetica, clip audio, link al glossario o chiarimento contestuale — e che sia accessibile.
• Verifica a campione con screen reader: I tester che utilizzano screen reader (NVDA, JAWS, VoiceOver, TalkBack) dovrebbero ascoltare il contenuto e annotare qualsiasi istanza in cui la voce sintetizzata pronuncia una parola in modo che confligge con il significato inteso nel contesto. Questo è un forte segnale che è necessario un meccanismo di pronuncia.

Come Testare

1. Esegui prima una scansione automatizzata (per una base di riferimento): Usa axe DevTools o Lighthouse per eseguire un audit generale di accessibilità della pagina. Sebbene nessuno dei due strumenti abbia una regola dedicata per WCAG 3.1.6, la scansione può far emergere problemi linguistici correlati come un attributo lang mancante o errato sull’elemento <html> (WCAG 3.1.1) o l’assenza di identificazione della lingua per passaggi in una lingua diversa (WCAG 3.1.2). Questi problemi possono aggravare i problemi di pronuncia facendo sì che lo screen reader applichi un motore linguistico completamente errato. Verifica che <html lang='tr'> (o il codice lingua appropriato) sia presente e corretto.
2. Conduci un audit dei contenuti per omografi e termini ambigui: Con competenza nel dominio dell’argomento e della lingua della pagina, leggi tutto il contenuto testuale. Crea un elenco di tutte le parole che hanno più pronunce con significati distinti. Presta particolare attenzione a: prestiti dall’inglese, francese, arabo o altre lingue che potrebbero non seguire le regole fonetiche standard del turco; gergo tecnico in medicina, diritto o ingegneria; nomi propri con pronuncia non ovvia; e qualsiasi parola esplicitamente segnalata in revisione editoriale come potenzialmente confusa.
3. Testa con NVDA + Firefox: Apri la pagina in Firefox con NVDA in esecuzione. Usa la modalità di lettura continua di NVDA (Insert + Freccia giù) per ascoltare l’intera pagina o le sezioni rilevanti. Annota qualsiasi parola che il sintetizzatore pronuncia in modo potenzialmente fraintendibile. Verifica se è disponibile un meccanismo di pronuncia (annotazione fonetica, pulsante audio, link al glossario) e se NVDA lo annuncia chiaramente.
4. Testa con JAWS + Chrome: Ripeti il test di ascolto sopra descritto in Chrome con JAWS. JAWS e NVDA utilizzano sintetizzatori vocali diversi e possono pronunciare la stessa parola in modo differente, quindi entrambi i test sono utili. Usa le impostazioni di verbosità di JAWS per assicurarti che tutte le annotazioni in linea e il contenuto dell’elemento <ruby> vengano letti ad alta voce.
5. Testa con VoiceOver + Safari (macOS/iOS): Abilita VoiceOver e naviga nella pagina usando Safari. Usa VO + A per leggere la pagina in modo continuo. Il sintetizzatore vocale di Apple ha una propria logica di pronuncia; verifica che eventuali annotazioni <ruby> o override di aria-label vengano esposte correttamente.
6. Verifica che il meccanismo di pronuncia sia accessibile: Per ogni meccanismo di pronuncia presente sulla pagina, conferma che sia raggiungibile solo tramite tastiera, che venga annunciato dagli screen reader e che le informazioni di pronuncia fornite risolvano effettivamente l’ambiguità (ad esempio, una trascrizione IPA è utile solo se il pubblico di destinazione sa leggere l’IPA; una grafia fonetica in linguaggio semplice come «pronunciato: EYE-lee-um» può essere più universalmente utile).
7. Controlla le clip audio di pronuncia: Se vengono utilizzate clip audio, verifica che abbiano controlli accessibili (pulsante di riproduzione con etichetta, controllo del volume) e che siano disponibili trascrizioni o alternative testuali per gli utenti sordi che non possono beneficiare dell’audio.

Come Correggere

Omografo nel testo del corpo — Non corretto

<!-- The word "bass" is used in a music context, but its pronunciation
     is ambiguous (rhymes with "face" not "mass" in this context).
     No mechanism is provided to clarify. -->
<p>
  The bass guitar part in the recording was improvised live during
  the studio session.
</p>

Omografo nel testo del corpo — Corretto

<!-- A parenthetical phonetic guide immediately resolves the ambiguity.
     Alternatively, a link to a glossary entry with an audio clip
     would also satisfy the criterion. -->
<p>
  The bass <span lang='en-x-phonetics'>(pronounced: "base", rhymes with "face")</span>
  guitar part in the recording was improvised live during the studio session.
</p>

Script dell’Asia orientale o annotato con ruby — Non corretto

<!-- Japanese kanji without furigana: the reading of this compound
     is not clear to all readers and screen readers may mispronounce it. -->
<p>本日の<span>音楽</span>イベントへようこそ。</p>

Script dell’Asia orientale o annotato con ruby — Corretto

<!-- The <ruby> element with <rt> provides the phonetic reading.
     <rp> provides fallback parentheses for browsers that do not
     support ruby annotations, ensuring backward compatibility. -->
<p>本日の
  <ruby>
    音楽
    <rp>(</rp>
    <rt>おんがく</rt>
    <rp>)</rp>
  </ruby>
イベントへようこそ。</p>

Termine tecnico con pronuncia ambigua — Non corretto

<!-- "Ileum" and "ilium" sound identical when mispronounced by a TTS engine.
     No disambiguation mechanism is present in this medical content. -->
<p>
  The surgical procedure involves resection of the terminal ileum
  to treat the affected region.
</p>

Termine tecnico con pronuncia ambigua — Corretto

<!-- A glossary link provides access to a page with an audio pronunciation
     clip and IPA notation, satisfying the criterion. The link text is
     descriptive so screen reader users understand where it leads. -->
<p>
  The surgical procedure involves resection of the terminal
  <a href='/glossary/ileum' aria-label='ileum — view pronunciation and definition'>ileum</a>
  to treat the affected region.
</p>

<!-- The linked glossary entry should contain: -->
<article id='glossary-ileum'>
  <h2>Ileum</h2>
  <p><strong>Pronunciation:</strong> ILL-ee-um (/ˈɪliəm/)</p>
  <audio controls aria-label='Audio pronunciation of ileum'>
    <source src='/audio/ileum.mp3' type='audio/mpeg'>
    Your browser does not support the audio element.
  </audio>
  <p><strong>Definition:</strong> The final section of the small intestine,
  connecting to the large intestine. Not to be confused with the ilium
  (a bone of the pelvis, pronounced identically).</p>
</article>

Prestito linguistico con pronuncia non standard in turco — Non corretto

<!-- The English loanword "cache" is used in a Turkish tech article.
     Turkish TTS engines may pronounce this as "kah-sheh" or "kash"
     rather than the intended "kash". No guidance is provided. -->
<p>Tarayıcı cache dosyalarını temizlemek performansı artırabilir.</p>

Prestito linguistico con pronuncia non standard in turco — Corretto

<!-- A phonetic clarification in parentheses uses familiar Turkish
     phonetic conventions to guide the reader. -->
<p>
  Tarayıcı cache
  <span class='pronunciation-guide' aria-label='telaffuz: keş'>
    (telaffuz: keş)
  </span>
  dosyalarını temizlemek performansı artırabilir.
</p>

Errori Comuni

• Fornire solo una definizione testuale senza pronuncia: Aggiungere un tooltip o una definizione di glossario che spiega il significato di una parola non soddisfa WCAG 3.1.6 se la definizione stessa non chiarisce la pronuncia. Ad esempio, definire "bass" come «un suono o strumento musicale a bassa frequenza» lascia comunque ambigua la pronuncia; il meccanismo deve affrontare specificamente il modo in cui la parola è pronunciata.
• Usare <ruby> senza tag di fallback <rp>: Nei browser che non supportano nativamente le annotazioni ruby, omettere <rp> (parentesi ruby) fa sì che l’annotazione fonetica scompaia completamente. Includi sempre <rp>(</rp> e <rp>)</rp> attorno a ciascun elemento <rt> in modo che gli utenti su piattaforme non supportate vedano comunque il testo di pronuncia in linea.
• Fornire clip audio senza controlli accessibili o alternative testuali: Un pulsante di pronuncia audio che non ha etichetta (ad esempio, <button><img src='speaker.png'></button> senza alt o aria-label) è inaccessibile proprio agli utenti che ne hanno più bisogno. Ogni controllo audio deve avere un’etichetta descrittiva e il contenuto di pronuncia dell’audio deve essere disponibile anche in forma testuale per gli utenti sordi.
• Dare per scontato che il motore TTS la pronunci correttamente: Molti team saltano i meccanismi di pronuncia perché i loro test interni (eseguiti visivamente o all’ascolto da tester vedenti/udenti) non evidenziano l’ambiguità. Affidarsi alle euristiche di un motore di sintesi vocale per selezionare la pronuncia corretta di un omografo non è una strategia di accessibilità valida; tali euristiche falliscono regolarmente, soprattutto per contenuti specifici di dominio o multilingue.
• Collocare le indicazioni di pronuncia troppo lontano dalla parola: Collegare a un glossario di pronuncia a livello di sito in fondo alla pagina o in una sezione di aiuto non soddisfa il criterio se gli utenti devono allontanarsi dal contenuto per trovarlo, perdendo la posizione di lettura. Il meccanismo deve essere chiaramente associato alla specifica parola ambigua, sia in linea sia tramite un link prossimo e chiaramente etichettato.
• Usare la notazione IPA senza considerare il pubblico: Le trascrizioni in Alfabeto Fonetico Internazionale sono precise ma non sono leggibili dalla maggior parte del pubblico generale. Se i tuoi utenti non sono professionisti del linguaggio, le grafie fonetiche in linguaggio semplice («pronunciato: KAY-oss» per "chaos") sono più utili in pratica. Scegliere un formato inaccessibile per la guida alla pronuncia mina l’intero scopo di fornirla.
• Non marcare gli span di pronuncia con gli attributi di lingua appropriati: Quando si fornisce una grafia fonetica in una lingua o in un sistema di notazione diverso dalla lingua principale della pagina, omettere il corretto attributo lang sull’elemento contenitore. Ciò fa sì che gli screen reader applichino regole fonetiche errate proprio al testo destinato a guidare la pronuncia, creando un problema amplificato.
• Applicare il criterio solo al testo del corpo ignorando intestazioni, navigazione e etichette UI: Omografi ambigui possono comparire in intestazioni, etichette di pulsanti, testo dei link, etichette dei campi dei moduli e messaggi di errore. Queste posizioni sono spesso lette in isolamento dagli utenti di screen reader che navigano per landmark o tipo di elemento, rendendo la disambiguazione contestuale ancora meno affidabile che nel testo del corpo.
• Confondere WCAG 3.1.3 (Parole insolite) con 3.1.6 (Pronuncia): WCAG 3.1.3 richiede meccanismi per parole usate in modo insolito o specializzato. WCAG 3.1.6 affronta un problema distinto: parole il cui significato dipende dal modo in cui sono pronunciate. Una parola può richiedere un intervento ai sensi di 3.1.6 anche se non è insolita — "read" e "wind" sono parole comuni. Non dare per scontato che soddisfare un criterio significhi soddisfare anche l’altro.
• Non testare con più screen reader e motori TTS: Sintetizzatori diversi (eSpeak di NVDA, Eloquence o Vocalizer di JAWS, le voci integrate di Apple) hanno euristiche di pronuncia diverse e gestiranno gli omografi in modo differente. Una parola che un particolare motore pronuncia correttamente può essere pronunciata male da un altro. Gli autori di contenuti dovrebbero testare con almeno due combinazioni screen reader/browser per identificare errori di pronuncia che influiscono sugli utenti reali.

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 vincolanti di accessibilità web per un’ampia gamma di entità che operano in Turchia. La circolare impone la conformità agli standard WCAG 2.2, con un’enfasi primaria sui criteri di livello A e livello AA per le entità interessate. Le entità esplicitamente soggette alla circolare includono istituzioni e agenzie pubbliche, piattaforme di e-commerce, banche e fornitori di servizi finanziari, ospedali e organizzazioni sanitarie, società di telecomunicazioni con 200.000 o più abbonati, agenzie di viaggio, società di trasporto privato e scuole private che operano con autorizzazione del Ministero dell’Istruzione Nazionale (MoNE).

WCAG 3.1.6 Pronuncia è un criterio di livello AAA e pertanto non rientra tra i requisiti legalmente obbligatori ai sensi della circolare. Le entità interessate non sono obbligate dalla circolare a implementare meccanismi di pronuncia come misura di conformità di base. Tuttavia, lo scopo più ampio della circolare — garantire che i servizi digitali siano realmente utilizzabili da tutti i cittadini, comprese le persone con disabilità — è ben servito dall’adozione volontaria dei criteri di livello AAA ovunque sia tecnicamente ed editorialmente fattibile.

Per alcune categorie di entità interessate, il caso pratico per implementare WCAG 3.1.6 è particolarmente forte anche in assenza di un obbligo legale. I portali sanitari gestiti da ospedali coperti dalla circolare trattano una terminologia in cui l’ambiguità di pronuncia può causare un reale danno ai pazienti. I testi legali o normativi pubblicati da istituzioni pubbliche possono contenere vocabolario specializzato con pronuncia non ovvia che crea barriere per gli utenti di screen reader. Le piattaforme di e-commerce che servono pubblici linguistici diversificati — inclusi parlanti non nativi di turco — possono scoprire che le indicazioni di pronuncia riducono la confusione e l’abbandono dei clienti.

Il turco è una lingua foneticamente regolare, il che significa che la corrispondenza tra ortografia e pronuncia è più coerente rispetto a lingue come l’inglese o il francese. Questo riduce (ma non elimina) la portata del lavoro di conformità a WCAG 3.1.6 per i contenuti in lingua turca. Tuttavia, la prevalenza di prestiti dall’inglese e dal francese nei contenuti tecnici, commerciali e digitali in turco — in particolare nei settori coperti dalla circolare — significa che l’ambiguità di pronuncia rimane una preoccupazione reale. Le parole prese in prestito da altre lingue non seguono sempre le convenzioni fonetiche turche e possono essere rese in modo diverso dai motori TTS turchi a seconda della configurazione del sintetizzatore.

Le organizzazioni soggette alla circolare che aspirano a un’accessibilità di livello eccellente — o che servono utenti in contesti multilingue, operano in ambiti ad alto rischio come la salute o la finanza, o desiderano dimostrare leadership in materia di accessibilità nel mercato digitale turco — dovrebbero considerare WCAG 3.1.6 come parte di un programma di accessibilità completo che va oltre la conformità legale minima. L’implementazione di meccanismi di pronuncia è un miglioramento relativamente a basso costo per la maggior parte dei tipi di contenuto e segnala un reale impegno verso il design inclusivo che è in linea sia con lo spirito della circolare sia con le migliori pratiche internazionali.