WCAG 2.4.4: リンクの目的（文脈内）

WCAG 2.4.4 では、すべてのリンクの目的が、リンクテキスト単独、またはリンクテキストとその周囲の文脈を合わせて判断できることが求められています。これにより、スクリーンリーダー利用者、キーボードのみの利用者、認知障害のある人が、リンク先へ実際に移動しなくても、そのリンクがどこへ導くのかを理解できるようになります。

このルールの意味

WCAG 2.4.4 — Link Purpose (In Context)（リンクの目的（文脈内））— は、原則「操作可能」の下にあるレベルAの達成基準です。各リンクの目的は、リンクテキスト単体、またはリンクテキストとそのプログラムによって決定可能なリンクの文脈を組み合わせたものから判別できなければならないと定めています。どちらからも十分に判別できない場合、そのリンクはこの基準に不適合となります。

「プログラムによって決定可能なリンクの文脈」という表現は、WCAGによって慎重に定義されています。これは、リンクと同じ文、段落、リスト項目、または表セル、あるいはリンクを含むセクションの直前にある見出しから導き出せる情報を指します。また、aria-labelledby や aria-describedby のようなARIAの関連付けによって公開される文脈も含まれます。重要なのは、この文脈がプログラム的に利用可能である必要があるという点です。つまり、支援技術が自動的に読み取れる必要があり、視覚ユーザーに対して視覚的に示唆されているだけでは不十分です。

実務的には、次のHTML要素や属性がこの達成基準の直接的な対象となります。<a href> アンカー要素、イメージマップ内の <area> 要素、ナビゲーションをトリガーする <button> 要素、role='link' のようなARIAロールを用いてリンクとして振る舞うようにスタイルやスクリプトが適用された要素、そしてSVGの <a> 要素です。リンクのアクセシブルネーム（内側のテキスト、aria-label、aria-labelledby、または子画像の alt 属性から計算される名前）が、目的を伝えるための主要な手段となります。

適合とみなされるケース: ユーザーが追加の文脈なしにリンクの遷移先や機能を判断できる場合（例: 「2024年年次報告書をPDFでダウンロード」）、または周囲のプログラム的な文脈によって目的が明確になる場合（例: 記事タイトルで始まる <li> 内の「Read more」リンク）、そのリンクは適合とみなされます。リンクテキストはページ全体で一意である必要はなく、その文脈内で曖昧でなければ十分です。

不適合とみなされるケース: 「click here」「read more」「here」「more」「link」といった汎用的なリンクテキストで、周囲のプログラム的な文脈が遷移先を明確にしていない場合は不適合となります。alt 属性が欠落している、または空の画像リンクも、アクセシブルネームがまったく存在しないため不適合です。

公式な例外: WCAGは1つの例外を認めています。リンクの目的が意図的に曖昧であり、その目的を事前に明らかにするとリンク自体または周囲のコンテンツの有用性が損なわれる場合、この達成基準は適用されません。この例外は非常に範囲が狭く、実際の場面で適用されることはまれです。

なぜ重要か

世界保健機関によると、世界で約22億人が何らかの視覚障害を抱えています。その中でも、スクリーンリーダーに依存する全盲ユーザーは、曖昧なリンクテキストの影響を最も強く受けます。NVDA、JAWS、VoiceOverといったスクリーンリーダーソフトウェアは、文脈から抽出したすべてのリンクの一覧を生成してページをナビゲートできるようにします。この一覧に「read more」や「click here」といった同じ文言のエントリが何十件も並ぶと、全盲ユーザーはそれぞれのリンクがどこへつながるのかを、1つずつ元の位置に戻って周囲のコンテンツを読み直さない限り判断できません。これは時間がかかるだけでなく、方向感覚を失わせるプロセスです。

キーボードのみの入力、スイッチコントロール、視線追跡デバイスなどでナビゲートする運動障害のあるユーザーも大きな恩恵を受けます。これらのユーザーは、インタラクティブ要素をTabキーで順番に移動し、フォーカスされた要素のラベルを頼りにそれを実行するかどうかを判断することが多くあります。曖昧なリンクテキストは、疲労やエラー率を高める余分なナビゲーションステップを強要します。

