WCAG 3.1.6 : Prononciation

Ce que signifie cette règle

WCAG 3.1.6 Pronunciation est un critère de succès de niveau AAA relevant du principe Compréhensible. Il stipule : « Un mécanisme est disponible pour identifier la prononciation spécifique de mots dont le sens, dans le contexte, est ambigu si l’on ne connaît pas leur prononciation. »

L’exigence centrale est que lorsque le sens d’un mot dépend entièrement de la façon dont il est prononcé — et que cette prononciation ne peut pas être déterminée à partir du contexte — les auteurs doivent fournir un moyen permettant aux utilisateurs de découvrir la prononciation correcte. Cela se distingue du simple fait de fournir une définition ; le critère porte spécifiquement sur la prononciation phonétique qui résout une ambiguïté sémantique.

Le critère vise les situations où la même chaîne de caractères peut être lue de plusieurs façons, chacune produisant un sens différent. Les exemples classiques en anglais incluent le mot « read » (présent, rime avec « reed ») versus « read » (passé, rime avec « red »), ou « wind » (vent, rime avec « sinned ») versus « wind » (enrouler, rime avec « find »). Dans les langues avec des systèmes d’écriture plus complexes ou des distinctions tonales — comme le japonais, le chinois ou l’arabe — le problème est encore plus fréquent et plus lourd de conséquences.

Le turc, bien que largement régulier sur le plan phonétique par rapport à de nombreuses autres langues, comporte tout de même des mots et des emprunts dont la prononciation peut être peu claire dans des contextes spécialisés, techniques ou formels, en particulier pour les utilisateurs de lecteurs d’écran dont le moteur de synthèse vocale peut mal accentuer ou mal prononcer une terminologie inconnue ou des mots étrangers empruntés.

Ce qui est considéré comme conforme : Une page est conforme si, partout où un mot est ambigu sans connaître sa prononciation, au moins un des mécanismes suivants est présent :

• Un guide phonétique en ligne immédiatement adjacent au mot (par exemple, en utilisant l’élément HTML <ruby> et ses balises associées <rt> et <rp> pour les écritures d’Asie de l’Est, ou une clé de prononciation entre parenthèses en API ou dans un autre système de notation reconnu).
• Un lien vers une entrée de glossaire ou un guide de prononciation qui couvre explicitement le mot ambigu.
• Un extrait audio de prononciation associé au mot.
• Un texte en ligne immédiatement avant ou après le mot qui décrit sa prononciation d’une manière que le lecteur peut interpréter (par exemple, « Le mot “bass” ici fait référence au poisson — prononcé comme “mass” »).

Ce qui est considéré comme non conforme : Une page n’est pas conforme si le sens d’un mot est réellement ambigu sans l’entendre prononcé, et qu’aucun mécanisme n’existe pour résoudre cette ambiguïté via une information de prononciation. Le simple fait de fournir une définition textuelle qui ne clarifie pas la prononciation est insuffisant si le sens ne peut pas être déduit de la définition seule sans savoir comment le mot se prononce. Notez que si le contexte — comme la phrase environnante, l’intitulé ou l’image — rend déjà la prononciation claire, le critère est satisfait sans mécanisme supplémentaire.

Exceptions officielles : La spécification WCAG limite explicitement ce critère aux cas où l’ambiguïté existe sans connaître la prononciation. Si le texte environnant, les éléments visuels ou la structure sémantique résolvent déjà l’ambiguïté de manière non ambiguë, aucun mécanisme de prononciation supplémentaire n’est requis. Le critère n’exige pas d’annotation phonétique pour chaque mot sur chaque page — uniquement pour ceux dont le sens dépend réellement d’une prononciation qui ne peut pas être déduite du contexte.

Pourquoi c’est important

L’ambiguïté de prononciation crée des obstacles significatifs pour plusieurs groupes d’utilisateurs distincts, et l’impact est particulièrement aigu pour ceux qui ne peuvent pas s’appuyer sur des indices visuels ou auditifs en dehors du texte principal.

