WCAG 3.1.6: 発音

WCAG 3.1.6 は、発音を知らなくても意味があいまいになる語について、その特定の発音を特定できる仕組みが利用可能であることを求めています。この基準は、音声読み上げ技術に依存するユーザーや、なじみのない言語に出会うユーザーが、あいまいなコンテンツの正しい意味にアクセスできるようにするものです。

この規則が意味すること

WCAG 3.1.6「発音」は、理解可能という原則の下にあるレベルAAAの達成基準です。そこでは次のように述べられています。「文脈において、発音を知らなければ語の意味が曖昧になる場合に、その語の特定の発音を特定できるメカニズムが利用可能である。」

中核となる要件は、ある語の意味がその発音の仕方だけに依存しており、しかもその発音が周囲の文脈からは判断できない場合には、利用者が正しい発音を知ることができる手段を著者が提供しなければならない、という点です。これは単に定義を提供することとは異なります。この達成基準は、意味上の曖昧さを解消する音声学的な発音に特化したものです。

この達成基準が対象とするのは、同じ文字列が複数の読み方を持ち、それぞれが異なる意味を生む状況です。英語の典型的な例としては、「read」（現在形で「reed」と同じ発音）と「read」（過去形で「red」と同じ発音）、あるいは「wind」（風、「sinned」と韻を踏む）と「wind」（巻く、「find」と韻を踏む）などがあります。日本語、中国語、アラビア語のように、より複雑な文字体系や声調の区別を持つ言語では、この問題はさらに頻繁かつ重大になります。

トルコ語は、多くの他言語と比べると音声的には規則的な言語ですが、それでも専門的・技術的・形式的な文脈では、発音が不明瞭になりうる語や外来語が存在します。特にスクリーンリーダー利用者にとっては、合成音声エンジンが馴染みのない用語や外来語のアクセントや発音を誤る可能性があります。

合格とみなされる条件: 語の発音を知らなければ意味が曖昧になる箇所について、少なくとも次のいずれかのメカニズムが存在する場合、そのページは合格となります。

語のすぐそばに配置されたインラインの発音ガイド（例: 東アジアの文字体系に対してHTMLの<ruby>要素と、それに付随する<rt>および<rp>タグを用いる、あるいはIPAなどの認知された表記体系による括弧付きの発音表記を用いる）。
その曖昧な語の発音を明示的に扱っている用語集の項目や発音ガイドへのリンク。
語に紐づいた音声による発音クリップ。
読者が解釈できる形で、その語の直前または直後に発音を説明するインラインテキスト（例: 「ここでの 'bass' は魚を指し、'mass' と同じ発音です」のような説明）。

不合格とみなされる条件: 語の意味が、実際に音声で聞かなければ曖昧なままであり、その曖昧さを発音情報によって解消するメカニズムが存在しない場合、そのページは不合格となります。発音を明らかにしないテキスト上の定義だけを提供しても、発音を知らなければ定義から意味を導けないのであれば不十分です。なお、周囲の文、見出し、画像などの文脈によってすでに発音が明確になっている場合には、追加のメカニズムがなくてもこの達成基準は満たされます。

公式な例外: WCAG仕様は、この達成基準の対象を、発音を知らなければ曖昧さが生じるケースに明示的に限定しています。周囲のテキスト、ビジュアル、意味構造によってすでに曖昧さが完全に解消されている場合には、追加の発音メカニズムは不要です。この達成基準は、すべてのページのすべての語に音声学的注釈を付けることを求めているわけではなく、文脈から推測できない発音に意味が依存している語に限って求めています。

なぜ重要か

発音の曖昧さは、いくつかの異なるユーザーグループにとって実質的な障壁となり、とりわけ一次的なテキスト以外の視覚的・聴覚的手がかりに頼れない人々にとって深刻な影響を及ぼします。

スクリーンリーダーに依存する全盲およびロービジョンのユーザーは、最も直接的な影響を受けるグループです。スクリーンリーダーはテキストを合成音声に変換しますが、ある語に複数の正しい発音があり、それぞれが異なる意味を持つ場合、TTSエンジンはどれか一つを選ばなければならず、しばしば誤った方を選びます。例えば「compound interest（複利）」についての金融記事を聞いているユーザーが、「compound」が名詞（囲われた敷地）と同じ発音で読まれてしまい、一時的あるいは継続的な混乱を招くことがあります。周囲の視覚的文脈を素早く見直すことができないユーザーにとって、この混乱を解消するには、該当箇所を何度も聞き直したり、別の手段で確認したりする必要があります。世界保健機関によれば、世界で約22億人が何らかの視覚障害を抱えており、その相当数がデジタルコンテンツへの主なアクセス手段としてスクリーンリーダー技術を利用しています。

