WCAG 2.2の達成基準3.1.6「発音」は、読み方が分からないと文脈上の意味を一つに定められない語について、特定の発音を確認できる仕組みを用意するよう求めるLevel AAAの基準です。
すべての漢字、固有名詞、難読語に読みを付ける基準ではありません。
対象を見極めたうえで、読者が必要なときに正しい読みへ到達できるようにすることが対応の中心です。
達成基準3.1.6が求めること
W3Cによる達成基準3.1.6の解説では、発音を知らなければ文脈中の意味が曖昧になる語に対し、特定の発音を識別できる仕組みを提供することが示されています。
周囲の文章だけで意味と読み方を判断できる場合は、この達成基準のために読みを追加する必要はありません。
反対に、同じ表記に複数の読みと意味があり、文脈だけではどちらか決められない場合は対応候補になります。
Level AAAはWCAGのA、AA、AAAという三つの適合レベルのうち最も高いレベルです。
ただし、3.1.6だけに対応しても、ページやサイト全体がLevel AAAに適合したことにはなりません。
WCAGの構成を先に確認したい場合は、関連記事「WCAG 2.2とは何か」も参照してください。
対応が必要な語を見分ける
対象語の洗い出しでは、単に「読みにくいか」ではなく、「読みが分からないと意味を決められないか」を確認します。
| 確認すること | 判断の目安 |
|---|---|
| 同じ表記に複数の読みがあるか | 読みの違いによって意味も変わる場合は、次の確認へ進みます。 |
| 前後の文だけで意味を決められるか | 一つに決められるなら、3.1.6のための追加対応は通常不要です。 |
| 誤った読みで別の意味に受け取られるか | 意味が変わる、または内容を理解できなくなる場合は、読みを示します。 |
| 正しい読みを確認できる仕組みがあるか | 括弧書き、ルビ、発音情報へのリンク、用語集などから適した方法を選びます。 |
たとえば「この店は人気がない」という一文は、「人気」を「にんき」と読むか「ひとけ」と読むかで意味が変わります。
文脈だけでどちらか判断できない場合は、次のように特定の読みを示します。
<p>この店は<ruby>人気<rp>（</rp><rt>にんき</rt><rp>）</rp></ruby>がない。</p>「にんき、または、ひとけ」と二つの候補を並べるだけでは、特定の発音を識別できません。
制作者は意図する意味を確認し、その意味に対応する読みを一つ示します。
発音を示す四つの方法
W3Cが挙げる実装技法は、達成基準を満たす方法の例であり、特定の技法だけを必須とするものではありません。
コンテンツの種類、更新方法、利用環境に合わせて選びます。
語の直後に読みを記載する
初出の語の直後に読みを括弧書きする方法は、HTML以外の文書でも使いやすく、読みが本文中で確実に見える利点があります。
<p>慶應大学（けいおうだいがく）の案内です。</p>W3Cの技法G120は、原則としてページ内の初出語の直後に発音を置く方法を示しています。
同じ表記がページ内で異なる発音として使われる場合は、初出だけでは区別できないため、それぞれの該当箇所で読みを示します。
ruby要素で読みを示す
日本語の漢字に読みを添える場合は、ruby要素とrt要素を使えます。
<p><ruby>慶應大学<rp>（</rp><rt>けいおうだいがく</rt><rp>）</rp></ruby>の案内です。</p>rubyの中では、読みの対象となる文字列を一度だけ記述し、rtに読みを入れます。
rpは、ルビ表示に対応しない環境で読みを括弧内に見せるための補助要素です。
詳しい構造と確認手順は、W3Cの技法H62で確認できます。
発音情報へリンクする
音声、発音辞書、発音記号などを別の場所に用意する場合は、対象語から発音情報へ直接リンクします。
リンク文言は「こちら」ではなく、「慶應大学の読みを音声で確認する」のように、移動先で何を確認できるかを示します。
W3Cの技法G121では、発音情報が必要な語の少なくとも最初の出現をリンクにし、移動先でその発音を確認できることをテストします。
用語集に読みと意味をまとめる
専門用語や固有名詞が繰り返し登場するサイトでは、用語集に読みと意味をまとめ、本文中の語から該当項目へリンクする方法が適しています。
用語集へ移動した読者が探し直さなくて済むように、一覧の先頭ではなく対象項目へ直接つなぎます。
アクセント記号を使う場合の注意
言語によっては、標準的なダイアクリティカルマーク（アクセント記号など）が読みや意味の区別に使われます。
ただし、単語に記号を一つ加えるだけで常に達成基準を満たすわけではありません。
W3Cの技法G163は、標準的な記号を既定で表示することに加え、利用者が表示を切り替えられる仕組みまで含めて説明しています。
対象言語の正書法と利用者の読み方を確認し、日本語のルビと同じ感覚で扱わないことが必要です。
実装後のテスト手順
この達成基準は、語の意味と発音の関係を判断するため、機械的な検査だけでは完結しません。
- 編集者または対象言語を理解する担当者が、読みで意味が変わる語を抽出します。
- 前後の文だけで正しい意味を判断できるかを確認します。
- 判断できない語について、意図する意味と発音が一致しているかを確認します。
- 括弧書き、ルビ、リンク、用語集のいずれかで、読者が特定の発音へ到達できることを確認します。
rubyを使う場合は、対象文字の重複、rtの欠落、表示崩れがないかを確認します。- 発音情報へのリンクを使う場合は、リンク文言と移動先の内容が一致し、リンク切れがないかを確認します。
- 主要なブラウザと実際に想定する読み上げ環境で、読み上げ順や重複の有無を確認します。
ルビを追加しただけで、すべてのスクリーンリーダーが意図どおりに読むと断定することはできません。
ブラウザ、スクリーンリーダー、設定の組み合わせで読み方が変わり得るため、実環境での確認を残します。
読み上げ環境の基本は、関連記事「スクリーンリーダーとは」で解説しています。
よくある実装ミス
- 読みの対象を二重に書く：
調査<ruby>調査…</ruby>のように記述すると、画面上でも読み上げでも語が重複する原因になります。 - 候補だけを並べる：「リードまたはレッド」のように二つの読みを示しても、その文で使う特定の発音は分かりません。
- 難読語をすべて対象にする：3.1.6の判断軸は、読みが不明なために意味が曖昧になるかどうかです。
- 自動検査だけで合否を決める：HTMLの構造を検出できても、文脈上の意味と読みの一致は人が確認する必要があります。
- ルビだけで読み上げを保証する：支援技術の挙動を決めつけず、想定する環境で確認します。
公開前に確認する項目
- 対象語は、読みが分からなければ文脈上の意味が曖昧になるか。
- 意図する意味に対応した特定の発音を示しているか。
- 同じ表記を異なる読みで使う箇所を個別に確認したか。
- ルビの対象文字を重複していないか。
- 発音情報へのリンクに、移動先の内容が分かる文言を付けたか。
- 自動検査に加えて、目視と読み上げ環境で確認したか。
達成基準3.1.6への対応は、ルビを増やす作業ではなく、読みの違いが理解の違いにつながる箇所を見つけ、正しい意味へ案内する作業です。
対象を絞り、コンテンツに合う方法を選び、実際の利用環境で確認するところまでを一つの工程として扱います。
当社では、Webアクセシビリティの導入と運用を支援するUUU ウェブアクセシビリティを提供しています。
既存サイトの課題整理や改善方法を検討している方は、サービスの詳細をご覧ください。