WCAG 達成基準 · Level AAA

WCAG 3.1.4: 略語

WCAG 3.1.4 は、コンテンツ内で使用されている略語の完全な形や意味を特定できる仕組みが利用可能であることを求めています。この基準は、略語、頭字語、イニシャリズムに不慣れなユーザーがその完全な意味にアクセスできるようにし、認知障害のある人、非母語話者、スクリーンリーダー利用者の理解を支援することを目的としています。

このルールの意味

WCAG 達成基準 3.1.4 — 略語(レベル AAA)は、略語、頭字語、頭字語イニシャリズムがウェブコンテンツに現れるたびに、ユーザーがその完全な形や意味を知ることができる仕組みが存在することを求めています。WCAG の用語でいう略語とは、単語、語句、名称の短縮形であり、従来型の略語(例:「approximately」を「approx.」とするもの)、頭字語(例:「National Aeronautics and Space Administration」を「NASA」とするもの)、イニシャリズム(例:「HyperText Markup Language」を「HTML」とするもの)を含みます。

この達成基準は、特定の技術を 1 つだけ義務付けているわけではありません。その代わりに、ユーザーが見慣れない省略表現に出会ったとき、それが何を意味するのかを判断できるようにするための何らかの仕組みが存在することを求めています。許容される仕組みには、初出時に本文中で略語を展開すること(例:「HyperText Markup Language (HTML)」)、展開形を提供する title 属性付きの HTML の <abbr> 要素を使用すること、ページからリンクされた用語集を提供すること、あるいは周囲の文脈に完全な形を含めて意味が曖昧にならないようにすることなどが含まれます。

適合(パス)となるのは、コンテンツ内のすべての略語について、少なくとも次のいずれかの仕組みがある場合です。すなわち、初出時に略語の直前または直後に完全な形が本文中に現れている、情報量のある title 属性を持つ <abbr> 要素で略語が囲まれている、ページからアクセスできる用語集または定義リストでその用語が定義されている、あるいは周囲の文脈によって意味が完全に明確で曖昧さがない場合です。不適合(フェイル)となるのは、略語がこれらのいずれの支援もなしに現れる場合です。つまり、ユーザーが「MoNE」や「SCR」のような省略形を見ても、それが何を意味するのかを示す手がかりがなく、ツールチップも、事前の展開も、リンクされた用語集も存在しない場合です。

WCAG には狭い例外が含まれています。略語が言語そのものの一部と見なされる場合、すなわち、単独の単語として機能するほど広く理解されている場合(もともとは頭字語であった「laser」や「radar」など)、展開は必須ではありません。同様に、そのコンテンツ自身の定義済み用語として略語が定義され、その文脈で一貫して使用され、明確にアクセス可能な用語集がある場合も適合と見なされます。常に重要なテストは、その略語に不慣れなユーザーが、コンテンツ内で利用可能な仕組みを通じてその意味を見つけることができるかどうかです。

なぜ重要か

略語はウェブコンテンツに広く浸透しています。政府ポータル、医療システム、e コマースプラットフォーム、教育サイトなどは、いずれも省略表現に大きく依存しています。これらの短縮形は専門家にはなじみ深い一方で、いくつかのユーザー層にとっては重大な障壁となります。

ディスレクシア、知的障害、注意欠如などの認知・学習障害のある人は、見慣れない略語を解読するのに苦労し、その意味を調べるためにページを離れざるを得なかったり、完全に諦めてしまったりすることがあります。記憶障害のあるユーザーにとっては、以前に見た略語であっても、セッションごとに確実に記憶されるとは限らないため、ページ内の仕組みが継続的な重要な支援となります。

スクリーンリーダー利用者 — 盲人や重度の弱視の人を含む — は直接的な影響を受けます。スクリーンリーダーは略語を、意味不明または紛らわしい形で音声化することがあるからです。例えば、スクリーンリーダーが「SCR」を「Sustainable Corporate Responsibility」としてではなく、意味をなさない文字列として読み上げてしまう場合があります。<abbr> 要素が title 属性とともに適切に使用されていると、一部のスクリーンリーダー設定ではイニシャリズムではなく完全な展開形を読み上げることができ、理解度が大幅に向上します。世界保健機関によれば、世界で約 22 億人が何らかの視覚障害を抱えており、その多くがデジタルコンテンツにアクセスするために支援技術に依存しています。

非母語話者も、影響を受けるグループの一つです。英語の技術文書を読むトルコ人ユーザーや、トルコ政府ポータルを利用する英語話者は、その言語に堪能であっても、分野固有または文化固有の略語にはまったく馴染みがない場合があります。展開形を提供することは、ユーザーの背景や知識の多様性を尊重することにつながります。