注意欠如障害、記憶障害、識字能力の低さなどを含む認知障害のあるユーザーは、ページ構造を理解するために必要な認知負荷を軽減できるため、明確で説明的なリンクテキストから恩恵を受けます。リンクを走査している間、文脈情報をワーキングメモリに保持しておく必要がなくなるためです。

具体的な実例: 10個の製品を表示するECサイトの商品一覧ページを考えてみましょう。各製品には同じ見た目の「Buy Now」ボタンと「Learn More」リンクがあります。リンク一覧でナビゲートしている全盲ユーザーは、「Learn More」という同じ文言が10回連続して読み上げられ、どのリンクがどの製品に対応しているのかまったく分かりません。正しい製品を購入するには、各リンクについて周囲の文脈をすべて読み直さなければならず、このプロセスには数秒ではなく数分かかることがあります。「Learn more about the Sony WH-1000XM5 Headphones」のような説明的なリンクテキストであれば、同じ作業は1回のナビゲーション操作で済みます。

アクセシビリティにとどまらず、説明的なリンクテキストは測定可能なSEO上の利点ももたらします。検索エンジンクローラーは、リンク先ページの内容を理解するためのシグナルとしてアンカーテキストを利用します。説明的でキーワードを含んだリンクテキストは、リンク先リソースのクロール性とインデックス性を高め、検索順位に良い影響を与えます。さらに、明確なリンクテキストは、ナビゲーション前にユーザーの期待値を正しく設定することで、直帰率やサポート問い合わせを減らします。

テスト方法

axe DevToolsまたはLighthouseによる自動スキャン: axe DevToolsブラウザ拡張機能（ChromeまたはFirefox）をインストールするか、Chrome DevToolsでLighthouseのアクセシビリティ監査を実行します。ページ全体のスキャンを実行し、link-name と duplicate-id-aria のルールで結果をフィルタリングします。フラグが立てられた各要素を確認し、link-name の違反については算出されたアクセシブルネームが欠落または空であることを確認し、duplicate-id-aria の違反については、重複したIDがARIAラベル参照を壊していることを検証します。これらの自動チェックに合格しても、2.4.4への完全な適合が保証されるわけではないことに注意し、手動ステップに進んでください。
リンク一覧の手動レビュー: Firefox上のNVDAでは、Insert+F7 キーの組み合わせを押して「要素リスト」ダイアログを開き、「リンク」を選択します。視覚的な文脈なしで、一覧のすべてのエントリを個別に確認します。それぞれのリンクテキストだけから、どこへつながるリンクか判断できるかどうかを自問してください。Chrome上のJAWSでも Insert+F7 を使って「リンクリスト」を開き、同様に繰り返します。macOSのSafari上のVoiceOverでは、Control+Option+U を押してWeb項目ローターを開き、「リンク」を選択します。単独では目的が曖昧なリンクは、そのプログラム的な文脈に照らして検証する必要があります。
キーボードナビゲーションテスト: Tab キーだけを使って、ページ上のすべてのインタラクティブ要素をナビゲートします。フォーカスがリンクに移動するたびに、周囲の視覚的なコンテンツではなく、読み上げられるテキストだけを確認します。読み上げられた内容からリンクの遷移先を判断できない場合、そのリンクは2.4.4に不適合である可能性が高いです。アイコンのみのリンク（ソーシャルメディアアイコン、矢印ボタン）や画像リンクには特に注意してください。
文脈の検証: 周囲の文脈に依存するリンク（例: リスト項目内の「Read more」）については、DOMを確認し、その文脈テキストがリンクと同じ文、段落、リスト項目、または表セル内にあることを確認します。視覚的には隣接していても、プログラム的に関連付けられていない文脈は、この達成基準を満たしません。ブラウザのDevToolsを使ってアクセシビリティツリーを確認し、その関係を検証します。
ARIAラベルの監査: ページのソースコード内で、リンク要素に対するすべての aria-labelledby と aria-describedby の使用箇所を検索します。参照されている各IDが文書内にちょうど1回だけ存在し、その要素が意図した説明テキストを含んでいることを確認します。ブラウザのアクセシビリティツリーパネル（Chrome DevToolsのAccessibilityタブ内にあります）を使って、各リンクの算出された名前を確認します。

修正方法

アクセシブルネームのないアイコンのみのリンク — 不適切な例

