意図
この達成基準の意図は、利用者がリンクを辿りたいかどうか決めることができるように、各リンクの目的を理解することを助けることである。可能な限りいつでも、追加のコンテキストを必要とせずに、リンクの目的を特定するリンクテキストを提供すること。支援技術は、ウェブページにあるリンクの一覧を利用者に提供することができる。可能な限り意味を持たせたリンクテキストは、このリンクの一覧から選択したい利用者の助けとなる。意味のあるリンクテキストはまた、リンクからリンクへと Tab キーで移動したい利用者にとっても役に立つ。意味のあるリンクは、ページを理解するために複雑な戦略を必要とせずに利用者が辿るリンクを選択するのに役立つ。
リンクのテキスト又はリンクに関連付けられたテキストは、リンクの目的を説明することを意図している。リンクが利用者を文書又はウェブアプリケーションへ導く場合、その文書又はウェブアプリケーションの名前は、リンクの目的 (その文書又はウェブアプリケーションに導くためのもの) を説明するものとして十分であろう。文書又はウェブアプリケーションの名前を使用することが必須ではないことに注意すること。他のものも、リンクの目的を説明することがある。
達成基準 2.4.2 は、ページのタイトルを取り扱っている。ここでもまた、ページに表示されている文書又はウェブアプリケーションの名前は、ページの目的を説明するのに十分であろう。リンクとタイトルが一致する又は極めて似ていることは、グッドプラクティスであり、リンクの「クリック」と利用者が着地するウェブページとの間の連続性を提供する。
場合によっては、コンテンツ制作者は、リンクのコンテキストを提供する論理的に関係のあるテキストの中でリンクの説明の一部を提供したいことがある。この場合、利用者は、リンクからフォーカスを移動させずに、そのリンクの目的を特定できることが望ましい。言い換えれば、利用者はあるリンクに到達でき、その位置を失うことなく、リンクに関してさらに調べることができる。これは、リンク自体と直接関連付けられているため、リンクと同じ文、段落、リスト項目、又はテーブルのセル、又はデータテーブル内にあるリンクのテーブル見出しセル、リンクの説明を配置することで達成可能である。あるいは、コンテンツ制作者は、ARIA技術を用いてページ上の追加テキストをリンクに関連付けてもよい。
このコンテキストは、リンクの前にある場合に、最も有用だろう (例えば、曖昧なリンクテキストを使わなければならない場合、その曖昧なリンクテキストを文の初めに置くよりも、リンク先を説明する文の最後に置くほうがよい)。説明がリンクの後に続く場合、ページを (上から下へ) 順に読んでいるスクリーンリーダーの利用者に対して混乱及び困難が存在する可能性がある。
同じ宛先のリンクには一貫したテキストがあることがベストプラクティスとなる(そしてこれは、一式内のページに対して達成基準 3.2.4 により要件となる)。さまざまな目的や宛先を持つリンクが異なるテキストを持つこともベストプラクティスとなる。
適合している代替版へのリンクにおけるベストプラクティスは、その適合している代替版へのリンクテキストが、リンク先のページがよりアクセシブルなバージョンであることをリンクテキストの中で示すことである。リンクの目的が何であるかをエンドユーザが確実に理解できるようにすることがゴールなので、この情報はテキストで提供されることもある。
この達成基準には、リンクの目的をウェブページ上にある情報からは判断できないリンクに対して例外が認められている。そのような状況では、障害のある利用者が不利な立場にあるわけではない。リンクの目的を理解するために追加入手可能な文脈が一切ないのである。しかし、リンクの目的を解釈するために使用できるウェブページ上で利用可能ないかなるコンテキストの量であっても、達成基準を満たすためのリンクテキストで利用可能にされる、又はリンクとプログラム的に関連付けられなければならない。
リンクの目的が不明又は曖昧になることが想定できる状況もありえる。例えば、ゲームにはドア 1、ドア 2、そしてドア 3 としてのみ識別されるリンクがあるかもしれない。リンクの目的がすべての利用者に対するサスペンスを引き起こすことにあるので、このリンクテキストは十分である。
達成基準 2.4.9: リンクの目的 (リンクのみ) を理解する を併せて参照のこと。
メリット
- この達成基準は、関心のないリンクをスキップし、参照されたコンテンツを訪問し現在のコンテンツに戻るために必要なキーストロークを回避することで運動障害のある人を支援する。
- 認知に制約のある人が、関心のないコンテンツへのナビゲーションの複数手段によって混乱することがなくなる。
- 視覚障害のある人が、リンクの文脈を探ることによって、リンクの目的を判断できるようになる。
事例
リンクがリンク先の URI にある情報を説明するテキストを含んでいる
あるページに、「中世の歴史には大量の虐殺があった」という文がある。ここで「中世の歴史」がリンクになっている。
リンクの前にリンク先の URI にある情報のテキストによる説明がある
あるページに、「アイルランド政府の電子選挙委員会に関する詳細を投票に行こう!で見る」という文がある。ここで、「投票に行こう!」がリンクである。
アイコンとテキストの両方が同じリンク内にある
自動投票機のアイコンと「アイルランド政府の電子選挙委員会」というテキストが、一つのリンクになっている。リンクの目的がアイコンの隣にあるリンクのテキストで説明されているので、そのアイコンの代替テキストは空である。
書籍名のリスト
リストにある書籍が、HTML、PDF、そして mp3 (人が本を読み上げているのを録音したもの) の三つのフォーマットで利用可能である。各書籍のタイトルを 3 回 (フォーマットごとに 1 回) 聞かないですむように、各書籍の最初のリンクは書籍のタイトル、二つめのリンクは「PDF」、三つめのリンクは「mp3」となっている。
ニュース記事の要約
あるウェブサイトには、ニュース記事のコレクションが含まれている。メインページでは、各記事の最初の部分が少し表示され、その後に「続きを読む」というリンクがある。現在の段落を読みあげるスクリーンリーダーのコマンドは、リンクの目的を解釈するためのコンテキストを提供する。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成方法
この節にある番号付きの各項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組み合わせを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。その他の達成方法についての詳細は、WCAG 達成基準の達成方法を理解するの「その他の達成方法」を参照のこと。
十分な達成方法
- G91: リンクの目的を説明したリンクテキストを提供する
- H30: a 要素のリンクの目的を説明するリンクテキストを提供する
- H24: イメージマップの area 要素にテキストによる代替を提供する
次の達成方法の一つを用いて、利用者が短めのリンクテキスト又は長めのリンクテキストを選べるようにする:
- G53: リンクテキストとそれが含まれている文中のテキストとを組み合わせて、リンクの目的を特定する
次の達成方法の一つを用いて、リンクの目的を補足説明する:
次に挙げる達成方法の一つを用いて、プログラムによる解釈されるリンクのコンテキストと一緒にリンクの目的を特定する:
- ARIA7: リンクの目的を示すために aria-labelledby を使用する
- ARIA8: リンクの目的を示すために aria-label を使用する
- H77: リンクテキストとそれが含まれているリスト項目とを組み合わせて、リンクの目的を特定する
- H78: リンクテキストとそれが含まれている段落とを組み合わせて、リンクの目的を特定する
- H79: リンクテキストとそれが含まれているデータセル及び関連づけられた見出しセルとを組み合わせて、リンクの目的を特定する
- H81: リストが入れ子になっている状況で、親のリスト項目と結合したリンクテキストを用いて、入れ子になったリストの中でリンクの目的を特定する
G91: リンクの目的を説明したリンクテキストを提供する、かつ、次の達成方法の一つを用いて、セマンティックにリンクを示す:
参考達成方法
適合のために必須ではないが、コンテンツをよりアクセシブルにするために、次の追加の達成方法を検討することが望ましい。ただし、すべての状況において、すべての達成方法が使用可能、又は効果的であるとは限らない。
失敗例
以下に挙げるものは、WCAG ワーキンググループが達成基準の失敗例とみなした、よくある間違いである。
テストルール
以下は、この達成基準の特定の側面に関するテストルールである。WCAG への適合を確認するために、これらの特定のテストルールを使用する必要はないが、これらは定義され、承認されたテスト方法である。テストルールの使用については、WCAG 達成基準のテストルールを理解するを参照のこと。
重要な用語
利用者の支援技術だけでなく、ブラウザ及びその他のユーザエージェントにあるアクセシビリティ機能でサポートされていること。
あるウェブコンテンツ技術 (又は、ある技術の機能) のアクセシビリティ サポーテッドな使用方法とみなされるためには、そのウェブコンテンツ技術 (又は機能) について、次の 1.と 2.の両方が満たされていなければならない:
そのウェブコンテンツ技術の使用方法が、利用者の支援技術によりサポートされていなければならない。これは、その技術の使用方法が、そのコンテンツの自然言語における利用者の支援技術との相互運用性について検証されていることを意味する。
かつ
そのウェブコンテンツ技術には、利用者が入手できるアクセシビリティ サポーテッドなユーザエージェントがなければならない。これは、次の四つのうち少なくとも一つを満たしていることを意味する:
その技術が、広く配布されているアクセシビリティ サポーテッドなユーザエージェントに標準でサポートされている (HTML、CSS など)。
又は、
その技術が、広く配布されているアクセシビリティ サポーテッドなプラグインでサポートされている。
又は、
そのコンテンツが、大学、企業内ネットワークのような閉じた環境で利用できるものである。この環境で、その技術に必要とされていて、その組織で使用されているユーザエージェントがアクセシビリティ サポーテッドである。
又は、
その技術をサポートするユーザエージェントが、アクセシビリティ サポーテッドであって、次の方法でダウンロード又は購入できる:
- 障害のある人の費用が、障害のない人の費用を上回ることがなく、かつ、
- 障害のある人も、障害のない人と同程度に容易に探して入手できる。
Accessibility Guidelines Working Group 及び W3C は、あるウェブ技術の特定の使用方法がアクセシビリティ サポーテッドであると分類するために、どの支援技術によるどれだけのサポートが必要なのかを定めない (「アクセシビリティ サポーテッド」とするのに必要な支援技術によるサポートのレベル を参照)。
ウェブ技術がアクセシビリティ サポーテッドな方法で用いられている場合、その技術全体、又はその技術の使用方法すべてがアクセシビリティ サポーテッドであるということを暗に示すわけではない。ほとんどの技術は、HTML を含めてアクセシビリティ サポーテッドではない機能、又は使用方法が少なくとも一つある。ウェブページが WCAG に適合するのは、依存する技術のアクセシビリティ サポーテッドな使用方法を用いて WCAG の要件を満たしている場合だけである。
複数のバージョンを有するウェブコンテンツ技術を挙げる際は、アクセシビリティ サポーテッドなバージョンを特定すべきである。
コンテンツ制作者が技術のアクセシビリティ サポーテッドな使用方法を見つける方法の一つは、アクセシビリティ サポーテッドであることが文書化されている使用方法の資料を参照することである (ウェブ技術のアクセシビリティ サポーテッドな使用法を理解する を参照)。コンテンツ制作者、企業、技術ベンダー、又はその他の者が、ウェブコンテンツ技術のアクセシビリティ サポーテッドな使用方法を文書化してもよい。しかし、文書中の技術の使用方法はすべて、上記のアクセシビリティ サポーテッドなウェブコンテンツ技術の定義を満たしている必要がある。
リンク、及びリンクと同時に利用者に提供されているウェブページのどの情報からも、そのリンクの目的を判断できない (すなわち、障害がない閲覧者でも、そのリンクを動作させるまで、そのリンクが何をするのか分からない)。
「注目すべき輸出品のひとつはグァバです」という文中にある「グァバ」という単語がリンクになっている。そのリンク先は、グァバの定義、グァバの輸出量を挙げる図表、又はグァバを収穫している人々の写真のいずれにもなり得る。リンクを動作させるまで、すべての利用者が確信を持てないため、障害のある人が不利な立場に置かれることはない。
障害のある利用者の要件を満たすために、主流のユーザエージェントが提供する機能を超えた機能を提供するような、ユーザエージェントとして動作する、又は主流のユーザエージェントと共に動作するハードウェア及び/又はソフトウェア。
支援技術が提供する機能としては、代替の提示 (例: 合成音声や拡大表示したコンテンツ)、代替入力手法 (例: 音声認識)、付加的なナビゲーション又は位置確認のメカニズム、及びコンテンツ変換 (例: テーブルをよりアクセシブルにするもの) などを挙げることができる。
支援技術は、API を利用、監視することで、主流のユーザエージェントとデータやメッセージのやりとりをすることが多い。
主流のユーザエージェントと支援技術との区別は、絶対的なものではない。多くの主流のユーザエージェントは、障害のある個人を支援する機能を提供している。基本的な差異は、主流のユーザエージェントが障害のある人もない人も含めて、広く多様な利用者を対象にしているのに対し、支援技術は、特定の障害のある利用者という、より狭く限られた人たちを対象にしているということである。支援技術により提供される支援は、対象とする利用者に特化した、よりニーズに適したものである。主流のユーザエージェントは、プログラムオブジェクトからのウェブコンテンツの抽出、マークアップの識別可能な構造への解釈といった、重要な機能を支援技術に対して提供する場合がある。
この文書の文脈において重要な支援技術としては、以下のものが挙げられる:
- 画面拡大ソフト及びその他の視覚的な表示に関する支援技術。視覚障害、知覚障害、及び読書困難などの障害のある人が、レンダリング後のテキスト及び画像の視覚的な読みやすさを改善するために、テキストのフォント、サイズ、間隔、色、音声との同期などを変更するのに使用している。
- スクリーンリーダー。全盲の人がテキスト情報を合成音声あるいは点字で読み取るために使用している。
- 音声変換ソフトウェア。認知障害、言語障害、及び学習障害のある人が、テキストを合成音声に変換するために使用している。
- 音声認識ソフトウェア。何らかの身体障害のある利用者が使用することがある。
- 代替キーボード。特定の身体障害のある人がキーボード操作をシミュレートするのに使用している (ヘッドポインタ、シングルスイッチ、呼気・吸気スイッチ、及びその他の特別な入力デバイスを使った代替キーボードを含む)。
- 代替ポインティングデバイス。特定の身体障害のある人がマウスポインタとボタンの動きをシミュレートするのに使用している。
与えられた規格、ガイドライン、又は仕様のすべての要件を満たすこと。
以下の事項を満たす版のことを指す:
- 指定されたレベルで適合しており、かつ
- 同じ情報及び機能のすべてを同一の自然言語で提供しており、かつ
- 不適合コンテンツと同時に更新されていて、かつ
-
以下に挙げる事項のうち少なくとも一つを満たしていること:
- アクセシビリティ サポーテッドな メカニズムを用いて、 不適合ページから適合版へ到達できる。もしくは、
- 不適合版に到達できるのは、適合版からのみである。
- 不適合版に到達できるのは、適合版に到達するメカニズムも提供している適合ページからのみである。
この定義において、「到達できるのは……からのみ」とは、利用者が適合版から来ていない限り、不適合ページに「到達する」 (読み込む) のを防ぐ条件付きリダイレクトのような何らかのメカニズムがある、ということを意味する。
代替版は、元のページと一対一で対応している必要はない (例えば、適合している代替版は複数のページであってもよい)。
複数の言語版が利用できる場合、各言語版に対して、適合している代替版を提供する必要がある。
異なる技術環境又は利用者層に対応するために、代替版が提供される場合がある。それぞれの版は、可能な限り適合させるべきである。適合要件 1 を満たすためには、一つの版が完全に適合している必要がある。
適合している代替版は、不適合版と同様に自由に利用可能である限り、適合宣言の範囲内に存在する必要はなく、同じウェブサイト上に存在する必要もない。
代替版は、元のページを補助して理解を高める補足コンテンツと混同されないようにすべきである。
コンテンツ内で利用者が設定を行うことで適合版が作り出される仕組みは、その利用者の設定に用いられている手法がアクセシビリティ サポーテッドであるかぎり、代替版への到達メカニズムとして条件を満たしているといえる。
適合している代替版を理解するを参照。
コンテンツの構造、提示、及びインタラクションを定義するコード又はマークアップも含めて、ユーザエージェントによって利用者に伝達される情報及び感覚的な体験。
利用者の操作により実現可能なプロセス及び結果。
人間とコミュニケーションをとるために話される、書かれる、又は (視覚的もしくは触覚的な手段で) 手話にされる言語。
手話も参照。
ハイパーリンクを動作させたときに得られる結果の本質。
結果を得るためのプロセス又は手法。
メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。
利用者が知覚できる形式でコンテンツをレンダリングすること。
ある活動を完了させるために必要な利用者の一連の動作。
ショッピングサイト上の一連のウェブページで目的を果たすためには、利用者が選択肢となりうる製品、価格及び内容を閲覧した後、製品を選択して発注し、配送先情報及び支払情報を提供する必要がある。
アカウント登録ページでは、登録フォームにアクセスする前にチューリングテストに成功する必要がある。
支援技術を含む様々なユーザエージェントが抽出でき、利用者に様々な感覚モダリティで提示できるような形のデータがコンテンツ制作者によって提供されたとき、そのデータがソフトウェアによって解釈されること。
マークアップ言語で、一般に入手可能な支援技術が直接アクセスできる要素と属性から解釈される。
非マークアップ言語の技術特有のデータ構造から解釈され、一般に入手可能な支援技術がサポートするアクセシビリティ API を通じて支援技術に提供される。
リンクとの関係性からプログラムによる解釈が可能であり、リンクテキストと結びつけることができ、様々な感覚モダリティで利用者に提示することができる付加的情報。
HTML において、英語で書かれたリンクからプログラムによる解釈が可能な情報には、そのリンクと同じ段落、リスト、もしくはテーブルのセル内にあるテキスト、又はテーブル内のリンクを含むセルに関連付けられたヘッダーセル内のテキストが挙げられる。
スクリーンリーダーは句読点を解釈するので、フォーカスが文中のリンクにある場合は、その文からコンテキストを提供することも可能である。
コンテンツの異なる部分間における意味のあるつながり。
意味を伝えるために、手と腕の動き、顔の表情又は身振りなどの組み合わせを用いる言語。
元のコンテンツを説明、又はより明確にするために付加されたコンテンツ。
ウェブページの音声版。
複雑なプロセスを示したイラスト。
調査研究でなされた主要な成果及び提言を要約する段落。
ユーザエージェントがどのようにレンダリング、再生、又は実行するかを符号化するメカニズム。
このガイドラインで用いられている「ウェブ技術」及び (単独で用いられている) 「技術」という用語は、どちらもウェブコンテンツ技術を指す。
ウェブコンテンツ技術には、マークアップ言語、データ形式、及びプログラム言語などがあり、これらをコンテンツ制作者が単独で、又は組み合わせて用いることによって、静的なウェブページや同期したメディアによる提示、さらには動的なウェブアプリケーションに至るまでの様々なエンドユーザ体験を作ることができる。
ウェブコンテンツ技術のよくある事例としては、HTML、CSS、SVG、PNG、PDF、Flash、 JavaScript などがある。
ウェブコンテンツを取得して利用者に提示するあらゆるソフトウェア。
ウェブブラウザ、メディアプレーヤ、プラグイン、及びその他のプログラム。その他のプログラムには、ウェブコンテンツの取得、レンダリング、やり取りを支援する支援技術を含む。
単一の URI から HTTP で得た埋め込まれていないリソースに加え、レンダリングに使われる、又はユーザエージェントがこのリソースと一緒にレンダリングすることを意図しているその他のあらゆるリソースを合わせたもの。
どのような「その他のリソース」も主たるリソースと一緒にレンダリングされるであろうが、これらのリソースが同時にレンダリングされるとは限らない。
このガイドラインの適合範囲に含まれる対象となるウェブページとみなされるためには、リソースが「埋め込まれていない」リソースでなければならない。
単体のウェブリソースであり、埋め込まれている画像及びメディアのすべてを含んだもの。
Asynchronous JavaScript and XML (AJAX) を用いたウェブメールのプログラム。そのプログラム全体は http://example.com/mail に存在しているが、受信トレイ、連絡先、カレンダーがある。受信トレイ、連絡先、又はカレンダーを表示するリンク又はボタンが提供されているが、全体としてページの URI は変更されない。
カスタマイズ可能なポータルサイトで、利用者が様々なコンテンツモジュールのセットから表示させるコンテンツを選択できるようなもの。
ブラウザで "http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは 1 ページだけのウェブサイトかもしれないし、ウェブサイトの中のほんの 1 ページなのかもしれない。