Les personnes aveugles ou malvoyantes qui utilisent des lecteurs d’écran sont le groupe le plus directement affecté. Les lecteurs d’écran convertissent le texte en parole synthétisée, et lorsqu’un mot a plusieurs prononciations valides avec des sens différents, le moteur de synthèse vocale doit faire un choix — et il se trompe fréquemment. Une personne écoutant un article financier sur les « intérêts composés » peut entendre « compound » prononcé comme son nom commun (un enclos), créant une confusion momentanée ou durable. Pour les personnes qui ne peuvent pas jeter un coup d’œil rapide au contexte visuel environnant, résoudre cette confusion nécessite de réécouter des passages ou de chercher des clarifications ailleurs. Selon l’Organisation mondiale de la Santé, environ 2,2 milliards de personnes dans le monde présentent une forme de déficience visuelle, dont une proportion significative utilise la technologie de lecture d’écran comme principal moyen d’accès au contenu numérique.

Les personnes ayant des handicaps cognitifs et des troubles d’apprentissage, y compris celles ayant une dyslexie ou des troubles du traitement du langage, s’appuient souvent sur des outils de synthèse vocale même lorsqu’elles ont une vision fonctionnelle. Pour ces personnes, entendre une prononciation incorrecte d’un homographe peut perturber la compréhension d’une manière dont il est difficile de se remettre, en particulier lorsque le passage est technique ou peu familier.

Les personnes sourdes ou malentendantes qui utilisent les langues des signes comme langue principale peuvent rencontrer du texte écrit dans une deuxième ou troisième langue. Pour elles, voir une représentation phonétique d’un mot — même si elles ne peuvent pas l’entendre — peut relier la forme écrite à un concept connu plus fiablement qu’une simple définition textuelle.

Les personnes non natives et les apprenants de la langue bénéficient énormément des indications de prononciation. Un apprenant du turc qui rencontre un terme médical ou juridique spécialisé, ou un terme technique étranger transcrit en turc, peut ne pas savoir si l’accent tombe sur la première ou la deuxième syllabe, ce qui peut changer le sens ou simplement entraver la compréhension.

Un scénario concret : Considérons un portail de santé turc décrivant une procédure impliquant le mot « ileum » (une section de l’intestin grêle) aux côtés de contenu qui fait également référence à l’ilium (un os du bassin). En anglais, ces mots sonnent de manière identique dans de nombreux dialectes. Sur une page lue à voix haute par un lecteur d’écran, un patient se préparant à une opération, qui est aveugle ou malvoyant, n’aurait aucun moyen de distinguer les deux termes à partir du seul audio, à moins qu’une prononciation ou un contexte phonétique ne soit fourni. Ce n’est pas un cas hypothétique marginal — la documentation médicale est un domaine à forts enjeux où de telles ambiguïtés peuvent causer un réel préjudice.

Il existe aussi des bénéfices en termes de SEO et d’ergonomie. Les guides de prononciation encouragent l’utilisation d’une terminologie précise et bien définie. Les glossaires avec annotations phonétiques améliorent les métriques de temps passé sur la page et réduisent la frustration des utilisateurs. Un contenu structuré riche qui explique la terminologie a tendance à attirer davantage de liens entrants et à signaler une expertise thématique aux moteurs de recherche.

Règles Axe-core associées

WCAG 3.1.6 nécessite uniquement des tests manuels. Il n’existe aucune règle axe-core automatisée qui corresponde directement à ce critère. L’explication suivante clarifie pourquoi l’automatisation ne peut pas détecter de manière fiable les violations et ce que les testeurs doivent vérifier manuellement.

• Aucune règle automatisée n’existe pour l’ambiguïté de prononciation. Les moteurs de test d’accessibilité automatisés comme axe-core fonctionnent en analysant le DOM à la recherche de motifs structurels, d’attributs manquants, de rôles invalides et d’autres conditions basées sur des règles. Déterminer si un mot spécifique est ambigu sans connaître sa prononciation nécessite une compréhension sémantique et linguistique du contenu — un jugement qui dépend du vocabulaire, de la langue, du contexte de domaine et de l’arrière-plan du lecteur. Aucun moteur d’analyse statique actuel ne peut déterminer de manière fiable que le mot « read » dans une phrase donnée est ambigu en prononciation sans interprétation humaine du sens environnant. C’est pourquoi les WCAG reconnaissent que ce critère est difficile à tester par programmation et le placent au niveau AAA.
• Ce que les testeurs manuels doivent vérifier : Les testeurs doivent lire le contenu de la page avec une connaissance du domaine et de la ou des langues utilisées, et signaler tout mot pour lequel (a) deux prononciations ou plus existent, (b) chaque prononciation correspond à un sens différent, et (c) le contexte environnant ne résout pas de manière non ambiguë le sens voulu. Pour chaque mot signalé, le testeur doit ensuite vérifier qu’un mécanisme de prononciation — guide phonétique, extrait audio, lien vers un glossaire ou clarification contextuelle — est présent et accessible.
• Vérification ponctuelle avec un lecteur d’écran : Les testeurs utilisant des lecteurs d’écran (NVDA, JAWS, VoiceOver, TalkBack) doivent écouter le contenu et noter tout cas où la voix synthétisée prononce un mot d’une manière qui contredit le sens voulu dans le contexte. C’est un signal fort qu’un mécanisme de prononciation est nécessaire.