<!-- An icon link with no text and no aria-label -->
<a href='https://twitter.com/accsible'>
  <svg viewBox='0 0 24 24' width='24' height='24'>
    <path d='M23 3a10.9 10.9...' />
  </svg>
</a>

アクセシブルネームのないアイコンのみのリンク — 適切な例

<!-- aria-label provides a descriptive accessible name for screen readers -->
<a href='https://twitter.com/accsible' aria-label='Accsible on Twitter'>
  <svg viewBox='0 0 24 24' width='24' height='24' aria-hidden='true' focusable='false'>
    <path d='M23 3a10.9 10.9...' />
  </svg>
</a>

カードリスト内の汎用的な「Read more」リンク — 不適切な例

<!-- Multiple identical link texts with no distinguishing context -->
<ul>
  <li>
    <h3>Istanbul Accessibility Summit 2024</h3>
    <p>Join us for the annual summit on digital inclusion.</p>
    <a href='/events/istanbul-2024'>Read more</a>
  </li>
  <li>
    <h3>New WCAG 2.2 Guidelines Released</h3>
    <p>W3C has published the updated guidelines.</p>
    <a href='/news/wcag-22'>Read more</a>
  </li>
</ul>

カードリスト内の汎用的な「Read more」リンク — 適切な例

<!-- Option 1: Visually hidden text appended to the link -->
<ul>
  <li>
    <h3>Istanbul Accessibility Summit 2024</h3>
    <p>Join us for the annual summit on digital inclusion.</p>
    <a href='/events/istanbul-2024'>
      Read more
      <span class='sr-only'>about the Istanbul Accessibility Summit 2024</span>
    </a>
  </li>
  <li>
    <h3>New WCAG 2.2 Guidelines Released</h3>
    <p>W3C has published the updated guidelines.</p>
    <a href='/news/wcag-22'>
      Read more
      <span class='sr-only'>about the New WCAG 2.2 Guidelines</span>
    </a>
  </li>
</ul>

<!-- Option 2: Use aria-label to override the visible text entirely -->
<a href='/events/istanbul-2024' aria-label='Read more about the Istanbul Accessibility Summit 2024'>
  Read more
</a>

空のalt属性を持つ画像リンク — 不適切な例

<!-- The image has an empty alt, making the link completely unnamed -->
<a href='/products/overlay-widget'>
  <img src='widget-logo.png' alt='' />
</a>

空のalt属性を持つ画像リンク — 適切な例

<!-- The alt attribute on the image provides the link's accessible name -->
<a href='/products/overlay-widget'>
  <img src='widget-logo.png' alt='Accsible Overlay Widget — product details' />
</a>

重複したIDを参照するaria-labelledby — 不適切な例

<!-- Two elements share the same ID; the second link resolves to the wrong label -->
<div>
  <span id='card-title'>Accsible SDK Documentation</span>
  <a href='/docs' aria-labelledby='card-title'>View</a>
</div>
<div>
  <span id='card-title'>Accsible Pricing Plans</span>
  <a href='/pricing' aria-labelledby='card-title'>View</a>
</div>

重複したIDを参照するaria-labelledby — 適切な例

<!-- Each ID is unique; each link resolves to the correct label -->
<div>
  <span id='card-title-docs'>Accsible SDK Documentation</span>
  <a href='/docs' aria-labelledby='card-title-docs'>View</a>
</div>
<div>
  <span id='card-title-pricing'>Accsible Pricing Plans</span>
  <a href='/pricing' aria-labelledby='card-title-pricing'>View</a>
</div>

よくある間違い