具体的なシナリオを考えてみましょう。病院のオンラインポータルを訪れた患者が、自身の診断レポートを読み、「KOAH」という表記に出会ったものの、展開がない場合です。トルコ人の臨床医であれば、すぐにこれが「Kronik Obstrüktif Akciğer Hastalığı」(慢性閉塞性肺疾患)を意味することを理解しますが、医療用語に不慣れな患者や介護者は、自分の診断内容を理解できないまま取り残されてしまいます。初出時にインラインで展開するか、<abbr title='Kronik Obstrüktif Akciğer Hastalığı'>KOAH</abbr> 要素を用いることで、この分かりにくい用語は理解可能な情報へと変わり、情報に基づく意思決定を支援します。

アクセシビリティにとどまらず、使いやすさや SEO にも測定可能なメリットがあります。検索エンジンは略語の展開形をインデックス化するため、完全な用語で検索するユーザーに対するコンテンツの発見性が向上します。明確で曖昧さのない言葉遣いは、サポートへの問い合わせを減らし、タスク完了率を高め、あらゆるリテラシーレベルのユーザーとの信頼関係を構築します。

関連する axe-core ルール

WCAG 3.1.4 には手動テストが必要です。なぜなら、特定の略語がページの文脈の中で十分に説明されているかどうかを、自動ツールが確実に判断することはできないからです。自動スキャナーは <abbr> 要素の存在を検出することはできますが、ページ上のすべての略語にアクセシブルな展開形が与えられているかどうかを判断することはできません。以下は、関連する axe-core の文脈の概要です。

  • 手動テストが必要(専用の axe-core ルールなし): Axe-core には WCAG 3.1.4 専用の自動ルールは含まれていません。これは、どの文字列が略語に該当するか、それがページのどこかで十分に展開されているか、リンクされた用語集がアクセシブルかどうかを判断するには、人間の判断と文脈に基づく読み取りが必要だからです。自動ツールは、深い自然言語理解なしには、「IT」(Information Technology)、「it」(代名詞)、「It」(固有名詞)を区別することができません。テスターはページコンテンツを手動で読み、すべての略語、頭字語、イニシャリズムを特定し、それぞれにアクセシブルな展開の仕組みがあるかどうかを確認する必要があります。
  • 関連チェック — title のない <abbr> 3.1.4 に対応する独立した axe-core ルールではありませんが、一部のアクセシビリティリンティングツールやブラウザー拡張機能は、ベストプラクティスの警告として title 属性を欠く <abbr> 要素をフラグ付けします。<abbr> を展開の仕組みとして使用する場合、title 属性は必須であり、完全な展開形を含んでいなければなりません。空の title や欠落した title は、この要素の目的を損ない、この達成基準における不適合となります。

テスト方法

  1. 自動スキャンによるベースライン: ページに対して axe DevTools または Lighthouse を実行します。どちらのツールにも 3.1.4 専用のルールはありませんが、axe DevTools は title 属性のない <abbr> 要素に関するベストプラクティス通知を表示する場合があります。これらを出発点として記録しつつ、<abbr> マークアップ自体がまったくない略語は検出されないことを理解しておきます。
  2. 手動によるコンテンツ監査: 見出し、本文、表、フォームラベル、ボタンラベル、ナビゲーション項目、フッターテキストを含むページ全体のコンテンツを読みます。略語、頭字語、イニシャリズムとなり得るすべての単語または文字列をハイライトします。それぞれについて、(a) 同じページ上で以前に展開されているか、(b) 空でない title を持つ <abbr> 要素で囲まれているか、(c) それを定義する用語集へのリンクがページにあるか、(d) 周囲の文脈によって意味が曖昧さなく明確になっているかを確認します。
  3. NVDA + Firefox によるスクリーンリーダー検証: NVDA を有効にした状態で Firefox でページを開きます。矢印キーを使ってコンテンツを移動します。NVDA が <abbr> 要素と title を検出した場合、その title テキストを読み上げるはずです。展開形が読み上げられているか確認します。<abbr>title 属性に対する NVDA の挙動は、バージョンや設定によって異なる場合があるため、まずは NVDA のデフォルト設定でテストします。
  4. VoiceOver + Safari(macOS/iOS)によるスクリーンリーダー検証: VoiceOver を有効にし、ページをナビゲートします。macOS の VoiceOver は <abbr> 要素の title 属性を読み上げます。VO+A を使ってページを直線的に読み上げ、略語に展開形が付与されているかどうかを確認します。iOS ではスワイプでコンテンツを移動し、同様の挙動を確認します。
  5. JAWS + Chrome によるスクリーンリーダー検証: JAWS を有効にした状態で、矢印キーを使ってページをナビゲートします。JAWS は <abbr title='...'> を、title を読み上げることで処理します。マークアップされた各略語について、展開形が正しく読み上げられるかテストします。
  6. ツールチップ展開のキーボードおよび視覚チェック: 実装が CSS のツールチップパターンや、<abbr> のホバー状態に紐づく JavaScript 製ツールチップに依存している場合、キーボードでタブキーを使って要素にフォーカス(またはプログラム的にフォーカス)し、ツールチップが表示されるか確認します。WCAG は、マウスだけでなくアクセシブルな仕組みであることを求めています。ホバー時にのみ表示されるツールチップは、キーボードユーザーにとって不適合です。
  7. 用語集リンクの検証: ページがリンクされた用語集に依存している場合、そのリンクをたどり、元のコンテンツで使用されているすべての略語に、明確な定義を持つ対応する項目があることを確認します。また、用語集へのリンクが目立つ位置にあり、キーボードでアクセス可能であることを確認します。

