WCAG 2.2の達成基準2.4.4「リンクの目的（文脈内）」は、リンクを開く前に、そのリンクが何をするものか判断できるようにする基準です。
リンクテキストだけで目的が分かる形を基本とし、難しい場合はプログラムで関連付けられた周囲の文脈と組み合わせて示します。
「こちら」や「もっと見る」という文言を一律に禁止する基準ではありません。
ただし、リンクだけを拾い読みする利用者にも伝わりやすいため、可能であればリンクテキスト自体を具体的にするのが実装しやすく、確認もしやすい方法です。
達成基準2.4.4が求めること
リンクの目的とは、リンクを開いた結果、どの情報や機能に移動するのかという意味です。
WCAG 2.2の達成基準2.4.4では、各リンクの目的を次のいずれかで判断できることを求めています。
- リンクテキストだけで目的を判断できる。
- リンクテキストと、プログラムで判定できるリンクの文脈を合わせると目的を判断できる。
例外は、ページ上の情報をすべて見ても、一般の利用者にリンクの目的が分からない場合です。
ゲームで行き先を意図的に伏せた扉を選ばせる場合など、目的が分からないこと自体が体験の一部であれば、障害のある利用者だけが不利になるわけではありません。
「文脈内」の意味
プログラムで判定できる文脈とは、見た目が近いだけではなく、HTMLの構造や属性からリンクとの関係を支援技術が取得できる情報です。
HTMLでは、同じ文、段落、リスト項目、表のセル、またはそのセルに関連付けられた見出しセルなどが代表例です。
次の例では、「詳細を見る」だけでは対象が分かりませんが、同じ段落にある「製品Aの仕様と価格」が文脈になります。
<p>
製品Aの仕様と価格は
<a href="/products/a">詳細を見る</a>。
</p>この書き方は文脈と合わせれば目的を判断できます。
一方、スクリーンリーダーのリンク一覧では「詳細を見る」だけが提示される場合があるため、実装を選べるなら次のようにリンクテキストへ対象を含めるほうが明快です。
<a href="/products/a">製品Aの仕様と価格を見る</a>実装方法の選び方
目的を伝える方法は、表示されるリンクテキストから順に検討します。
ARIAやtitle属性は、見える文言だけでは説明しきれない事情がある場合の補助手段です。
| 方法 | 向いている場面 | 注意点 |
|---|---|---|
| 具体的なリンクテキスト | 原則として最初に選ぶ | 短さよりも、移動先や動作を判断できることを優先する |
| 同じ段落やリスト項目の文脈 | 繰り返し表示するカードや記事一覧 | 見た目の近さだけに頼らず、HTMLの構造で関係を保つ |
aria-labelledby |
画面上に説明となる見出しや名称がある | 参照先のidと表示リンクの文言を適切に組み合わせる |
aria-label |
参照できる表示テキストがなく、短い表示文言を補う | リンク内の文字列を上書きするため、表示文言をアクセシブルな名前に含める |
title属性 |
リンクテキストへの補足情報を添える | 利用環境によって取得しにくいため、必要な情報を任せきりにしない |
リンクテキストに目的を書く
最も分かりやすい方法は、リンクテキストだけで移動先や動作を説明することです。
「こちら」のような指示語を、対象を示す言葉に置き換えます。
目的が分かりにくい例
<a href="/contact">こちら</a>目的が分かる例
<a href="/contact">お問い合わせフォームを開く</a>リンク先が文書ファイルである場合は、資料名やダウンロードであることを含めると、開く前に結果を予測しやすくなります。
aria-labelledbyで表示中の情報を関連付ける
カードの見出しなど、画面上にリンクの対象を説明する文字がある場合は、aria-labelledbyで複数の文字列を関連付けられます。
次の例では、表示される「続きを読む」と記事見出しを、リンクのアクセシブルな名前としてこの順序で組み合わせます。
<h3 id="article-title">アクセシブルなフォームの設計</h3>
<p>
入力支援の基本を紹介します。
<a id="article-link"
href="/accessible-forms"
aria-labelledby="article-link article-title">続きを読む</a>
</p>aria-labelledbyが参照するidに誤りがあると、意図した名前を取得できません。
実装後はブラウザーのアクセシビリティツリーやスクリーンリーダーで、リンク名を確認します。
aria-labelで短い表示文言を補う
参照できる表示テキストがない場合は、aria-labelでリンクの目的を補えます。
aria-labelはリンク内の文字列を上書きするため、表示されている文言を含めた名前にします。
<a href="/catalog.pdf"
aria-label="ダウンロード：最新の製品カタログ">
ダウンロード
</a>表示だけを見て操作する人と、支援技術が伝える名前で操作する人の認識をそろえることが大切です。
画面上に使える説明があるなら、aria-labelで別の名前を作る前に、リンクテキストやaria-labelledbyで解決できないか検討します。
title属性は補足にとどめる
title属性は、リンクテキストに追加情報を添える方法の一つです。
しかし、利用するブラウザー、支援技術、入力方法によっては内容を取得しにくいため、移動前に必要な情報をtitle属性だけで伝える実装は避けます。
<a href="/help" title="お問い合わせ方法と受付案内">
ヘルプ
</a>この例でも、リンクテキストの「ヘルプ」だけで大まかな目的は分かります。
必ず知らせたい注意事項や移動先の種類は、リンクテキストまたは周囲の表示テキストに含めます。
よくある失敗と直し方
同じ「もっと見る」が別のページへ移動する
記事一覧や製品一覧で「もっと見る」を繰り返すと、リンクだけを一覧表示した際に区別できません。
「製品Aの詳細を見る」「製品Bの詳細を見る」のように対象を含めるか、各カードの見出しをHTMLの構造やARIAで関連付けます。
視覚的な配置だけを文脈とみなす
説明文とリンクが近くに見えても、HTML上で別の領域に置かれていれば、その関係を支援技術が取得できるとは限りません。
同じ段落やリスト項目にまとめるなど、意味上のまとまりをマークアップにも反映します。
ARIAの名前と表示文言が食い違う
aria-labelやaria-labelledbyを付けるだけでは、分かりやすさは保証されません。
表示が「ダウンロード」なのにアクセシブルな名前が「資料を開く」だけであれば、音声操作を含む利用場面で同じリンクだと判断しにくくなります。
自動検査だけで合否を決める
自動検査ツールは、リンク名が空である、同じ文言が繰り返されている、といった候補の発見に役立ちます。
ただし、リンクの目的が本文の意味と合っているか、周囲の文脈から十分に判断できるかは、機械的な検査だけでは確定できません。
確認手順
- ページ内のリンクを一覧にし、空のリンクや「こちら」「詳細」などの短い文言を抽出する。
- 各リンクについて、リンクテキストだけで移動先や動作を判断できるか確認する。
- リンクテキストだけでは足りない場合、同じ段落、リスト項目、表のセルなどから文脈をプログラムで取得できるか確認する。
aria-labelまたはaria-labelledbyを使うリンクは、計算されたアクセシブルな名前を開発者ツールで確認する。- キーボードでリンクを順番に移動し、表示されるフォーカスと前後の文脈を確認する。
- スクリーンリーダーのリンク一覧と通常の読み上げ順の両方で、目的を区別できるか確認する。
スクリーンリーダーの仕組みや基本的な確認方法は、スクリーンリーダーの仕組みと実装ポイントも参考になります。
2.4.9「リンクの目的（リンク単体）」との違い
2.4.4は、リンクテキストとプログラムで判定できる文脈の組み合わせを認めるLevel Aの基準です。
これに対して2.4.9は、原則としてリンクテキストだけで目的を判断できることを求めるLevel AAAの基準です。
両者の違いと実装例は、WCAG 2.2「2.4.9 リンクの目的（リンク単体）」の解説で確認できます。
実装時の要点
- まず、リンクテキストだけで移動先や動作が分かる文言にする。
- 短いリンク文言を使う場合は、同じ段落やリスト項目などの文脈をHTML上でも関連付ける。
- ARIAを使う場合は、表示文言を含むアクセシブルな名前になっているか確認する。
title属性と自動検査だけに頼らず、キーボードとスクリーンリーダーで確認する。
リンクの目的が分かれば、利用者は開くべきリンクを選び、不要な移動を避けられます。
リンク文言、HTML構造、支援技術に伝わる名前を一つずつ確認することが、達成基準2.4.4への適合性を判断するための基本になります。
当社では、Webアクセシビリティの導入と改善を支援するUUU ウェブアクセシビリティを提供しています。
サイトのアクセシビリティ向上を検討している方は、サービスの詳細をご覧ください。