認知・学習障害のあるユーザー（ディスレクシアや言語処理障害を含む）は、視力に問題がなくてもTTSツールに依存することがよくあります。こうしたユーザーにとって、同形異義語の誤った発音を聞くことは、特に技術的または馴染みのない文章では、回復が難しい形で理解を妨げることがあります。

ろう者および難聴のユーザーで、手話を第一言語としている人は、第二・第三言語として書記言語に触れることがあります。彼らにとっては、たとえ音として聞くことができなくても、語の音声表記を見ることで、単なるテキストの定義だけよりも確実に、書かれた形と既知の概念を結びつけることができます。

非母語話者や言語学習者も、発音ガイドから大きな恩恵を受けます。トルコ語学習者が専門的な医療・法律用語や、トルコ語表記に転写された外国の技術用語に出会ったとき、アクセントが第1音節にあるのか第2音節にあるのか分からないことがあります。これは意味を変えてしまう場合もあれば、単に理解を妨げる場合もあります。

具体的な実例シナリオ: トルコの医療ポータルで、小腸の一部を指す「ileum」という語と、骨盤の骨である「ilium」という語が同じページで扱われているとします。英語では、多くの方言でこれらは同じ発音になります。スクリーンリーダーで読み上げられるページ上では、手術を控えた全盲またはロービジョンの患者は、発音や音声学的な文脈が提供されない限り、音声だけから両者を区別することができません。これは仮想的なレアケースではなく、医療文書のような高リスク領域では、この種の曖昧さが実際の危害につながり得ます。

SEOとユーザビリティの利点も存在します。発音ガイドは、正確で明確に定義された用語の使用を促します。音声学的注釈付きの用語集は、ページ滞在時間の向上やユーザーのフラストレーションの軽減に寄与します。用語を丁寧に説明した構造化コンテンツは、より多くの被リンクを集めやすく、検索エンジンに対して専門性の高さを示すシグナルにもなります。

テスト方法

まず自動スキャンを実行する（ベースラインとして）: axe DevToolsやLighthouseを使って、ページの一般的なアクセシビリティ監査を行います。どちらのツールにもWCAG 3.1.6専用のルールはありませんが、<html>要素のlang属性の欠落や誤り（WCAG 3.1.1）、別言語の箇所に対する言語指定の欠如（WCAG 3.1.2）など、関連する言語上の問題が検出されることがあります。これらの問題は、スクリーンリーダーに誤った言語エンジンを適用させてしまい、発音の問題をさらに悪化させる可能性があります。<html lang='tr'>（または適切な言語コード）が存在し、正しいことを確認してください。
同形異義語や曖昧な用語のコンテンツ監査を行う: ページの主題と使用言語についての専門知識を持って、テキストコンテンツ全体を読みます。複数の発音とそれぞれ異なる意味を持つ語をリストアップします。特に注意すべきは、標準的なトルコ語の音声規則に従わない可能性のある英語・フランス語・アラビア語などからの外来語、医療・法律・工学などの専門用語、発音が直感的でない固有名詞、編集段階で混乱を招く可能性があると明示された語などです。
NVDA + Firefoxでテストする: Firefoxでページを開き、NVDAを起動します。NVDAの連続読み上げモード（Insert + 下矢印）を使って、ページ全体または該当セクションを聞きます。誤解を招きうる発音を合成音声がしている語がないかを確認します。発音メカニズム（音声学的注釈、音声ボタン、用語集リンクなど）が存在するか、またNVDAがそれを適切に読み上げているかを確認します。
JAWS + Chromeでテストする: ChromeとJAWSを使って、上記と同様の聞き取りテストを行います。JAWSとNVDAは異なる音声合成エンジンを使用しており、同じ語でも発音が異なる場合があるため、両方のテストに価値があります。JAWSの冗長度設定を調整し、インライン注釈や<ruby>要素の内容がすべて読み上げられるようにします。
VoiceOver + Safari（macOS/iOS）でテストする: VoiceOverを有効にし、Safariでページをナビゲートします。VO + Aでページ全体を連続読み上げします。Appleの音声合成エンジンには独自の発音ロジックがあるため、<ruby>注釈やaria-labelによる上書きが正しく読み上げられているかを確認します。
発音メカニズムがアクセシブルであることを検証する: ページ上に存在する各発音メカニズムについて、キーボードだけで操作可能か、スクリーンリーダーがそれを読み上げるか、そして提供されている発音情報が実際に曖昧さを解消しているかを確認します（例: IPA表記は正確ですが、対象ユーザーがIPAを読めなければ有用ではありません。「pronounced: EYE-lee-um」のような平易な音声表記の方が、より広く役立つ場合があります）。
音声発音クリップを確認する: 音声クリップを使用している場合は、アクセシブルなコントロール（ラベル付きの再生ボタン、音量調整など）があること、そして音声から恩恵を受けられないろう者のために、トランスクリプトやテキストによる代替が提供されていることを確認します。