修正方法

初出の略語がマークアップされていない — 不適切な例

<p>The WHO reported that NCDs account for 74% of all deaths globally each year.</p>

初出の略語がマークアップされていない — 適切な例

<!-- 初出時にインラインで展開し、その後の参照には abbr を使用 -->
<p>The World Health Organization (WHO) reported that non-communicable diseases
(<abbr title='non-communicable diseases'>NCDs</abbr>) account for 74% of all
deaths globally each year.</p>

title 属性のない abbr 要素 — 不適切な例

<!-- abbr 要素は存在するが title がないため、展開が提供されない -->
<p>Submit your <abbr>VAT</abbr> registration number to proceed.</p>

title 属性のない abbr 要素 — 適切な例

<!-- title 属性が支援技術向けに完全な展開形を提供する -->
<p>Submit your <abbr title='Value Added Tax'>VAT</abbr> registration number to proceed.</p>

ホバーのみのツールチップによる略語展開 — 不適切な例

<!-- CSS ツールチップはマウスホバー時にのみ表示される。キーボードユーザーやタッチユーザーはアクセスできない -->
<span class='tooltip-trigger'>KVKK
  <span class='tooltip-text'>Kişisel Verilerin Korunması Kanunu</span>
</span>

ホバーのみのツールチップによる略語展開 — 適切な例

<!-- abbr と title を使用することで、ホバーに依存せず、
     キーボードユーザーやスクリーンリーダーユーザーを含むすべてのユーザーが展開形を利用できる -->
<abbr title='Kişisel Verilerin Korunması Kanunu'>KVKK</abbr>

展開のない表ヘッダー内の略語 — 不適切な例

<table>
  <thead>
    <tr>
      <th>SKU</th>
      <th>MoQ</th>
      <th>ETA</th>
    </tr>
  </thead>
</table>

展開のない表ヘッダー内の略語 — 適切な例

<!-- th 内の title 付き abbr が、スクリーンリーダーユーザーを含むすべてのユーザーに文脈を提供する -->
<table>
  <thead>
    <tr>
      <th><abbr title='Stock Keeping Unit'>SKU</abbr></th>
      <th><abbr title='Minimum Order Quantity'>MoQ</abbr></th>
      <th><abbr title='Estimated Time of Arrival'>ETA</abbr></th>
    </tr>
  </thead>
</table>