Comment tester

1. Exécuter d’abord une analyse automatisée (pour la base) : Utilisez axe DevTools ou Lighthouse pour effectuer un audit général d’accessibilité de la page. Bien qu’aucun de ces outils n’ait de règle dédiée pour WCAG 3.1.6, l’analyse peut faire apparaître des problèmes de langue connexes tels qu’un attribut lang manquant ou incorrect sur l’élément <html> (WCAG 3.1.1) ou une identification manquante de la langue pour des passages dans une autre langue (WCAG 3.1.2). Ces problèmes peuvent aggraver les problèmes de prononciation en amenant le lecteur d’écran à appliquer un moteur de langue erroné. Vérifiez que <html lang='tr'> (ou le code de langue approprié) est présent et correct.
2. Effectuer un audit de contenu pour les homographes et les termes ambigus : Avec une expertise du domaine et de la langue du contenu de la page, lisez l’ensemble du texte. Créez une liste de tous les mots qui ont plusieurs prononciations avec des sens distincts. Portez une attention particulière aux : emprunts à l’anglais, au français, à l’arabe ou à d’autres langues qui peuvent ne pas suivre les règles phonétiques standard du turc ; jargon technique en médecine, droit ou ingénierie ; noms propres dont la prononciation n’est pas évidente ; et tout mot explicitement signalé lors de la relecture éditoriale comme potentiellement déroutant.
3. Tester avec NVDA + Firefox : Ouvrez la page dans Firefox avec NVDA en cours d’exécution. Utilisez le mode de lecture continue de NVDA (Insert + Flèche bas) pour écouter l’ensemble de la page ou les sections pertinentes. Notez tout mot que le synthétiseur prononce d’une manière qui pourrait être mal comprise. Vérifiez si un mécanisme de prononciation (annotation phonétique, bouton audio, lien vers un glossaire) est disponible et si NVDA l’annonce clairement.
4. Tester avec JAWS + Chrome : Répétez le test d’écoute ci-dessus dans Chrome avec JAWS. JAWS et NVDA utilisent des synthétiseurs vocaux différents et peuvent prononcer le même mot différemment, de sorte que les deux tests sont précieux. Utilisez les paramètres de verbosité de JAWS pour vous assurer que toutes les annotations en ligne et le contenu des éléments <ruby> sont lus à voix haute.
5. Tester avec VoiceOver + Safari (macOS/iOS) : Activez VoiceOver et naviguez dans la page avec Safari. Utilisez VO + A pour lire la page en continu. Le synthétiseur vocal d’Apple a sa propre logique de prononciation ; vérifiez que les annotations <ruby> ou les substitutions aria-label sont correctement exposées.
6. Vérifier que le mécanisme de prononciation est accessible : Pour chaque mécanisme de prononciation présent sur la page, confirmez qu’il est accessible au clavier seul, qu’il est annoncé par les lecteurs d’écran, et que l’information de prononciation fournie résout effectivement l’ambiguïté (par exemple, une transcription en API n’est utile que si le public cible sait lire l’API ; une orthographe phonétique en langage clair comme « prononcé : EYE-lee-um » peut être plus universellement utile).
7. Vérifier les extraits audio de prononciation : Si des extraits audio sont utilisés, vérifiez qu’ils disposent de contrôles accessibles (bouton de lecture avec une étiquette, contrôle du volume) et que des transcriptions ou des alternatives textuelles sont disponibles pour les personnes sourdes qui ne peuvent pas bénéficier de l’audio.

Comment corriger

Homographe dans le corps du texte — Incorrect

<!-- 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>

Homographe dans le corps du texte — Correct

<!-- 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>