修正方法

本文中の同形異義語 — 不適切な例

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

本文中の同形異義語 — 適切な例

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

東アジア言語やルビ付きスクリプト — 不適切な例

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

東アジア言語やルビ付きスクリプト — 適切な例

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

発音が曖昧な専門用語 — 不適切な例

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

発音が曖昧な専門用語 — 適切な例

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

トルコ語における非標準的な発音の外来語 — 不適切な例

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

トルコ語における非標準的な発音の外来語 — 適切な例

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

よくある間違い

発音なしでテキストの定義だけを提供する: ツールチップや用語集の定義を追加して語の意味を説明しても、その定義自体が発音を明確にしないのであれば、WCAG 3.1.6を満たしたことにはなりません。例えば、「bass」を「低周波の音または楽器」と定義しても、発音の曖昧さは残ったままです。メカニズムは、その語がどのように発音されるかを明示的に扱う必要があります。
<ruby>を<rp>フォールバックタグなしで使用する: ルビ注釈をネイティブにサポートしないブラウザでは、<rp>（ルビ用括弧）を省略すると、発音注釈が完全に表示されなくなります。サポートしていない環境でも発音テキストがインラインで見えるように、各<rt>要素の前後に必ず<rp>(</rp>と<rp>)</rp>を含めてください。
アクセシブルなコントロールやテキスト代替なしで音声クリップを提供する: ラベルのない音声発音ボタン（例: <button><img src='speaker.png'></button>でaltやaria-labelがない）は、まさにそれを必要とするユーザーにとってアクセシブルではありません。すべての音声コントロールには説明的なラベルが必要であり、音声の内容である発音は、音声から恩恵を受けられないろう者のためにテキストでも提供されなければなりません。
TTSエンジンが正しく発音してくれると想定する: 多くのチームは、視覚的または聴覚的に健常なテスターによる内部テストでは曖昧さが露呈しないため、発音メカニズムを省略してしまいます。しかし、同形異義語の正しい発音を選ぶことをTTSエンジンのヒューリスティクスに任せるのは、有効なアクセシビリティ戦略ではありません。特にドメイン固有や多言語のコンテンツでは、これらのヒューリスティクスは頻繁に失敗します。
発音ガイドを語から離れた場所に配置する: ページ下部やヘルプセクションにあるサイト全体の発音用語集へのリンクは、ユーザーがコンテンツから離れて探しに行かなければならず、その間に読んでいた位置を失ってしまうため、この達成基準を満たしません。メカニズムは、曖昧な語と明確に関連づけられている必要があり、インラインか、近接した明確なラベル付きリンクとして提供されなければなりません。
ユーザー層を考慮せずにIPA表記だけを使う: 国際音声記号（IPA）は正確ですが、一般のユーザーにはほとんど読めません。ユーザーが言語の専門家でない場合は、「chaos」に対する「pronounced: KAY-oss」のような平易な音声表記の方が実用的です。ユーザーにとって読めない形式で発音ガイドを提供しても、本来の目的を損なうだけです。
発音用のスパンに適切な言語属性を付与しない: ページの主言語とは異なる言語や表記体系で音声表記を提供する場合に、包含要素に正しいlang属性を付けないと、スクリーンリーダーは誤った音声規則を適用してしまいます。これは、発音を案内するためのテキスト自体が誤って読まれるという、問題の上塗りになります。
本文だけにこの達成基準を適用し、見出し・ナビゲーション・UIラベルを無視する: 曖昧な同形異義語は、見出し、ボタンラベル、リンクテキスト、フォームラベル、エラーメッセージなどにも現れます。これらの場所は、スクリーンリーダーユーザーがランドマークや要素タイプごとに個別に読み上げることが多く、本文よりも文脈による解消が難しい場合があります。
WCAG 3.1.3（慣れない語）と3.1.6（発音）を混同する: WCAG 3.1.3は、特殊な意味で使われる語に対してメカニズムを求めるものです。一方、WCAG 3.1.6が対象とするのは、意味そのものが発音に依存する語です。「read」や「wind」のように一般的な語であっても、3.1.6の対象となることがあります。一方の達成基準を満たしたからといって、もう一方も自動的に満たされると考えてはいけません。
複数のスクリーンリーダーやTTSエンジンでテストしない: NVDAのeSpeak、JAWSのEloquenceやVocalizer、Appleの内蔵音声など、異なる合成音声は異なる発音ヒューリスティクスを持ち、同じ同形異義語でも扱いが異なります。あるエンジンではたまたま正しく発音される語が、別のエンジンでは誤って発音されることがあります。コンテンツ制作者は、少なくとも2つのスクリーンリーダー／ブラウザの組み合わせでテストし、実際のユーザーに影響する発音の問題を特定すべきです。