よくある間違い

  • title 属性なしで <abbr> を使用する: テキストを <abbr> タグで囲むだけでは、意味的な価値も展開も提供されません。この達成基準の下でアクセシビリティ上の目的を果たすには、title 属性が必須です。
  • 略語の展開を初出の後にのみ行う: 略語が読み順において展開より先に現れる場合(例:本文で展開される前に見出しに現れる場合)、その時点で見出しに出会ったユーザーは、それを理解する手段を持ちません。必ず初出時、またはそれ以前に展開してください。
  • マウスホバー専用のツールチップにのみ依存する: :hover のみで表示される CSS や JavaScript のツールチップは、キーボードのみのユーザー、タッチスクリーンユーザー、および多くのスクリーンリーダー設定にとってアクセシブルではありません。<abbr title> パターンの方が望ましく、ツールチップを使用する場合は :focus でも表示される必要があります。
  • リンクされた用語集を提供しているが、リンクが見つけにくい: 展開の仕組みとして用語集を使用する場合、そのリンクは明確なラベルが付けられ、目立つ位置にあり、キーボードでアクセス可能でなければなりません。フッターの小さな文字や折りたたまれたセクションの奥に用語集リンクを埋もれさせると、使いやすい仕組みという要件を満たさない可能性があります。
  • 略語の展開が一貫しておらず、一部の出現箇所のみマークアップしている: あるセクションでは頭字語に対して <abbr title> を使用しているのに、同じページの他の箇所では素のままにしている場合、検索やランドマークを使って直接そのセクションに移動したユーザーは、説明のない省略表現に出会うことになります。
  • すべての略語が普遍的に理解されていると想定する: 「EBITDA」(金融)、「API」(ソフトウェア開発)、「BKT」(トルコの行政文脈)など、実務者には自明な分野固有の略語も、当該分野外のユーザー、支援技術を利用する人、初めてページを訪れる人にはまったく理解できない場合があります。
  • 展開を画像の alt テキストのみに置き、テキストには含めない: 画像の alt テキストに展開形が含まれていても、表示テキストが略語のみの場合、その仕組みはすべてのユーザーにとってアクセシブルとは限りません(例:ブラウザーのリーダーモードを使用するユーザー)。展開形は、文書のプログラム的テキスト内で利用可能である必要があります。
  • 誤った、または省略された title 値を使用する: <abbr> 要素の title 属性には、別の略語や部分的な説明ではなく、完全な展開形を含めなければなりません。title='HyperText Markup Language' の代わりに title='HTML lang' と記述することは、この達成基準を満たしません。
  • 動的コンテンツ内の略語を考慮していない: AJAX、無限スクロール、シングルページアプリケーションのルーティングなどで読み込まれるコンテンツは、ページの初期読み込み後に新たな略語を導入する場合があります。DOM に挿入される動的コンテンツも同様に適合している必要があり、動的にレンダリングされるセクション内の略語にも、静的コンテンツと同じ展開の仕組みが必要です。
  • 一般的な単語になった頭字語は常に例外だとみなす: 「laser」「radar」のように単語として機能する略語に対する例外は、範囲が限定されています。「URL」や「PDF」のような用語は、テクノロジーに精通した文脈では非常に広く知られていますが、高齢者、認知障害のあるユーザー、異なる文化的背景を持つユーザーには依然として理解しづらい場合があります。迷ったときは展開を提供してください。すでにその用語を知っているユーザーに害を与えることはありません。

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

2025 年 6 月 21 日付官報第 32933 号で公布されたトルコ大統領通達 2025/10 は、WCAG 2.2 に整合した必須のデジタルアクセシビリティ義務を定めています。この通達は、あらゆるレベルの公的機関・政府機関、e コマースプラットフォーム、銀行・金融機関、病院・医療提供者、20 万人以上の加入者を持つ通信会社、認可旅行代理店、民間輸送会社、国民教育省(MoNE)に認可された私立学校など、幅広い主体を対象としています。

この通達は主として WCAG 2.2 レベル AA での遵守を義務付けています。WCAG 3.1.4 — 略語はレベル AAAの達成基準であり、そのため現行の大統領通達 2025/10 の文言において直接の法的要件ではありません。しかし、レベル AAA への適合は単なる理想目標ではなく、トルコのデジタル環境において実務的・評判上の大きな意味を持ちます。

多様な利用者層 — その多くは官僚的または医療的な略語にあまり馴染みがない — にサービスを提供する公共部門の機関、病院、教育機関にとって、3.1.4 の実装は真のサービス品質の問題です。トルコの行政・法的言語は、「SGK」(Sosyal Güvenlik Kurumu)、「KDV」(Katma Değer Vergisi)、「ÖTV」(Özel Tüketim Vergisi)などのイニシャリズムに富んでおり、担当者にとっては当たり前でも、一般市民、特に高齢者、地方のユーザー、ポータルを初めて訪れる人々にとっては分かりにくいものです。

通達の対象となる銀行、通信事業者、e コマースプラットフォームは、金融商品の説明、契約概要、料金表、サービス規約で使用される略語を展開することで、アクセシビリティの姿勢とブランドへの信頼を強化できます。特に金融文書は略語が多く、消費者が重要な情報を理解し、十分な情報に基づいて意思決定を行うことを妨げる可能性があります。

市場のリーダーシップを示すため、国際的なパートナーからの調達要件を満たすため、あるいは公衆衛生や教育の専門的な契約における期待に応えるために、WCAG 2.2 AAA への正式な適合を目指す組織は、3.1.4 を標準的な実務として実装すべきです。Accsible のオーバーレイ SDK は、略語展開パターンの実装と監査を支援し、コンテンツ作成ワークフローの中でガイダンスを提示するように構成できます。これにより、動的に更新されるコンテンツ全体にわたって、組織がコンプライアンスを維持できるよう支援します。