Écriture d’Asie de l’Est ou script annoté avec ruby — Incorrect

<!-- 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>

Écriture d’Asie de l’Est ou script annoté avec ruby — Correct

<!-- 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>

Terme technique avec prononciation ambiguë — Incorrect

<!-- "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>

Terme technique avec prononciation ambiguë — Correct

<!-- 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>

Mot emprunté avec prononciation non standard en turc — Incorrect

<!-- 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>

Mot emprunté avec prononciation non standard en turc — Correct

<!-- 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>

Erreurs courantes

• Fournir uniquement une définition textuelle sans prononciation : Ajouter une info-bulle ou une définition de glossaire qui explique le sens d’un mot ne satisfait pas WCAG 3.1.6 si la définition elle-même ne clarifie pas la prononciation. Par exemple, définir « bass » comme « un son ou un instrument de musique de basse fréquence » laisse toujours la prononciation ambiguë ; le mécanisme doit traiter spécifiquement la façon dont le mot est prononcé.
• Utiliser <ruby> sans balises de repli <rp> : Dans les navigateurs qui ne prennent pas en charge les annotations ruby nativement, omettre <rp> (parenthèses ruby) fait disparaître complètement l’annotation phonétique. Incluez toujours <rp>(</rp> et <rp>)</rp> autour de chaque élément <rt> afin que les utilisateurs sur des plateformes non prises en charge voient tout de même le texte de prononciation en ligne.
• Fournir des extraits audio sans contrôles accessibles ni alternatives textuelles : Un bouton de prononciation audio sans étiquette (par exemple, <button><img src='speaker.png'></button> sans alt ni aria-label) est inaccessible aux personnes qui en ont le plus besoin. Chaque contrôle audio doit avoir une étiquette descriptive, et le contenu de prononciation de l’audio doit également être disponible sous forme textuelle pour les personnes sourdes.
• Supposer que le moteur TTS fera le bon choix : De nombreuses équipes omettent les mécanismes de prononciation parce que leurs tests internes (effectués visuellement ou à l’oreille par des testeurs voyants/entendants) n’exposent pas l’ambiguïté. Compter sur les heuristiques d’un moteur de synthèse vocale pour choisir la bonne prononciation d’un homographe n’est pas une stratégie d’accessibilité valide ; ces heuristiques échouent régulièrement, en particulier pour le contenu spécifique à un domaine ou multilingue.
• Placer les indications de prononciation trop loin du mot : Lier à un glossaire de prononciation à l’échelle du site en bas de page ou dans une section d’aide ne répond pas au critère si les utilisateurs doivent quitter le contenu pour le trouver, perdant ainsi leur position de lecture. Le mécanisme doit être clairement associé au mot ambigu spécifique, soit en ligne, soit via un lien proche et clairement étiqueté.
• Utiliser la notation API sans tenir compte du public : Les transcriptions en Alphabet phonétique international sont précises mais ne sont pas lisibles par la plupart des publics généraux. Si vos utilisateurs ne sont pas des professionnels de la langue, des orthographes phonétiques en langage clair (« prononcé : KAY-oss » pour « chaos ») sont plus utiles en pratique. Choisir un format de guide de prononciation inaccessible sape l’objectif même d’en fournir un.
• Ne pas marquer les segments de prononciation avec les attributs de langue appropriés : Lorsqu’on fournit une orthographe phonétique dans une langue ou un système de notation différent de la langue principale de la page, omettre le bon attribut lang sur l’élément conteneur. Cela amène les lecteurs d’écran à appliquer des règles phonétiques incorrectes au texte même censé guider la prononciation, créant un problème supplémentaire.
• Appliquer le critère uniquement au corps du texte en ignorant les titres, la navigation et les libellés d’interface : Des homographes ambigus peuvent apparaître dans les titres, les libellés de boutons, le texte des liens, les libellés de champs de formulaire et les messages d’erreur. Ces emplacements sont souvent lus isolément par les utilisateurs de lecteurs d’écran qui naviguent par repère ou par type d’élément, ce qui rend la désambiguïsation contextuelle encore moins fiable que dans le corps du texte.
• Confondre WCAG 3.1.3 (Mots inhabituels) avec 3.1.6 (Prononciation) : WCAG 3.1.3 exige des mécanismes pour les mots utilisés d’une manière inhabituelle ou spécialisée. WCAG 3.1.6 cible un problème distinct : les mots dont le sens même dépend de la façon dont ils sont prononcés. Un mot peut nécessiter une correction au titre de 3.1.6 même s’il n’est pas inhabituel — « read » et « wind » sont des mots courants. Ne supposez pas que satisfaire un critère revient à satisfaire l’autre.
• Ne pas tester avec plusieurs lecteurs d’écran et moteurs TTS : Différents synthétiseurs (eSpeak de NVDA, Eloquence ou Vocalizer de JAWS, les voix intégrées d’Apple) ont des heuristiques de prononciation différentes et traiteront les homographes différemment. Un mot qu’un moteur particulier prononce correctement peut être mal prononcé par un autre. Les auteurs de contenu doivent tester avec au moins deux combinaisons lecteur d’écran/navigateur pour identifier les échecs de prononciation qui affectent les utilisateurs réels.

