WCAG 達成基準 · Level AAA
WCAG 3.1.3: 通常と異なる語句
WCAG 3.1.3 は、慣例的でないまたは限定的な方法で使用される語句や成句、専門用語を含む単語やフレーズの特定の定義を特定できる仕組みをウェブサイトが提供することを求めています。これにより、認知障害のあるユーザー、非ネイティブ話者、および専門用語に不慣れな人々がコンテンツを理解できるようになります。
- Level AAA
- Wcag
- Wcag 2 2 aaa
- 理解できる
- アクセシビリティ
このルールの意味
WCAG 3.1.3「通常とは異なる語」は、原則「理解可能」におけるレベルAAAの達成基準です。これは、通常とは異なる、専門的、または限定的な意味で使われている語や句を含むあらゆるウェブコンテンツについて、その用語の定義を利用者が調べたり参照したりできる仕組みを提供することを求めるものです。これは、言語使用の3つのカテゴリーに適用されます。すなわち、専門用語(ジャーゴン)(特定の業種、職業、分野に固有の専門語彙)、慣用句(イディオム)(「break a leg」や「hit the ground running」のように、語の文字どおりの意味からは全体の意味を推測できない句)、そして限定的または通常とは異なる意味で使われる語(特定の文脈で一般的な語に専門的または非標準的な意味を与えている場合)です。
この達成基準は、特定の実装方法を義務づけるものではありません。許容される仕組みには、本文中のインライン定義、ページからリンクされた用語集、ユーザー操作で表示されるツールチップや展開式の定義、周囲のテキスト内で提供される定義、アクセシブルな文脈と組み合わせたHTMLの<dfn>要素の使用などが含まれます。重要なのは、定義の仕組みが利用可能であること、つまり利用者が過度な負担なくそこに到達できることです。
ページ上のすべての専門用語、慣用句、または通常とは異なる使われ方をしている語のそれぞれに、到達可能な定義の仕組みが付随している場合に合格となります。逆に、専門的または曖昧な用語が、そのような仕組みなしに現れている場合は不合格です。たとえば、法務関連のウェブサイトが「tortfeasor」や「subrogation」といった用語を、用語集や本文中の説明なしに使用している場合などです。
WCAGは、限定的な例外も定めています。ある語が特定の一節の中だけで通常とは異なる意味で使われている場合、その語についてサイト全体で定義を提供するのではなく、その一節の中で定義を示せば十分です。さらに、固有名詞(人名、地名、組織名)は、文脈上、技術用語としても機能している場合を除き、一般的にはこの達成基準の対象外です。
なぜ重要か
言語理解の障壁は、非常に幅広い利用者層に影響します。ディスレクシア、知的障害、脳損傷などを含む認知障害のある人は、なじみのない用語が現れたときに文脈から意味を推測することが難しい場合があります。世界保健機関によれば、世界人口の約6人に1人が何らかの障害とともに生活しており、その中でも認知機能の障害は最大のカテゴリーの1つです。こうした利用者にとって、定義されていない専門用語に出会うことは、それ以外の点ではアクセシブルなページを完全に利用不能なものにしてしまいかねません。
非母語話者も、この達成基準の影響を大きく受けるグループです。トルコだけを見ても、第一言語がクルド語、アラビア語、その他の地域言語であり、トルコ語を第二言語として読む人が何百万人もいます。トルコ政府の健康ポータルが「anjiyoplasti」や「antikoagülan」といった医療用語を説明なしに使用している場合、これらの利用者—さらには多くのトルコ語母語話者でさえ—重要な健康情報を理解できない可能性があります。
スクリーンリーダー利用者も、より微妙ではあるものの重要な影響を受けます。用語が目に見えるツールチップや用語集で定義されている場合、晴眼者はそれを素早く視覚的に探すことができます。しかし、その仕組みがキーボードで操作できず、プログラム的にも判別できない場合、支援技術に依存する視覚障害のある利用者は定義にまったく到達できないかもしれません。構造化されたインライン定義や、適切にリンクされた用語集を提供することで、アクセスの公平性が確保されます。
具体的なシナリオを考えてみましょう。あるトルコのECプラットフォームが金融商品を販売しており、「faiz oranı bileşimi」(複利)という用語を説明なしに使用しているとします。知的障害のある利用者や、金融に不慣れな高齢の利用者がローン商品を比較しようとしたとき、用語が明確にされていないがために、経済的に不利な判断をしてしまうかもしれません。リンク付きの用語集や、平易な言葉で定義したアクセシブルなツールチップを提供することは、このリスクを直接的に軽減します。
アクセシビリティにとどまらず、この達成基準にはユーザビリティやSEOの観点からも測定可能なメリットがあります。検索エンジンにインデックスされる用語集ページは、トピックの権威性を高め、ロングテール検索トラフィックを獲得することができます。明確な定義は、カスタマーサポートの負荷を減らし、コンバージョン率を改善し、コンテンツ全体の品質向上にも寄与します。これらはすべて、商業事業者にとって重要な成果です。
関連するaxe-coreルール
WCAG 3.1.3は、手動テストを必要とする達成基準のカテゴリーに属します。通常とは異なる語が定義されているかどうかを検出できる自動のaxe-coreルールは存在しません。なぜなら、そのためにはツールがページ上のすべての語の意味やドメイン文脈を理解する必要があり、これは現在の自動解析の能力を超えているからです。
- 手動評価が必要 — 通常とは異なる語: axe-core、Lighthouse、IBM Equal Access Checkerといった自動アクセシビリティスキャナーは、どの語が専門用語、慣用句、または通常とは異なる使われ方をしている用語に該当するかを特定できません。これは、判断がドメイン知識、想定読者の文脈、言語的解釈に依存するためです。スキャナーは、「token」がある文脈ではセキュリティ認証情報を意味し、別の文脈ではバウチャーを意味することや、「cloud」が大気中の水蒸気ではなく分散コンピューティングインフラを指すことを知ることができません。人間のレビュアー—理想的にはターゲットオーディエンスのメンバーを含む—がコンテンツを読み、定義が必要な用語がないか評価する必要があります。そのうえで、レビュアーは、指摘された各用語に対してアクセシブルな定義の仕組みが存在するかを確認しなければなりません。
- 補完的な自動チェック: axe-coreはこの達成基準自体を直接評価することはできませんが、監査担当者は自動ツールを使って、使用されている定義の仕組み(
<dfn>要素、ツールチップ、リンクされた用語集など)がそれ自体としてアクセシブルかどうかを検証できます。たとえば、リンクの目的(link-name)、キーボードアクセシビリティ(tabindex)、ARIAの使用(aria-allowed-attr)を対象とするaxe-coreルールは、ツールが用語集リンクやツールチップウィジェットの実装が適切かどうかを確認するのに役立ちます—たとえ用語集が完全かどうかをツールが判断できないとしてもです。
テスト方法
- 自動プレスキャン: axe DevToolsやLighthouseをページに対して実行し、テストを妨げる可能性のあるベースラインのアクセシビリティ不具合(リンク切れ、フォーカスインジケーターの欠如など)がないことを確認します。ARIAやキーボード関連の問題として指摘されているインタラクティブな定義ウィジェット(ツールチップ、展開式用語など)をメモしておきます。これらの二次的な不具合は、定義が存在していても利用者がそこに到達することを妨げる可能性があります。
- コンテンツ監査 — 通常とは異なる用語の特定: ページのコンテンツを注意深く読みます。専門用語、技術用語、慣用句、非標準的な意味で使われている語のすべての出現箇所に印を付けます。その分野の背景知識がまったくない利用者にページを説明することを想像すると役立ちます。定義を確認する前に、指摘した用語のリストを作成します。
- 定義の仕組みの検証: 指摘した各用語について、定義の仕組みが存在し、到達可能であることを確認します。周囲のテキスト内のインライン定義、関連する
<abbr title>やリンクされた説明を伴う目に見える<dfn>要素、コンテンツからリンクされた用語集ページ、ツールチップ/展開式の定義などを確認します。仕組みがツールチップや展開式ウィジェットである場合は、ステップ4に進みます。 - キーボードナビゲーションテスト: キーボードのみ(Tab、Enter、Space、矢印キー)を使用して、ページ上のすべての定義の仕組みに到達し、起動できるか試します。ツールチップや展開式の定義が、マウスなしでもトリガーできることを確認します。FirefoxとNVDAの組み合わせでは、定義された用語に移動し、定義が読み上げられることを確認します。macOSのSafariとVoiceOverでは、VO+右矢印でコンテンツを移動し、定義の文脈が利用可能であることを確認します。ChromeとJAWSでは、用語集へのリンクがフォーカスを受け取り、リンクの目的が明確であることをテストします。
- スクリーンリーダーの読み上げ順テスト: FirefoxでNVDAを使用し、ブラウズモードを有効にしてページを直線的に読み進めます。専門用語が現れたとき、その定義がインラインで読み上げられるか、あるいは定義へのリンク/ボタンが直後にあり、明確にラベル付けされていることを確認します。定義にアクセスするために、利用者がページから離れて文脈を失うことを強いられていないことを確認します。
- 用語集の完全性チェック: サイトが集中管理された用語集を使用している場合、指摘した通常とは異なる用語のリストを用語集の項目と照合します。指摘したすべての用語に対応する項目があることを確認します。また、用語集ページ自体がアクセシブルであること(適切な見出し構造、キーボードでの操作性、スクリーンリーダーでの読み上げが可能であること)を検証します。
修正方法
定義のない技術的専門用語 — 不適切な例
<p>
The system uses OAuth2 for authorization, issuing a JWT
that expires after 3600 seconds. Refresh tokens are stored
in an HttpOnly cookie to mitigate XSS vectors.
</p>
インライン定義を伴う技術的専門用語 — 適切な例
<!-- Using dfn elements with title attributes and a linked glossary -->
<p>
The system uses
<dfn><abbr title='OAuth 2.0: An open authorization protocol that allows
third-party applications to access user data without exposing
credentials.'>OAuth2</abbr></dfn>
for authorization, issuing a
<dfn><abbr title='JWT (JSON Web Token): A compact, URL-safe token
format used to transmit claims between parties.'>JWT</abbr></dfn>
that expires after 3600 seconds. See our
<a href='/glossary#security-terms'>Security Glossary</a>
for full definitions.
</p>
説明のない慣用的表現 — 不適切な例
<p>
Our customer support team will go the extra mile to ensure
your issue is resolved. We believe in burning the midnight
oil so you never have to.
</p>
平易な言葉に書き換えた慣用的表現 — 適切な例
<!-- Plain language replacement is the most robust fix for idioms.
If idioms must be retained for brand voice, provide a
parenthetical explanation or tooltip. -->
<p>
Our customer support team will make every effort to ensure
your issue is resolved. We work extended hours so you
receive help whenever you need it.
</p>
定義されていない専門用語を含む医療・法務コンテンツ — 不適切な例
<p>
Patients diagnosed with dyslipidemia may be prescribed
statins to manage LDL cholesterol levels and reduce the
risk of atherosclerosis.
</p>
アクセシブルな用語集リンクを伴う医療コンテンツ — 適切な例
<!-- Each technical term links to the relevant glossary anchor.
The glossary page contains plain-language definitions. -->
<p>
Patients diagnosed with
<a href='/glossary#dyslipidemia'>dyslipidemia</a>
(abnormal levels of lipids in the blood) may be prescribed
<a href='/glossary#statins'>statins</a>
to manage
<a href='/glossary#ldl'>LDL cholesterol</a>
levels and reduce the risk of
<a href='/glossary#atherosclerosis'>atherosclerosis</a>
(hardening and narrowing of the arteries).
</p>
限定的またはドメイン固有の意味で使われる語 — 不適切な例
<p>
Submit your token at the kiosk to claim your reward.
Tokens expire at the end of each session.
</p>
文脈的な定義を伴う限定的意味の語 — 適切な例
<!-- The first use of the term in the restricted sense is
marked with dfn and explained. Subsequent uses are clear
by context. -->
<p>
Submit your
<dfn id='def-token'>token</dfn>
(a single-use digital voucher issued when you complete
a qualifying purchase) at the kiosk to claim your reward.
Tokens expire at the end of each session.
</p>
よくある間違い
- 用語集で用語を定義しているが、コンテンツからリンクしていない: 用語集は、利用者がその存在を知り、そこに到達できる場合にのみ有用です。通常とは異なる用語を定義にリンクしない、あるいはナビゲーションに目立つ用語集リンクを設けないと、多くの利用者はそのリソースに気づかないままになります。
- 略語ではなく完全な語に対して
<abbr title='...'>を使用している:<abbr>のtitle属性は、あらゆる用語に対する汎用ツールチップとして誤用されることがよくあります。スクリーンリーダーはtitleを一貫して扱っておらず、ほとんどのブラウザではキーボード利用者からはデフォルトで見えません。完全な語には、アクセシブルなリンク付き説明や隣接テキストを伴う<dfn>を使用してください。 - キーボードでアクセスできないツールチップ定義を提供している: マウスホバーでのみ起動するCSSのみまたはJavaScriptのツールチップは、キーボード利用者やタッチデバイス利用者を完全に排除してしまいます。定義を伝えるために使用されるツールチップは、キーボードフォーカスで起動でき、利用者が内容を読むためにフォーカスをツールチップ内に移動しても消えてはならないとされています。
- 一般向けサイトにおいて業界標準用語には定義が不要だと想定している: 「bandwidth」「uptime」「SLA」「API」といった用語は、技術チームにとっては自明でも、通信事業者やクラウドサービスのウェブサイトを訪れる一般の人々には理解しづらい場合があります。常に、想定読者の中で最も知識の少ない人の視点から用語を評価してください。
- 文書内の最初の出現箇所でのみ用語を定義し、その後、別ページで前置きなしに登場させている: ある利用者が、用語が別のページでのみ定義されているにもかかわらず、その用語を参照している深い階層の記事ページからサイトに入ってきた場合、その利用者は定義にアクセスできません。各ページは、それ単体で完結しているか、エントリーポイントに関係なく定義へのナビゲーションを提供しなければなりません。
- フォームラベル、ボタンテキスト、エラーメッセージ内で定義なしに専門用語を使用している: 「Authorize delegated access」のようなボタンや、「Your session token is invalid」のようなエラーメッセージなど、インタラクティブなUI要素内の通常とは異なる語は、利用者が重要なタスクを完了するために理解する必要があるため、特に有害です。こうした箇所はコンテンツ監査で見落とされがちです。
- 用語集の定義をさらに別の専門用語で書いている: 「amortization」を「the systematic allocation of an intangible asset's cost over its useful life」と定義する用語集の項目は、一般の利用者の助けにはなりません。定義自体も、想定読者にとってアクセスしやすい平易な言葉で書かれていなければなりません。
- 多言語または翻訳コンテンツにおいて、言語固有の慣用表現を無視している: コンテンツが英語からトルコ語(またはその逆)に翻訳される際、慣用表現が文字どおりに訳され、ターゲット言語では意味不明または紛らわしいフレーズになってしまうことがよくあります。各ローカライズ版は、慣用表現の正確さと理解しやすさについて、ネイティブスピーカーによるレビューを受ける必要があります。
<dfn>を、利用者向けの定義を伴わない純粋なセマンティック要素として扱っている: HTMLの<dfn>要素は、用語が定義されている箇所を示すものですが、それ自体が利用者に定義を提供するわけではありません。常に、隣接テキスト、aria-describedbyによる関連付け、または周囲の段落内の目に見える定義のいずれかと組み合わせる必要があります。- axeルールで指摘されないからという理由で、通常とは異なる語を自動監査チェックリストから外している: この達成基準は手動評価を必要とするため、技術的な監査の際に優先度が下がりがちです。チームは、アクセシビリティQAワークフローの正式なステップとして、言語と用語に関する文書化された手動レビュー手順を確立すべきであり、後回しにしてはなりません。
トルコのアクセシビリティ規制との関係
2025年6月21日付官報第32933号で公布されたトルコ大統領通達2025/10は、トルコで事業を行う幅広い公的・民間主体に対し、WCAG 2.2に整合したウェブおよびモバイルのアクセシビリティ要件を義務づけています。対象となる主体には、公的機関・行政機関、ECプラットフォーム、銀行・金融機関、病院・民間医療提供者、20万件以上の加入者を有する通信会社、旅行代理店、民間輸送会社、国民教育省(MoNE)により認可された私立学校などが含まれます。
この通達は、法的な最低要件としてWCAG 2.2レベルAAへの準拠を義務づけています。WCAG 3.1.3「通常とは異なる語」はレベルAAAの達成基準であり、この規制の下では法的義務には含まれません。しかし、それでもトルコの組織にとっての実務的な重要性が損なわれるわけではありません。公的な健康ポータル、国の教育プラットフォーム、金融サービス企業など、言語的に多様な人々にサービスを提供する主体には、3.1.3のようなAAA達成基準を実装する強い倫理的・評判上の動機があります。
特定の専門サービスにおいては、実質的にレベルAAAへの適合が必要となる場合もあります。健康リテラシーのレベルがさまざまな患者にサービスを提供する医療機関、認知障害のある学生にサービスを提供するMoNE認可の教育プラットフォーム、すべての市民に対して明確なコミュニケーションを求められる政府ポータルなどは、この達成基準を実装することで大きな恩恵を受けるでしょう。トルコの障害者権利の枠組みは、トルコが障害者の権利に関する国連条約を批准していることによって強化されており、AAA達成基準は、法的に厳密に義務づけられていない場合でも、情報への平等なアクセスというより広い使命を精神的に補完するものです。
競争上の優位性、国際市場へのアクセス、公的部門の調達要件の充足、あるいはインクルーシブデザインへの真摯なコミットメントなどを目的として、最高水準のアクセシビリティを示そうとする組織は、WCAG 3.1.3を、規制上の最低限を超えた包括的なアクセシビリティプログラムの一部として位置づけるべきです。構造化された用語集システムの実装、コンテンツ作成者に対する通常とは異なる用語の認識と定義方法のトレーニング、編集ワークフローへの言語アクセシビリティの組み込みなどは、トルコの利用者に貢献し、大統領通達2025/10のより広い目標とも整合する実践的なステップです。