トルコのアクセシビリティ規制との関係

2025年6月21日付官報第32933号で公布されたトルコ大統領通達2025/10は、トルコで事業を行う幅広い主体に対して、拘束力のあるウェブアクセシビリティ要件を定めています。この通達は、対象となる主体に対し、WCAG 2.2標準への準拠を義務づけており、主にレベルAおよびレベルAAの達成基準に重点を置いています。通達の対象として明示されているのは、公共機関・行政機関、eコマースプラットフォーム、銀行・金融サービス提供者、病院・医療機関、20万人以上の加入者を持つ通信会社、旅行代理店、民間の交通事業者、国民教育省（MoNE）の認可を受けて運営される私立学校などです。

WCAG 3.1.6「発音」はレベルAAAの達成基準であり、そのため通達で法的に義務づけられている要件には含まれていません。対象組織は、ベースラインのコンプライアンス措置として発音メカニズムを実装する義務は負いません。しかし、通達のより広い目的は、障害のある人を含むすべての市民がデジタルサービスを真に利用できるようにすることにあり、技術的・編集的に可能な範囲でレベルAAAの達成基準を自主的に採用することは、この目的に大いに資するものです。

特定の対象組織カテゴリーにとっては、法的義務がない場合でも、WCAG 3.1.6を実装する実務的な意義が特に大きくなります。通達の対象となる病院が運営する医療ポータルでは、発音の曖昧さが患者に実害を与えうる用語が扱われます。公共機関が公開する法律・規制文書には、発音が直感的でない専門用語が含まれることがあり、スクリーンリーダーユーザーにとって障壁となり得ます。多様な言語背景を持つ利用者（トルコ語を母語としない人を含む）にサービスを提供するeコマースプラットフォームでは、発音ガイドを提供することで、顧客の混乱や離脱を減らせる可能性があります。

トルコ語は音声的に規則的な言語であり、綴りと発音の対応は英語やフランス語などに比べて一貫しています。そのため、トルコ語コンテンツにおけるWCAG 3.1.6対応の範囲は、ある程度は限定されます。しかし、特に通達の対象となるセクターでは、トルコ語の技術・商業・デジタルコンテンツに英語やフランス語からの外来語が多く含まれているため、発音の曖昧さは依然として現実的な懸念事項です。他言語から借用された語は、必ずしもトルコ語の音声規則に従うとは限らず、使用される合成音声エンジンの設定によって、トルコ語のTTSエンジンが異なる発音をする場合があります。

通達の対象となる組織のうち、最高水準のアクセシビリティを目指す組織、複数言語環境のユーザーにサービスを提供する組織、医療や金融などの高リスク領域で事業を行う組織、あるいはトルコのデジタル市場においてアクセシビリティのリーダーシップを示したい組織は、最低限の法的コンプライアンスを超えた包括的なアクセシビリティプログラムの一環として、WCAG 3.1.6を検討すべきです。発音メカニズムの実装は、多くのコンテンツタイプにとって比較的低コストの改善であり、通達の精神および国際的なベストプラクティスの双方に合致した、インクルーシブデザインへの真摯なコミットメントを示すものです。

出典と参考資料

AWCAG 1.1.1: 非テキストコンテンツ AWCAG 1.2.1: 音声のみおよび映像のみ（事前録画）AWCAG 1.2.2: キャプション（事前録画）