Lien avec la réglementation sur l’accessibilité en Turquie

La circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des exigences contraignantes en matière d’accessibilité web pour un large éventail d’entités opérant en Turquie. La circulaire impose la conformité aux normes WCAG 2.2, avec un accent principal sur les critères de niveau A et AA pour les entités couvertes. Les entités explicitement soumises à la circulaire incluent les institutions et agences publiques, les plateformes de commerce électronique, les banques et prestataires de services financiers, les hôpitaux et organisations de santé, les entreprises de télécommunications comptant 200 000 abonnés ou plus, les agences de voyage, les entreprises de transport privé et les écoles privées opérant sous autorisation du ministère de l’Éducation nationale (MoNE).

WCAG 3.1.6 Pronunciation est un critère de niveau AAA et ne fait donc pas partie des exigences légalement obligatoires au titre de la circulaire. Les entités couvertes ne sont pas tenues par la circulaire de mettre en œuvre des mécanismes de prononciation comme mesure de conformité de base. Cependant, l’objectif plus large de la circulaire — garantir que les services numériques soient réellement utilisables par tous les citoyens, y compris les personnes handicapées — est bien servi par l’adoption volontaire des critères de niveau AAA partout où cela est techniquement et éditorialement possible.

Pour certaines catégories d’entités couvertes, l’argument pratique en faveur de la mise en œuvre de WCAG 3.1.6 est particulièrement fort même en l’absence d’obligation légale. Les portails de santé gérés par des hôpitaux couverts par la circulaire traitent d’une terminologie où l’ambiguïté de prononciation peut causer un véritable préjudice aux patients. Les textes juridiques ou réglementaires publiés par les institutions publiques peuvent contenir un vocabulaire spécialisé dont la prononciation n’est pas évidente et qui crée des obstacles pour les utilisateurs de lecteurs d’écran. Les plateformes de commerce électronique qui servent des publics linguistiquement divers — y compris des personnes non natives en turc — peuvent constater que les indications de prononciation réduisent la confusion et l’abandon des clients.

Le turc est une langue phonétiquement régulière, ce qui signifie que la correspondance entre l’orthographe et la prononciation est plus cohérente que dans des langues comme l’anglais ou le français. Cela réduit (mais n’élimine pas) l’ampleur du travail de conformité à WCAG 3.1.6 pour le contenu en turc. Cependant, la prévalence des emprunts à l’anglais et au français dans le contenu technique, commercial et numérique en turc — en particulier dans les secteurs couverts par la circulaire — signifie que l’ambiguïté de prononciation reste une préoccupation réelle. Les mots empruntés à d’autres langues ne suivent pas toujours les conventions phonétiques turques et peuvent être rendus différemment par les moteurs TTS turcs selon la configuration du synthétiseur.

Les organisations soumises à la circulaire qui aspirent à une accessibilité de premier plan — ou qui servent des utilisateurs dans des contextes multilingues, opèrent dans des domaines à forts enjeux comme la santé ou la finance, ou souhaitent démontrer un leadership en matière d’accessibilité sur le marché numérique turc — devraient envisager WCAG 3.1.6 dans le cadre d’un programme d’accessibilité global qui va au-delà de la conformité légale minimale. La mise en œuvre de mécanismes de prononciation est une amélioration relativement peu coûteuse pour la plupart des types de contenu et témoigne d’un engagement réel en faveur de la conception inclusive, en phase avec l’esprit de la circulaire et avec les meilleures pratiques internationales.