「click here」「here」「more」「read more」といったテキストを、aria-label、aria-labelledby、視覚的に非表示の <span> 要素による補足的なアクセシブルネームなしでリンクテキストとして使用すること — これらの文字列は、スクリーンリーダーによって視覚的文脈から切り離されて抽出されたとき、意味を持ちません。
リンクに aria-label を追加する際、可視テキストとは異なるラベルを付け、ラベルが可視テキスト文字列で始まるようにしていないこと — これはWCAG 2.5.3（Label in Name）に違反し、リンクの可視名を発話してリンクを起動しようとする音声コントロールユーザーを混乱させます。
リンクの唯一のコンテンツである画像に alt='' を設定し、リンクの算出されるアクセシブルネームを空にして link-name の違反を引き起こすこと — 空のaltは装飾的な画像には適切ですが、画像がインタラクティブ要素の唯一のコンテンツである場合には適切ではありません。
リンク内の唯一のテキストノードに aria-hidden='true' を適用し、アクセシビリティツリーからアクセシブルネームを削除して、スクリーンリーダーユーザーにとってリンクを無名にしてしまうこと。
異なるリンクに対して aria-labelledby で参照される複数の要素に同じ id 値を再利用し、ID解決の予測不能性により、スクリーンリーダーが1つ以上のリンクに対して誤ったアクセシブルネームを算出してしまうこと。
カードコンポーネント全体（見出し、画像、段落、ボタン）を1つの <a> タグでラップし、スクリーンリーダーにカード全体のコンテンツをリンクのアクセシブルネームとして読み上げさせてしまうこと — これは冗長で方向感覚を失わせる体験であり、簡潔で説明的なラベルを使うべき場面に適していません。
CSSの title 属性ツールチップや :hover 疑似クラスだけにリンク文脈の提供を依存すること — title 属性はスクリーンリーダーによって一貫して公開されるわけではなく、ホバー状態をトリガーできないキーボードのみのユーザーにはまったくアクセスできません。
URL自体をリンクテキストとして使用すること（例: <a href='https://example.com/p?id=12345'>https://example.com/p?id=12345</a>）。これはスクリーンリーダーには発音しづらく、認知障害のあるユーザーにとっても意味を持ちません。
JavaScriptフレームワークでリンクのIDやARIA属性値を動的に生成する際に、一意性を確保していないこと — リスト内でレンダリングされるReact、Vue、Angularコンポーネントは、明示的なキー戦略を実装しない限り、重複したIDを生成しがちです。
Internet Explorerや旧Edgeバージョンで、リンク内のインラインSVGアイコンに focusable='false' を追加し忘れ、SVG自体がタブ移動の対象となり、スクリーンリーダーがリンクテキストとは別にSVGを読み上げてアクセシブルネームの計算を分断してしまうこと。

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

2025年6月21日付官報第32933号で公布されたトルコ大統領通達2025/10は、WCAG 2.2に整合した強制的なデジタルアクセシビリティ要件を定めています。WCAG 2.4.4 Link Purpose (In Context) はレベルAの達成基準であり、通達の対象となるすべての主体が達成しなければならない必須のベースラインに含まれます。

この通達は、公的部門と民間部門の両方にまたがる特定の主体類型に適用されます。省庁、国家機関、自治体、公立大学などの公的機関は、通達の公布から1年以内にレベルAの完全な適合を達成することが求められます。通達の対象となる民間部門の主体には、2年間の適合猶予期間が与えられます。民間部門の範囲は広く、ECプラットフォーム、銀行・金融機関、民間病院・医療提供者、20万件以上の加入者を持つ通信事業者、旅行代理店、民間交通事業者、国民教育省に認可された私立学校を明示的に含みます。

これらすべての主体にとって、不適合なリンクテキストは直接的な規制違反を意味します。たとえば、トルコのECプラットフォームが、プログラム的な文脈を伴わない「Satın Al」（今すぐ購入）や「Devamını Oku」（続きを読む）リンクを商品一覧ページに繰り返し表示しているとします。TalkBack、NVDA、VoiceOverに依存する全盲ユーザーは、各リンクがどの商品を指しているのかを判断できず、これは2.4.4の不適合であり、通達の要件違反となります。同様に、アクセシブルネームのないアイコンのみのナビゲーションリンクを使用している公立病院の予約ポータルは、link-name のaxeルールと通達の義務の両方に違反することになります。

2.4.4への適合は、単なる技術的なチェックボックスではありません。この通達は、トルコの約850万人の障害者に対するデジタルインクルージョンに向けた政府のより広範なコミットメントを示しています。対象となる主体にとって、デザインシステムの標準化、開発者トレーニング、自動CI/CDスキャンを通じてリンク目的の不適合を積極的に解消することは、法的義務であると同時に、ユーザビリティと検索パフォーマンスへの健全な投資でもあります。定められた期間内に適合しない場合、通達で指定された所管監督当局による規制措置の対象となる可能性があります。

出典と参考資料

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