時間依存メディア:
ガイドライン1.2を理解する
ガイドライン1.2: 時間依存メディアには代替コンテンツを提供すること。
ガイドライン 1.2 の意図
このガイドラインの目的は、時間の経過に伴って変化する、同期したメディアへのアクセスを提供することである。具体的には、次のようなメディアがある：
コンテンツ制作者が、そのコンテンツにはどの達成基準が適用されるのかを素早く容易に判断できるように、各達成基準が適用されるメディアの種類をその簡潔な名前で示している。
音声しか含まないメディア又は映像しか含まないメディアに対しては、達成基準の名前に「音声しか含まない」又は「映像しか含まない」とあるものを適用するだけでよい。そのメディアが、音声しか含まないメディア又は映像しか含まないメディアではない場合、残りの達成基準すべてが適用される。
そして、メディアは、ライブ又は収録済のどちらかである。その達成基準がライブ又は収録済のどちらのメディアに適用されるのかが、各達成基準の簡潔な名前ではっきりと分かるようになっている。
同期したメディアは、用語集で次のように定義されている：
- 同期したメディア (synchronized media)
情報を提示するために、他のフォーマットと同期した音声もしくは映像、又は時間に依存するインタラクティブな構成要素と同期した音声又は映像。ただし、そのメディアが
メディアによるテキストの代替であって、メディアによる代替であることが明確にラベル付けされているものは除く。
インタラクションに付随する音声ファイルは、インタラクションを伴う映像しか含まないファイルと同様に、このガイドラインの対象であることに留意されたい。これらが対象となっているのは、インタラクションが特定のタイミングで発生しなければならないからである。例えば、「より多くの情報を知るためには、今、クリックしてください」というトランスクリプトをつけるのは、全く役に立たない。なぜなら、利用者にはその音声がどのタイミングで「今」と言ったのかが分からないからである。そのため、同期したキャプションが必要となる。
時には、音声解説を発話内にある合間にぴったり収めることができないくらい沢山の発話があることがある。同期したメディアの音声解説ではなく、時間の経過に伴って変化するメディアの代替を提供するレベル A での選択肢は、同期したメディアにあるすべての情報へのアクセスを可能にすることである。また、この選択肢は、何らかの理由で音声解説が提供されていないとき、視覚的でない形態での視覚的な情報へのアクセスも可能にする。
インタラクションを伴う同期したメディアの場合、時間の経過に伴って変化するメディアの代替の中にインタラクティブな要素（例えば、リンク）を埋め込むことが可能である。
また、このガイドラインには、（レベル AAA で）同期したメディアへの手話通訳というアプローチの他に、拡張した音声解説と呼ばれるアプローチがある。拡張した音声解説では、映像を一時的に停止させて、実際に存在する発話の合間で可能な量よりも多くの音声解説を提供することができる。これは、要件を積み上げていくようにして徐々に強めていくという意図があって、低いレベルの達成基準の上にそれよりも高いレベルの達成基準を設けている一例である。
ガイドライン 1.2 の参考にすべき達成方法(特定の達成基準に特有ではない達成方法)
このガイドラインにある各達成基準を満たすための達成方法は、この後に達成基準ごとに挙げられている。しかし、このガイドラインに対処するための達成方法がどの達成基準にも該当しない場合は、ここで挙げている。そういった達成方法は、どの達成基準を満たす上でも必須ではないし、十分でもないが、ウェブコンテンツの種類によってはより多くの利用者にとってよりアクセシブルにすることができるものである。
- このガイドラインの参考にすべき達成方法はすべて、特定の達成基準に関係している。
音声のみ及び映像のみ (収録済) :
達成基準 1.2.1 を理解する
この達成基準の意図は、収録済の音声しか含まないコンテンツ及び収録済の映像しか含まないコンテンツの伝える情報を、すべての利用者が入手できるようにすることである。テキストベースの、時間の経過に伴って変化するメディアの代替は、情報をアクセシブルにする。それは、利用者のニーズに合った、あらゆる感覚モダリティ（例えば、視覚、聴覚、あるいは触覚）を通じて、テキストが描画可能だからである。将来的には、テキストをシンボル、手話、あるいはその言語でよりシンプルな形態に変えることも可能になるのではないだろうか。
音声情報や利用者のインタラクションを伴わない収録済み映像の例は、サイレントムービー（無声映画）である。書き起こしテキストの目的は、視覚的に提示されるものと同等のものを提供することである。収録済の映像コンテンツの場合、コンテンツ制作者には音声トラックを提供するという選択肢がある。音声による代替の目的は、映像と同等のものになることである。それにより、視覚障害の有無に関係なく、利用者はコンテンツを同時に楽しむことが可能になる。また、映像と音声の並行したプレゼンテーションを提供することにより、認知の障害、言語の障害、及び学習障害のある利用者がコンテンツを理解しやすくなることにもつながる。
注記：音声情報がない映像に対する代替コンテンツとして提供されている音声に対しては、代替テキストは必要ない。例えば、サイレントムービーの代替コンテンツとして提供されている音声解説にキャプションを付与する必要はない。
達成基準1.2.9 音声のみ (ライブ) を理解するも参照のこと。
この達成基準は、視覚的なコンテンツを知覚するのが困難な利用者の役に立つ。支援技術が、代替テキストを音声で読み上げたり、視覚的に提示したり、点字に変換したりすることが可能になる。
時間の経過に伴って変化するメディアの代替は、それがテキストベースであれば、収録済の映像コンテンツの意味を理解するのが困難な利用者の役に立つことがある。
デフ、音声の聞こえづらい、あるいは何らかの理由で音声情報を理解するのが困難な利用者が、テキストでの表現を読むことができるようになる。テキストを手話に自動変換する研究が現在進められている。
盲ろうの利用者が、テキストを点字で読むことができるようになる。
加えて、テキストは、非テキストコンテンツを検索可能なものにし、コンテンツを様々な方法で再利用できるようにする。
演説を録音した音声
「議会での議長の演説」という音声クリップへのリンクがある。そして、書き起こしテキストへのリンクが、その音声クリップへのリンクの直後に提供されている。
記者会見を録音した音声
ウェブページに、記者会見を録音した音声へのリンクがあり、リンクテキストが録音された音声であることを示している。また、そのページには記者会見の書き起こしテキストへのリンクもある。書き起こしテキストには、話者が発言したすべての逐語的な記録がある。そこには、例えば、喝采、笑い、聴衆からの質問など、その録音の一部であるその他の重要な音声とあわせて、誰が話しているのかも記されている。
車のエンジンがどのように動くのかを紹介するアニメーション
車のエンジンがどのように動くのかを見せているアニメーションがある。音声はなく、そのアニメーションはエンジンがどのように動くかを解説する指導書の一部である。指導書のテキストがすでにすべての説明を提供しているため、そのアニメーションはテキストの代替物であり、その代替テキストにはアニメーションの簡潔な説明のみが記述されていて、より詳細な情報は指導書のテキストを参照している。
音声トラック付きの、映像しか含まないファイル
無音映画に音声トラックがあり、映像に見られる動きや振る舞いを説明している。
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の達成方法（又は、達成方法の組合せ）がある。
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
H96: 音声解説を提供するために、track 要素を使用する (HTML)
事後に、ライブの音声しか含まないプレゼンテーションの書き起こしテキストを提供する（リンク追加予定）
同程度の情報を提供するテキスト情報へのリンクを提供する（例えば、交通情報ウェブカメラに対して、ある自治体ではテキストの交通情報レポートへのリンクを提供している）（リンク追加予定）
以下に挙げるものは、WCAG ワーキンググループが達成基準1.2.1に適合していないとみなした、よくある不適合事例である。
- メディアによるテキストの代替 (media alternative for text)
テキストで (直接又はテキストによる代替によって) 既に提示されている情報以上のものを提示していないメディア。
注記: メディアによるテキストの代替は、テキストを代替する提示の恩恵を受ける人たちのために提供される。テキストの代替メディアになりうるのは、音声しか含まないメディア、映像しか含まない (手話の映像を含む) メディア、又は音声付映像メディアである。
- 収録済 (prerecorded)
ライブではない情報。
- 映像しか含まない (video-only)
映像のみを含んだ、時間に依存する提示 (音声やインタラクションを含まない)。
- 時間依存メディアに対する代替コンテンツ (alternative for time-based media)
時間依存の視覚的及び聴覚的情報を正しい順序で説明したテキストを含み、あらゆる時間依存のインタラクションによる結果を得る手段を提供している文書。
注記: 同期したメディアのコンテンツを作るために用いられる脚本は、編集が終了した最終版の同期したメディアを正確に描写した脚本に修正されている場合だけ、この定義を満たす。
- 音声しか含まない (audio-only)
音声のみを含んだ、時間に依存する提示 (映像やインタラクションを含まない)。
キャプション (収録済) :
達成基準 1.2.2 を理解する
この達成基準の意図は、デフ又は音声の聞こえづらい利用者が、同期したメディアのプレゼンテーションを見られるようにすることである。キャプションは、コンテンツの中で音声トラックを通じて提示されている部分の代替を提供するものである。キャプションは、発話の内容だけを含むのではなく、誰が話しているのかも示し、発話ではなく音声（意味のある効果音を含む）によって伝えられている情報も含む。
現在のところ、情報発信までに一刻を争う素材に対してキャプションを作成するのが困難であることは、一般に広く認められている。そのため、コンテンツ制作者は、キャプションの完成を待って情報発信を遅らせるか、もしくは待たずに情報を発信してしまうか、という選択を迫られることになる。いずれは、情報配信プロセスの中にキャプション作成を組み込むツールや、キャプションを付加するツールによって、そういった遅延は短縮化されるか、なくなるだろう。
ただし、同期したメディア自体が、ウェブページ上でテキストによってすでに提示されている情報の代替プレゼンテーションである際には、キャプションは必要ない。例えば、ウェブページ上の情報に同期したメディアのプレゼンテーションが付随していて、そのメディアがテキストですでに提示されている情報と同程度の情報しか提示していないが、認知の障害、言語の障害、又は学習障害のある利用者にとってはそれが理解しやすい場合がある。そのような場合には、キャプションを提供する必要はない。なぜなら、その情報は、ウェブページ上でテキスト、あるいは、（例えば、画像の）代替テキストによって、すでに提供されているからである。
達成基準1.2.4 キャプション (ライブ) を理解するも参照のこと。
キャプションを提供しているチュートリアル
結び目の作り方を紹介している映像があり、次のようなキャプションが提供されている。
「（音楽）
水兵、兵士、そして木こりのような人たちにとっては、
ロープを使って結び目を作るのは、重要なスキルでした。」
Whit Anderson氏による、書き起こしテキストのフォーマットのサンプルより。
複雑な法律文書には、段落ごとに同期したメディアのクリップがあり、その段落の内容を話している人を表示している。各クリップは、その対応する段落と関連付けられている。その同期したメディアには、キャプションが提供されていない。
取扱説明書で、ある部品に関しての説明とその必要な使用方法を含む取扱説明書では、その部品の正しい使用方法を紹介する同期したメディアのクリップがある。その同期したメディアのクリップには、キャプションが提供されていない。
オーケストラがコンサート映像にキャプションを提供している。台詞や歌詞を逐語的に提供するだけでなく、タイトル、楽章、作曲者などさまざまな情報を提供することで、利用者が音声の特徴を理解することを助け、歌詞のない音楽も認識できるようにしている。例えば、
「[管弦楽組曲第3番 ニ長調 BWV 1068 - 第2曲 G線上のアリア]
[作曲者 ヨハン・ゼバスティアン・バッハ]
♪ 遅いテンポの落ち着いたメロディ ♪」
注記: キャプションのスタイルガイドは言語によって異なる可能性がある。
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
映像しか含まないクリップに対して、「このクリップには音は使われていません」というノートを提供する（リンク追加予定）
オーディオトラックのすべての言語のキャプションを提供するためにSMIL 1.0を使う（リンク追加予定）
オーディオトラックのすべての言語のキャプションを提供するためにSMIL 2.0を使う（リンク追加予定）
以下に挙げるものは、WCAG ワーキンググループが達成基準1.2.2に適合していないとみなした、よくある不適合事例である。
- キャプション (captions)
そのメディアのコンテンツを理解するのに必要な、会話及び会話でない音声情報に対する、同期した視覚、又はテキストによる代替。
注記 1:
キャプションは会話のみの字幕と似ているが、会話の内容だけを伝えるのではなく、その番組の内容を理解するために必要な効果音、音楽、笑い声、話者の特定、位置などを含む、会話でない音声情報と同等の内容も伝える点が異なる。
注記 2:
クローズドキャプションは、音声情報と同等の内容で、プレーヤーによっては表示／非表示を切り替えることができるものを指す。
注記 3:
オープンキャプションは、非表示にできないキャプションである。例えば、キャプションが同等の視覚化された文字画像で映像に埋め込まれている場合である。
注記 4:
キャプションは、映像に含まれる情報を分かりにくくしたり遮ったりすべきではない。
注記 5:
国によっては、キャプションは "subtitle" と呼ばれている。
訳注： subtitleには、「字幕」の意がある。日本では、キャプションのことを一般に字幕と呼ぶことが多い。
注記 6:
音声解説にキャプションをつけることもできるが、つける必要はない。なぜなら、音声解説は既に視覚的に提示されている情報の説明だからである。
- メディアによるテキストの代替 (media alternative for text)
テキストで (直接又はテキストによる代替によって) 既に提示されている情報以上のものを提示していないメディア。
注記: メディアによるテキストの代替は、テキストを代替する提示の恩恵を受ける人たちのために提供される。テキストの代替メディアになりうるのは、音声しか含まないメディア、映像しか含まない (手話の映像を含む) メディア、又は音声付映像メディアである。
- 収録済 (prerecorded)
ライブではない情報。
- 同期したメディア (synchronized media)
情報を提示するために、他のフォーマットと同期した音声もしくは映像、又は時間に依存するインタラクティブな構成要素と同期した音声又は映像。ただし、そのメディアが
メディアによるテキストの代替であって、メディアによる代替であることが明確にラベル付けされているものは除く。
- 音声 (audio)
音の再生技術。
注記: 音声には、合成して作られたもの (音声合成を含む)、実世界の音を収録したもの、又はその両方が含まれる。
音声解説、又はメディアに対する代替 (収録済) :
達成基準 1.2.3 を理解する
この達成基準の意図は、全盲又は視覚障害のある利用者が、同期したメディアのプレゼンテーションにある視覚的な情報を入手できるようにすることである。この達成基準では、2つのアプローチについて説明しているが、どちらを用いてもよい。
1つめのアプローチは、映像コンテンツの音声解説を提供することである。音声解説は、利用者が映像の情報を入手できない場合のために、利用者が必要とする情報をそのプレゼンテーションの音声部分に加えて、映像コンテンツを増補するものである。発話の合間に存在する無音部分を使って、動き、登場人物、シーンの変化、画面上の文字に関する情報のうち、コンテンツを理解する上で重要で、かつ主音声では説明されていなかったり、話されていない情報を、音声解説で提供する。
2つめのアプローチは、同期したメディアにある（視覚的及び聴覚的な）情報すべてをテキスト形式で提供することである。時間の経過に伴って変化するメディアの代替は、同期したメディアのコンテンツで提供されているすべての情報をそのままに提供するものである。時間の経過に伴って変化するメディアの代替は、いわば台本や書物のようなものである。音声解説とは異なり、映像部分の説明が、既存の発話の合間だけに制限されることはない。視覚的な状況、登場人物の動きや表情、及びその他のあらゆる視覚的なものを含めて、すべての視覚的な情報について、説明を十分に提供する。さらに、発話ではない音声（笑い声、画面の外から聞こえてくる声など）を説明し、すべての発話の書き起こしテキストを含む。そして、そういった説明と発話の書き起こしテキストの登場順は、同期したメディア自体での登場順と同じである。結果的に、時間の経過に伴って変化するメディアの代替は、同期したメディアコンテンツについて、音声解説だけの場合よりもずっと多くの完全な説明を提供することが可能である。
同期したメディアのプレゼンテーションの一部分として何らかのインタラクションがある場合（例えば、「質問に答えるために、今、ボタンを押してください。」）、時間の経過に伴って変化するメディアの代替は、ハイパーリンク又は同じ機能を提供するのに必要なものを提示することになる。
注記 1:
達成基準 1.2.3、1.2.5、及び 1.2.7 では、映像トラックにある情報のすべてが音声トラックですでに提供されている場合には、音声解説を必要としない。
注記 2:
達成基準 1.2.3、1.2.5、及び 1.2.8 は、お互いに重なり合う部分がある。これは、最低限の適合レベルではコンテンツ制作者に選択肢を与え、より高い適合レベルでは付加的な要件を提示するためである。達成基準 1.2.3 のレベル A では、コンテンツ制作者には、音声解説又は完全な代替テキストのどちらかを提供するという選択肢がある。レベル AA で適合したい場合、達成基準 1.2.5 において、コンテンツ制作者は音声解説を提供しなければならない。もし達成基準 1.2.3 を満たすための代替コンテンツとして音声解説を選択していれば、レベル AA の要件をすでに満たしていることになるが、そうでなければ、音声解説の提供は付加的な要件ということになる。達成基準 1.2.8 のレベル AAA では、コンテンツ制作者は拡張したテキストの説明を提供しなければならない。達成基準 1.2.3 及び 1.2.5 において音声解説だけを提供することで要件を満たしていた場合には、達成基準 1.2.8 は付加的な要件ということになる。しかし、達成基準 1.2.3 をテキストの説明による代替を提供することで満たし、なおかつ達成基準 1.2.5 の音声解説の要件を満たしている場合には、達成基準 1.2.8 は新しい要件を付加することにはならない。
達成基準1.2.5 音声解説 (収録済) を理解する、
達成基準1.2.7 拡張音声解説 (収録済) を理解する、及び
達成基準1.2.8 メディアに対する代替 (収録済) を理解するも参照のこと。
音声解説を提供している映画
音声解説：タイトル「Teaching Evolution ケーススタディ ボニー・チェン」くちばしが長くて薄い鳥の写真を、先生が見せている。
ボニー・チェン：「これらの写真はすべて、フロリダのエバーグレイド国立公園で撮影されたものです。」
音声解説：先生が生徒ひとりひとりに2つの平らで薄い木の棒切れを手渡ししています。
ボニー・チェン：「今日、皆さんは、こんなくちばしをした、脚の長い鳥になったふりをしてください。」
音声解説： 先生が、2つの棒切れを口にあてて、くちばしの形を作っています。
音声の書き起こしテキストは、「Teaching Evolution ケーススタディ ボニー・チェン(copyright WGBH and Clear Blue Sky Productions, Inc.)」の冒頭の数分間に基づいいる。
ある研修ビデオでの、時間の経過に伴って変化するメディアの代替
ある企業では、従業員のための研修ビデオを購入し、その企業のイントラネット上に置いている。そのビデオでは、新しい技術の使い方を説明していて、同時にそれを説明しながら実演する人物が登場する。ビデオの発話部分の合間に、視覚的なデモの音声解説を挿入する時間的な余裕がないため、その企業では、そのデモを見ることができない人を含む従業員すべてがその内容をよりよく理解することができるように、時間の経過に伴って変化するメディアの代替を提供している。
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
以下に挙げるものは、WCAG ワーキンググループが達成基準1.2.3に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
- メディアによるテキストの代替 (media alternative for text)
テキストで (直接又はテキストによる代替によって) 既に提示されている情報以上のものを提示していないメディア。
注記: メディアによるテキストの代替は、テキストを代替する提示の恩恵を受ける人たちのために提供される。テキストの代替メディアになりうるのは、音声しか含まないメディア、映像しか含まない (手話の映像を含む) メディア、又は音声付映像メディアである。
- 収録済 (prerecorded)
ライブではない情報。
- 同期したメディア (synchronized media)
情報を提示するために、他のフォーマットと同期した音声もしくは映像、又は時間に依存するインタラクティブな構成要素と同期した音声又は映像。ただし、そのメディアが
メディアによるテキストの代替であって、メディアによる代替であることが明確にラベル付けされているものは除く。
- 映像 (video)
写真や画像を動かしたり、連続して表示したりする技術。
注記: 映像はアニメーション、実写、もしくはその両方で構成され得る。
- 時間依存メディアに対する代替コンテンツ (alternative for time-based media)
時間依存の視覚的及び聴覚的情報を正しい順序で説明したテキストを含み、あらゆる時間依存のインタラクションによる結果を得る手段を提供している文書。
注記: 同期したメディアのコンテンツを作るために用いられる脚本は、編集が終了した最終版の同期したメディアを正確に描写した脚本に修正されている場合だけ、この定義を満たす。
- 音声解説 (audio description)
主音声のトラックだけでは理解できない重要で視覚的な詳細を説明するために、音声トラックに追加されたナレーション。
注記 1:
映像の音声解説は、動作、登場人物、場面の変化、画面上のテキスト、及びその他の視覚的なコンテンツに関する情報を提供する。
注記 2:
標準的な音声解説では、ナレーションが会話の合間に挿入される。 (拡張音声解説も参照。)
注記 3:
映像情報のすべてが既存の音声ですでに提供されている場合、補足の音声解説は不要である。
注記 4:
"video description" や "descriptive narration" とも呼ばれる。
キャプション (ライブ) :
達成基準 1.2.4 を理解する
この達成基準の意図は、デフ又は音声が聞こえにくい利用者がリアルタイムのプレゼンテーションを見られるようにすることである。キャプションは、コンテンツの中で音声トラックを通じて提示されている部分の代替を提供するものである。キャプションには、発話の内容だけを含むのではなく、誰が話しているのかも示し、また、意味のある効果音やその他の重要な音声も含める。
この達成基準は、同期したメディアの放送に適用することを意図しており、Webアプリケーションを介し2人ないしそれ以上の個人同士で行う双方向のマルチメディア電話に対し、利用者の要求の有無にかかわらずキャプションの提供を求めることは意図していない。キャプションを提供する責任は、コンテンツの提供者（電話をかけた人）または「ホスト」として電話をかけた人に課せられるもので、アプリケーションには課せられない。
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
(まだ文書化されていない)
以下に挙げるものは、WCAG ワーキンググループが達成基準1.2.4に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
- キャプション (captions)
そのメディアのコンテンツを理解するのに必要な、会話及び会話でない音声情報に対する、同期した視覚、又はテキストによる代替。
注記 1:
キャプションは会話のみの字幕と似ているが、会話の内容だけを伝えるのではなく、その番組の内容を理解するために必要な効果音、音楽、笑い声、話者の特定、位置などを含む、会話でない音声情報と同等の内容も伝える点が異なる。
注記 2:
クローズドキャプションは、音声情報と同等の内容で、プレーヤーによっては表示／非表示を切り替えることができるものを指す。
注記 3:
オープンキャプションは、非表示にできないキャプションである。例えば、キャプションが同等の視覚化された文字画像で映像に埋め込まれている場合である。
注記 4:
キャプションは、映像に含まれる情報を分かりにくくしたり遮ったりすべきではない。
注記 5:
国によっては、キャプションは "subtitle" と呼ばれている。
訳注： subtitleには、「字幕」の意がある。日本では、キャプションのことを一般に字幕と呼ぶことが多い。
注記 6:
音声解説にキャプションをつけることもできるが、つける必要はない。なぜなら、音声解説は既に視覚的に提示されている情報の説明だからである。
- ライブ (live)
現実の出来事から取り込まれ、放送遅延以上の遅延なく受け手に送信される情報。
注記 1:
放送遅延は、短時間の (通常は自動的な) 遅れで、例えば放送局に放送のタイミングの調整や音声 (又は映像) の検閲のための時間を与えるものだが、意味のある編集ができるほどのものではない。
注記 2:
もし情報が完全にコンピュータで生成されたものならば、それはライブではない。
- 同期したメディア (synchronized media)
情報を提示するために、他のフォーマットと同期した音声もしくは映像、又は時間に依存するインタラクティブな構成要素と同期した音声又は映像。ただし、そのメディアが
メディアによるテキストの代替であって、メディアによる代替であることが明確にラベル付けされているものは除く。
- 音声 (audio)
音の再生技術。
注記: 音声には、合成して作られたもの (音声合成を含む)、実世界の音を収録したもの、又はその両方が含まれる。
音声解説 (収録済) :
達成基準 1.2.5 を理解する
この達成基準の意図は、全盲あるいは視覚障害のある利用者に、同期したメディアのプレゼンテーションにある視覚的な情報を提供することである。 音声解説は、利用者が映像の情報を入手できない場合のために、利用者が必要とする情報をそのプレゼンテーションの音声部分に加えて、映像コンテンツを増補するものである。 発話の合間に存在する無音部分を使って、動き、登場人物、シーンの変化、画面上の文字に関する情報のうち、コンテンツを理解する上で重要で、かつ主音声では説明されていなかったり、話されていない情報を、音声解説で提供する。
注記 1:
達成基準 1.2.3、1.2.5、及び 1.2.7 では、映像トラックにある情報のすべてが音声トラックですでに提供されている場合には、音声解説を必要としない。
注記 2:
達成基準 1.2.3、1.2.5、及び 1.2.8 は、お互いに重なり合う部分がある。これは、最低限の適合レベルではコンテンツ制作者に選択肢を与え、より高い適合レベルでは付加的な要件を提示するためである。達成基準 1.2.3 のレベル A では、コンテンツ制作者には、音声解説又は完全な代替テキストのどちらかを提供するという選択肢がある。 レベル AA で適合したい場合、達成基準 1.2.5 において、コンテンツ制作者は音声解説を提供しなければならない。もし達成基準 1.2.3 を満たすための代替コンテンツとして音声解説を選択していれば、レベル AA の要件をすでに満たしていることになるが、そうでなければこれは付加的な要件ということになる。 達成基準 1.2.8 のレベル AAA では、コンテンツ制作者は拡張したテキストの説明を提供しなければならない。達成基準 1.2.3 及び 1.2.5 において音声解説だけを提供することで要件を満たしていた場合には、達成基準 1.2.8 が付加的な要件ということになる。 しかし、達成基準 1.2.3 をテキストの説明による代替を提供することで満たし、なおかつ達成基準 1.2.5 の音声解説の要件を満たしている場合には、達成基準 1.2.8 は新しい要件を付加することにはならない。
音声解説を提供している映画
音声解説：タイトル「Teaching Evolution ケーススタディ ボニー・チェン」くちばしが長くて薄い鳥の写真を、先生が見せている。
ボニー・チェン：「これらの写真はすべて、フロリダのエバーグレイド国立公園で撮影されたものです。」
音声解説：先生が生徒ひとりひとりに2つの平らで薄い木の棒切れを手渡ししています。
ボニー・チェン：「今日、皆さんは、こんなくちばしをした、脚の長い鳥になったふりをしてください。」
音声解説： 先生が、2つの棒切れを口にあてて、くちばしの形を作っています。
音声の書き起こしテキストは、「Teaching Evolution ケーススタディ ボニー・チェン(copyright WGBH and Clear Blue Sky Productions, Inc.)」の冒頭の数分間に基づいいる。
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
以下に挙げるものは、WCAG ワーキンググループが達成基準1.2.5に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
- 収録済 (prerecorded)
ライブではない情報。
- 同期したメディア (synchronized media)
情報を提示するために、他のフォーマットと同期した音声もしくは映像、又は時間に依存するインタラクティブな構成要素と同期した音声又は映像。ただし、そのメディアが
メディアによるテキストの代替であって、メディアによる代替であることが明確にラベル付けされているものは除く。
- 映像 (video)
写真や画像を動かしたり、連続して表示したりする技術。
注記: 映像はアニメーション、実写、もしくはその両方で構成され得る。
- 音声解説 (audio description)
主音声のトラックだけでは理解できない重要で視覚的な詳細を説明するために、音声トラックに追加されたナレーション。
注記 1:
映像の音声解説は、動作、登場人物、場面の変化、画面上のテキスト、及びその他の視覚的なコンテンツに関する情報を提供する。
注記 2:
標準的な音声解説では、ナレーションが会話の合間に挿入される。 (拡張音声解説も参照。)
注記 3:
映像情報のすべてが既存の音声ですでに提供されている場合、補足の音声解説は不要である。
注記 4:
"video description" や "descriptive narration" とも呼ばれる。
手話 (収録済) :
達成基準 1.2.6 を理解する
この達成基準の意図は、ろう者又は難聴の利用者で手話に堪能な利用者が、同期したメディアのプレゼンテーションの音声トラックコンテンツを理解できるようにすることである。例えば、字幕に書かれているようなテキストは、第二言語であることがよくある。手話は、イントネーション、感情、及び、字幕には反映されないが手話通訳には反映されるその他の音声情報を提供するので、手話通訳は同期したメディアの内容に対して字幕よりも豊富でより等価な情報を提供する。手話で頻繁にやりとりする利用者はまた、手話でより早口になり、同期したメディアは、時間依存のプレゼンテーションとなる。
事例 1.ある企業が、従業員すべてに対して重要な発表をしている。総会は本社で行われていて、その模様がウェブでストリーミング配信されている。総会の場には手話通訳者がいて、ライブの映像にはプレゼンテーションをしている人物及び手話通訳者の全身が映し出されている。
事例 2.事例 1 にあるのと同じ発表が、遠隔地にいる従業員にはウェブキャストで届けられている。画面が一つしかないため、手話通訳者は画面のコーナーに映し出されている。
事例 3.ある大学が、講義をする教授の同期したメディアによるプレゼンテーションを作成して、講義のオンライン版を提供している。そのプレゼンテーションには、化学の実験を解説して実演している教授の映像がある。講義内容の手話通訳を制作して、ウェブ上で同期したメディア版とあわせて提供している。
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
以下に挙げるものは、WCAG ワーキンググループが達成基準1.2.6に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
- 収録済 (prerecorded)
ライブではない情報。
- 同期したメディア (synchronized media)
情報を提示するために、他のフォーマットと同期した音声もしくは映像、又は時間に依存するインタラクティブな構成要素と同期した音声又は映像。ただし、そのメディアが
メディアによるテキストの代替であって、メディアによる代替であることが明確にラベル付けされているものは除く。
- 手話通訳 (sign language interpretation)
ある言語、通常は発話された言葉を、手話に訳すこと。
注記:
手話は、本来、同じ国や地域で話されている言葉とは関係がない独立したものである。
- 音声 (audio)
音の再生技術。
注記: 音声には、合成して作られたもの (音声合成を含む)、実世界の音を収録したもの、又はその両方が含まれる。
拡張音声解説 (収録済) :
達成基準 1.2.7 を理解する
この達成基準の意図は、全盲又は視覚障害のある利用者に、同期したメディアのプレゼンテーションについての情報を標準的な音声解説よりも多く提供することである。同期したメディアのプレゼンテーションを一時的に停止させて、追加の音声解説を再生することで提供できる。その再生が終わった後に、同期したメディアのプレゼンテーションを再開する。
ただし、追加の説明を必要としない利用者にとっては、閲覧の邪魔になってしまうため、その機能のオンとオフを切り替えることのできる方法を提供する。あるいは、その代わりに、拡張した音声解説のあるバージョンとないバージョンとを提供してもよい。
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
以下に挙げるものは、WCAG ワーキンググループが達成基準1.2.7に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
- 収録済 (prerecorded)
ライブではない情報。
- 同期したメディア (synchronized media)
情報を提示するために、他のフォーマットと同期した音声もしくは映像、又は時間に依存するインタラクティブな構成要素と同期した音声又は映像。ただし、そのメディアが
メディアによるテキストの代替であって、メディアによる代替であることが明確にラベル付けされているものは除く。
- 拡張音声解説 (extended audio description)
映像を一時停止することで追加の説明を付加するための時間を確保し、視聴覚プレゼンテーションに付加した音声解説。
注記: この達成方法は、追加の音声解説がないと映像の意味が損なわれてしまい、かつ会話やナレーションの合間が短すぎる場合だけに用いられる。
- 映像 (video)
写真や画像を動かしたり、連続して表示したりする技術。
注記: 映像はアニメーション、実写、もしくはその両方で構成され得る。
- 音声解説 (audio description)
主音声のトラックだけでは理解できない重要で視覚的な詳細を説明するために、音声トラックに追加されたナレーション。
注記 1:
映像の音声解説は、動作、登場人物、場面の変化、画面上のテキスト、及びその他の視覚的なコンテンツに関する情報を提供する。
注記 2:
標準的な音声解説では、ナレーションが会話の合間に挿入される。 (拡張音声解説も参照。)
注記 3:
映像情報のすべてが既存の音声ですでに提供されている場合、補足の音声解説は不要である。
注記 4:
"video description" や "descriptive narration" とも呼ばれる。
メディアに対する代替 (収録済) :
達成基準 1.2.8 を理解する
この達成基準の意図
この達成基準の意図は、視力が弱すぎてキャプションを確実に読むことができず、なおかつ聴力も弱すぎて発話や音声解説を確実に聞くことができない利用者が、視聴覚のコンテンツを利用できるようにすることである。時間の経過に伴って変化するメディアの代替を提供することで、それが可能になる。
このアプローチは、同期したメディアにある（視覚的及び聴覚的な）情報すべてをテキスト形式で提供することである。時間の経過に伴って変化するメディアの代替は、同期したメディアのコンテンツで提供されているすべての情報をそのままに提供するものである。時間の経過に伴って変化するメディアの代替は、本のようなものになる。 音声解説とは異なり、映像部分の説明が、既存の発話の合間だけに制限されることはない。 視覚的な状況、登場人物の動きや表情、及びその他のあらゆる視覚的なものを含めて、すべての視覚的な情報について、説明を十分に提供する。さらに、発話ではない音声（笑い声、画面の外から聞こえてくる声など）を説明し、すべての発話の書き起こしテキストを含む。そして、そういった説明と発話の書き起こしテキストの登場順は、同期したメディア自体での登場順と同じである。そして、そういった説明と発話の書き起こしテキストの登場順は、同期したメディア自体での登場順と同じである。結果的に、時間の経過に伴って変化するメディアの代替は、同期したメディアコンテンツについて、音声解説だけでの場合よりもずっと多くの完全な説明を提供することが可能である。
同期したメディアのプレゼンテーションの一部分として何らかのインタラクションがある場合（例：「質問に、今、答えてください。」）、時間の経過に伴って変化するメディアの代替は、ハイパーリンク又は同じ機能を提供するのに必要なものを提示することになる。
視力が弱すぎてキャプションを確実に読むことができず、なおかつ聴力も弱すぎて発話を確実に聞き取ることのできない利用者は、点字ピンディスプレイを使うことによって、時間の経過に伴って変化するメディアの代替を利用することができる。
注記 1:
達成基準 1.2.3、1.2.5、及び 1.2.7 では、映像トラックにある情報のすべてが音声トラックですでに提供されている場合には、音声解説を必要としない。
注記 2:
達成基準 1.2.3、1.2.5、及び 1.2.8 は、お互いに重なり合う部分がある。 これは、最低限の適合レベルではコンテンツ制作者に選択肢を与え、より高い適合レベルでは付加的な要件を提示するためである。 達成基準 1.2.3 のレベル A では、コンテンツ制作者には、音声解説又は完全な代替テキストのどちらかを提供するという選択肢がある。 レベル AA で適合したい場合、達成基準 1.2.5 において、コンテンツ制作者は音声解説を提供しなければならない。もし達成基準 1.2.3 を満たすための代替コンテンツとして音声解説を選択していれば、レベル AA の要件をすでに満たしていることになるが、そうでなければこれは付加的な要件ということになる。 達成基準 1.2.8 のレベル AAA では、コンテンツ制作者は拡張したテキストの説明を提供しなければならない。達成基準 1.2.3 及び 1.2.5 において音声解説だけを提供することで要件を満たしていた場合には、達成基準 1.2.8 が付加的な要件ということになる。 しかし、達成基準 1.2.3 をテキストの説明による代替を提供することで満たし、なおかつ達成基準 1.2.5 の音声解説の要件を満たしている場合には、達成基準 1.2.8 は新しい要件を付加することにはならない。
達成基準 1.2.8の事例
事例 1. ある研修ビデオでの、時間の経過に伴って変化するメディアの代替
あるコミュニティセンターは、その会員向けに研修ビデオを購入し、それをセンターのイントラネットに置いている。そのビデオでは、新しい技術の使い方を説明していて、同時にそれを説明しながら実演する人物が登場している。そのコミュニティセンターでは、時間依存メディアに対して代替を提供している。ひとつの代替によって、同期したメディアの実演を見ることも、説明を聞くこともできない人を含むすべての会員が、提供されている内容をよりよく理解できるようになっている。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準1.2.8の達成方法及び不適合事例 - メディアに対する代替 (収録済)
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
達成基準を満たすことのできる達成方法
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の達成方法（又は、達成方法の組合せ）がある。
1.2.8 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 1.2.8のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準1.2.8に適合していないとみなした、よくある不適合事例である。
重要な用語
- 収録済 (prerecorded)
ライブではない情報。
- 同期したメディア (synchronized media)
情報を提示するために、他のフォーマットと同期した音声もしくは映像、又は時間に依存するインタラクティブな構成要素と同期した音声又は映像。ただし、そのメディアが
メディアによるテキストの代替であって、メディアによる代替であることが明確にラベル付けされているものは除く。
- 映像しか含まない (video-only)
映像のみを含んだ、時間に依存する提示 (音声やインタラクションを含まない)。
- 時間依存メディアに対する代替コンテンツ (alternative for time-based media)
時間依存の視覚的及び聴覚的情報を正しい順序で説明したテキストを含み、あらゆる時間依存のインタラクションによる結果を得る手段を提供している文書。
注記: 同期したメディアのコンテンツを作るために用いられる脚本は、編集が終了した最終版の同期したメディアを正確に描写した脚本に修正されている場合だけ、この定義を満たす。
音声のみ (ライブ) :
達成基準 1.2.9 を理解する
この達成基準の意図は、例えばテレビ会議のような、ライブの音声、ライブの発話、及びラジオのウェブキャストが伝えている情報を、代替テキストを用いることによってアクセシブルにすることである。ライブのキャプション付加サービスは、デフ又は音声の聞こえづらい利用者、あるいは他のやり方で音声を聞くことのできない利用者に対してライブの音声をアクセシブルにすることが可能であろう。そういったサービスでは、訓練された人間のオペレーターが、話の内容を聞きながら、特殊なキーボードを用いてほんの少しの遅延だけでテキストを入力している。オペレーターは、かなり忠実にライブの出来事をテキストで記録することができる。また、内容を理解する上で不可欠な発話以外の音声に関する注記も挿入することができる。ライブの音声が予め用意された現行通りのものであれば、書き起こしテキストを事前に準備しておけることもある。しかし、ライブのキャプション付加サービスのほうが好まれる。なぜなら、キャプションが音声自体と同じペースで表示され、台本にはないことが起こったとしてもそれに対処できるからである。
訓練されていないオペレーターを使用したり、実際に起こっていることとは明らかに違う書き起こしテキストを提供したりしている場合は、この達成基準を満たしているとはいえない。
この達成基準は、音声の放送に適用することを意図しており、Webアプリケーションを介し2人ないしそれ以上の個人同士で行う双方向のマルチメディア電話に対し、利用者の要求の有無にかかわらずキャプションの提供を求めることは意図していない。キャプションを提供する責任は、コンテンツの提供者（電話をかけた人）または「ホスト」として電話をかけた人に課せられるもので、アプリケーションには課せられない。
ある広告会社が、ウェブベースのキャプションサービスを利用して、ライブのイベントのキャプションを提供している。そのサービスによるキャプションは、ストリーミングの音声制御コントロールのあるウェブページのサブフレームに表示されている。
フリンジ劇場のライブのラジオ劇が、ウェブで放送されている。俳優たちが大部分は用意された台本通りに演じていて、番組の予算が限られているため、（脚本家の許諾を得た上で）プロデューサーは劇の台本へのリンクを提供している。
ストリーミングの音声サーバーは、例えば Flash や Silverlight のように、テキスト及びグラフィックも使用可能なメディア形式を利用している。速記者が、あるイベントでライブのキャプションを書き起こしていて、それがその場で組み込まれて、メディアプレーヤーで閲覧可能なメディア配信のライブのキャプションとして使われている。
ある CEO が、ニュース速報の報道に反応して、報道メディア向けに電話による記者発表を行っている。その音声を録音して、インターネット上でも配信したが、時間の制約があって、ウェブ・キャプション付加サービスを間に合わせることができなかった。CEO がそこで読み上げる記者発表の内容は予め準備されていたので、その会社は発表内容の書き起こしテキストを同時に提供することにした。
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
以下に挙げるものは、WCAG ワーキンググループが達成基準1.2.9に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
- ライブ (live)
現実の出来事から取り込まれ、放送遅延以上の遅延なく受け手に送信される情報。
注記 1:
放送遅延は、短時間の (通常は自動的な) 遅れで、例えば放送局に放送のタイミングの調整や音声 (又は映像) の検閲のための時間を与えるものだが、意味のある編集ができるほどのものではない。
注記 2:
もし情報が完全にコンピュータで生成されたものならば、それはライブではない。
- 時間依存メディアに対する代替コンテンツ (alternative for time-based media)
時間依存の視覚的及び聴覚的情報を正しい順序で説明したテキストを含み、あらゆる時間依存のインタラクションによる結果を得る手段を提供している文書。
注記: 同期したメディアのコンテンツを作るために用いられる脚本は、編集が終了した最終版の同期したメディアを正確に描写した脚本に修正されている場合だけ、この定義を満たす。
- 音声しか含まない (audio-only)
音声のみを含んだ、時間に依存する提示 (映像やインタラクションを含まない)。
適応可能:
ガイドライン1.3を理解する
ガイドライン1.3: 情報、及び構造を損なうことなく、様々な方法 (例えば、よりシンプルなレイアウト) で提供できるようにコンテンツを制作すること。
ガイドライン 1.3 の意図
このガイドラインの目的は、例えば、音声で読み上げたり、あるいはより単純なレイアウトで提示したりというように、すべての情報をすべての利用者が知覚できるように提供することである。すべての情報が、ソフトウェアによって解釈できるように提供されていれば、情報を様々な方法で（視覚的、聴覚的、触覚的、又はその他の方法で）提示することが可能である。もし、支援技術によって構造及び情報をプログラムが解釈できないような方法で、情報がある特定の表現形態で提供されていたとしたら、その情報は利用者が必要とするその他の形式では描画できない。
このガイドラインにある達成基準はすべて、ある表現形態で提供されている様々な種類の情報を、その他の感覚モダリティでも提示可能であるように提供するためのものである。
情報及び関係性:
達成基準 1.3.1 を理解する
この達成基準の意図
この達成基準の意図は、視覚的又は聴覚的な体裁によって暗に伝えられている情報及び関係性を、その表現形式が変わったときにも保つようにすることである。例えば、コンテンツがスクリーンリーダーによって読み上げられたり、コンテンツ制作者が提供するスタイルシートがユーザスタイルシートに置き換えられたりしたときには、表現形式が変わる。
画面を見ている利用者は、様々な視覚的な手がかりによって構造を知覚する。例えば、見出しは大きめで太字のフォントで、次の段落とはスペースを空けて表示されていることがほとんどである。リスト項目は、その先頭に中黒等があって、字下げされていることが多い。段落と段落の間にはスペースがある。共通の特徴を有する条項は、表の行と列で整理されている。フォームの複数のテキストフィールドは、テキストのラベルを共有するグループとして配置されていることがある。異なる背景色を用いて、いくつかのアイテムが互いに関係のあることを示していることもある。特別な意味を持つ語句は、フォントの種類を変えたり、イタリック、下線付きにすることによって示されている。共通の特徴を有する条項は、同じ行・列を持つセル同士の関係性や、行・列見出しとセルとの関係性が分かるように整理されている。などなど。これらの構造と関係性はプログラムが解釈可能、またはテキストで入手可能であり、すべての利用者にとって重要な情報が感知可能であることを保証する。
同様に、聴覚的な手がかりを用いることもある。例えば、チャイム音が新しい節の開始位置を示している。声のピッチや発話のスピードを変えて、重要な情報を強調したり、引用されたテキストを示したりしている、など。
そういった関係性が、ある利用者にとって知覚可能であれば、その関係性をすべての利用者が知覚できるようにすることが可能である。情報をすべての利用者にきちんと提供できたかどうかを判断する一つの方法は、その情報に様々な感覚モダリティで連続してアクセスしてみることである。
用語集にある用語へのリンクを a 要素（又は、使用している技術特有のリンク要素）を用いて実装して、異なるフォントで示していれば、スクリーンリーダーの利用者は、用語集にある用語のところで、たとえフォントの違いに関する情報は受け取れなかったとしても、それがリンクであることが音声読み上げを聞けば分かるだろう。あるオンラインカタログの価格表示では赤い大きなフォントを使用している。スクリーンリーダーの利用者は赤色の情報は得られないが、価格の前に通貨表示を記載することで情報を得ることができる。
ウェブコンテンツ技術の中には、ある種の情報及び関係性をプログラムで解釈する手段を提供していないものがある。そういった場合には、その情報及び関係性を説明するテキストを提供すべきである。例えば、「アスタリスク (*) のある項目はすべて必須項目です。」のように説明テキストを提供する。テキストによる説明は、例えば、その親要素又は隣接する要素内などのように、（そのページをリニアライズした際に）テキストが説明している情報の近くに置くべきである。
場合によっては、関係性をプログラムで解釈できるようにすべきかテキストで提供すべきか、各自の判断に委ねるしかないこともありうる。しかし、プログラムに基づいた関係性を技術的に示すことができる場合、情報や関係性をテキストで提供するよりも、プログラムが解釈できるようにすることを強く推奨する。
注記: 色の値がプログラムが解釈可能であることは要求していない。色によって伝えられる情報は、その値を明らかにするだけでは、十分に提示することができないからである。そのため、色に特有の問題については、達成基準 1.3.1 ではなく、達成基準 1.4.1で対処している。
達成基準1.3.1の具体的なメリット
この達成基準は、ユーザエージェントが個々の利用者のニーズに応じてコンテンツに適応できるようにすることによって、様々な障害のある利用者の役に立つ。
全盲の（スクリーンリーダーを使用している）利用者が、色を用いて伝えられている情報をテキストでも得られるようになる（色を用いて情報を伝えている画像の代替テキストを含む）。
点字ピンディスプレイを使用している盲ろうの利用者は、色に依存した情報を利用できないことがある。
達成基準 1.3.1の事例
必須項目のある入力フォーム
入力フォームに、いくつかの必須項目がある。必須項目のラベルを、赤で表示している。さらに、各ラベルの最後には、アスタリスクの記号文字 (*) が付いている。フォームへの入力に関する説明文には、「すべての必須項目は赤字で示してあり、アスタリスク (*) が付いています。」と書かれていて、例が後に続いている。
必須項目を示すために色とテキストを用いている入力フォーム
入力フォームに、必須項目と任意項目の両方がある。入力フォームの先頭にある説明文には、必須項目のラベルが赤字になっていて、「必須」という代替テキストのあるアイコンも付いている。赤字とアイコンの両方が、フォームのテキストフィールドとプログラムで関連付けられているので、支援技術の利用者はどれが必須項目なのかが判断できる。
各セルの見出しをプログラムが解釈可能なバスの時刻表テーブル
バスの運行スケジュールが、1列目には縦にバス停の名前が並び、1行目には横に異なるバスが並んでいる表で示されている。各セルには、バスがそのバス停に到着する時刻が書かれている。支援技術が、各セルにある時刻がどのバスとどのバス停とに関連付けられているのかを解釈することができるように、各バス停と各バスのセルは、それぞれの対応する行又は列の見出しとして示されている。
チェックボックスのラベルをプログラムが解釈可能な入力フォーム
あるフォームでは、各チェックボックスに対するラベルが、支援技術によってプログラムが解釈可能になっている。
テキスト文書
構造をプログラムが解釈できるように、シンプルなテキスト文書は、タイトルの前に2行の空行があり、アスタリスクを使ってリスト項目を示し、その他の標準的な書式の決まりに従ってフォーマットされている。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準1.3.1の達成方法及び不適合事例 - 情報及び関係性
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
達成基準を満たすことのできる達成方法
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の達成方法（又は、達成方法の組合せ）がある。
1.3.1 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 1.3.1のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準1.3.1に適合していないとみなした、よくある不適合事例である。
重要な用語
- プログラムによる解釈 (プログラムによる解釈が可能) (programmatically determined (programmatically determinable))
支援技術
を含む様々なユーザエージェントが抽出でき、利用者に様々な感覚モダリティで提示できるような形のデータがコンテンツ制作者によって提供されたとき、そのデータがソフトウェアによって解釈されること。
事例 1:
マークアップ言語で、一般に入手可能な支援技術が直接アクセスできる要素と属性から解釈される。
事例 2:
非マークアップ言語の技術特有のデータ構造から解釈され、一般に入手可能な支援技術がサポートするアクセシビリティ API を通じて支援技術に提供される。
- 提示 (presentation)
利用者が知覚できる形式でコンテンツをレンダリングすること。
- 構造 (structure)
ウェブページ
の各部を相互の関係性によりまとめる方法論。及び、
一連のウェブページをまとめる方法論。
- 関係性 (relationships)
コンテンツの異なる部分間における意味のあるつながり。
意味のある順序:
達成基準 1.3.2 を理解する
この達成基準の意図
この達成基準の意図は、コンテンツの意味を理解するのに必要な音声読み上げの順序を保ちながら、ユーザエージェントがコンテンツの代替表現を提供できるようにすることである。重要なのは、意味が通じるコンテンツの順序を、少なくとも一つのプログラムが解釈できることである。この達成基準を満たしていないコンテンツは、支援技術がそのコンテンツを正しくない順序で読み上げたり、代替スタイルシート又はその他の書式変更が適用されたりしたときに、利用者を困惑あるいは混乱させてしまう恐れがある。
コンテンツの並び順を変更すると、コンテンツの意味に影響を及ぼす場合、その順序には意味がある。例えば、あるページに2つの独立した記事がある場合、それらの記事の相対的な順序がそれぞれの意味に影響を及ぼす可能性はない。そのような状況においては、それらの記事自体には意味のある順序があるかもしれないが、それらの記事が入っているテキスト・コンテナには意味のある順序はないかもしれない。
ある要素のプログラムが持つ意味が、そのコンテンツに意味のある順序があるかどうかを定義している。例えば、HTMLでは、テキストには常に意味のある順序がある。テーブル及び順序付きリストには意味のある順序があるが、順序なしリストには意味のある順序がない。
コンテンツの並び順には、常に意味があるとは限らない。例えば、あるウェブページのメイン部分とナビゲーション部分の相対的な順序は、それぞれの意味には影響を及ぼさない。それらは、プログラムで解釈される音声読み上げ順序で、どちらが先にもなりえる。もう一つの例としては、雑誌の記事にはいくつかの補足記事がいくつか含まれている。記事と補足記事の順序は、それぞれの意味に影響を及ぼすことはない。このような場合においては、この達成基準を満たすことのできるウェブページには、異なる音声読み上げ順序が複数あることになる。
誤解のないように書くと:
特定の線形順序を提供することが要求されるのは、意味に影響を与えるときだけである。
複数の順序が（WCAG 2.0の定義する）「正しい」読み順となることもありえる。
提供する正しい読み順はひとつだけでよい。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準1.3.2の達成方法及び不適合事例 - 意味のある順序
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
1.3.2 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
左から右へ書き綴る言語は左寄せを使い、右から左へ書き綴る言語は右寄せを用いる（リンク追加予定）
線形化された描画のリンクを提供する（リンク追加予定）
表現順序に影響するスタイルシートの切替を提供する（リンク追加予定）
達成基準 1.3.2のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準1.3.2に適合していないとみなした、よくある不適合事例である。
重要な用語
- プログラムによる解釈 (プログラムによる解釈が可能) (programmatically determined (programmatically determinable))
支援技術
を含む様々なユーザエージェントが抽出でき、利用者に様々な感覚モダリティで提示できるような形のデータがコンテンツ制作者によって提供されたとき、そのデータがソフトウェアによって解釈されること。
事例 1:
マークアップ言語で、一般に入手可能な支援技術が直接アクセスできる要素と属性から解釈される。
事例 2:
非マークアップ言語の技術特有のデータ構造から解釈され、一般に入手可能な支援技術がサポートするアクセシビリティ API を通じて支援技術に提供される。
- 正しく読む順序 (correct reading sequence)
コンテンツの意味を変更せずに、単語や段落が提示される順序。
感覚的な特徴:
達成基準 1.3.3 を理解する
1.3.3 感覚的な特徴:
コンテンツを理解し操作するための説明は、形、大きさ、視覚的な位置、方向、又は音のような、構成要素が持つ感覚的な特徴だけに依存していない。
(レベル A)
この達成基準の意図
この達成基準の意図は、形又は大きさを知覚できない、あるいは空間的な位置又は方向に関する情報を利用できない場合でも、すべての利用者がコンテンツを利用するための指示にアクセスできるようにすることである。コンテンツによっては、コンテンツの構造からは入手できない対象の形又は位置の知識（例えば、「円いボタン」又は「右のボタン」）に依存していることがある。障害のある利用者は、使用している支援技術の性質のために、形又は配置を知覚できないことがある。この達成基準は、このような情報に依存しているあらゆるものを明確にするために、補足の情報を提供することを要求している。
しかし、形及び/又は位置を用いて情報を提供することは、認知能力の低下している利用者を含む多くの利用者に対しては効果的な手法である。この達成基準は、その情報が他の形でも提供されている限り、形や位置の手がかりを使わないようにするものではない。
ある言語においては、「上記」はコンテンツのその地点よりも前にあるコンテンツを指し、「下記」はその地点よりも後にあるコンテンツを指すことが共通理解となっている。そういった言語では、そのように示されたコンテンツが、読み上げ順序の中で適切な位置にあり、その示し方が曖昧でなければ、「下記のリンクの中から一つ選んでください」あるいは「上記のすべて」といった記述は、この達成基準に適合していることになるだろう。
WCAG はウェブページ上に表示されたコントロールのみに該当するよう設計された。その意図は、視覚的又は聴覚的な手がかりのみを参考にコントロールを説明をすることを避けるためである。これをハードウェアコントロール（例えば、専用コンテンツのためのインターネットキオスク）を操作する時の説明に適用する時は、おそらく触知できる手がかり（例えば、矢印の形をしたキー、右側の丸いキー）が説明されるだろう。この達成基準は、指示の中で触知できる手がかりの使用を防ぐことを意図したものではない。
達成基準 1.3.3の事例
事例 1： 重複したイベントのスケジュールに、それぞれのイベント時間を区別するために色と形を使う
テーブルの1行目に時間のリストが表示され、1列目にイベントリストが表示されている表がある。セルは、色と形で定義づけできるため、特定のイベントの時間を背景色とダイヤモンドの形をした記号で表示する。
事例 2： 複数のページによるオンライン調査
複数のページによるオンライン調査では、あるページから次のページへ遷移するためのリンクに緑色の矢印のアイコンを使っていて、それをコンテンツの右下に置いている。矢印には「次へ」というラベルがはっきりと記述されていて、「次の調査へ進むには、最後の質問の右下にある『次へ』というラベルの付いた緑色の矢印のアイコンを選択してください。」という説明文が書かれている。この例では、アイコンを特定できるように、配置、色及びラベルを用いている。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準1.3.3の達成方法及び不適合事例 - 感覚的な特徴
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
1.3.3 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 1.3.3のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準1.3.3に適合していないとみなした、よくある不適合事例である。
判別可能:
ガイドライン1.4を理解する
ガイドライン1.4:
コンテンツを、利用者にとって見やすく、聞きやすいものにすること。これには、前景と背景を区別することも含む。
ガイドライン 1.4 の意図
代替手法を用いて情報を提示できることに焦点をあてたガイドラインがいくつかあるが、このガイドラインは、デフォルトの表現を障害のある利用者にとってできる限り知覚しやすくすることに関係している。利用者が前景の情報と背景とを区別しやすくすることに主に重点を置いている。視覚的な表現の場合は、背景の上に提示されている情報とその背景とのコントラストを十分に確保しているかどうかを確認する。そして、音声による表現の場合は、前景音が背景音よりも十分に大きいかどうかを確認する。視覚及び聴覚に障害のある利用者は、前景と背景の情報を区別することがかなり困難である。
ガイドライン 1.4 の参考にすべき達成方法(特定の達成基準に特有ではない達成方法)
このガイドラインにある各達成基準を満たすための達成方法は、この後に達成基準ごとに挙げられている。しかし、このガイドラインに対処するための達成方法がどの達成基準にも該当しない場合は、ここで挙げている。そういった達成方法は、どの達成基準を満たす上でも必須ではないし、十分でもないが、ウェブコンテンツの種類によってはより多くの利用者にとってよりアクセシブルにすることができるものである。
色の使用:
達成基準 1.4.1 を理解する
1.4.1 色の使用:
色が、情報を伝える、動作を示す、反応を促す、又は視覚的な要素を判別するための唯一の視覚的手段になっていない。
(レベル A)
注記: この達成基準は、特に色の知覚に関するものである。その他の知覚形態については、色やその他の視覚的提示のコーディングへのプログラムによるアクセスも含めて、ガイドライン 1.3で網羅されている。
この達成基準の意図
この達成基準の意図は、色の違いによって伝えられている情報、言い換えれば、それぞれの色には割り当てられた意味があり、その色を使うことによって伝えている情報に、すべての利用者がアクセスできるようにすることである。画像（又は、その他の非テキスト形式）で色の違いによって情報を伝えている場合、色弱の利用者はその色が分からないかもしれない。この場合、色で伝えている情報を他の視覚的な手段で提供することで、色の分からない利用者もその情報を知覚することができるようになる。
色は、感覚的な訴求力、ユーザビリティ、そしてアクセシビリティを高めるため、ウェブコンテンツのデザインにおいて重要なものである。しかし、色を知覚しづらい利用者もいる。ロービジョンの利用者は、色覚に限界を感じることがよくあり、年配の利用者の多くも色がよく見えない。さらに、テキストしか表示しない、色数が制限されている、又はモノクロのディスプレイ及びブラウザを使用している利用者は、色だけで提示されている情報を知覚することができないであろう。
色の違いで伝えられている情報の例としては、「必須項目は赤字」、「赤字はエラー」、そして「赤がメアリーの売上、青がトムの売上」などが挙げられる。何が起こるかを示している例では、リンクが新しいウィンドウで開くことやデータベースの入力内容の更新が成功したことを示すのに色を使っていることがある。また、利用者の反応を促している例には、必須項目が未入力であることを示すためにフォームの入力フィールドを反転表示していることが挙げられる。
注記: この達成基準は、ページ上での色の使用、あるいは他の視覚的な表示と重複していても色分けすることを阻むものではない。
達成基準1.4.1の具体的なメリット
ロービジョンの利用者が、色覚の限界を感じることがよくある。
年配の利用者は、色がよく見えないかもしれない。
色弱の利用者が、色で伝えられている情報をその他の視覚的な手段で知覚できるようになる。
テキストしか表示しない、色数の制限された、又はモノクロのディスプレイを使用している利用者は、色に依存している情報を知覚することができないことがある。
色の識別に問題を抱える利用者が、テキストの手がかりを見たり、聞いたりすることができる。
点字ピンディスプレイやその他の触覚インタフェースを使用している利用者は、触覚からテキストの手がかりを読み取れる。
達成基準 1.4.1の事例
必須項目を示すために色とテキストを用いている入力フォーム
ある入力フォームには、必須項目と任意項目の両方がある。 入力フォームの先頭にある説明文には、必須項目のラベルが赤字になっていて、「必須」という代替テキストのあるアイコンも付いている。 赤字とアイコンの両方が、フォームのテキストフィールドとプログラムで関連付けられているので、支援技術の利用者はどれが必須項目なのかが判断できる。
試験
学生は、化学化合物の SVG 画像を見て、図に使用されている色や数字に基づいて、存在する化学の要素を識別する。各要素に関連付けられたテキストによる代替は、要素の色に名前を付けて、図で要素の位置を示している。色を知覚できない学生は、クラスメートと同じように、化合物に関する同じ情報を得る。（この達成方法は、ガイドライン 1.1 のレベル A も満たす）
使用不可になっているフォーム要素
マークアップ又はスクリプトによって使用不可になっているフォーム要素は、ユーザエージェントによってグレー表示され、使用できない。使用不可の状態では、これらの要素はフォーカスを受け取らない。支援技術は、使用不可の状態になっている要素をプログラムが解釈することが可能であろう。色の変化及びフォーカスがあたらないことによって、コントロールの状態に関する情報を視覚的に提供している。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準1.4.1の達成方法及び不適合事例 - 色の使用
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
達成基準を満たすことのできる達成方法
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の達成方法（又は、達成方法の組合せ）がある。
1.4.1 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 1.4.1のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準1.4.1に適合していないとみなした、よくある不適合事例である。
音声の制御:
達成基準 1.4.2 を理解する
1.4.2 音声の制御:
ウェブページ上にある音声が自動的に再生され、3秒より長く続く場合、その音声を一時停止又は停止するメカニズム、もしくはシステム全体の音量レベルに影響を与えずに音量レベルを調整できるメカニズムが利用できる。
(レベル A)
注記: この達成基準を満たさないコンテンツでは、利用者がそのウェブページ全体を使用できない恐れがあるため、ウェブページ上のすべてのコンテンツは他の達成基準を満たすために用いられているか否かにかかわらず、この達成基準を満たさなければならない。達成基準 5: 非干渉を参照。
この達成基準の意図
スクリーンリーダーを使用している利用者は、同時に他の音声が再生されていると、スクリーンリーダーによる読み上げ音声が聞き取りづらくなる。スクリーンリーダーの読み上げ音声が、（今日ではほとんどがそうであるように）ソフトウェアをベースにしたもので、システム全体と同じ音量コントロールによって制御されていると、この状況はさらに悪化する。そのため、重要なのは、利用者が背景音の再生をオフにできることである。注記： 音量コントロールには、その音量をゼロまで下げられることを含む。
注記: 利用者があるページを閲覧し始めた時に音声が自動再生されると、スクリーンリーダーの利用者はその音声を停止させるメカニズムを探しづらくなることがある。なぜなら、スクリーンリーダーの利用者は、読み上げ音声を聞きながらナビゲートしており、自動的に開始した音声がそのナビゲーションを邪魔してしまうかもしれないからである。そのため、WCAG ワーキンググループでは、音声を自動的に再生しないことを推奨し（特に、3秒よりも長く続く場合）、利用者がそのページを閲覧し始めた後、利用者によって音声の再生を停止させるのではなく、利用者の起こしたアクションによって音声が再生されることを勧める。
達成基準1.4.7 小さな背景音、又は背景音なしを理解するも参照のこと。
達成基準1.4.2の具体的なメリット
スクリーンリーダーの利用者が、他に再生されている音声に邪魔されることなく、スクリーンリーダーの音声を聞くことができるようになる。これは、難聴の利用者及びシステム全体の音量制御を用いるスクリーンリーダーの利用者にとって（システム全体の音量を下げて、スクリーンリーダーの音量を上げることができないため）特に重要である。
この達成基準はまた、音声が再生されているとき、（テキストを含む）視覚的なコンテンツに集中することが困難な利用者に対しても役に立つ。
達成基準 1.4.2の事例
ページを開いたときに、音声ファイルの再生が自動的に開始される。しかし、利用者が、そのページの先頭にある「音を消す」というリンクを選択することで、その音声を停止させることができる。
音声を再生するFlashのスプラッシュページがあり、3秒以内にその音声が停止する。
音声を自動的に再生するFlashのスプラッシュページの先頭に、利用者が音声を停止可能にするコントロールがある。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準1.4.2の達成方法及び不適合事例 - 音声の制御
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
1.4.2 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 1.4.2のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準1.4.2に適合していないとみなした、よくある不適合事例である。
重要な用語
- メカニズム (mechanism)
結果を得るためのプロセス又は手法。
注記 1:
メカニズムは、コンテンツ内で明示的に提供されることもあれば、プラットフォーム又は支援技術を含むユーザエージェントで提供されるものに 依存することもある。
注記 2:
メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。
コントラスト (最低限) :
達成基準 1.4.3 を理解する
1.4.3 コントラスト (最低限) :
テキスト及び文字画像の視覚的提示に、少なくとも 4.5:1 のコントラスト比がある。ただし、次の場合は除く:
(レベル AA)
大きな文字:
サイズの大きなテキスト及びサイズの大きな文字画像に、少なくとも 3:1 のコントラスト比がある。
付随的: テキスト又は文字画像において、次の場合はコントラストの要件はない。アクティブではないユーザインタフェース コンポーネントの一部である、純粋な装飾である、誰も視覚的に確認できない、又は重要な他の視覚的なコンテンツを含む写真の一部分である。
ロゴタイプ:
ロゴ又はブランド名の一部である文字には、最低限のコントラストの要件はない。
この達成基準の意図
この達成基準の意図は、中度のロービジョンの利用者（コントラストを強化する支援技術を使用していない利用者）がテキストを読めるように、テキストとその背景とのコントラストを十分に確保することである。色弱ではない利用者にとっては、色相及び彩度が文字の読みやすさに影響を与えることはほとんど又は全くないことが読解力による評価の結果からわかっている (Knoblauch et al., 1991)。色弱は、輝度コントラストに多少の影響を及ぼす可能性がある。そのため、この勧告では、色弱の利用者にとってもテキストと背景のコントラストが十分になるように、色が主要因とならないような方法でコントラストを算出している。
装飾を目的にしていて、情報を何も伝えていないテキストは対象外である。例えば、背景でランダムに使われている語句があり、その語句を並び替えたり置き換えたりしても意味が変わらないのであれば、それは装飾を目的にしたものであり、この達成基準を満たす必要はない。
サイズの大きいテキスト及び文字の線幅が広めのテキストは、低めのコントラストでも読みやすい。そのため、サイズの大きいテキストに対するコントラスト要件は、低めになっている。そのため、コンテンツ制作者は、特にタイトルなど、ページのデザインにサイズの大きいテキストを用いる際は、より多くの色の中から選ぶことができる。18 ポイントのテキスト又は太字で 14 ポイントのテキストが、低めのコントラストで十分なサイズの大きさとしている（「関連リソース」にある "The American Printing House for the Blind Guidelines for Large Printing and The Library of Congress Guidelines for Large Print"を参照のこと）。「18 ポイント」及び「太字」は、異なるフォントでは異なる意味合いを持つこともあるが、特別に細い線のフォント又は一般的ではないフォントを除き、十分である。とても多くの様々なフォントがあるため、ここでは一般的な基準を用いることとして、用語集にて装飾的なフォント又は細い線のフォントに関する注記を付けている。
注記：画像編集アプリケーションによって標準となるピクセル密度が異なるため（例：72 PPI または 96 PPI）、文字を特定のサイズで提示する際には、画像編集アプリケーションでのフォントのポイントサイズを特定することは当てにならない。サイズの大きな文字の画像を作成する際、コンテンツ制作者は画面に表示される画像の文字が、おおよそ本文のテキストの標準サイズの1.2emと1.5emまたは120％と150％に相当することを確認すべきである。例えば、72 PPIの画像の場合、画像でサイズの大きな文字（アルファベットで14ptと18pt）とするにはコンテンツ制作者は約19ptと24ptのフォントサイズを用いる必要がある。
また、前述のテキストに対するコントラストの要件は、達成基準 1.4.3 で述べられているように、画像化された文字（ピクセルで描画され、画像フォーマットで保存された文字）にも適用される。
この要件は、画像化された文字が情報を伝えることを目的としている状況に対して適用される。例えば、写真の中にたまたま入っていた街頭の標識にあるような付随的なテキストは、対象外である。また、何らかの理由で、すべての利用者が視覚的に確認できないことを意図しているテキストも対象外である。企業のロゴなどの定型化されたテキストは、代替テキストの内容を含むことを、それが保証する、あるいは保証しないかもしれないが、そのページでの機能の観点から取り扱われるべきである。ロゴとロゴタイプを超えた企業の視覚的なガイドラインは例外に含まれない。
この達成基準には、「意味のあるその他の視覚的なコンテンツを含む写真の一部分である」という例外がある。この例外は、文字の写っている写真と、特定の見た目にするためにテキストと置き換えられた画像化された文字とを区別することを意図している。
注記 1:
認知の障害のある利用者は、低いコントラストの色の組合せ又は色相を必要とすることがある。そのため、コンテンツ制作者にコンテンツの前景色と背景色を調節するメカニズムを提供することを認め、それを推奨する。選択可能な組合せの中には、この達成基準にあるコントラストよりも低いレベルのコントラストがあってもよい。もし、この達成基準に合わせて設定したデフォルトの値に戻すことのできるメカニズムが提供されていれば、その場合はこの達成基準に反していることにはならない。
注記 2:
画像化された文字は、画素に分解されてしまうので、テキストと同じようにきれいに拡大することができない。また、画像化された文字の前景と背景のコントラスト及び色の組合せを変更できることを必要とする利用者もいるが、テキストよりも困難である。そのため、可能な限り、テキストを用いることを勧めるが、それができない場合には、さらに高い解像度の画像を提供することを考慮すること。
注記 3:
最低限のコントラスト（1.4.3）達成基準は、ページ内のテキストに適用されるが、プレースホルダーテキストもページ内のテキストである。プレースホルダーテキストを使用するのであれば、十分なコントラストを提供する必要がある。
この達成基準はテキストだけに適応されるが、図表やグラフ、また別の非テキストベースの情報でも同様の問題が起こる。コンテンツはより多くの利用者が確実に情報にアクセスできるようにするため、十分なコントラストを確保すべきである。
達成基準1.4.6 コントラスト (高度) を理解するも参照のこと。
コントラスト比を定めた論理的根拠
3：1 のコントラスト比は、[ISO-9241-3]及び [ANSI-HFES-100-1988]によって推奨されている、標準的なテキスト及び視力における最低限のレベルである。4.5：1 のコントラスト比は、この達成基準では、中度の弱い視力、先天的又は後天的な色弱、あるいは通常、加齢に伴うコントラスト感度の衰えに起因する、コントラスト感度の低下を考慮している。
論理的根拠は、次のことに基づいている。a) ANSI標準規格（American National Standards Institute：米国の国家規格）では、最低限の許容可能なコントラストとして、コントラスト比 3：1 を採用しており、b）集団内では、20/40 の視力は、おおよそ 1.5 のコントラスト感度低下と関連付けられているという経験的事実がある[ARDITI-FAYE]。したがって、視力が 20/40 の利用者は、「3 * 1.5 = 4.5：1」のコントラスト比を必要とするであろう。類似した経験的事実及び同じ論理に沿うと、視力が 20/80 の利用者は、約 7:1 のコントラスト比を必要とすることになる。
色相は、色弱の利用者（先天的及び後天的の両方）によって知覚のされ方が様々なため、色及び相対的な輝度コントラストが色弱ではない利用者とは異なる。このため、有効なコントラスト及び読みやすさは、色弱の利用者に対しては異なったものになる。しかし、色弱は多様であるため、（コントラストのために）量的なデータに基づいて有効で一般的な色の組合せを規定することは、適切であるとはいえない。色の知覚に依存しないコントラストを要求することにより、十分な輝度コントラストを要求することが、この問題に対応している。幸いにも、輝度の寄与のほとんどは、分光感度において大部分が重なる中波長及び長波長の受容体からくるものである。その結果、有効な輝度コントラストが一般的に特定の色弱に関係なく計算できる。ただし、赤色を知覚しにくい1型2色覚の利用者に対して、暗い色（一般的に黒のようである）に対して主に波長の長い色を用いることは除く（この理由から、WCAG ワーキンググループは、黒の背景に赤の前景を使うことを避けるという参考達成方法を提供している）。より詳細な情報は、[ARDITI-KNOBLAUCH]
[ARDITI-KNOBLAUCH-1996]
[ARDITI]を参照のこと。
レベル AA で 4.5：1 のコントラスト比を選択したのは、20/40 程度まで視力の低下した利用者におけるコントラスト感度の低下を補うためである（20/40 は約 4.5：1 という計算になる）。また、20/40 は、80歳前後の高齢者の標準的な視力として、よく報告される視力である[GITTINGS-FOZARD]。
レベル AAA で 7：1 のコントラスト比を選択したのは、20/80 程度まで視力の低下した利用者におけるコントラスト感度の低下を補うためである。より視力の弱い利用者は、通常は支援技術を使用して、コンテンツを利用している（その支援技術には、コントラスト増強と画面拡大の機能が搭載されている）。そのため、7：1 というコントラスト比は、一般的に支援技術を使用していないロービジョンの利用者のコントラスト感度の低下を補い、同様に色弱の利用者に対してもコントラストを向上させる。
計算式に関する注記
RGB 値の非線形から線形への変換は、IEC/4WD 61966-2-1[IEC-4WD]及び "A Standard Default Color Space for the Internet - sRGB"[sRGB]に基づいている。
コントラストの計算式（L1/L2）は、[ISO-9241-3]及び[ANSI-HFES-100-1988]の標準規格に基づいている。
ANSI/HFS 100-1988 は、L1 及び L2 の計算に含めるために、周辺光からの寄与を必要としている。用いている 0.05 という値は、[IEC-4WD]の Typical Viewing Flare 及び論文[sRGB](M. Stokes et al) に基づいている。
この達成基準及びその定義では、ウェブコンテンツが光自体を発するわけではないという事実を反映するために、「輝度」ではなく、「コントラスト比」及び「相対輝度」という用語を用いている。コントラスト比は、コンテンツが表示されたときに生じる相対輝度の評価基準（尺度）を与える（それは、比率なので、無次元である）。
注記 1:
コントラスト比を用いてウェブコンテンツのコントラストを分析するツールの一覧は、関連リソースを参照のこと。
注記 2:
キーボード・フォーカスを示すための達成方法については、
達成基準2.4.7 フォーカスの可視化を理解するも参照のこと。
注記 3:
コンテンツを閲覧するのに特定の色の組合せを必要とする利用者が、好みの色の配置でコンテンツを閲覧できるようにするために、コンテンツ制作者がページの特定の部分に色を指定しないことが役に立つことがある。より詳細な情報は、
達成基準1.4.5 文字画像を理解するを参照のこと。
達成基準 1.4.3の事例
(none currently documented)
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準1.4.3の達成方法及び不適合事例 - コントラスト (最低限)
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
達成基準を満たすことのできる達成方法
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の達成方法（又は、達成方法の組合せ）がある。
1.4.3 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
G156: 一般に入手可能なユーザエージェントで、テキストのブロックの前景及び背景を変更できるウェブコンテンツ技術を使用する
模様のついた背景色にテキストを重ねるためにより高いコントラストの値を用いる（リンク追加予定）
画像化された文字の代わりにUnicodeテキストとスタイルシートを用いる（リンク追加予定）
図表の線に、より高いコントラストの値を用いる（リンク追加予定）
赤と黒の組み合わせによる文字と背景色には、さらに大きなコントラストレベルを用いる（リンク追加予定）
主に中間のスペクトル要素からなる明るい要素とスペクトルの両端（青と赤の波長）からなる暗い要素で構成された色を用いる
両端のコントラストではなく黒文字に白の背景よりも明るいパステルの背景色を用いる（リンク追加予定）
テキストのコントラストを満たしているシンプルな線で描かれたアイコンを使う（リンク追加予定）
グラフやチャートに十分なコントラストを提供する（リンク追加予定）
デフォルトの表現に3:1のコントラスト比又はそれ以上を用いる（リンク追加予定）
空のテキストフィールドに十分な色のコントラストを提供する（リンク追加予定）
達成基準 1.4.3のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準1.4.3に適合していないとみなした、よくある不適合事例である。
重要な用語
- コントラスト比 (contrast ratio)
(L1 + 0.05) / (L2 + 0.05) ここでは、
注記 1:
コントラスト比は、1～21の範囲になりうる (通常は、1:1～21:1 と記述される)。
注記 2:
コンテンツ制作者は、テキストのレンダリング (例: フォントのスムージングやアンチエイリアス) に関する利用者の設定を制御できないため、アンチエイリアスをオフにした状態でテキストのコントラスト比を評価してもよい。
注記 3:
達成基準 1.4.3 及び 1.4.6 の目的上、コントラストは通常の使用においてテキストがレンダリングされるときに指定されている背景色に対して測定する。もし背景色の指定がない場合は、背景色には白を想定する。
注記 4:
背景色は、テキストが通常の使用においてレンダリングされるときに背景となるコンテンツの色として指定された色である。テキストの色は指定されているが背景色が指定されていない場合、利用者のデフォルトの背景色は未知であり、コントラストが十分かどうかを評価することができないため、問題がある。同じ理由で、背景色が指定されているがテキストの色が指定されていない場合も問題がある。
注記 5:
文字の周囲に縁取りがある場合、その縁取りがコントラストを強めることもあり、文字とその背景色におけるコントラストの計算に用いられる。文字の周囲の細い縁取りは文字として扱われる。文字の周囲の太い縁取りが、光彩のようになって、文字の内側の細部を塗りつぶしていれば、背景色として考慮されることになる。
注記 6:
WCAG に適合しているか判断する場合は、典型的な提示において隣接するであろうと制作者が想定するコンテンツで指定された色の組み合わせについて評価しなければならない。制作者は、ユーザエージェントによる色の変更などのように通常とは異なる提示を考慮する必要はない。ただし、それが制作者のコードによって起こる場合は除く。
- サイズの大きな (テキスト) (large scale (text))
少なくとも18ポイント、又は14ポイントの太字。あるいは、中国語、日本語、及び韓国語 (CJK) のフォントは、それと同等の文字サイズ。
注記 1:
特別に細い線のフォント、又は文字の形が分かりにくくなるような独特の見た目や特徴のあるフォントは、コントラストが低い場合に特に読みづらい。
注記 2:
ここでいう文字サイズは、コンテンツが提供される際のサイズであり、利用者によるサイズ変更は含まれない。
注記 3:
利用者が目にする文字の実際のサイズは、コンテンツ制作者が指定したサイズと利用者のディスプレイあるいはユーザエージェントの設定の両方に依存している。多くの主流となっている本文テキストで用いられるフォントにおいて、14ポイントと18ポイントは、1.2emと1.5em、又は、 (本文フォントが100％であると仮定して) デフォルトサイズの120%と150%に、おおよそ同等である。しかし、制作者は、使用する特定のフォントについて、このことをチェックしておく必要がある。フォントが相対単位で定義されている時、実際に表示される文字サイズのポイント数は、ユーザエージェントによって計算される。この達成基準について評価する時には、文字サイズのポイント数は、ユーザエージェントから取得されるべきであり、又はユーザエージェントが行うフォントの計算基準に基づいて計算するべきである。ロービジョンの利用者については、自分で適切な設定を選択することを想定している。
注記 4:
フォントサイズを指定せずにテキストを用いる際は、サイズを指定していないテキストに対して主要ブラウザで用いられる最小のフォントサイズをそのテキストのサイズとみなすのが妥当であろう。もし、レベル1の見出しが、主要なブラウザで14ポイントの太字あるいはそれ以上のサイズでレンダリングされるならば、それは「サイズの大きな」テキストであると考えてよい。相対的な拡大縮小は、同様の方法でそのデフォルトのサイズから算出することが可能である。
注記 5:
半角の英数字のテキストにおける18ポイント及び14ポイントのサイズは、拡大印刷の最小サイズ (14ポイント) と標準的な大きい文字サイズ (18ポイント) に基づいている。例えば、CJK言語のようなその他の文字については、「同等な」サイズはその言語での拡大印刷の最小サイズと拡大印刷でその次に大きな標準のサイズとなる。
- テキスト (text)
プログラムによる解釈が可能な文字の並びで、自然言語で何かを表現しているもの。
- ユーザインタフェース コンポーネント (user interface component)
コンテンツの一部分で、特定の機能を実現するための単一のコントロールとして利用者が知覚するもの。
注記 1:
複数のユーザインタフェース コンポーネントが、単一のプログラム要素で実装されることもある。ここでいうコンポーネントは、プログラムの手法と結びついたものではなく、利用者が別々のコントロールとして知覚するものを指す。
注記 2:
ユーザインタフェース コンポーネントには、フォーム要素、リンクだけでなく、スクリプトで生成されるコンポーネントが含まれる。
事例: アプレットには、コンテンツ内を行単位、ページ単位、又はランダムアクセスで移動するために用いられる「コントロール」がある。これらには、いずれも名前 (name) を割り当て、個別に設定できるようにする必要があるため、それぞれが「ユーザインタフェース コンポーネント」となる。
- 文字画像 (image of text)
特定の視覚的効果を得るために非テキスト形式 (例えば画像) でレンダリングされたテキスト。
注記: テキスト以外の部分が重要な視覚的コンテンツである場合、画像に含まれるテキストは該当しない。
- 純粋な装飾 (pure decoration)
見栄えのためだけのもので、情報は提供せず、機能性も備えていないもの。
注記: テキストが純粋な装飾といえるのは、単語を並べ替え、又は置き換えても意図が変わらないときだけである。
事例: 背景にとても淡い文字で単語がランダムに並んでいる辞書の表紙。
テキストのサイズ変更:
達成基準 1.4.4 を理解する
この達成基準の意図
この達成基準の意図は、軽度の視覚障害のある利用者が、例えば画面拡大ソフトのような支援技術を使わずにそのまま読むことができるように、テキストベースのコントロールを含む視覚的に描画されるテキスト（ [ASCIIのようにデータとしての属性を持ち続ける文字ではなく] 視覚的に見ることができるように表示された文字）を問題なく拡大可能にすることである。利用者がメリットを享受できるのは、ウェブページ上のすべてのコンテンツを拡大できることだが、テキストが最も重要な意味を持つ。
コンテンツを拡大縮小することは、第一にユーザエージェントが果たすべき役割である。UAAG 1.0 チェックポイント 4.1を満たしているユーザエージェントは、利用者がテキストの拡大及び縮小を設定できるようにしている。コンテンツ制作者が果たすべき役割は、ユーザエージェントがコンテンツを効果的に拡大縮小できるように、ウェブコンテンツを制作することである。コンテンツ制作者は、コンテンツがユーザエージェントによるテキストベースのコントロールを含むテキストのサイズ変更を妨げていないことを確認すること、又はテキストのサイズ変更あるいはレイアウトの変更を直接可能にすることによって、この達成基準を満たすことができる。一つの例は、様々なスタイルシートを適用することができるサーバーサイドのスクリプトによって直接可能にすることができるかもしれない。
利用者が、拡大機能を持つユーザエージェントを利用できない場合、制作者は、HTML コンテンツに対するこの達成基準を満たすためにユーザエージェントに依存することはできない。例えば、利用者が、IE6を使用する必要のある環境で作業をしている場合である。
ユーザエージェントが拡大縮小機能を提供していないウェブコンテンツ技術をコンテンツ制作者が使用している場合、拡大縮小機能を直接提供すること、又はユーザエージェントの提供する機能と連携するコンテンツを提供することが、コンテンツ制作者の果たすべき役割である。ユーザエージェントが拡大縮小機能を提供していなくても利用者がテキストの大きさを変更できる場合、テキストの大きさを変更してもコンテンツが利用できる状態のままであるようにすることが、コンテンツ制作者の果たすべき役割となる。
ラベルとして機能し、コンテンツにアクセスするために利用者によるアクティベーションを必要とするいくつかのユーザインタフェース コンポーネントは、ラベル コンテンツを収容するのに十分な幅がない。例えば、ウェブメール アプリケーションにおける件名のカラムは、全ての実行可能な件名の見出しを収容するために十分な幅でなくてもよいが、件名の見出しをアクティブにすることで、利用者は、完全な件名の見出しを伴う完全なメッセージを得る。ウェブベースのスプレッドシートでは、カラム内に表示するには長すぎるセルのコンテンツは切り落とされ、そのセルの全コンテンツは、セルがフォーカスを受け取ったとき、利用者に提供される。ユーザインタフェース コンポーネントのコンテンツは、利用者がカラムの幅の幅を変更することができるユーザインタフェースでも同様に、広くなるかもしれない。コンポーネントの完全なコンテンツが、フォーカスを置く又は利用者のアクティベーションの後に利用可能であり、この情報にアクセスすることができることが示され、それが切り捨てられるという事実の他にいずれかの方法で利用者へ提供される場合、切り捨ては許容される。
コンテンツが200％まで、言い換えれば、幅と高さが2倍になるまで、拡大可能であれば、そのコンテンツはこの達成基準を満たしていることになる。コンテンツ制作者はそれ以上の拡大をサポートしてもよいが、コンテンツをそれ以上拡大していくにつれて、アダプティブ・レイアウトはユーザビリティの問題を引き起こす可能性がある。例えば、語句の横幅が広くなりすぎると、省略されてしまうことになる。レイアウト上の制約によって、拡大していったときに、テキストが他のコンテンツと重なり合ってしまうこともある。あるいは、文章中の一つの単語だけが各行にある状態になると、その文章が縦に表示されてしまって読みづらくなってしまう。
WCAGワーキンググループは、広範囲に及ぶデザイン及びレイアウトをサポートできるという点と、最小の拡大率が200％である古い画面拡大ソフトを補完するという点から、200％が妥当ではないかと考えている。200％を超えると、拡大（テキスト、画像、及びレイアウト領域のサイズを変更し、横スクロールと縦スクロールを必要とする可能性のある大きなキャンバスを作り出す）のほうが、テキストのサイズ変更よりも効果的かもしれない。200％を超える状況では、拡大機能専用の支援技術が通常は使用されており、コンテンツ制作者が利用者に直接提供する機能よりもより良いアクセシビリティを提供することができる。
注記: 画像化された文字は、画素に分解されてしまうので、テキストと同じように拡大できない。そのため、可能な限り、テキストを用いることを勧める。また、画像化された文字の前景と背景のコントラスト及び色の組合せを変更することを必要とする利用者もいるが、テキストよりも困難である。
達成基準1.4.8 視覚的提示を理解するも参照のこと。
達成基準 1.4.4の事例
視覚障害のある利用者が、ウェブページのテキストの大きさをブラウザで 1 em から 1.2 em に変更している。その利用者は小さいテキストを読むことはできないが、大きいテキストは読むことができる。テキストの大きさが大きくなっても、ページ上のすべての情報は表示されている。
ページを拡大縮小するためのコントロールがウェブページにある。異なる設定を選択すると、そのサイズで最適なデザインとなるようにページのレイアウトが変更される。
利用者が、ユーザエージェントの拡大縮小機能を使って、コンテンツのサイズを変更している。すべてのコンテンツは均一に拡大し、必要に応じてユーザエージェントがスクロールバーを提供している。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準1.4.4の達成方法及び不適合事例 - テキストのサイズ変更
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
1.4.4 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 1.4.4のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準1.4.4に適合していないとみなした、よくある不適合事例である。
重要な用語
- (この文書で用いられている) 支援技術 (assistive technology (as used in this document))
ユーザエージェントとして機能する、又は主流のユーザエージェントと一緒に機能するハードウェア及び/あるいはソフトウェアで、主流のユーザエージェントで提供されている機能以上の機能を、障害のある利用者の要求を満たすために提供するもの。
注記 1:
支援技術が提供する機能としては、代替の提示 (例: 合成音声や拡大表示したコンテンツ)、代替入力手法 (例: 音声認識)、付加的なナビゲーション又は位置確認のメカニズム、及びコンテンツ変換 (例: テーブルをよりアクセシブルにするもの) などを挙げることができる。
注記 2:
支援技術は、API を利用、監視することで、主流のユーザエージェントとデータやメッセージのやりとりをすることが多い。
注記 3:
主流のユーザエージェントと支援技術との区別は、絶対的なものではない。多くの主流のユーザエージェントは、障害者を支援する機能を提供している。基本的な差異は、主流のユーザエージェントが障害のある人もない人も含めて、広く多様な利用者を対象にしているのに対し、支援技術は、特定の障害のある利用者という、より狭く限られた人たちを対象にしているということである。支援技術により提供される支援は、対象とする利用者に特化した、よりニーズに適したものである。主流のユーザエージェントは、プログラムオブジェクトからのウェブコンテンツの抽出、マークアップの識別可能な構造への解釈といった、重要な機能を支援技術に対して提供する場合がある。
事例: この文書の文脈において重要な支援技術としては、以下のものが挙げられる:
画面拡大ソフト及びその他の視覚的な表示に関する支援技術。視覚障害、知覚障害、及び読書困難などの障害のある人が、レンダリング後のテキスト及び画像の視覚的な読みやすさを改善するために、テキストのフォント、サイズ、間隔、色、音声との同期などを変更するのに使用している。
スクリーンリーダー。全盲の人がテキスト情報を合成音声あるいは点字で読み取るために使用している。
音声変換ソフトウェア。認知障害、言語障害、及び学習障害のある人が、テキストを合成音声に変換するために使用している。
音声認識ソフトウェア。何らかの身体障害のある利用者が使用することがある。
代替キーボード。特定の身体障害のある人がキーボード操作をシミュレートするのに使用している (ヘッドポインタ、シングルスイッチ、呼気・吸気スイッチ、及びその他の特別な入力デバイスを使った代替キーボードを含む)。
代替ポインティングデバイス。特定の身体障害のある人がマウスポインタとボタンの動きをシミュレートするのに使用している。
- キャプション (captions)
そのメディアのコンテンツを理解するのに必要な、会話及び会話でない音声情報に対する、同期した視覚、又はテキストによる代替。
注記 1:
キャプションは会話のみの字幕と似ているが、会話の内容だけを伝えるのではなく、その番組の内容を理解するために必要な効果音、音楽、笑い声、話者の特定、位置などを含む、会話でない音声情報と同等の内容も伝える点が異なる。
注記 2:
クローズドキャプションは、音声情報と同等の内容で、プレーヤーによっては表示／非表示を切り替えることができるものを指す。
注記 3:
オープンキャプションは、非表示にできないキャプションである。例えば、キャプションが同等の視覚化された文字画像で映像に埋め込まれている場合である。
注記 4:
キャプションは、映像に含まれる情報を分かりにくくしたり遮ったりすべきではない。
注記 5:
国によっては、キャプションは "subtitle" と呼ばれている。
訳注： subtitleには、「字幕」の意がある。日本では、キャプションのことを一般に字幕と呼ぶことが多い。
注記 6:
音声解説にキャプションをつけることもできるが、つける必要はない。なぜなら、音声解説は既に視覚的に提示されている情報の説明だからである。
- テキスト (text)
プログラムによる解釈が可能な文字の並びで、自然言語で何かを表現しているもの。
- 文字画像 (image of text)
特定の視覚的効果を得るために非テキスト形式 (例えば画像) でレンダリングされたテキスト。
注記: テキスト以外の部分が重要な視覚的コンテンツである場合、画像に含まれるテキストは該当しない。
文字画像:
達成基準 1.4.5 を理解する
1.4.5 文字画像: 使用している技術で意図した視覚的提示が可能である場合、文字画像ではなくテキストが情報伝達に用いられている。ただし、次に挙げる場合を除く:
(レベル AA)
注記: ロゴタイプ (ロゴ又はブランド名の一部である文字) は必要不可欠なものであると考えられる。
この達成基準の意図
この達成基準の意図は、テキストによる特定の視覚的な表現を必要とする方へ、必要に応じてテキスト表現を調整できるように、望ましいデフォルトのビジュアルプレゼンテーションを達成することができる技術をコンテンツ制作者に推奨することである。テキストに、特定のフォントサイズ、前景色及び背景色、書体、行間、又は配置を求める利用者を含む。
もし、テキストを用いて同じ視覚的な効果が得られるのであれば、コンテンツ制作者は、情報を提示するのに画像を用いるのではなく、テキストを用いるべきである。もしも何らかの理由により、コンテンツ制作者がテキストの書式を整えても同じ効果が得られない場合、その効果が一般に入手可能なユーザエージェントでは確実に提示できない場合、又は、この達成基準を満たすウェブコンテンツ技術を用いることが達成基準1.4.4などの他の達成基準を満たすことの妨げになる場合には、画像化された文字を使うことができる。例としては、書体のサンプル、ロゴタイプ、ブランドなどのように、伝える情報にとってそのテキストの特定の表現が必要不可欠な場合を含む。また、画像化された文字は、広く普及していない又はコンテンツ制作者が再配布する権利を持っていない特定の書体を用いる目的で使われることもある。あるいは、そのテキストがすべてのユーザエージェントでアンチエイリアスをかけた状態になるようにする目的で使われることもある。
利用者が画像化された文字を自分の好みに合わせてカスタマイズできる場合にも、画像化された文字を用いてもよい。
「文字画像 (image of text)」の定義には、「注記: テキスト以外の部分が重要な視覚的コンテンツである場合、画像に含まれるテキストは該当しない。」とある。例えば、テキストのみよりも視覚的に重要な情報を伝えるグラフ、スクリーンショット、ダイアグラムのような画像が含まれる。
この達成基準を満たすための達成方法は、達成基準 1.4.9 と同じである。ただし、その視覚的な表現がコンテンツ制作者の用いるウェブコンテンツ技術で実現可能な場合に適用されるという点だけが異なる。達成基準 1.4.9 では、利用者がカスタマイズできるときのみ、十分な達成方法が適用される。
達成基準1.4.9 文字画像 (例外なし) を理解するも参照のこと。
達成基準 1.4.5の事例
スタイルを指定した見出し
特定のフォント及びサイズで見出しを提示するために、ビットマップ画像を用いるのではなく、コンテンツ制作者はCSSを用いて同じ見栄えにしている。
動的に生成された画像
あるウェブページでは、サーバーサイドのスクリプトを用いてテキストを画像として提示している。そのページには、利用者が生成される画像のフォントサイズ及び前景色と背景色を調節することのできるコントロールがある。
引用
あるウェブページに引用がある。その引用部分自体は、イタリックのテキストで、左側をインデントした状態で提示されている。その引用した部分の人名が、引用の下に1.5倍の行間を空けて、左側からさらにインデントした状態になっている。そのテキストの配置、行間スペースの指定、そしてテキストの書体・サイズ・色及び装飾には、CSS を用いている。
ナビゲーション
ウェブページに、ナビゲーション・リンクのメニューがあり、アイコンとテキストの両方でリンク先を示している。CSSを用いて、テキストの書体、サイズ、前景色及び背景色、そしてナビゲーション・リンク間の間隔を指定している。
文字を含んだロゴ
あるウェブサイトには、各ウェブページの左上のコーナーに組織のロゴがある。そのロゴには、ロゴタイプ（ロゴの一部又は全部に文字）がある。文字の視覚的な表現は、そのロゴのアイデンティティに不可欠であり、その文字の特徴を変更することができないGIF画像である。そして、その画像には、代替テキストがある。
書体のサンプル
ウェブページに、特定の書体に関する情報がある。その書体を他の書体に置き換えると、サンプルとしての目的が損なわれてしまう。そのサンプルは、その文字の特徴を変更することができない JPEG 画像である。そして、その画像には代替テキストがある。
手紙の写し
ウェブページに、手紙の原本を描写したものがある。オリジナルの体裁でその手紙を見せることが、その手紙の書かれた時代に関する情報を伝える上で不可欠である。その手紙は、その文字の特徴を変更することができない GIF 画像である。そして、その画像には、代替テキストがある。
記号的な文字
利用者がテキストのブロックを入力できるフォームがある。そのフォームは、テキストのスタイル指定やスペルチェックなどの機能のボタンをたくさん提供している。ボタンの中には文字を用いたものがあり、その文字に自然言語で何かを表現する並び順はない。例えば、フォントを太字にする機能には"B"、テキストをイタリックにする機能には"I"、そしてスペルチェックの機能には"ABC"が使われている。その記号的な文字は、その文字の特徴を変更することができない GIF 画像としてボタンになっている。そして、そのボタンには代替テキストがある。
画像化された文字のカスタマイズ可能なフォント設定
あるウェブサイトでは、利用者がフォントを設定できるようになっており、このウェブサイトのすべての画像化された文字は、その設定に基づいて提供される。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準1.4.5の達成方法及び不適合事例 - 文字画像
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
1.4.5 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
非テキストコンテンツ向けの一般的な達成方法
情報を提供する非テキストコンテンツを識別する（リンク追加予定）
達成基準 1.4.5のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準1.4.5に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
重要な用語
- テキスト (text)
プログラムによる解釈が可能な文字の並びで、自然言語で何かを表現しているもの。
- 必要不可欠 (essential)
もし取り除いてしまうと、コンテンツの情報あるいは機能を根本的に変えてしまい、かつ、適合する他の方法では情報及び機能を実現できない。
- 文字画像 (image of text)
特定の視覚的効果を得るために非テキスト形式 (例えば画像) でレンダリングされたテキスト。
注記: テキスト以外の部分が重要な視覚的コンテンツである場合、画像に含まれるテキストは該当しない。
- 視覚的なカスタマイズ (visually customized)
フォント、サイズ、色、及び背景を設定できること。
コントラスト (高度) :
達成基準 1.4.6 を理解する
1.4.6 コントラスト (高度) :
テキスト及び文字画像の視覚的提示には、少なくとも 7:1 のコントラスト比がある。ただし、次の場合は除く:
(レベル AAA)
大きな文字:
サイズの大きなテキスト及びサイズの大きな文字画像には、少なくとも 4.5:1 のコントラスト比がある。
付随的: テキスト又は文字画像において、次の場合はコントラストの要件はない。アクティブではないユーザインタフェース コンポーネントの一部である、純粋な装飾である、誰も視覚的に確認できない、又は重要な他の視覚的なコンテンツを含む写真の一部分である。
ロゴタイプ:
ロゴ又はブランド名の一部である文字には、最低限のコントラストの要件はない。
この達成基準の意図
この達成基準の意図は、（コントラストを強化する支援技術を使用していない）中度のロービジョンの利用者がテキストを読めるように、テキストとその背景とのコントラストを十分に確保することである。色弱ではない利用者にとっては、読解力によって評価されるように (Knoblauch et al., 1991)、色相及び彩度が文字の読みやすさに影響を与えることはほとんど又は全くない。色弱は、輝度コントラストに多少の影響を及ぼす可能性がある。そのため、この勧告では、色弱の利用者にとってもテキストと背景のコントラストが十分になるように、色が主要因とならないような方法でコントラストを算出している。
装飾を目的にしていて、情報を何も伝えていないテキストは対象外である。例えば、背景でランダムに使われている語句があり、その語句を並び替えたり置き換えたりしても意味が変わらないのであれば、それは装飾を目的にしたものであり、この達成基準を満たす必要はない。
サイズの大きいテキスト及び文字の線幅が広めのテキストは、低めのコントラストでも読みやすい。そのため、サイズの大きいテキストに対するコントラスト要件は、低めになっている。そのため、コンテンツ制作者は、特にタイトルなど、ページのデザインにサイズの大きいテキストを用いる際は、より多くの色の中から選ぶことができる。18 ポイントのテキスト又は太字で 14 ポイントのテキストが、低めのコントラストで十分なサイズの大きさとしている（「関連リソース」にある "The American Printing House for the Blind Guidelines for Large Printing and The Library of Congress Guidelines for Large Print" を参照のこと）。「18 ポイント」及び「太字」は、異なるフォントでは異なる意味合いを持つこともあるが、特別に細い線のフォント又は文字の形が分かりにくくなるような独特の見た目や特徴のあるフォントについては対象外とする。とても多くの様々なフォントがあるため、ここでは一般的な基準を用いることとして、用語集にて装飾的なフォント又は細い線のフォントに関する注記を付けている。
注記 1:
フォントの見た目を滑らかにするためにアンチエイリアス処理がされている際は、暗さ又は明るさを損なうことがある。それにより、実際のコントラストが引き下げられる可能性がある。フォントの線幅をより太くすれば、この問題を軽減することになるだろう（細い線のフォントでは文字の端の部分よりもむしろ細い部分を明るくすることができる）。大きめのフォントを用いて、ユーザエージェントのフォント・スムージング機能をオンにして読みやすさをテストすることを推奨する。
注記 2:
画像編集アプリケーションによって標準となるピクセル密度が異なるため（例：72 PPI または 96 PPI）、文字を特定のサイズで提示する際には、画像編集アプリケーションでのフォントのポイントサイズを特定することは当てにならない。サイズの大きな文字の画像を作成する際、コンテンツ制作者は画面に表示される画像の文字が、おおよそ本文のテキストの標準サイズの1.2emと1.5emまたは120％と150％に相当することを確認すべきである。例えば、72 PPIの画像の場合、画像でサイズの大きな文字（アルファベットで14ptと18pt）とするにはコンテンツ制作者は約19ptと24ptのフォントサイズを用いる必要がある。
また、前述のテキストに対するコントラストの要件は、達成基準 1.4.5 で述べられているように、画像化された文字（ピクセルで描画され、画像フォーマットで保存された文字）にも適用される。
この要件は、画像化された文字が情報を伝えることを目的としている状況に対して適用される。例えば、写真の中にたまたま入っていた街頭の標識にあるような付随的なテキストは、対象外である。また、何らかの理由で、すべての利用者が視覚的に確認できないことを意図しているテキストも対象外である。企業ロゴのようにデザインされた文字は、代替えテキストを含んでいてもいなくてもページ上ではその機能として扱われるべきである。ロゴやロゴタイプを超えて企業の視覚的なガイドラインには例外は含まれない。
この達成基準には、「意味のあるその他の視覚的なコンテンツを含む写真の一部分である」という例外がある。この例外は、文字の写っている写真と、特定の見た目にするためにテキストと置き換えられた画像化された文字とを区別することを意図している。
この達成基準はテキストだけに適用されるが、チャートやグラフ、ダイアグラム、および他の非テキスト情報内のコンテンツにおいても同様の問題は起こる。この様に表示されるコンテンツは、より多くの利用者が情報にアクセスすることを保障するために、十分なコントラストも確保している必要がある。
コントラスト比を定めた論理的根拠
3：1 のコントラスト比は、[ISO-9241-3] 及び [ANSI-HFES-100-1988]によって推奨されている、標準的なテキスト及び視力における最低限のレベルである。達成基準1.4.3で用いられる4.5：1 のコントラスト比は、中度の弱い視力、先天的又は後天的な色弱、あるいは加齢に伴うコントラスト感度の衰えに起因する、コントラスト感度の低下を考慮している。
論理的根拠は、次のことに基づいている。a) ANSI標準規格（American National Standards Institute：米国の国家規格）では、最低限の許容可能なコントラストとして、コントラスト比 3：1 を採用しており、b）集団内では、20/40 の視力は、おおよそ 1.5 のコントラスト感度低下と関連付けられているという経験的事実がある[ARDITI-FAYE]。したがって、視力が 20/40 の利用者は、「3 * 1.5 = 4.5：1」のコントラスト比を必要とするであろう。類似した実証的事実及び同じ論理に沿うと、視力が 20/80 の利用者は、約 7:1 のコントラスト比を必要とすることになる。
色相は、色弱の利用者（先天的及び後天的の両方）によって知覚のされ方が様々なため、色及び相対的な輝度コントラストが色弱ではない利用者とは異なる。このため、有効なコントラスト及び読みやすさは、色弱の利用者に対しては異なったものになる。しかし、色弱は多様であるため、（コントラストのために）量的なデータに基づいて有効で一般的な色の組合せを規定することは、適切であるとはいえない。十分な輝度コントラストを要求することで、色の知覚に依存しないコントラストを要求し、この問題に対応している。幸いにも、輝度の寄与のほとんどは、分光感度において大部分が重なる中波長及び長波長の受容体からくるものである。その結果は、有効な輝度コントラストが一般的に特定の色弱に関係なく計算できるということである。ただし、赤色を知覚しにくい1型2色覚の利用者の場合、暗い色（一般的に黒のようである）に対して主に波長の長い色を用いることは除く（この理由から、WCAG ワーキンググループは、黒の背景に赤の前景を使うことを避けるという参考達成方法を提供している）。より詳細な情報は、[ARDITI-KNOBLAUCH] [ARDITI-KNOBLAUCH-1996] [ARDITI] を参照のこと。
レベル AA で 4.5：1 のコントラスト比を選択したのは、20/40 程度まで視力の低下した利用者におけるコントラスト感度の低下を補うためである（20/40 は約 4.5：1 という計算になる）。また、20/40 は、80歳前後の高齢者の標準的な視力として、よく報告される視力である [GITTINGS-FOZARD]。
レベル AAA で 7：1 のコントラスト比を選択したのは、20/80 程度まで視力の低下した利用者におけるコントラスト感度の低下を補うためである。より視力の弱い利用者は、通常は支援技術を使用して、コンテンツを利用している（その支援技術には、コントラスト増強と画面拡大の機能が搭載されている）。そのため、7：1 というコントラスト比は、一般的に支援技術を使用していないロービジョンの利用者のコントラスト感度の低下を補い、同様に色弱の利用者に対してもコントラストを向上させる。
計算式に関する注記
RGB 値の非線形から線形への変換は、IEC/4WD 61966-2-1 [IEC-4WD]及び "A Standard Default Color Space for the Internet - sRGB" [sRGB]に基づいている。
コントラストの計算式（L1/L2）は、[ISO-9241-3]及び[ANSI-HFES-100-1988]の標準規格に基づいている。
ANSI/HFS 100-1988 は、L1 及び L2 の計算に含めるために、周辺光からの寄与を必要としている。用いている 0.05 という値は、[IEC-4WD]の Typical Viewing Flare 及び 論文[sRGB](M. Stokes et al) に基づいている。
この達成基準及びその定義では、ウェブコンテンツが光自体を発するわけではないという事実を反映するために、「輝度」ではなく、「コントラスト比」及び「相対輝度」という用語を用いている。コントラスト比は、コンテンツが表示されたときに生じる相対輝度の評価基準（尺度）を与える（それは、比率なので、無次元である）。
達成基準 1.4.6の事例
(none currently documented)
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準1.4.6の達成方法及び不適合事例 - コントラスト (高度)
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
達成基準を満たすことのできる達成方法
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の達成方法（又は、達成方法の組合せ）がある。
1.4.6 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
G156: 一般に入手可能なユーザエージェントで、テキストのブロックの前景及び背景を変更できるウェブコンテンツ技術を使用する
模様のある背景にはよりハイコントラストな値の文字を用いる（リンク追加予定）
画像化された文字の代わりにUnicodeテキストとスタイルシートを用いる（リンク追加予定）
ダイヤグラムの線にハイコントラストな値を用いる（リンク追加予定）
赤と黒の組み合わせによる文字と背景色には、さらに大きなコントラストレベルを用いる
主に中間のスペクトル要素からなる明るい要素とスペクトルの両端（青と赤の波長）からなる暗い要素で構成された色を用いる
両端のコントラストではなく、黒文字に白の背景よりも明るいパステルの背景色を用いる（リンク追加予定）
テキストのコントラスト規定を満たしているシンプルな線で描かれたアイコンを使う（リンク追加予定）
グラフやチャートに十分な色コントラストを提供する（リンク追加予定）
デフォルトから3:1のコントラスト比又はそれよりも高い比率を用いる（リンク追加予定）
空のテキストフィールドに十分な色のコントラストを提供する（リンク追加予定）
達成基準 1.4.6のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準1.4.6に適合していないとみなした、よくある不適合事例である。
重要な用語
- コントラスト比 (contrast ratio)
(L1 + 0.05) / (L2 + 0.05) ここでは、
注記 1:
コントラスト比は、1～21の範囲になりうる (通常は、1:1～21:1 と記述される)。
注記 2:
コンテンツ制作者は、テキストのレンダリング (例: フォントのスムージングやアンチエイリアス) に関する利用者の設定を制御できないため、アンチエイリアスをオフにした状態でテキストのコントラスト比を評価してもよい。
注記 3:
達成基準 1.4.3 及び 1.4.6 の目的上、コントラストは通常の使用においてテキストがレンダリングされるときに指定されている背景色に対して測定する。もし背景色の指定がない場合は、背景色には白を想定する。
注記 4:
背景色は、テキストが通常の使用においてレンダリングされるときに背景となるコンテンツの色として指定された色である。テキストの色は指定されているが背景色が指定されていない場合、利用者のデフォルトの背景色は未知であり、コントラストが十分かどうかを評価することができないため、問題がある。同じ理由で、背景色が指定されているがテキストの色が指定されていない場合も問題がある。
注記 5:
文字の周囲に縁取りがある場合、その縁取りがコントラストを強めることもあり、文字とその背景色におけるコントラストの計算に用いられる。文字の周囲の細い縁取りは文字として扱われる。文字の周囲の太い縁取りが、光彩のようになって、文字の内側の細部を塗りつぶしていれば、背景色として考慮されることになる。
注記 6:
WCAG に適合しているか判断する場合は、典型的な提示において隣接するであろうと制作者が想定するコンテンツで指定された色の組み合わせについて評価しなければならない。制作者は、ユーザエージェントによる色の変更などのように通常とは異なる提示を考慮する必要はない。ただし、それが制作者のコードによって起こる場合は除く。
- サイズの大きな (テキスト) (large scale (text))
少なくとも18ポイント、又は14ポイントの太字。あるいは、中国語、日本語、及び韓国語 (CJK) のフォントは、それと同等の文字サイズ。
注記 1:
特別に細い線のフォント、又は文字の形が分かりにくくなるような独特の見た目や特徴のあるフォントは、コントラストが低い場合に特に読みづらい。
注記 2:
ここでいう文字サイズは、コンテンツが提供される際のサイズであり、利用者によるサイズ変更は含まれない。
注記 3:
利用者が目にする文字の実際のサイズは、コンテンツ制作者が指定したサイズと利用者のディスプレイあるいはユーザエージェントの設定の両方に依存している。多くの主流となっている本文テキストで用いられるフォントにおいて、14ポイントと18ポイントは、1.2emと1.5em、又は、 (本文フォントが100％であると仮定して) デフォルトサイズの120%と150%に、おおよそ同等である。しかし、制作者は、使用する特定のフォントについて、このことをチェックしておく必要がある。フォントが相対単位で定義されている時、実際に表示される文字サイズのポイント数は、ユーザエージェントによって計算される。この達成基準について評価する時には、文字サイズのポイント数は、ユーザエージェントから取得されるべきであり、又はユーザエージェントが行うフォントの計算基準に基づいて計算するべきである。ロービジョンの利用者については、自分で適切な設定を選択することを想定している。
注記 4:
フォントサイズを指定せずにテキストを用いる際は、サイズを指定していないテキストに対して主要ブラウザで用いられる最小のフォントサイズをそのテキストのサイズとみなすのが妥当であろう。もし、レベル1の見出しが、主要なブラウザで14ポイントの太字あるいはそれ以上のサイズでレンダリングされるならば、それは「サイズの大きな」テキストであると考えてよい。相対的な拡大縮小は、同様の方法でそのデフォルトのサイズから算出することが可能である。
注記 5:
半角の英数字のテキストにおける18ポイント及び14ポイントのサイズは、拡大印刷の最小サイズ (14ポイント) と標準的な大きい文字サイズ (18ポイント) に基づいている。例えば、CJK言語のようなその他の文字については、「同等な」サイズはその言語での拡大印刷の最小サイズと拡大印刷でその次に大きな標準のサイズとなる。
- テキスト (text)
プログラムによる解釈が可能な文字の並びで、自然言語で何かを表現しているもの。
- ユーザインタフェース コンポーネント (user interface component)
コンテンツの一部分で、特定の機能を実現するための単一のコントロールとして利用者が知覚するもの。
注記 1:
複数のユーザインタフェース コンポーネントが、単一のプログラム要素で実装されることもある。ここでいうコンポーネントは、プログラムの手法と結びついたものではなく、利用者が別々のコントロールとして知覚するものを指す。
注記 2:
ユーザインタフェース コンポーネントには、フォーム要素、リンクだけでなく、スクリプトで生成されるコンポーネントが含まれる。
事例: アプレットには、コンテンツ内を行単位、ページ単位、又はランダムアクセスで移動するために用いられる「コントロール」がある。これらには、いずれも名前 (name) を割り当て、個別に設定できるようにする必要があるため、それぞれが「ユーザインタフェース コンポーネント」となる。
- 文字画像 (image of text)
特定の視覚的効果を得るために非テキスト形式 (例えば画像) でレンダリングされたテキスト。
注記: テキスト以外の部分が重要な視覚的コンテンツである場合、画像に含まれるテキストは該当しない。
- 純粋な装飾 (pure decoration)
見栄えのためだけのもので、情報は提供せず、機能性も備えていないもの。
注記: テキストが純粋な装飾といえるのは、単語を並べ替え、又は置き換えても意図が変わらないときだけである。
事例: 背景にとても淡い文字で単語がランダムに並んでいる辞書の表紙。
小さな背景音、又は背景音なし:
達成基準 1.4.7 を理解する
1.4.7 小さな背景音、又は背景音なし: 収録済の音声しか含まないコンテンツで、(1) 前景に主として発話を含み、(2) 音声CAPTCHA 又は音声ロゴではなく、かつ、(3) 例えば、歌やラップなどのように、主として音楽表現を意図した発声ではないものについては、次に挙げる事項のうち、少なくとも一つを満たしている:
(レベル AAA)
この達成基準の意図
この達成基準の意図は、発話ではないあらゆる音が、音声の聞こえづらい利用者が発話を背景音又は前景にある不要な他の発話コンテンツと区別することができるようにすることである。
20 dB（デシベル）という値は、 Large area assistive listening systems (ALS): Review and recommendations [LAALS]と、In-the-ear measurements of interference in hearing aids from digital wireless telephones [HEARING-AID-INT] に基づいている。
達成基準 1.4.7の事例
(none currently documented)
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準1.4.7の達成方法及び不適合事例 - 小さな背景音、又は背景音なし
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
1.4.7 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 1.4.7のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準1.4.7に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
重要な用語
- CAPTCHA
コンピュータと人間とを判別する完全自動化されたチューリングテスト (Completely Automated Public Turing test to tell Computers and Humans Apart) の頭文字語。
注記 1:
CAPTCHA のテストは多くの場合、利用者に対し、不明瞭な画像又は音声ファイルによって提示されたテキストを入力するよう求める。
注記 2:
チューリングテストは、人間とコンピュータを区別することを目的としたテストの仕組みである。その名は、高名なコンピュータ科学者のアラン チューリングにちなんでいる。この用語は、カーネギーメロン大学の研究者たちによる造語である。[CAPTCHA]
- 収録済 (prerecorded)
ライブではない情報。
- 音声しか含まない (audio-only)
音声のみを含んだ、時間に依存する提示 (映像やインタラクションを含まない)。
視覚的提示:
達成基準 1.4.8 を理解する
1.4.8 視覚的提示: テキストブロックの視覚的提示において、次を実現するメカニズムが利用できる:
(レベル AAA)
利用者が、前景色と背景色を選択できる。
幅が80字を越えない (全角文字の場合は、40字)。
テキストが、均等割り付けされていない (両端揃えではない)。
段落中の行送りは、少なくとも1.5文字分ある。そして、段落の間隔は、その行送りの少なくとも1.5倍以上ある。
テキストは、支援技術なしで200％までサイズ変更でき、利用者が全画面表示にしたウィンドウで1行のテキストを読むときに横スクロールする必要がない。
この達成基準の意図
この達成基準の意図は、視覚的に描画されるテキストを、そのレイアウトにより読みやすさを損なうことなく、知覚できるように提示することである。認知の障害、言語の障害、及び学習障害のある利用者やロービジョンの利用者は、彼らにとってテキストが読みづらい方法で提示されていると、そのテキストを知覚できなかったり、どこを読んでいるのかが分からなくなったりすることがある。
視覚障害又は認知の障害のある利用者は、テキストの色及び背景色を選択できる必要がある。彼らは、その障害のない利用者にとっては分かりにくいとも思える組合せを選んでいることがある。そして、その組合せは、コントラストがとても低いこともある。また、とても限定された色の組合せしか有効でないこともある。色又はテキストの表現におけるその他の外観を制御できるかどうかによって、そういった利用者の読解力には大きな差が生じる。
読字障害又は視覚障害のある利用者にとっては、長い行のテキストは大きな障壁となりうる。彼らは、自分が読んでいる位置を把握し続けることや、テキストの行送りを目で追うことが苦手である。テキストのブロックの幅を狭くすることで、そういった利用者はテキストのブロックを読んでいるときに次の行へ読み進めていきやすくなる。そのため、行の幅は文字又はテキストを記述する構造上の構成要素である図形記号を含めて80文字以下（中国語、日本語、韓国語の場合は、40文字以下）とすべきである。諸研究によれば、中国語、日本語、及び韓国語の文字は、アルファベット文字と同じ読みやすさで表示すると、幅がほぼ2倍になる。そこで、中国語、日本語、及び韓国語の文字の場合は、行の長さの最長を半分にしている。
認知の障害のある利用者は、行送り幅（行間隔）が接近していると、テキストを目で追うのが困難である。行送り幅及び段落の間隔をさらに空けることで、次の行へ移動しやすくなり、段落の終わりにたどりついたことも認識しやすくなる。例えば、行送り幅には1.5倍と1行おきというように、様々な選択肢があるのが最もよい。段落中の行送り幅が1.5文字分あるというのは、ある行のベースラインと次の行のベースラインとが、テキストが「シングルスペース」（そのフォントでのデフォルトの行送り幅）の150％離れていることを意味する。そして、段落の間隔が行送り幅の1.5倍広いというのは、ある段落の最終行のベースラインが次の段落の最初の行のベースラインから250％離れていることを意味する（言い換えれば、2つの段落の間に、シングルスペースの空行の150％に相当する、空行が1行あるということである）。
いくらかの認知の障害のある利用者は、均等割り付けされているテキストを読むのに問題を抱えている。左右両端を揃えた状態で行ごとに単語間（日本語では文字間）がまちまちの場合に、空白が「白い川」のようにページの下のほうへ流れているように見えると、テキストが読みづらくなり、全く読めなくなることもありうる。また、テキストの均等割り付けは、単語間が近くなりすぎて、単語と単語の分かれ目が分かりづらくなってしまうこともある。
テキストのサイズ変更は、視覚的に描画されるテキスト（視覚的に見ることができるように表示されたテキストの文字 [対ASCIIのようにデータとしての属性を持つテキスト]）を、利用者がすべてのコンテンツを見るのに左右にスクロールすることのないように、問題なく拡大可能にすることである。それが可能なようにコンテンツが制作されていると、コンテンツは折り返しになる。これにより、ロービジョンの利用者及び認知の障害のある利用者は、混乱することなく、テキストのサイズを拡大することができるようになる。
コンテンツを拡大することは、第一にユーザエージェントが果たすべき役割である。UAAG 1.0 チェックポイント 4.1 を満たしているユーザエージェントは、利用者がテキストの拡大及び縮小を設定できるようにしている。コンテンツ制作者が果たすべき役割は、ユーザエージェントがコンテンツを効果的に拡大できるように、そして表示されているビューポートの横幅の中でコンテンツが折り返すように、ウェブコンテンツを制作することである。テキストのサイズ拡大に関するその他の情報は、
達成基準1.4.4 テキストのサイズ変更を理解するを参照のこと。
横スクロールする必要がないという要件は、長い語句を1行に表示すると利用者が横にスクロールする必要があるような、小さい画面の端末に適用することを意図していない。この要件の目的のためには、コンテンツ制作者は、標準的なデスクトップ/ラップトップの画面でブラウザのウィンドウを最大化した状態で、コンテンツがこの要件を満たすようにしなければならない。利用者は一般的に何年も自分のコンピュータを使い続けるので、この基準をテストする際には、最新のデスクトップ/ラップトップの画面解像度ではなく、数年間にわたって普及しているデスクトップ/ラップトップの画面解像度を考慮すべきである。
一つの単語が全画面の幅の半分以上になるほど長くない限り、折り返して全体を表示することが可能である。とても長いURIは、拡大された画面からはみ出してしまうかもしれないが、URI は「読む」ためのテキストではないとみなされるので、この基準に反することはない。
この基準は、利用者が横スクロールをする必要が絶対にないということを意味するわけではない。単に、1行のテキストを読むために、利用者が横スクロールを繰り返す必要がないということを意味しているだけである。例えば、テキストが同じ幅の二段組になっているページは、この基準を自動的に満たしていることになるだろう。ページを拡大するというのは、一つめの段が画面上に全部見えていて、利用者がページを縦にスクロールするだけで読むことができるということを意味する。2つめの段を読むには、利用者は右へ横スクロール移動して、右側の段が画面の幅の中に完全に見える状態にして、それ以上は横にスクロールすることなく、その段を読むであろう。
達成基準1.4.8の具体的なメリット
この達成基準は、コンテンツの表現はそのままでテキストを読めるようにすることにより、ロービジョンの利用者の役に立つ。テキストのブロックの色及びサイズを調節できるようにすることにより、ロービジョンの利用者は、自分が見やすくなるようにテキストを調節することができるようになる。
この達成基準は、認知の障害、言語の障害、及び学習障害のある利用者がテキストを知覚して、テキストのブロック内での位置を把握できるようにする。
認知の障害のある利用者は、自分に最適な前景色と背景色の組合せを選ぶと、テキストをより読みやすくすることができるようになる。
認知の障害のある利用者は、テキストのブロックの幅が狭く、行送り幅及び段落の間隔を調整できると、自分の読んでいる位置をより容易に把握できるようになる。
認知の障害のある利用者は、単語と単語の間隔が均一になっていると、テキストをより容易に読めるようになる。
達成基準 1.4.8の事例
次の画像は、段落内で行間の幅を変えたテキストの例を示している。左から1行送り幅、1.5行送り幅、及び2行送り幅になっている。
図形記号の例としては、「A」、「→」（矢印の記号）、そして「さ」（日本語の文字）などが挙げられる。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
CSS 2 Box Model
CSS 2 Visual formatting Model
CSS 2 Visual formatting Model Details
About fluid and fixed width layouts
Accessible CSS
Ideal line length for content
Developing sites for users with Cognitive disabilities and learning difficulties
RDFA Primer
MULTIFUNK: Bringing computer-supported reading one step further, Date: April 2002, ISBN: 82-539-0491-6, Author: Gjertrud W. Kamstrup, Eva Mjøvik, Anne-Lise Rygvold og Bjørn Gunnar Saltnes
Effective Monitor Display Design on the ERIC Web portal
Cognitive difficulties and access to information systems - an interaction design perspective, Peter Gregor and Anna Dickinson, Applied Computing, University of Dundee
Legge, G.E., Pelli, D.G., Rubin, G.S., & Schleske, M.M.:Psychophysics of reading. I. Normal Vision,Vision Research, 25, 239-252, 1985.
Legge, G.E., Rubin, G.S., Pelli, D.G., & Schleske, M.M.:Psychophysics of reading. II. Low Vision,Vision Research, 25, 253-266, 1985.
Osaka,N. and Oda, K. (1991). Effective visual field size necessary for vertical reading during Japanese text processing. Bulletin of Psychonomic Society,29(4),345-347.
Beckmann, P.J. & Legge, G.E. (1996). Psychophysics of reading. XIV. The page-navigation problem in using magnifiers. Vision Research, 36, 3723-3733.
川嶋英嗣・小田浩一(2003).読書におけるスクロール方向とウィンドウ幅の影響 日本心理学会第67回大会, 502.
小田浩一・今橋真理子(1995). 文字認知の閾値と読みの閾値.VISION, 7,
165-168.
Osaka,N. (1994). Size of saccade and fixation duration of eye movements during reading: psychophysics of Japanese text processing. Journal of Optical Society of America A, 9(1), 5-13.
山中今日子・小田浩一 (2007). 漢字の画数と書体のウェイトが視認性に及ぼす影響. 視覚学会2007年夏季大会ポスター 1p1 Vision, P.167.
Line Length, Volume, and Density
Guidance on accessible publishing
An Accessibility Frontier: Cognitive disabilities and learning difficulties
Cognitive/Perceptual Difference And Good Web Design
6 Surprising Bad Practices That Hurt Dyslexic Users
Design for Dyslexics
Web Design for Dyslexia
達成基準1.4.8の達成方法及び不適合事例 - 視覚的提示
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
達成基準を満たすことのできる達成方法
使用法：これは複数の要件から成る達成基準なので、次の要件それぞれについて、番号付きの項目の中から1つを満たさなければならない。
1.4.8 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
パラグラフ、リスト又はテーブルセルをハイライトするのにHover効果を用いる (HTML, CSS)（リンク追加予定）
sans serif フォント又はそれを達成できるメカニズムを提供する(CSS)（リンク追加予定）
インラインリストよりもリスト（ビュレット又は番号順）を用いる（リンク追加予定）
テキスト言語の綴りの慣習に従って上付又は下付を用いる（リンク追加予定）
デフォルトを大きな文字で提供する（リンク追加予定）
ビットマップ（ラスター画像）の文字利用を避ける（リンク追加予定）
ユーザエージェントの初期値よりも小さなサイズのフォント尺度を使わない（リンク追加予定）
十分なスペースを持った行間を提供する（リンク追加予定）
中心揃えの文字を使わない（リンク追加予定）
イタリックテキストをたくさんを使わない（リンク追加予定）
個々のページやサイト内で異なるスタイルを乱用しない（リンク追加予定）
視覚的に異なるリンクを用いる（リンク追加予定）
拡張的なビュレットを提供する（リンク追加予定）
ビュレットポイントを見せる又は隠す（リンク追加予定）
文の後はemスペース又は2スペースをあてる（リンク追加予定）
達成基準 1.4.8のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準1.4.8に適合していないとみなした、よくある不適合事例である。
重要な用語
- テキストブロック (blocks of text)
一文よりも長いテキスト。
- メカニズム (mechanism)
結果を得るためのプロセス又は手法。
注記 1:
メカニズムは、コンテンツ内で明示的に提供されることもあれば、プラットフォーム又は支援技術を含むユーザエージェントで提供されるものに 依存することもある。
注記 2:
メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。
- 全画面表示のウィンドウで (on a full-screen window)
最も普及したサイズのデスクトップやラップトップのディスプレイで、ビューポートを最大化した状態。
注記: 利用者は一般的にコンピュータを数年間使い続けるので、評価の際は、最新のデスクトップやラップトップの画面解像度を基準にするのではなく、数年間にわたって普及したデスクトップやラップトップの画面解像度を考慮するのが望ましい。
文字画像 (例外なし) :
達成基準 1.4.9 を理解する
1.4.9 文字画像 (例外なし) : 文字画像は、純粋な装飾に用いられているか、テキストの特定の表現が伝えようとする情報にとって必要不可欠である場合に用いられている。
(レベル AAA)
注記: ロゴタイプ (ロゴ又はブランド名の一部である文字) は必要不可欠なものであると考えられる。
この達成基準の意図
この達成基準の意図は、テキストの特定の視覚的な表現を必要とする利用者が、必要に応じてテキストの表現を整えられるようにすることである。テキストに、特定のフォントサイズ、前景色及び背景色、書体、行間、又は配置が必要な利用者がいる。
これは、テキストをその表現が変更できるように実装すること、又は利用者が代替の表現を選択できるメカニズムを提供することを意味する。画像化された文字を使用することは、すべての利用者がテキストの表現を変えることができない実装の一例である。
ある状況においては、文字の特定の視覚的な表現がその情報を伝える上で不可欠である。その特定の視覚的な表現でないと、その情報が損なわれてしまうことになる。そのような場合は、テキストを変更できるような方法で実装する必要はない。例えば、ある書体を紹介する際のようにテキストの特定の視覚的な様相を示す場合や、企業ロゴにある文字のようにアイデンティティを伝える文字などが挙げられる。
装飾を目的にした文字は、その表現を変更できるように実装する必要はない。
「画像化された文字」の定義には、「注記： これには、重要なその他の視覚的なコンテンツを含む画像の一部であるテキストは含まれない。」とある。そのような画像の事例としては、グラフ、スクリーンショットやダイアグラムなどが挙げられ、それらは文字以外のものを通じて重要な情報を視覚的に伝えているからである。
達成基準 1.4.9の事例
引用
あるウェブページに引用がある。その引用部分自体は、イタリックのテキストで、左側をインデントした状態で提示されている。その引用した部分の人名が、引用の下に1.5倍の行間を空けて、左側からさらにインデントした状態になっている。そのテキストの配置、行間スペースの指定、そしてテキストの書体・サイズ・色及び装飾には、CSS を用いている。
ナビゲーション
ウェブページに、ナビゲーション・リンクのメニューがあり、アイコンとテキストの両方でリンク先を示している。CSSを用いて、テキストの書体、サイズ、前景色及び背景色、そしてナビゲーション・リンク間の間隔を指定している。
文字を含んだロゴ
あるウェブサイトには、各ウェブページの左上のコーナーに組織のロゴがある。そのロゴには、ロゴタイプ（ロゴの一部又は全部に文字）がある。 文字の視覚的な表現は、そのロゴのアイデンティティに不可欠であり、その文字の特徴を変更することができないGIF画像である。そして、その画像には、代替テキストがある。
書体のサンプル
ウェブページに、特定の書体に関する情報がある。その書体を他の書体に置き換えると、サンプルとしての目的が損なわれてしまう。そのサンプルは、その文字の特徴を変更することができない JPEG 画像である。そして、その画像には、代替テキストがある。
手紙の写し
ウェブページに、手紙の原本を描写したものがある。オリジナルの体裁でその手紙を見せることが、その手紙の書かれた時代に関する情報を伝える上で不可欠である。その手紙は、その文字の特徴を変更することができない GIF 画像である。そして、その画像には、代替テキストがある。
記号的な文字
利用者がテキストのブロックを入力できるフォームがある。そのフォームは、テキストのスタイル指定やスペルチェックなどの機能のボタンをたくさん提供している。ボタンの中には文字を用いたものがあり、その文字に自然言語で何かを表現する並び順はない。例えば、フォントを太字にする機能には"B"、テキストをイタリックにする機能には"I"、そしてスペルチェックの機能には"ABC"が使われている。その記号的な文字は、その文字の特徴を変更することができない GIF 画像としてボタンになっている。そして、そのボタンには代替テキストがある。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準1.4.9の達成方法及び不適合事例 - 文字画像 (例外なし)
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
1.4.9 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 1.4.9のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準1.4.9に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
重要な用語
- テキスト (text)
プログラムによる解釈が可能な文字の並びで、自然言語で何かを表現しているもの。
- 必要不可欠 (essential)
もし取り除いてしまうと、コンテンツの情報あるいは機能を根本的に変えてしまい、かつ、適合する他の方法では情報及び機能を実現できない。
- 文字画像 (image of text)
特定の視覚的効果を得るために非テキスト形式 (例えば画像) でレンダリングされたテキスト。
注記: テキスト以外の部分が重要な視覚的コンテンツである場合、画像に含まれるテキストは該当しない。
- 純粋な装飾 (pure decoration)
見栄えのためだけのもので、情報は提供せず、機能性も備えていないもの。
注記: テキストが純粋な装飾といえるのは、単語を並べ替え、又は置き換えても意図が変わらないときだけである。
事例: 背景にとても淡い文字で単語がランダムに並んでいる辞書の表紙。
キーボード操作可能:
ガイドライン2.1を理解する
ガイドライン2.1:
すべての機能をキーボードから利用できるようにすること。
ガイドライン 2.1 の意図
すべての機能がキーボードを用いて利用可能であれば、キーボードの利用者、（キーボード入力を生成する）音声入力、（オンスクリーン・キーボードを使用する）マウス、及び出力として疑似的な打けんを生成する様々な支援技術により、その機能を実現することができる。キーボード入力が時間に依存しない限り、柔軟性があり、広く一般にサポートされて、そして様々な障害のある利用者が操作可能な入力形態は他にはない。
汎用キーボードの入力を提供することは、他の入力方法をサポートしないという意味ではないことに留意してほしい。最適化された音声入力、最適化されたマウス/ポインタ入力などもまた有効である。重要な点は、キーボード入力及びそれと同等の操作方法を提供することである。
例えば、PDA又は携帯電話のような機器の中には、もともとキーボードを搭載していないものもある。しかし、これらの機器にウェブ閲覧機能がある場合には、テキスト又は「打けん」を生成する何らかの手段があるはずである。このガイドラインでは、キーボード、キーボードエミュレータ、又はキーボード入力やテキスト入力を生成するその他のハードウェアもしくはソフトウェアで生成される打けんにより、ウェブコンテンツが制御される必要があることを認識するために、「キーボードインタフェース」という用語を用いている。
ガイドライン 2.1 の参考にすべき達成方法(特定の達成基準に特有ではない達成方法)
このガイドラインにある各達成基準を満たすための達成方法は、この後に達成基準ごとに挙げられている。しかし、このガイドラインに対処するための達成方法がどの達成基準にも該当しない場合は、ここで挙げている。そういった達成方法は、どの達成基準を満たす上でも必須ではないし、十分でもないが、ウェブコンテンツの種類によってはより多くの利用者にとってよりアクセシブルにすることができるものである。
- このガイドラインの参考にすべき達成方法はすべて、特定の達成基準に関係している。
キーボード:
達成基準 2.1.1 を理解する
2.1.1 キーボード: コンテンツのすべての機能は、個々のキーストロークに特定のタイミングを要することなく、キーボードインタフェースを通じて操作可能である。ただし、その根本的な機能が利用者の動作による始点から終点まで続く一連の軌跡に依存して実現されている場合は除く。
(レベル A)
注記 1:
上記の例外は、根本的な機能に関するものであり、入力手法に関するものではない。例えば、テキスト入力に手書き入力を用いるのであれば、その入力手法 (手書き) は利用者の動作による軌跡に依存した入力を必要とするが、その根本的な機能 (テキスト入力) は利用者の動作による軌跡に依存した入力を必要とするものではない。
注記 2:
これは、キーボード操作に加えて、マウス入力、又はその他の入力手段を提供することを禁ずるものでも妨げるものでもない。
この達成基準の意図
ここの達成基準の意図は、可能な限り、コンテンツをキーボード又は（代替キーボードが利用できるような）キーボードインタフェースで操作できるようにすることである。コンテンツがキーボード又は代替キーボードで操作可能であれば、（目と手を一緒に使うマウスのようなデバイスを使用できない）全盲の利用者にも、代替キーボード又はキーボードエミュレータのような入力デバイスを使用しなければならない利用者にも操作できることになる。キーボードエミュレータには、音声認識入力ソフトウェア、呼気/吸気操作ソフトウェア、オンスクリーンキーボード、スキャニングソフトウェア、そして様々な支援技術及び代替キーボードがある。ロービジョンの利用者は、ポインタを目で追うのが困難なことがあり、キーボードでソフトウェアを操作できれば、ソフトウェアがとても使いやすくなる（又は、単に使えるようになる）。
「個々のキーストロークに特定のタイミング」の事例としては、利用者が短時間のうちに複数の打けんを繰り返す又は実行する必要がある状況、又は打けんが受け付けられるまでは長い間キーを押下していなければならないような状況がある。
「ただし、その根本的な機能が単に利用者の動作の終点に依存しておらず、利用者の動作による軌跡に依存して実現されている場合は除く。」というフレーズがあるのは、キーボードから無理なく操作することができないものとを区別するためである。
ポインティング・デバイスにより実行される操作のほとんどは、キーボードでも実行可能である（例えば、クリックする、選択する、動かす、拡大・縮小する）。しかし、ポインティング・デバイスでは可能だが、ものすごく多くの打けんでないと、あらゆる知られた方法でキーボードでは不可能な入力がある。手書き描画、水彩画、及び障害物訓練コースでのヘリコプター操縦は、どれも軌跡に依存した入力を要する機能の事例である。直線や規則的な幾何学的図形を描くこと、ウィンドウのサイズを変更すること、及びある位置へオブジェクトをドラッグして移動させること（その位置への軌跡に意味がない場合）は、軌跡に依存した入力を必要としない。
（テンキーでマウスポインタを操作する）マウスキーを使用することでは、この達成基準を満たしたことにはならないだろう。なぜなら、アプリケーションに対して、キーボードと同等ではなく、マウスと同等だからである（つまり、アプリケーションからはマウスのように見えるためである）。
利用者の入力機能を設計する際に、利用者がそのオペレーティング・システムのキーボード・アクセシビリティ機能を使用する可能性があることを考慮するのは当然のことである。例えば、修飾キーがロックされているかもしれない。しかし、修飾キーのロックとぶつかるイベントを送って予期しない結果が生じることのないように、コンテンツはそのような環境においても機能し続ける必要がある。
達成基準2.1.1の具体的なメリット
（目と手を一緒に使うマウスのようなデバイスを使用できない）全盲の利用者
（画面上のポインタを見つけたり、目で追ったりするのが困難である）ロービジョンの利用者
マウスを使うのがとても困難なため、通常はキーボードを使用している手に震えのある利用者。
達成基準 2.1.1の事例
事例 1： 描画プログラム
描画プログラムは、利用者がキーボード操作でオブジェクトの作成、サイズ変更、配置及び回転をすることが可能である。
事例 2： ドラッグアンドドロップ機能
ドラッグアンドドロップを用いるアプリケーションは、オブジェクトを移動させるための「カット」及び「ペースト」、又はフォーム・コントロールをサポートしている。
事例 3： 離れている点の間の移動及び接続
点を結ぶプログラムは、利用者が画面上の点間を移動し、スペースキーで現在の点と直前の点を結ぶことができる。
事例 4： 例外 － お絵描きプログラム
水彩画を描くプログラムは、ひと筆の動きが移動の速度及び持続時間にかなり依存して変化するため、例外の一つとして認められる。
事例 5： 例外 － 模型ヘリコプター操縦訓練シミュレータ
ヘリコプター操縦訓練シミュレータは、シミュレータの性質上、模型ヘリコプターの動作をリアルタイムで教えるものであるため、例外の一つとして認められる。
事例 6： オプションのキーボード付き PDA
通常スタイラスペンで操作する PDA は、オプションで接続可能なキーボードがある。そのキーボードは、標準的な方法で全てのウェブ閲覧を行うことが可能である。ウェブコンテンツはキーボードのみでも利用できるように設計されているので、そのキーボードでも操作可能である。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準2.1.1の達成方法及び不適合事例 - キーボード
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
2.1.1 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
インタラクティブなユーザインタフェース・コンポーネントとして静的な要素に再度目的を持たせる場合、XHTMLの役割、状態、及び値の属性を使用する（リンク追加予定） 及び SCR29: 静的なHTML要素にキーボード操作可能なアクションを追加する (Scripting)
重要なリンク及びフォームのコントロールへのキーボード・ショートカットを提供する（リンク追加予定）
一覧表の各項目を始めるために固有の文字の組合せを使用する（リンク追加予定）
もっとも抽象的なイベント・ハンドラを選択する（リンク追加予定）(Scripting)
OnActivateイベントを使用する（リンク追加予定）(Scripting)
他の目的で、一般的なユーザエージェントのキーボード・コマンドの使用を避ける（リンク追加予定）
達成基準 2.1.1のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準2.1.1に適合していないとみなした、よくある不適合事例である。
重要な用語
- キーボードインタフェース (keyboard interface)
キーストローク入力を取得するためにソフトウェアが用いるインタフェース。
注記 1:
標準ではキーボードが存在しない技術であっても、キーボードインタフェースによって、利用者がキーストローク入力をプログラムに提供できる。
事例: タッチスクリーンを搭載している PDA には、外部キーボードへのコネクタとあわせて、そのオペレーティングシステムに組み込まれたキーボードインタフェースがある。PDA 上のアプリケーションはそのインタフェースを用いて、外部キーボード、あるいは手書き解釈プログラムや「キーボードエミュレーション」機能付きの音声テキスト変換アプリケーションのような擬似キーボード出力を提供する他のアプリケーションのいずれかからキーボード入力を取得することができる。
注記 2:
マウスキーのようなキーボード操作によるマウスエミュレータによるアプリケーション (又は、そのアプリケーションの一部) の操作は、キーボードインタフェースからの操作とは見なさない。なぜならば、この場合、プログラムの操作は、キーボードインタフェースからではなく、そのポインティングデバイス インタフェースからの入力によって行われるからである。
- 機能 (functionality)
利用者の操作により実現可能なプロセス及び結果。
キーボードトラップなし:
達成基準 2.1.2 を理解する
2.1.2 キーボードトラップなし: キーボードインタフェースを用いてキーボードフォーカスをそのウェブページのあるコンポーネントに移動できる場合、キーボードインタフェースだけを用いてそのコンポーネントからフォーカスを外すことが可能である。さらに、修飾キーを伴わない矢印キー、 Tab キー、又はフォーカスを外すその他の標準的な方法でフォーカスを外せない場合は、フォーカスを外す方法が利用者に通知される。
(レベル A)
注記: この達成基準を満たさないコンテンツでは、利用者がそのウェブページ全体を使用できない恐れがあるため、ウェブページ上のすべてのコンテンツは他の達成基準を満たすために用いられているか否かにかかわらず、この達成基準を満たさなければならない。達成基準 5: 非干渉を参照。
この達成基準の意図
この達成基準の意図は、コンテンツがウェブページ上の一部分にキーボード・フォーカスを「閉じ込める」ことのないようにすることである。これは、1ページ中に複数のフォーマットが組み合わされていて、プラグイン又は埋め込みアプリケーションで描画される際によく起こる問題である。
ただし、その状態を抜け出してフォーカスを「閉じ込められない」ようにする方法を利用者が分かっているのであれば、ウェブページの機能がフォーカスの移動をコンテンツの一部分に限定しているときがあってもよいのかもしれない。
達成基準 2.1.2の事例
カレンダーのプログラム
カレンダーのプログラムは、利用者がキーボードを用いてそのカレンダーに項目の追加、削除又は更新することができるようになっている。プログラムにあるコントロールは、ウェブページ内の Tab キーによるフォーカス移動の一つで、あらゆるリンク又はコントロールと同様に利用者がプログラムのコントロールもTabキーで移動できる。
パズルのアプレット
利用者が Tab キーでフォーカスをアプレットの中に入れると、そこから先のフォーカス移動及びその他の打けんはアプレットが処理することになる。そして、そのアプレットから抜け出すのに用いる打けんに関する命令は、そのアプレットの中にあるのと同様に、アプレットに入る前に提供されている。
モーダル・ダイアログボックス
ウェブアプリケーションが、ダイアログボックスを立ち上げる。そのダイアログボックスの下部には、「キャンセル」と「OK」の二つのボタンがある。ダイアログボックスが開くと、フォーカスはそのダイアログボックスから外へ抜け出せなくなる。ダイアログボックスの最後のコントロールで Tab キーを押すと、フォーカスはダイアログボックスの最初のコントロールへ移動する。「キャンセル」ボタン又は「OK」ボタンを押下すると、そのダイアログボックスは閉じられる。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準2.1.2の達成方法及び不適合事例 - キーボードトラップなし
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
2.1.2 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
(まだ文書化されていない)
達成基準 2.1.2のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準2.1.2に適合していないとみなした、よくある不適合事例である。
重要な用語
- キーボードインタフェース (keyboard interface)
キーストローク入力を取得するためにソフトウェアが用いるインタフェース。
注記 1:
標準ではキーボードが存在しない技術であっても、キーボードインタフェースによって、利用者がキーストローク入力をプログラムに提供できる。
事例: タッチスクリーンを搭載している PDA には、外部キーボードへのコネクタとあわせて、そのオペレーティングシステムに組み込まれたキーボードインタフェースがある。PDA 上のアプリケーションはそのインタフェースを用いて、外部キーボード、あるいは手書き解釈プログラムや「キーボードエミュレーション」機能付きの音声テキスト変換アプリケーションのような擬似キーボード出力を提供する他のアプリケーションのいずれかからキーボード入力を取得することができる。
注記 2:
マウスキーのようなキーボード操作によるマウスエミュレータによるアプリケーション (又は、そのアプリケーションの一部) の操作は、キーボードインタフェースからの操作とは見なさない。なぜならば、この場合、プログラムの操作は、キーボードインタフェースからではなく、そのポインティングデバイス インタフェースからの入力によって行われるからである。
キーボード (例外なし) :
達成基準 2.1.3 を理解する
2.1.3 キーボード (例外なし) : コンテンツのすべての機能は、個々のキーストロークに特定のタイミングを要することなく、キーボードインタフェースを通じて操作可能である。
(レベル AAA)
この達成基準の意図
この達成基準の意図は、すべてのコンテンツをキーボードで操作可能にすることである。例外が認められないということを除いては、達成基準 2.1.1 と同じである。ただし、その根本的な機能が単に利用者の動作の終点に依存しておらず、利用者の動作による軌跡に依存した入力を必要とするコンテンツ（つまり、達成基準 2.1.1 では例外とされていたコンテンツ）をキーボードで操作可能にするということではない。正しくは、そういった軌跡に依存した入力を用いるコンテンツは、この達成基準に適合することができないため、ガイドライン 2.1 にレベル AAA で適合することはできないということである。
達成基準 2.1.3の事例
(none currently documented)
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準2.1.3の達成方法及び不適合事例 - キーボード (例外なし)
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
達成基準を満たすことのできる達成方法
この達成基準には、特に追加された達成方法があるわけではない。達成基準 2.1.1 の達成方法を参照のこと。アナログで時間の経過に依存した入力があるためにその達成方法が不可能な場合は、このレベル AAA の達成基準に適合することはできない。
重要な用語
- キーボードインタフェース (keyboard interface)
キーストローク入力を取得するためにソフトウェアが用いるインタフェース。
注記 1:
標準ではキーボードが存在しない技術であっても、キーボードインタフェースによって、利用者がキーストローク入力をプログラムに提供できる。
事例: タッチスクリーンを搭載している PDA には、外部キーボードへのコネクタとあわせて、そのオペレーティングシステムに組み込まれたキーボードインタフェースがある。PDA 上のアプリケーションはそのインタフェースを用いて、外部キーボード、あるいは手書き解釈プログラムや「キーボードエミュレーション」機能付きの音声テキスト変換アプリケーションのような擬似キーボード出力を提供する他のアプリケーションのいずれかからキーボード入力を取得することができる。
注記 2:
マウスキーのようなキーボード操作によるマウスエミュレータによるアプリケーション (又は、そのアプリケーションの一部) の操作は、キーボードインタフェースからの操作とは見なさない。なぜならば、この場合、プログラムの操作は、キーボードインタフェースからではなく、そのポインティングデバイス インタフェースからの入力によって行われるからである。
- 機能 (functionality)
利用者の操作により実現可能なプロセス及び結果。
十分な時間:
ガイドライン2.2を理解する
ガイドライン2.2:
利用者がコンテンツを読み、使用するために十分な時間を提供すること。
ガイドライン 2.2 の意図
障害のある利用者の多くは、障害のない利用者と比べると、タスクを完了するのにより長い時間を必要とする。それは、身体的に反応するのに時間がかかることがある、何かを読むのに時間がかかることがある、ロービジョンのために何かを見つけたり読んだりするのに時間がかかることがある、又は、より時間を要する支援技術を使用してコンテンツを利用していることがあるからである。このガイドラインは、利用者がコンテンツに要求されるタスクを利用者の必要とする時間をかけて完了できるようにすることに焦点を当てている。主なアプローチとして、制限時間を取り除くこと、又はタスクを完了するために十分な時間を利用者が追加できるようにすることを挙げている。ただし、それが不可能な場合に対する例外が認められている。
ガイドライン 2.2 の参考にすべき達成方法(特定の達成基準に特有ではない達成方法)
このガイドラインにある各達成基準を満たすための達成方法は、この後に達成基準ごとに挙げられている。しかし、このガイドラインに対処するための達成方法がどの達成基準にも該当しない場合は、ここで挙げている。そういった達成方法は、どの達成基準を満たす上でも必須ではないし、十分でもないが、ウェブコンテンツの種類によってはより多くの利用者にとってよりアクセシブルにすることができるものである。
- このガイドラインの参考にすべき達成方法はすべて、特定の達成基準に関係している。
タイミング調整可能:
達成基準 2.2.1 を理解する
2.2.1 タイミング調整可能: コンテンツに制限時間を設定する場合は、次に挙げる事項のうち、少なくとも一つを満たしている:
(レベル A)
解除: 制限時間があるコンテンツを利用する前に、利用者がその制限時間を解除することができる。又は、
調整: 制限時間があるコンテンツを利用する前に、利用者が少なくともデフォルト設定の10倍を超える、大幅な制限時間の調整をすることができる。又は、
延長: 時間切れになる前に利用者に警告し、かつ少なくとも20秒間の猶予をもって、例えば「スペースキーを押す」などの簡単な操作により、利用者が制限時間を少なくとも10倍以上延長することができる。又は、
リアルタイムの例外: リアルタイムのイベント (例えば、オークション) において制限時間が必須の要素で、その制限時間に代わる手段が存在しない。又は、
必要不可欠な例外: 制限時間が必要不可欠なもので、制限時間を延長することがコンテンツの動作を無効にすることになる。又は、
20時間の例外: 制限時間が20時間よりも長い。
注記: この達成基準は、制限時間の結果として、コンテンツ又はコンテキストの予期せぬ変化を引き起こさないように利用者がタスクを完了できるようにするためのものである。この達成基準は、利用者の動作の結果としてのコンテンツ又はコンテキストの変化を制限する
達成基準 3.2.1と併せて考慮すること。
この達成基準の意図
この達成基準の意図は、障害のある利用者がウェブコンテンツを操作するのに十分な時間の提供を、可能な限り保証することである。全盲、ロービジョン、巧緻性障害、及び、認知能力の低下している利用者は、コンテンツを読んだり、オンラインフォームに記入したりするような操作を実行するのに、より長い時間を必要とする場合もある。そのため、ウェブコンテンツの機能が時間の経過に依存している場合、制限時間内に必要な操作を実行することが困難な利用者もいるだろう。このことは、サービスをそういった利用者に対してアクセシブルではないものにしてしまう。そこで、機能を時間の経過に依存しないように設計することで、障害のある利用者がその操作を完了させやすくなる。制限時間を解除する、制限時間の長さを調整する、又は時間切れになる前に制限時間を延長するための選択肢を提供することは、作業を無事に終えると見込まれているよりも多くの時間を必要とする利用者の助けになる。利用者にとって最も有用なものから順に選択肢を挙げている。時間切れになる前に制限時間を延長できるようにすることよりも、制限時間の長さを調整できるようにすることのほうが望ましく、さらにそれよりも制限時間を解除できるようにすることのほうが望ましい。
利用者による起動がなく、設定時間後又は定期的に発生する処理は、どれも制限時間を表す。コンテンツの一部又は全部の更新（例えば、ページのリフレッシュ）、コンテンツの変更、利用者が入力の要求に対応するウィンドウの有効期限などが含まれる。
また、利用者が読んだり、理解したり、又はその両方をすることができない速度で進んだり更新したりするコンテンツも含まれる。言い換えれば、アニメーションや動画のコンテンツ、動きのあるコンテンツ、又はスクロールするコンテンツは、利用者がコンテンツを読むのに制限時間を課することになる。
しかし、ある場合において、（例えば、オークション又は他のリアルタイムのイベントの）制限時間を変更することは不可能であり、それゆえこれらの場合における例外が提供されている。
サーバーの制限時間に関する注記
制限時間のあるサーバーのリダイレクトは、以下にある「よくある不適合事例」の中で述べられている。
制限時間のないサーバーのリダイレクト（例： HTTPレスポンスコード 3xx）は、時間の制限がなく、瞬時に作動するので、この達成基準は適用されない。
この達成基準は、コンテンツ自体が設定する制限時間だけに適用される。例えば、セキュリティ上の懸念に対処するために制限時間を設けている場合、そのコンテンツの表現やインタラクションによる体験の一部であるため、コンテンツによって制限時間が設定されているとみなされる。ユーザエージェント又はインターネット固有の要因などにより、コンテンツ以外のものが設定する制限時間は、コンテンツ制作者が制御できるものではなく、WCAG への適合要件の対象とはならない。ウェブサーバにより設定される制限時間は、コンテンツ制作者や運営組織が制御できるものであり、対象となる（達成基準 2.2.3、2.2.4 及び 2.2.5 も適用されることがある）。
デフォルトの10倍は、臨床的経験及び他のガイドラインに基づいて選んでいる。例えば、利用者が反応してスイッチを押すのに15秒間与えられていたら、たとえ問題があったとしても、150秒はすべての利用者がスイッチを押すのに十分な時間であろう。
また、20秒間も、臨床的経験及び他のガイドラインに基づいている。「あらゆるスイッチ」を押すのに、20秒あれば、痙性（麻痺している筋肉が自分の意思に関わらず勝手に緊張して収縮する症状）のある利用者も含むほとんどすべての利用者にとって十分である。中にはそれでも足りない利用者もいるかもしれないし、時間をどれだけ延ばしても足りない利用者もいるだろう。任意の長い時間にしてしまうと、あるアプリケーションに対して障害のある利用者を含むすべての利用者を危険な状態にするため、時間の延長を要求するのに妥当な時間を定める必要がある。例えば、金融取引に用いられるキオスク端末又は端末装置は、利用者が取引を終了せずにその場を離れてしまうことが非常によくある。そのままでは、端末を次の人に不正利用されやすい状態にしておくことになる。利用者の確認をせずに休止状態を長時間与えて、長時間にわたって利用者がその場にいるという状態にしておくことは、端末を不正利用の危険にさらすことになる。何も動きがなければ、システムはそこに利用者がいるかどうかを確認しなければならない。そのため、システムは、利用者がそこにいることを確認するように求め（「どれかキーを押してください」）、誰もが応じることができるだけの長さで利用者の反応を待つべきである。「どれかキーを押してください」に対して、20秒という時間は、この条件を満たすであろう。もし利用者が自分はまだそこにいるということを示せば、その端末は利用者に確認する前と同じ状況を利用者に再び提示しなくてはならない。
一日に起きている時間よりも長いので、上限として20時間を選んだ。
制限時間が本質的な要件ではなく、利用者に制限時間のあるイベントを制御できるようにすることが、その結果を無価値にするような場合には、第三者がその利用者のために制限時間を調整することができる（例えば、試験に2倍の時間を与える）。
達成基準2.2.3 タイミング非依存を理解するも参照のこと。
達成基準2.2.1の具体的なメリット
身体障害のある利用者は、反応したり、入力したり、タスクを完了したりするのに、より長い時間を要することが多い。ロービジョンの利用者は、画面上で何かを探したり、読んだりするのに時間がかかる。全盲でスクリーンリーダーを使用している利用者は、画面のレイアウトを理解したり、情報を見つけたり、そしてコントロールを操作したりするのに時間がかかるかもしれない。認知能力の低下、又は言語の障害のある利用者は、読んだり、理解したりするのに時間がかかる。音声が聞こえなくて手話でコミュニケーションしている利用者は、（彼らにとっては第二言語のようなものかもしれない）テキストで書かれた情報を読むのに時間がかかるかもしれない。
手話通訳者が、デフの利用者に音声コンテンツを通訳しているような状況では、制限時間を制御できることも重要である。
読字障害、認知の障害及び学習障害のある利用者は、情報を読んだり、理解したりするのに時間がかかることがあり、コンテンツを一時停止させることによって、その情報を読む時間を延長することができる。
達成基準 2.2.1の事例
ウェブサイトは、クライアントサイドの制限時間を用いて、コンピュータから離れてしまう可能性のある利用者を保護している。何も活動がないと、ウェブページは利用者がまだ時間が必要かどうかを確認する。もし利用者からの反応がなければ、そこでタイムアウトになる。
ウェブページには、巡回手段で最新のニュース見出しを自動的に更新するフィールドがある。利用者は更新する時間をデフォルトの10倍の長さに延ばすことができるインタラクティブなコントロールがある。そのコントロールは、マウス又はキーボードのどちらかで操作可能である。
ウェブページには、至るところに現れては消えるテキストが組み込まれたアニメーションがある。テキストがスクロールして画面を横切るものもあれば、表示されると短時間で背景に消えていくものもある。テキストを読むのが困難な利用者がテキストの消えてしまう前に読むことができるように、そのページには一時停止ボタンがある。
オークションにおいて、利用者が入札しなければならない時間に期限がある。その制限時間は、特定に品目に入札したいと思っているすべての利用者に適用されるので、特定の利用者の誰か1人だけに制限時間の延長を認めると公平ではなくなる。そのため、制限時間はこの種のコンテンツには必須であり、この達成基準によって、制限時間の延長、調整、又は解除を要求されることはない。
オンラインチケット購入サイトでは、利用者が席を確保して購入内容を確認するのに2分間の制限時間が与えられている。そのようなサイトのチケットはすぐに売り切れてしまうため、それ以上チケットを確保しておくと、サイト本来の機能を発揮できない可能性がある。そのため、これは制限時間が必要不可欠で、コンテンツを無効にすることなく時間延長することができない事例の一つである。しかし、そのサイトは、時間制約のある段階に入る前に、例えば氏名、支払方法などの必要な情報を利用者が提供できるようにするなどして、できる限り多くのプロセスを制約時間外で行えるようにしている。
チケット購入サイトは、利用者が選択した席の購入を確認するために2分間の制限時間を与えているが、時間切れが近づくと利用者に警告を出し、例えば、「時間を延長する」ボタンを押すなどの簡単な操作で、利用者がこの制限時間を何倍か延長できるようにしている。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準2.2.1の達成方法及び不適合事例 - タイミング調整可能
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
達成基準を満たすことのできる達成方法
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の達成方法（又は、達成方法の組合せ）がある。
2.2.1 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 2.2.1のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準2.2.1に適合していないとみなした、よくある不適合事例である。
重要な用語
- 必要不可欠 (essential)
もし取り除いてしまうと、コンテンツの情報あるいは機能を根本的に変えてしまい、かつ、適合する他の方法では情報及び機能を実現できない。
一時停止、停止、非表示:
達成基準 2.2.2 を理解する
2.2.2 一時停止、停止、非表示:
動きのある、点滅している、スクロールする、又は自動更新する情報は、次のすべての事項を満たしている:
(レベル A)
動き、点滅、スクロール: 動きのある、点滅している、又はスクロールしている情報が、(1) 自動的に開始し、(2) 5秒よりも長く継続し、かつ、(3) その他のコンテンツと並行して提示される場合、利用者がそれらを一時停止、停止、又は非表示にすることのできるメカニズムがある。ただし、その動き、点滅、又はスクロールが必要不可欠な動作の一部である場合は除く。
自動更新: 自動更新する情報が、(1) 自動的に開始し、 (2) その他のコンテンツと並行して提示される場合、利用者がそれを一時停止、停止、もしくは非表示にする、又はその更新頻度を調整することのできるメカニズムがある。ただし、その自動更新が必要不可欠な動作の一部である場合は除く。
注記 1:
画面がちらつく、又は閃光を放つコンテンツに関する要件は、ガイドライン 2.3を参照。
注記 2:
この達成基準を満たさないコンテンツでは、利用者がそのウェブページ全体を使用できない恐れがあるため、ウェブページ上のすべてのコンテンツは他の達成基準を満たすために用いられているか否かにかかわらず、この達成基準を満たさなければならない。達成基準 5: 非干渉を参照。
注記 3:
定期的にソフトウェアによって自動的に更新されるコンテンツ、又はユーザエージェントにストリーム配信されるコンテンツでは、コンテンツ再生の一時停止と再開の操作の間に生成、又は受信される情報を保持、又は提示する必要はない。これは技術的に不可能であることが考えられ、多くの状況において利用者の混乱を招くことにつながる可能性があるためである。
注記 4:
コンテンツの読み込み中やそれに類似した状況の一部として表示されるアニメーションについては、この段階ですべての利用者に対していかなるインタラクションも発生する可能性がなく、かつコンテンツ読み込みの進行状況を表示しないことが利用者の混乱を招いたり、コンテンツが動作を停止した、又はコンテンツが破損しているという誤解を生じたりする可能性がある場合には、必要不可欠なものと考えることができる。
この達成基準の意図
この達成基準の意図は、利用者がウェブページとやりとりしている間、他の事に注意をそらされないようにすることである。
「動き、点滅、スクロール」は、目に見えるコンテンツが動きの印象を伝えているコンテンツのことを指している。一般的な例は、動画、同期したメディアの表示、アニメーション、リアルタイムのゲーム、スクロールする株価表示などがある。「自動更新」は、あらかじめ設定された間隔で更新したり、消えたりするコンテンツのことを指している。一般的な時間の経過に伴って変化するコンテンツは、音声、自動的に更新される天気情報、ニュース、株価更新、及び自動進行する表示やメッセージなどがある。動き、点滅、スクロールするコンテンツと自動更新するコンテンツに対する要件は、次のものを除いて同じである：
動きのある又は自動更新するコンテンツは、動かないテキストを素早く読むのが困難な利用者及び動きのあるオブジェクトを目で追うのが困難な利用者にとっての障壁となることがある。また、スクリーンリーダーの利用者にも問題を引き起こすことがある。
動きのあるコンテンツは、ある利用者にとっては深刻なかく乱を引き起こすことがある。特に注意力欠如障害のある利用者などは、点滅しているコンテンツに気を取られてしまい、ウェブページのそれ以外の部分に集中するのが困難になってしまう。5秒を基準として選んだのは、利用者の注意を引くには十分な長さであり、なおかつ、ページを利用することが必要であれば、利用者が気が散らされるのを待てない長さではないからである。
一時停止したコンテンツは、リアルタイムで再開するか、利用者が一時停止したところから再生を続けるかのどちらかである。
一時停止した後、利用者が一時停止したところから再開することが、コンテンツを読むために一時停止したいと思う利用者にとっては最適であり、コンテンツがリアルタイムのイベント又は状態に関係のないときには最も良い方法である。
一時停止した後、（一時停止を解除した時に）最新の表示へ移ることが、リアルタイム又は本来の「状態」にある情報にとってよりよいことである。例えば、気象レーダー、株価表示、交通情報カメラ、又はオークションのタイマーなどは、コンテンツ再開時に一時停止したことで古い情報が表示されると、誤った情報を提供してしまうことになる。
注記: コンテンツを非表示にすることは、一時停止した後、（一時停止を解除した時に）最新の表示へ移るのと同じ効果が得られる。
メカニズムが「利用者が一時停止するためのメカニズム」と判断されるためには、それが利用者に一時停止の手段として提供されつつも、利用者やフォーカスをそこに縛り付けてページが使用できなくなるようなものではない必要がある。ここでの「一時停止」という単語は「一時停止ボタン」という意味で使われているが、ボタンではないほかのメカニズムを使用することもできる。利用者がフォーカスしている時だけアニメーションが停止する(そしてフォーカスを解除し次第再開する)ようなものは、その過程でページが使い物にならなくするため「利用者が一時停止するためのメカニズム」とは判断されず、この達成基準も満たさないだろう。
注記: 「点滅」と「閃光」は、同じコンテンツを指すこともあることに注意することが重要である。
「点滅」は、利用者の注意を散漫にさせる問題を引き起こすコンテンツを指している。点滅は、それを停止する（又は停止させることができる）限り、短時間であれば許容することができる。
「閃光」は、（1秒間に3回よりも多く、大きさと明るさが十分な場合には）光過敏性発作を引き起こす恐れのあるコンテンツを指している。これは、光過敏性発作を引き起こす恐れがあるため、たとえ1秒間だけであったとしても許容されない。光過敏性発作は利用者が止める前に引き起こす恐れがあるため、閃光を止めることも選択肢にはならない。
通常、点滅は1秒間に3回以上の頻度では起こらないが、点滅を1秒間に3回以上の頻度で起こすこともできる。点滅が1秒間に3回以上の頻度で起こる場合には、それも閃光とみなされるであろう。
達成基準2.2.2の具体的なメリット
5秒後に点滅を停止するコンテンツを提供すること、又は利用者が点滅するコンテンツを停止できるメカニズムを提供することで、特定の障害のある利用者がウェブページと情報のやりとりをできるようになる。
点滅するコンテンツの一つの使い方は、そのコンテンツへ利用者の注意を引くことである。これは画面を見ているすべての利用者に対して効果的な達成方法ではあるが、点滅が続くとある利用者に対しては問題を引き起こす恐れがある。読み書き能力の低い利用者、読字障害及び知的障害のある利用者、及び注意力欠如障害のある利用者などにとっては、点滅するコンテンツは残りのウェブページとの情報のやりとりを困難にしたり、ときには不可能にしてしまうことがある。
達成基準 2.2.2の事例
利用者の行動に影響を与えずに一時停止できる基本的なアニメーション
あるウェブサイトは、プロセスを説明するアニメーションによって、利用者が「どのように機能するか」を理解するための手助けをしている。アニメーションには「一時停止」と「再開」のボタンがある。
株式相場表示機
株式相場表示機には、「一時停止」と「再開」のボタンがある。株式相場表示機を一時停止すると、現在表示している株価のところで一時停止する。再開すると、株式相場表示機は停止したところから再開するが、表示が遅れていることを示す注意書きが表示される。株式相場表示機の目的は、通常はリアルタイムの情報を提供することなので、株式相場表示機を最新の取引株価に進めるボタンもあるかもしれない。
利用者がリアルタイムで競い合うのではなく、交代で行うように設計されたゲーム
一つのグループが、ゲームの競争での形勢を無効にすることなく、ゲームを一時停止することができる。
ウェブ広告
広告は、閲覧者の注意を引くために点滅するが、5秒後に停止する。
フォームのプロンプト
フォームは、利用者がフォームへの記入を終えても送信ボタンを押下しないと、送信ボタンの近くにある矢印が点滅する。その点滅は5秒後に停止する。
アニメーション
アニメーションはページの上部で再生されるが、アニメーションの下側には「アニメーションを一時停止する」ボタンがある。
「読み込み中」のアニメーション
再生を開始するまでに大容量のファイルの何パーセントまでがダウンロードされたかを要求するページ上に、読み込み中であることを示すアニメーションが表示されている。ページ上のコンテンツはそのアニメーションだけで、映像を読み込んでいる間、利用者にしばらく待つ必要があることを知らせている。接続回線の遅い利用者に対してアニメーションが5秒以上再生されていたとしても、その動きのあるコンテンツは他のコンテンツと同時に表示されていないので、アニメーションを一時停止、停止、又は非表示にするメカニズムを提供する必要はない。
全面広告
サイトは、利用者がサイトで利用できる無料コンテンツにアクセスする前に、すべての利用者に15秒の広告を閲覧することを要求している。広告を閲覧することはすべての利用者に対する要求であり、他のコンテンツと同時に表示されていないので、広告を一時停止、停止、又は非表示にするメカニズムを提供する必要はない。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準2.2.2の達成方法及び不適合事例 - 一時停止、停止、非表示
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
2.2.2 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 2.2.2のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準2.2.2に適合していないとみなした、よくある不適合事例である。
重要な用語
- 一時停止 (paused)
利用者の要求により停止し、利用者の要求があるまで再開しない。
- 必要不可欠 (essential)
もし取り除いてしまうと、コンテンツの情報あるいは機能を根本的に変えてしまい、かつ、適合する他の方法では情報及び機能を実現できない。
- 点滅 (blinking)
注意を引く意図で、二つの視覚的な状態を交互に切り替えること。
注記: 閃光も参照。ある程度の面積をもち、ある程度の明るさ、特定の頻度で点滅するものは、閃光に分類されることもありうる。
タイミング非依存:
達成基準 2.2.3 を理解する
この達成基準の意図
この達成基準の意図は、制限時間のあるインタラクションを要求するコンテンツの提供を最小限にすることである。それにより、全盲、ロービジョン、認知能力の低下、又は運動障害のある利用者が、コンテンツとやりとりできるようになる。この達成基準は、唯一の例外がリアルタイムのイベントであるという点で、達成基準レベル A とは異なる。
達成基準2.2.3の具体的なメリット
身体障害のある利用者は、反応したり、入力したり、タスクを完了したりするのに、より長い時間を要することが多い。ロービジョンの利用者は、画面上で何かを探したり、読んだりするのに時間がかかる。全盲でスクリーンリーダーを使用している利用者は、画面のレイアウトを理解したり、情報を見つけたり、そしてコントロールを操作したりするのに時間がかかるかもしれない。認知能力の低下、又は言語の障害のある利用者は、読んだり、理解したりするのに時間がかかる。音声が聞こえなくて手話でコミュニケーションしている利用者は、（彼らにとっては第二言語のようなものかもしれない）テキストで書かれた情報を読むのに時間がかかるかもしれない。
手話通訳者が、デフの利用者に音声コンテンツを通訳しているような状況では、制限時間を制御できることも重要である。
達成基準 2.2.3の事例
試験を完了する時間が採点に影響しないように設計された試験
制限時間を用いてオンライン試験の結果を評価するのではなく、制限時間がないときの点数をもとに試験の結果を評価している。
利用者がリアルタイムで競い合うのではなく、交代で行うように設計されたゲーム
1つのグループが、ゲームの競争時の形勢を無効にすることなく、ゲームを一時停止することができる。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準2.2.3の達成方法及び不適合事例 - タイミング非依存
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
2.2.3 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
(まだ文書化されていない)
達成基準 2.2.3のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準2.2.3に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
重要な用語
- リアルタイムのイベント (real-time event)
a) 閲覧と同時に発生し、b) コンテンツによる生成だけでは完結しないイベント。
事例 1:
ライブパフォーマンスのウェブ放送 (閲覧と同時に発生していて、収録済ではない)。
事例 2:
人々が入札するオンラインのオークション (閲覧と同時に発生している)。
事例 3:
アバターを用いたバーチャルな世界での、生身の人間のやりとり (コンテンツによる生成だけで完結するものではなく、閲覧と同時に発生する)。
- 同期したメディア (synchronized media)
情報を提示するために、他のフォーマットと同期した音声もしくは映像、又は時間に依存するインタラクティブな構成要素と同期した音声又は映像。ただし、そのメディアが
メディアによるテキストの代替であって、メディアによる代替であることが明確にラベル付けされているものは除く。
- 必要不可欠 (essential)
もし取り除いてしまうと、コンテンツの情報あるいは機能を根本的に変えてしまい、かつ、適合する他の方法では情報及び機能を実現できない。
割り込み:
達成基準 2.2.4 を理解する
2.2.4 割り込み: 割り込みは、利用者が延期、又は抑制することができる。ただし、緊急を要する割り込みは除く。
(レベル AAA)
この達成基準の意図
この達成基準の意図は、緊急を要する場合を除いて、利用者がコンテンツ制作者／サーバーからの更新を止めることができるようにすることである。緊急には、市民向け緊急警報メッセージ、又はデータを失ったり，つながりを失ったりするなどを含む、健康、安全、財産の危険を警告するその他のメッセージがある。
これにより、認知能力の低下、又は注意力欠如のある利用者は、コンテンツに集中することができるようになることで、コンテンツを使用することができる。全盲又はロービジョンの利用者が、現在読んでいるコンテンツに神経を集中し続けられるようにもなる。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準2.2.4の達成方法及び不適合事例 - 割り込み
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
2.2.4 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
(まだ文書化されていない)
達成基準 2.2.4のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準2.2.4に適合していないとみなした、よくある不適合事例である。
重要な用語
- 緊急 (emergency)
健康、安全や財産を守るために直ちに行動をとる必要のある、突然で予期されなかった状況あるいは出来事。
再認証:
達成基準 2.2.5 を理解する
2.2.5 再認証: 認証済のセッションが切れた場合は、再認証後でもデータを失うことなく利用者が操作を継続できる。
(レベル AAA)
この達成基準の意図
この達成基準の意図は、何の作業もしていない時の制限時間又は処理を完了する途中で利用者をログアウトさせてしまうその他の状況がある、認証済の処理を、すべての利用者が完了できるようにすることである。
セキュリティ上の理由により、多くのサイトが、何の作業もせずに一定時間が経過した後の認証の制限時間を設定している。障害のある利用者は作業を完了させるのにより長く時間がかかるので、制限時間は問題を引き起こすかもしれない。
その他のサイトでは、利用者が他のコンピュータからそのウェブサイトにログインするか、その利用者がもともとログインした利用者と本当に同じかどうかに疑問を抱くようなその他の行為があった場合には、利用者を認証済のセッションからログアウトさせるだろう。処理中であったとしても利用者がログアウトさせられる際には、再認証を受けることができ、すでに入力済のデータを失うことなくその処理を継続できるようにすることが重要である。
達成基準2.2.5の具体的なメリット
この達成基準は、作業を完了するのに時間の延長を必要とする利用者の役に立つ。認知能力の低下している利用者は、ゆっくり読むので、アンケートを読んで回答するのに時間の延長を必要とすることがある。スクリーンリーダーを使用している利用者は、複雑なフォームを操作して完了させるのに時間の延長を必要とするかもしれない。運動障害のある利用者又は代替入力デバイスで操作する利用者は、フォーム内を操作して入力を完了させるのに、やはり時間の延長を必要とすることがある。
手話通訳者がデフの利用者に音声コンテンツを通訳しているような状況では、制限時間を調整できることも重要である。
達成基準 2.2.5の事例
ショッピングサイトの支払手続
手をほとんど使うことのできない利用者が、ショッピングサイトにログインしている。アプリケーションが始まってからクレジットカード情報を入力するのに時間がとてもかかるので、利用者が支払手続をしている間に制限時間が切れる。利用者が支払手続に戻ってフォームを送信するとき、サイトは再認証するためのログイン画面を表示する。利用者がログインした後、支払手続は同じ段階の同じ情報に復元させる。セッションが時間切れになり、再認証が完了した後に利用者を同じ状態に戻してはいるが、サーバーが一時的に送信を受け付けて保存していたため、利用者はデータを失わずに済んだのである。
電子メールプログラムでの認証
電子メールプログラムは、30分後に認証が時間切れになる。そのプログラムは、時間切れの数分前に利用者にプロンプトを表示し、再認証するために新しいウィンドウを開くリンクを提供する。作成中のメールがあった元のウィンドウはそのままで、再認証後に、利用者はそのデータを送信することができる。
制限時間のあるアンケート
1ページのウェブページで提供されている長いアンケートは、ページの冒頭に、15分経過後にセッションがタイムアウトすることを知らせる情報がある。アンケートはどの時点でも保存することが可能で、後から完了させることも可能であることも、利用者には知らされている。そのウェブページには、部分的に記入が終わったフォームを保存するためのいくつかのボタンがある。さらに、信頼されているアクセシビリティ・サポーテッドなウェブコンテンツ技術の一覧にあるJavaScriptによって、セッションが時間切れに近づいたらポップアップで通知されるように利用者が選択できる。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準2.2.5の達成方法及び不適合事例 - 再認証
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
達成基準を満たすことのできる達成方法
次の実装技術の一つを使用することでデータを損うことなく継続することができる選択肢を提供する:
2.2.5 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
(まだ文書化されていない)
達成基準 2.2.5のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準2.2.5に適合していないとみなした、よくある不適合事例である。
ナビゲーション可能:
ガイドライン2.4を理解する
ガイドライン2.4:
利用者がナビゲートしたり、コンテンツを探し出したり、現在位置を確認したりすることを手助けする手段を提供すること。
ガイドライン 2.4 の意図
このガイドラインの意図は、利用者が必要とするコンテンツを見つけるのを手助けして、自分の現在位置を確認し続けられるようにすることである。こういったタスクは、障害のある利用者にとってはより困難であることがしばしばである。発見、ナビゲーション及び位置確認において重要なのは、利用者が現在位置はどこなのかを確かめられることである。ナビゲーションにおいては、考えられうる行き先に関する情報を入手可能にする必要がある。スクリーンリーダーは、コンテンツを合成音声に変換するが、それは音声なので、合成音声は線形順序で提示されなければならない。このガイドラインにある達成基準では、スクリーンリーダーの利用者がコンテンツを無事にナビゲートできるようにするために、どの条項に対応する必要があるのかを説明しているものがある。また、利用者がより容易にナビゲーションバー及びページの見出しを認識できるようにして、そういった繰り返されているコンテンツを通過できるようにする達成基準もある。一般的ではないユーザインタフェースの機能又はふるまいは、認知の障害のある利用者を困惑させてしまうことがある。
Motive Web Design Glossaryで説明されているように、ナビゲーションには、主に2つの機能がある：
利用者に自分がどこにいるのかを知らせる
利用者が他のどこかへ行けるようにする
このガイドラインは、同様にナビゲーションの鍵を握り、コンテンツのあらゆる構造を知覚可能にするためのガイドライン 1.3 と密接に連動している。見出しは、利用者がコンテンツ内での自分の現在位置を確認して、ナビゲートしていく上で、特に重要なメカニズムである。情報を走り読みして、コンテンツの様々なセクションを容易に見つける際、支援技術の利用者の多くは適切な見出しを頼りにしている。見出しに関して、達成基準 1.3.1 に適合することは、同時にガイドライン 2.4 にも部分的に対処していることになる。
ガイドライン 2.4 の参考にすべき達成方法(特定の達成基準に特有ではない達成方法)
このガイドラインにある各達成基準を満たすための達成方法は、この後に達成基準ごとに挙げられている。しかし、このガイドラインに対処するための達成方法がどの達成基準にも該当しない場合は、ここで挙げている。そういった達成方法は、どの達成基準を満たす上でも必須ではないし、十分でもないが、ウェブコンテンツの種類によってはより多くの利用者にとってよりアクセシブルにすることができるものである。
ブロックスキップ:
達成基準 2.4.1 を理解する
この達成基準の意図
この達成基準の意図は、コンテンツ内を一つずつ順を追って行き来している利用者がウェブページのメインコンテンツへ直接移動できるようにすることである。ウェブページ及びウェブアプリケーションには、他のページ又は画面でも現れるコンテンツがしばしばある。コンテンツの中で繰り返されているブロックの例としては、ナビゲーション・リンク、見出しのグラフィック、そして広告を表示するフレームなどが挙げられる。個々の単語、フレーズ、又は単独のリンクなどの小さな繰り返される部分は、この達成基準の趣旨においては、ブロックとしてみなされない。
このことは、画面を見ている利用者が、画面の中央（通常は、メインコンテンツがあるところ）に意識を集中することによって、繰り返しているコンテンツを無視することができることや、マウスを使用している利用者が、目的のリンクの前にあるすべてのリンク又はフォームのコントロールと出くわさずに、1回のクリックでそのリンクを選択できることと対照的である。
この達成基準の意図は、コンテンツ制作者にユーザエージェントが提供している機能と重複する手段を提供するように求めることではない。ほとんどのウェブブラウザは、利用者がフォーカスをページの先頭に戻すことのできるキーボード・ショートカットを提供しているので、ナビゲーション・リンク一式をウェブページの下部で提供している場合は、いわゆる「スキップ」リンクを提供する必要はないかもしれない。
注記: この達成基準は、複数のページ上で繰り返されているコンテンツのブロックを取り扱っているが、WCAG ワーキンググループは、達成基準 1.3.1 にあるように、個々のページで構造をマークアップすることも強く奨励する。
この達成基準は、「ウェブページ一式において」という語を用いていないものの、ひとまとまりに属するウェブページという考え方を示唆している。制作者は、「共通の目的を共有し、同じコンテンツ制作者、グループ、又は組織により制作されたウェブページの集合」（ウェブページ一式の定義）ではない、何かしら相互に関係のあるウェブページにおいて起こり得る、いかなるコンテンツの重複も避けることを求められてはいない。
注記: たとえひとまとまりに属さないウェブページであっても、同じページ中に繰り返されるテキストのブロックがあったとき、それらをスキップする手段を提供することは、有用かもしれない（必要というわけではない）。
達成基準2.4.1の具体的なメリット
この達成基準を満たしていないと、何らかの障害のある利用者がウェブページのメインコンテンツへ素早くかつ容易に到達するのが困難になることがある。
同じサイト上でいくつかのページを訪れるスクリーンリーダーの利用者が、メインコンテンツが読み上げられる前にある、どのページにもあるすべての見出しのグラフィック及びたくさんのナビゲーション・リンクを聞かなくてすむようになる。
キーボード又はキーボード・インタフェースだけを使用している利用者が、より少ないキーストロークだけでコンテンツに到達できるようになる。そうでなければ、メインコンテンツ部分にあるリンクに到達するまでにたくさんのキーストロークが必要になってしまうかもしれない。これには長い時間がかかってしまう恐れがあり、利用者によっては深刻な肉体的苦痛を伴うことがある。
画面拡大ソフトを使用している利用者が、新しいページへ来るたびに、どこからメインコンテンツが始まるのかを見つけようとして、同じ見出し又はその他の情報のブロックの中を探し回らなくてもすむようになる。
リンクがリストにまとめられていると、認知に制約のある利用者及びスクリーンリーダーを使用している利用者のためになることがある。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準2.4.1の達成方法及び不適合事例 - ブロックスキップ
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
達成基準を満たすことのできる達成方法
次の達成方法の中から一つを用いて、繰り返されるブロックをスキップするリンクを作成する：
次の達成方法の中から一つを用いて、スキップ可能な方法で繰り返されるブロックをグループ化する：
2.4.1 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
重要なリンク及びフォーム制御へのキーボードアクセスを提供する（リンク追加予定）
ページナビゲーションに拡張したスキップリンクを提供する（リンク追加予定）
アクセスキーを提供する（リンク追加予定）
ユーザエージェント及び支援技術による構造化されたナビゲーションを与えるアクセシビリティサポート技術を使う（リンク追加予定）
C6: 構造を示すマークアップをした上で、コンテンツを配置する (CSS)
達成基準 2.4.1のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準2.4.1に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
重要な用語
- ウェブページ (Web page)
単一の URI から HTTP で得た埋め込まれていないリソースに加え、
レンダリングに使われる、又はユーザエージェントがこのリソースと一緒にレンダリングすることを意図しているその他のあらゆるリソースを合わせたもの。
注記 1:
どのような「その他のリソース」も主たるリソースと一緒にレンダリングされるであろうが、これらのリソースが同時にレンダリングされるとは限らない。
注記 2:
このガイドラインの適合範囲に含まれる対象となるウェブページとみなされるためには、リソースが「埋め込まれていない」リソースでなければならない。
事例 1:
すべての埋め込まれている画像とメディアを含んだウェブリソース。
事例 2:
Asynchronous JavaScript and XML (AJAX) を用いたウェブメールのプログラム。そのプログラム全体は http://example.com/mail に存在しているが、受信箱、アドレス帳、カレンダーがある。リンクまたはボタンがあり、それを押すと受信箱、アドレス帳やカレンダーを表示するが、ページの URI は全体を通して変わらない。
事例 3:
カスタマイズ可能なポータルサイトで、利用者が様々なコンテンツモジュールのセットから表示させるコンテンツを選択できるようなもの。
事例 4:
ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、 ウェブサイトの中のほんの1ページなのかもしれない。
- メカニズム (mechanism)
結果を得るためのプロセス又は手法。
注記 1:
メカニズムは、コンテンツ内で明示的に提供されることもあれば、プラットフォーム又は支援技術を含むユーザエージェントで提供されるものに 依存することもある。
注記 2:
メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。
ページタイトル:
達成基準 2.4.2 を理解する
この達成基準の意図
この達成基準の意図は、各ウェブページにその内容を示すページタイトルを付けることによって、利用者がコンテンツを見つけやすく、自分の現在位置を確認しやすくすることである。タイトルがあれば、利用者はページのコンテンツを読んだり解釈したりすることなく、現在位置を確認することができる。タイトルがサイトマップ又は検索結果のリストに表示されたときに、利用者は自分の求めているコンテンツをより素早く確認できるようになる。ユーザエージェントは、利用者がそのページを確認できるように、ページのタイトルを容易に見つけられるようにする。例えば、ユーザエージェントは、そのページタイトルをウィンドウのタイトルバーに表示するか、又はそのページを表示しているタブの名前として表示する。
ページが文書又はウェブアプリケーションの場合、文書又はウェブアプリケーションの名称はページの目的を説明するのに十分だろう。ここで注意すべきなのは、文書又はウェブアプリケーションの名称を使用することを求められていないことである。他の要素によってページの目的又は主題が説明される場合もあるだろう。
達成基準 2.4.4 及び 2.4.9 はリンクの目的を取り扱い、その多くはウェブページへのリンクである。ここでも、リンクされた文書又はウェブアプリケーションの名称がリンクの目的を説明するのに十分だろう。リンクとタイトルが一致する、又は非常に類似したものであることはよい習慣であり、「クリックされた」リンクと利用者が到達するウェブページとの間に連続性を与える。
達成基準2.4.2の具体的なメリット
この達成基準により、そのウェブページにある情報が自分のニーズに関係があるかどうかを、すべての利用者が素早くかつ容易に確認できるようになる。
視覚障害のある利用者が、複数のページが開いているとき、コンテンツを区別できるようになる。
認知の障害、短期記憶障害、及び読字障害のある利用者も、そのページタイトルでコンテンツを確認できるようになる。
この達成基準は、重度の運動障害があり、ウェブページ間を行き来するとき操作モードを音声に依存する利用者にも役立つ。
達成基準 2.4.2の事例
HTML のウェブページ
HTML で制作したウェブページの内容を示したタイトルが、ユーザエージェントのタイトルバーに表示されるように、title 要素でマークアップされている。
文書
WCAG 2.0 解説書のページタイトルが、「ウェブコンテンツ アクセシビリティ ガイドライン 2.0」となっている。
主要なページのページタイトルが、「ガイドライン X を理解する」や「達成基準 X を理解する」となっている。
ドキュメントのページタイトルが、「WCAG 2.0 ガイドライン」となっている。
附録 A のページタイトルが、「用語集」となっている。
附録 B のページタイトルが、「謝辞」となっている。
附録 C のページタイトルが、「参考文献」となっている。
ウェブアプリケーション
あるインターネット銀行のアプリケーションでは、利用者が自分の銀行口座をチェックしたり、過去の明細を確認したり、振込をしたりすることができる。そのウェブアプリケーションは、ウェブページごとにページタイトルを動的に生成している。例えば、「ジョン・スミスさんの講座： XYZ 銀行」、「口座番号 1234-5678 の取引明細 － 2005年12月： XYZ 銀行」などである。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準2.4.2の達成方法及び不適合事例 - ページタイトル
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
2.4.2 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 2.4.2のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準2.4.2に適合していないとみなした、よくある不適合事例である。
重要な用語
- ウェブページ (Web page)
単一の URI から HTTP で得た埋め込まれていないリソースに加え、
レンダリングに使われる、又はユーザエージェントがこのリソースと一緒にレンダリングすることを意図しているその他のあらゆるリソースを合わせたもの。
注記 1:
どのような「その他のリソース」も主たるリソースと一緒にレンダリングされるであろうが、これらのリソースが同時にレンダリングされるとは限らない。
注記 2:
このガイドラインの適合範囲に含まれる対象となるウェブページとみなされるためには、リソースが「埋め込まれていない」リソースでなければならない。
事例 1:
すべての埋め込まれている画像とメディアを含んだウェブリソース。
事例 2:
Asynchronous JavaScript and XML (AJAX) を用いたウェブメールのプログラム。そのプログラム全体は http://example.com/mail に存在しているが、受信箱、アドレス帳、カレンダーがある。リンクまたはボタンがあり、それを押すと受信箱、アドレス帳やカレンダーを表示するが、ページの URI は全体を通して変わらない。
事例 3:
カスタマイズ可能なポータルサイトで、利用者が様々なコンテンツモジュールのセットから表示させるコンテンツを選択できるようなもの。
事例 4:
ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、 ウェブサイトの中のほんの1ページなのかもしれない。
フォーカス順序:
達成基準 2.4.3 を理解する
2.4.3 フォーカス順序: ウェブページが順を追ってナビゲートできて、そのナビゲーション順が意味又は操作に影響を及ぼす場合、フォーカス可能なコンポーネントは、意味及び操作性を損なわない順序でフォーカスを受け取る。
(レベル A)
この達成基準の意図
この達成基準の意図は、利用者がコンテンツ内を一つずつ順を追いながら行き来している際に、キーボードにより操作可能な順序でコンテンツの意味に添って、情報と出会うようにすることである。このことにより、利用者のコンテンツに対するメンタルモデルを一貫したものとし、利用者が困惑する可能性を引き下げる。コンテンツの論理的な関係性を反映した異なる順序になることもある。例えば、テーブルのある行又は列にある構成要素内を一度に移動する際には、行を移動する際も列を移動する際もコンテンツにおける関係性を反映した順序になる。どちらの順序もこの達成基準を満たすことができる 。
ウェブコンテンツでのナビゲーションの順番が決まる方法は、コンテンツで用いるウェブコンテンツ技術によって定義されている。例えば、シンプルな HTML は、タブ移動順序によってナビゲーション順序を定義している。動的な HTML では、フォーカスを他の要素にも割り当てることができるように tabindex 属性を付加して、スクリプトを用いてナビゲーション順序を修正することができる。スクリプトも、tabindex 属性も使用していない場合、ナビゲーション順序は、コンポーネントがコンテンツの流れの中で表れる順序になる（HTML 4.01 仕様書の 17.11 "Giving focus to an element"：日本語訳は「17.11 ある要素にフォーカスを合わせる」を参照のこと）。
この達成基準で対処しているナビゲーション順序ではない、キーボード・ナビゲーションの一例は、ツリー・コンポーネントを行き来するための矢印キーを用いたナビゲーションである。利用者は、上下の矢印キーを使って、ツリーのノードからノードへと移動することができる。右向き矢印キーを押下するとノードを展開して、それから下向き矢印キーを押下すると新しく展開されたノードへと移動していく。アイテムが展開されたり閉じられたりするたびに、ナビゲーション順序に追加されたり削除されたりするので、このナビゲーション順序は、ツリー・コントロールで予期される順序に従っている。そして、アイテムが展開されたり閉じられたりするたびに、ナビゲーション順序に追加されたり削除されたりする。
利用者はウェブページを理解して操作できているが、フォーカス順序がプログラムが解釈する音声読み上げ順序（達成基準 1.3.2 を参照）とは一致しないかもしれない。コンテンツに対して考えられうる論理的な音声読み上げ順序が数通りあり、フォーカス順序はそのうちのどれかと合致するのかもしれない。しかし、特定のプレゼンテーションにおける順序が、プログラムが解釈する音声読み上げ順序とは異なるとき、複数あるプレゼンテーションの一つを使う利用者は、そのウェブページを理解したり操作したりするのを難しいと感じるかもしれない。コンテンツ制作者は、ウェブページを設計する際に、すべての利用者のことを注意深く考慮すべきである。
例えば、画面を見ているキーボードの利用者が、ウェブページの視覚的なプレゼンテーションの順序で情報をやりとりしているのに対し、スクリーンリーダーの利用者は、プログラムで判断される音声読み上げ順序で情報をやりとりしている。フォーカス順序が双方の利用者にとって意味が通じるようにし、どちらかがコンテンツ内をランダムに飛び回るようなことのないように、注意すべきである。
明確にするために:
フォーカス可能な構成要素は、ナビゲーションの順序が意味と操作性に影響を及ぼす時のみ、意味と操作性を保つ順序でフォーカスを受ける必要がある。
必要な場合は、意味と操作性を保つ複数の順序があるかもしれない。
意味と操作性を保つ複数の順序がある場合、それらのうち1つは提供される必要がある。
達成基準2.4.3の具体的なメリット
これらの達成方法は、コンテンツ内を順番に行き来していて、フォーカス順序が音声読み上げ順序と一致しているものと考えている、キーボードの利用者の役に立つ。
論理的で、使いやすいフォーカス順序は、ページの操作をキーボード使用に依存している運動障害のある利用者の役に立つ。
字を読むのが困難な障害のある利用者は、Tab キーを押下してフォーカスが予期しないどこかへ移動してしまうと、迷子のようになってしまう恐れがある。彼らは論理的なフォーカス順序の恩恵を受けている。
視覚障害のある利用者は、Tab キーを押下してフォーカスが予期しないどこかへ移動してしまったり、インタラクティブな要素に囲まれているコンテンツを容易に見つけることができなかったりすると、迷子のようになってしまう恐れがある。
画面拡大ソフトを使用していて、拡大率を高くしている利用者には、ページのごく小さい一部分だけしか見えないことがある。そのような利用者は、フォーカス順序が論理的でないと、誤った文脈でコンテンツの一部分を解釈してしまう恐れがある。
達成基準 2.4.3の事例
インタラクティブなコントロールのツリーがあるウェブページ上で、利用者は上下の矢印キーを使って、ツリーのノードからノードへと移動することができる。右向き矢印キーを押下するとノードを展開して、それから下矢印キーを押下すると新しく展開されたノードへと移動していく。
あるウェブページは、スクリプトでモードレス・ダイアログ（ダイアログボックスを閉じなくても作業が続行できるタイプのダイアログボックス）を実装している。起動ボタンを押下すると、ダイアログが開く。ダイアログ内にあるインタラクティブな要素が、起動ボタンのすぐ後のフォーカス順序の位置に挿入される。ダイアログが開いているときには、フォーカス順序は、その起動ボタンからダイアログ内の要素へ移動し、それから起動ボタンの後にあるインタラクティブな要素へと移動する。ダイアログが閉じているときは、フォーカス順序は起動ボタンからその次に続いている要素へ移動する。
あるウェブページは、スクリプトでモーダル・ダイアログ（ダイアログボックスの中だけで強制的に作業をさせるダイアログボックスで、それが閉じられない限り作業の続行ができない）を実装している。起動ボタンを押下すると、ダイアログが開き、そのダイアログにある最初のインタラクティブな要素にフォーカスがあたる。ダイアログが開いている限り、フォーカスはダイアログ内の要素だけに限定される。ダイアログが閉じられると、フォーカスはボタン又はボタンの次にある要素へ戻る。
HTML で制作されたウェブページには、左側にナビゲーションがある。そのナビゲーションは、HTML ではメインコンテンツの後にあり、CSS を用いてページの左側に表示されるように指定されている。tabindex 属性又はJavaScriptを用いずに、フォーカスがメインコンテンツへ移動できるようにするためである。
注記: この事例は達成基準を満たしているが、必ずしもすべての CSS による配置が当てはまるとはかぎらない。配置が複雑な例では、意味及び操作性を保持できることもあれば、できないこともある。
次の例は、この達成基準を満たさない：
ある企業のウェブサイトに、マーケティングデータを収集するフォームがあり、利用者がその企業の発行するいくつかのニュースレターに登録できるようになっている。マーケティングデータを収集するためのフォームのセクションには、氏名、郵便番号、県、市町村、番地などのテキストフィールドがある。フォームのその他のセクションには、利用者が配信してほしいニュースレターを指定することができるようにいくつかのチェックボックスがある。しかし、そのフォームのタブ移動順序は、フォームにおける異なるセクションのフィールドを行ったり来たりする。そのため、フォーカスは、氏名のテキストフィールドからあるチェックボックスへ、次に番地のテキストフィールドへ、そしてまた別のチェックボックスへというふうに移動してしまう。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準2.4.3の達成方法及び不適合事例 - フォーカス順序
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
2.4.3 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 2.4.3のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準2.4.3に適合していないとみなした、よくある不適合事例である。
重要な用語
- ウェブページ (Web page)
単一の URI から HTTP で得た埋め込まれていないリソースに加え、
レンダリングに使われる、又はユーザエージェントがこのリソースと一緒にレンダリングすることを意図しているその他のあらゆるリソースを合わせたもの。
注記 1:
どのような「その他のリソース」も主たるリソースと一緒にレンダリングされるであろうが、これらのリソースが同時にレンダリングされるとは限らない。
注記 2:
このガイドラインの適合範囲に含まれる対象となるウェブページとみなされるためには、リソースが「埋め込まれていない」リソースでなければならない。
事例 1:
すべての埋め込まれている画像とメディアを含んだウェブリソース。
事例 2:
Asynchronous JavaScript and XML (AJAX) を用いたウェブメールのプログラム。そのプログラム全体は http://example.com/mail に存在しているが、受信箱、アドレス帳、カレンダーがある。リンクまたはボタンがあり、それを押すと受信箱、アドレス帳やカレンダーを表示するが、ページの URI は全体を通して変わらない。
事例 3:
カスタマイズ可能なポータルサイトで、利用者が様々なコンテンツモジュールのセットから表示させるコンテンツを選択できるようなもの。
事例 4:
ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、 ウェブサイトの中のほんの1ページなのかもしれない。
- 順を追ってナビゲート (navigated sequentially)
キーボードインタフェースを用いて (一つの要素から次へ) フォーカスを移動するために、定義された順序でナビゲートすること。
リンクの目的 (コンテキスト内) :
達成基準 2.4.4 を理解する
この達成基準の意図
この達成基準の意図は、利用者がそのリンク先へ行きたいかどうかを決めることができるように、各リンクの目的を理解しやすくすることである。可能な限り、その他の文脈が必要ないように、リンクの目的を示すリンクテキストを提供するとよい。支援技術は、そのウェブページにあるリンクの一覧を利用者に提供することが可能である。リンクテキストにできる限り意味を持たせることで、利用者はこのリンクの一覧から選びやすくなる。また、意味のあるリンクテキストは、リンクからリンクへと Tab キーで移動したい利用者にとっても役に立つ。そして、意味のあるリンクは、そのリンク先のページを理解するのに面倒な方法をとることなく、利用者がリンクを選びやすくなるのである。
リンクのテキスト又はリンクに関連付けられたテキストは、リンクの目的を説明することを意図している。リンクが文書又はウェブアプリケーションに遷移する場合、その文書又はウェブアプリケーションの名称は、（その文書又はウェブアプリケーションへ遷移する）リンクの目的を説明するのに十分だろう。ここで注意すべきなのは、文書又はウェブアプリケーションの名称の使用が必要とされないことである。他のものがリンクの目的を説明する場合もあるだろう。
達成基準 2.4.2 は、ページのタイトルを取り扱っている。ここでも、ページに表示されている、文書又はウェブアプリケーションの名称は、ページの目的を説明するのに十分だろう。リンクとタイトルが一致する、又は非常に類似したものであることはよい習慣であり、「クリックされた」リンクと利用者が到達するウェブページとの間に連続性を与える。
状況によっては、コンテンツ制作者は、リンクの文脈を提供する関係のあるテキストに論理的にリンクの説明の一部を提供したいことがある。この場合、利用者がリンクからフォーカスを移動させずに、そのリンクの目的を確認できることが推奨される。言い換えれば、利用者があるリンクに到達でき、その位置を失うことなく、リンクに関するより多くの情報を探し出すことができる。これは、リンク自体と直接関連付けられているため、リンクと同じ文、段落、リスト項目、又はテーブルのセルにおける、又はデータテーブル内にあるリンクのテーブル見出しセルにおける、リンクの説明を置くことで達成可能である。あるいは、コンテンツ制作者は、ARIA技術を用いてページ上の追加テキストをリンクに関連付けることもできる。
こういった文脈は、リンクの前にあると、最も使いやすいだろう（例えば、曖昧なリンクテキストを使わなければならない場合、その曖昧な語句をリンクの行き先を説明する文章の初めに置くよりも、リンクの行き先を説明する文章の最後に置いたほうが分かりやすい）。リンクの後に説明がきてしまうと、ウェブページを（先頭から最後まで）順に読んでいるスクリーンリーダーの利用者が、困惑したり、理解しづらかったりする可能性がある。
同じ宛先のリンクには一貫した説明があることがベストプラクティスとなる（これは、達成基準 3.2.4によるセットでページの要件である）。さまざまな目的や目的地を持つリンクが異なる記述を持つこともベストプラクティスとなる。
この達成基準には、リンクの目的をウェブページ上にある情報からは判断できないリンクに対して例外が認められている。そのような状況では、障害のある利用者が不利な立場にあるわけではない。リンクの目的を理解するために追加入手可能な文脈が一切ないのである。しかし、ウェブページ上でリンクの目的を解釈するために どんな量であれ文脈が 利用できるなら、この達成基準を満たすためには リンクテキスト内で利用できるか、又はプログラム的にリンクと関連付けられるか、ができなければいけない。
注記: リンクの目的が未知のものである又は隠されているというのが当然であるという状況もありえる。例えば、ゲームには ドア 1、ドア 2、そしてドア 3とだけしか示されていないリンクがある可能性もある。こういう場合は、リンクの目的がすべての利用者をドキドキさせることなので、それらはリンクテキストとして十分であると考えてよい。
達成基準2.4.9 リンクの目的 (リンクのみ) を理解するも参照のこと。
達成基準2.4.4の具体的なメリット
この達成基準により、運動障害のある利用者が、リンク先のコンテンツへ行って、また元へ戻ってくるという無駄なキーストロークなしに、必要のないリンクをスキップすることができるようになる。
認知に制約のある利用者が必要のないコンテンツへ行ったり来たりして現在位置を見失う、ということがなくなる。
視覚障害のある利用者が、リンクの文脈を探ることによって、リンクの目的を判断できるようになる。
達成基準 2.4.4の事例
リンクがリンク先の URI にある情報を説明するテキストを含んでいる
あるページに、「中世の歴史には大量の虐殺があった」という文がある。そして、「中世の歴史」がリンクである。
リンクの前にリンク先の URI にある情報を説明するテキストがある
あるページに、「アイルランド政府の電子選挙委員会に関する詳細を『投票に行こう！』で見る」という文がある。そして、「投票に行こう！」がリンクである。
アイコンとテキストの両方が同じリンク内にある
自動投票機のアイコンと「アイルランド政府の電子選挙委員会」というテキストが、一つのリンクになっている。リンクの目的がアイコンの隣にあるリンクのテキストで説明されているので、そのアイコンの代替テキストは空である。
書籍名のリスト
リストにある書籍が、HTML、PDF、そして mp3（人が本を読み上げているの音声を録音したもの）の3つのフォーマットで利用可能である。各書籍のタイトルを3回（フォーマットごとに1回）聞かないですむように、各書籍の最初のリンクが書籍のタイトルで、2つめのリンクは「PDF」、3つめのリンクは「mp3」となっている。
ニュース記事の要約
あるウェブサイト に、ニュース記事が集められている。メインページでは、各記事の最初の部分が少しだけあって、その後に「続きを読む」というリンクがある。スクリーンリーダーでは、現在の段落を読むためのコマンドによって、リンクの目的を解釈するための文脈が得られる。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準2.4.4の達成方法及び不適合事例 - リンクの目的 (コンテキスト内)
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
2.4.4 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 2.4.4のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準2.4.4に適合していないとみなした、よくある不適合事例である。
重要な用語
- ほとんどの利用者にとって曖昧 (ambiguous to users in general)
リンク、及びリンクと同時に利用者に提供されているウェブページのどの情報からも、そのリンクの目的を判断できない (すなわち、障害がない閲覧者でも、そのリンクを動作させるまで、そのリンクが何をするのか分からない)。
事例: 「注目すべき輸出品のひとつはグァバです」という文中にある「グァバ」という単語がリンクになっている。そのリンク先は、グァバの定義、グァバの輸出量を挙げる図表、又はグァバを収穫している人々の写真のいずれにもなり得る。リンクを動作させるまで、すべての利用者が確信を持てないため、障害のある人が不利な立場に置かれることはない。
- プログラムによる解釈が可能なリンクのコンテキスト (programmatically determined link context)
リンクとの関係性からプログラムによる解釈が可能であり、リンクテキストと結びつけることができ、様々な感覚モダリティで利用者に提示することができる付加的情報。
事例: HTMLでは、英語で記述されたリンクからプログラムによる解釈が可能な情報には、そのリンクと同じ段落、リスト、又はテーブルのセルにあるテキスト、あるいはリンクのあるテーブルのセルと関連付けられたテーブルの見出しセルにあるテキストなどがある。
注記: スクリーンリーダーは句読点を解釈するので、フォーカスが文中のリンクにある場合は、その文からコンテキストを提供することも可能である。
- リンクの目的 (link purpose)
ハイパーリンクを動作させたときに得られる結果の本質。
複数の手段:
達成基準 2.4.5 を理解する
この達成基準の意図
この達成基準の意図は、利用者が自分のニーズに最も合う方法によってコンテンツを見つけることができるようにすることである。コンテンツを見つける手段が複数あれば、利用者は、自分にとって使いやすい又は分かりやすい手段を選ぶことができる。
小規模なサイトであっても、利用者に複数の探索手段を提供すべきである。すべてのページがサイトのホームからリンクされている3～4ページのサイトでは、ホームから各ページへのリンクと、各ページからホームへのリンクを提供するだけで十分かもしれない。ホームにあるリンクがサイトマップのような役割も果たすからである。
達成基準2.4.5の具体的なメリット
サイトをナビゲートする手段を複数提供することによって、利用者が情報をより早く見つけることができるようになる。視覚障害のある利用者は、画面拡大ソフト又はスクリーンリーダーを用いながら長いナビゲーションバーからを使って探していくよりも、検索機能を使用してサイト内の適切な部分へナビゲートしていくほうが容易なことがある。認知の障害のある利用者は、いくつものウェブページを読んだり行き来したりするよりも、サイト全体を見渡すことのできる目次又はサイトマップを好むことがある。中には、サイトのコンセプトやレイアウトを最もよく理解できるように、ウェブページからウェブページへと順番に移動しながらサイト内を探索するのを好む利用者もいるかもしれない。
認知に制約のある利用者は、階層構造を用いたナビゲーション・スキームは分かりづらいことがあるため、検索機能を使うほうがより容易なことがある。
達成基準 2.4.5の事例
検索メカニズム
大手の食品加工企業のサイトには、その製品を用いたレシピがある。そのサイトは、特定の食材を使ったレシピを検索できる検索メカニズムを提供している。あらに、食品のいろいろなカテゴリを挙げたリストボックスも提供している。その企業のスープ製品から作るレシピの一覧があるページへ行くためには、利用者は検索のキーワードに「スープ」と入力してもよいし、又はリストボックスから「スープ」を選択してもよい、その企業のスープ製品から作るレシピの一覧があるページへ行くことができる。
ウェブページ間のリンク
あるヘアサロンが、サービスを宣伝するためにウェブサイトを制作した。そのサイトは5ページしかない。各ページには、ウェブページ間を順に前後へ移動できるリンクがある。さらに、各ウェブページには、その他のウェブページへ移動するリンクの一覧がある。
コンテンツがプロセス又はタスクの結果である場合 - 送金確認
あるオンライン銀行サイトでは、ウェブを通じて口座間の送金ができる。口座の名義人が送金を完了する以外には、送金確認ページを見つける方法はない。
コンテンツがプロセス又はタスクの結果である場合 - 検索エンジンの検索結果
ある検索エンジンが、利用者の入力に応じた検索結果を提供している。その検索プロセスを行う以外に、その検索結果ページを見つける方法はない。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準2.4.5の達成方法及び不適合事例 - 複数の手段
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
達成基準を満たすことのできる達成方法
次の達成方法のうち2つ以上を用いる：
2.4.5 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 2.4.5のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準2.4.5に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
重要な用語
- ウェブページ (Web page)
単一の URI から HTTP で得た埋め込まれていないリソースに加え、
レンダリングに使われる、又はユーザエージェントがこのリソースと一緒にレンダリングすることを意図しているその他のあらゆるリソースを合わせたもの。
注記 1:
どのような「その他のリソース」も主たるリソースと一緒にレンダリングされるであろうが、これらのリソースが同時にレンダリングされるとは限らない。
注記 2:
このガイドラインの適合範囲に含まれる対象となるウェブページとみなされるためには、リソースが「埋め込まれていない」リソースでなければならない。
事例 1:
すべての埋め込まれている画像とメディアを含んだウェブリソース。
事例 2:
Asynchronous JavaScript and XML (AJAX) を用いたウェブメールのプログラム。そのプログラム全体は http://example.com/mail に存在しているが、受信箱、アドレス帳、カレンダーがある。リンクまたはボタンがあり、それを押すと受信箱、アドレス帳やカレンダーを表示するが、ページの URI は全体を通して変わらない。
事例 3:
カスタマイズ可能なポータルサイトで、利用者が様々なコンテンツモジュールのセットから表示させるコンテンツを選択できるようなもの。
事例 4:
ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、 ウェブサイトの中のほんの1ページなのかもしれない。
- ウェブページ一式 (set of Web pages)
共通の目的を共有し、同じコンテンツ制作者、グループ、又は組織により制作されたウェブページの集合。
注記: 他言語版は、異なるウェブページ一式と見なされることもある。
- プロセス (process)
ある活動を完了させるために必要な利用者の一連の動作。
事例 1:
ショッピングサイト上の一連のウェブページで目的を果たすためには、利用者が選択肢となりうる製品、価格及び内容を閲覧した後、製品を選択して注文し、配送先情報及び支払情報を入力する必要がある。
事例 2:
アカウント登録ページでは、登録フォームにアクセスする前にチューリングテストに成功する必要がある。
見出し及びラベル:
達成基準 2.4.6 を理解する
2.4.6 見出し及びラベル:
見出し及びラベルは、主題又は目的を説明している。
(レベル AA)
この達成基準の意図
この達成基準の意図は、ウェブページにどんな情報があるのか、及びその情報がどのように構成されているのかを、利用者が理解しやすくすることである。見出しが明快で内容を説明していれば、利用者は自分の探している情報をより容易に見つけことができる。また、利用者はコンテンツ内の様々な部分間の関係性をより容易に理解することができる。また、ラベルが分かりやすければ、利用者はコンテンツ内にある特定のコンポーネントを識別しやすくなる。
ラベル及び見出しを長くする必要があるわけではない。単語一つ又は一文字だけであっても、コンテンツを見つけてナビゲートする手がかりとして適切であれば、それだけで十分なこともある。
注記: この達成基準は見出しやラベルを必ずしも必要としない。見出しやラベルが提供されている場合、それらの内容がわかりやすくなっていることが求められる。また、見出しやラベルが提供されている場合には、
達成基準1.3.1 情報及び関係性を理解するを達成してなければならない。
達成基準2.4.6の具体的なメリット
分かりやすい見出しは、読む速度が遅くなる障害のある利用者及び短期記憶に制約のある利用者に特に役立つ。そのような利用者にとっては、それぞれのセクションの内容を予測できるようにセクションの見出しが記述されていると役立つ。
求めているコンテンツへたどりつくまでに必要なキーストローク数を減少することが、手を使いづらい利用者又は手を使うことに苦痛を伴う利用者に役立つ。
この達成基準は、例えば目次のように、前後に関係なく、ラベル及び見出しだけを読み上げたとき、又はページ内の見出しから見出しへ移動したときに、ラベル及び見出しが分かりやすいようにすると、スクリーンリーダーを使用している利用者に役立つ。
また、この達成基準は、一度にほんの少しの単語しか見ることのできない、ロービジョンの利用者にも役立つ。
達成基準 2.4.6の事例
ニュースサイト
ニュースサイトのホームに、その時間帯のトップニュースの見出しが並んでいる。それぞれの見出しの下には、記事の冒頭の35ワードと、記事の全文へのリンクがある。そして、見出しはどれも、記事の主題を明快に伝えている。
上手な文章の書き方ガイド
文章の書き方に関するガイドに、次のようなセクション見出しがある。「上手な文章の書き方」、「無駄な語句を取り除く」、「不要な語句を見つけ出す」、などである。これらのセクション見出しは明快かつ簡潔で、情報の構造が見出しの構造にも反映されている。
様々な記事での一貫した見出し
ウェブサイトには、ある学会の会議での論文が掲載されている。その学会の会議への投稿する論文は、次のような構成とすることが必須となっている： 要約、イントロダクション、（その論文に固有なその他のセクション）、結論、筆者略歴、用語集、そして参考文献。そうして、論文の独自性とセクション見出しの一貫性とのバランスをうまくとりながら、各ウェブページのタイトルはそのページにある論文をはっきりと特定している。
利用者に氏名を要求するフォーム
利用者に氏名を要求するフォーム。姓と名を要求する二つのテキストフィールドから成る。最初のフィールドは「姓」、次のフィールドは「名」とラベルづけされる。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準2.4.6の達成方法及び不適合事例 - 見出し及びラベル
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
2.4.6 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 2.4.6のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準2.4.6に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
重要な用語
- ラベル (label)
テキスト、又はテキストによる代替を伴うコンポーネントで、ウェブコンテンツ内のコンポーネントを識別するために利用者に提示されているもの。
注記 1:
名前 (name) は隠されていて支援技術に対してだけ明らかにされる場合がある一方で、ラベルはすべての利用者に提示される。多くの場合 (すべてではないが)、名前 (name) とラベルは同じである。
注記 2:
ラベルという用語は、HTML における label 要素だけに限定されない。
フォーカスの可視化:
達成基準 2.4.7 を理解する
2.4.7 フォーカスの可視化: キーボード操作が可能なあらゆるユーザインタフェースには、フォーカスインジケータが見える操作モードがある。
(レベル AA)
この達成基準の意図
この達成基準の意図は、キーボード フォーカスを持っている要素を利用者が認識しやすくすることである。
この達成基準の意図は、複数の要素のうち、どの要素がキーボード フォーカスを持っているか利用者が認識しやすくすることである。スクリーン上にキーボード操作可能な要素が1つだけある場合には、視覚的にはキーボード操作可能な要素を1つだけ提示するため、達成基準が満たされることになる。
注記: キーボードのフォーカスインジケータは異なる形態をとることができる点に注意すべきである。一般的な方法の1つとして、テキストフィールドがキーボード フォーカスを持っていることを示すための、テキストフィールド内のキャレット表示がある。別の方法としては、ボタンがキーボード フォーカスを持っていることを示すために、ボタンを視覚的に変化させるといった方法がある。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準2.4.7の達成方法及び不適合事例 - フォーカスの可視化
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
2.4.7 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 2.4.7のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準2.4.7に適合していないとみなした、よくある不適合事例である。
現在位置:
達成基準 2.4.8 を理解する
この達成基準の意図
この達成基準の意図は、集中力が長く持たない利用者がウェブページ一式、ウェブサイト、又はウェブアプリケーションの中で自分のいる位置を確認することができ、関連する情報を見つけることができるようにすることである。
達成基準 2.4.8の事例
利用者がサイト内での自分の現在位置を確認しやすくするリンク
ある大学の教育学部に研究会がある。研究会のウェブサイトのホームには、学部のウェブサイトのホーム及び大学のウェブサイトのホームへのリンクがある。
パンくずリスト
ポータルウェブサイトは、トピックをカテゴリごとに整理している。利用者がカテゴリ及びサブカテゴリ内を行き来していると、パンくずリストがカテゴリの階層における現在位置を示してくれる。また、各ページには、ポータルのホームへのリンクもある。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準2.4.8の達成方法及び不適合事例 - 現在位置
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
2.4.8 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 2.4.8のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準2.4.8に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
重要な用語
- ウェブページ一式 (set of Web pages)
共通の目的を共有し、同じコンテンツ制作者、グループ、又は組織により制作されたウェブページの集合。
注記: 他言語版は、異なるウェブページ一式と見なされることもある。
リンクの目的 (リンクのみ) :
達成基準 2.4.9 を理解する
この達成基準の意図
この達成基準の意図は、利用者がコンテンツ内にある各リンクの目的を理解するのを手助けすることで、彼らはそれを辿ることを望むかどうかを、彼らが決めることができる（同じ機能を持っているコンポーネントの識別に一貫性を求めるための達成基準 3.2.4 も見よ）。リンクの目的は、そのリンク テキストから識別されることができるので、ユーザエージェントが、ページ上にある全てのリンクの一覧を提供するときのように、リンクは、それらが文脈の中にあるとき、理解することができる。
リンク内のテキストは、リンクの目的を説明するように意図されている。リンクが、文書又はウェブ アプリケーションの一つへ導く場合は、文書またはウェブ アプリケーションの名前は、（文書またはウェブ アプリケーションにあなたを導く）リンクの目的を説明するのに十分であろう。文書又はウェブ アプリケーションの名前を使用する必要がないことに注意されたい。他のものが、リンクの目的を説明することもできる。
達成基準 2.4.2は、ページのタイトルに取り組んでいる。ここでもまた、ページに表示されている文書とウェブ アプリケーションの名前は、ページの目的を説明するのに十分であろう。リンクとタイトルが一致する又はとても似ていることは、良い習慣であり、リンクの「クリック」と利用者が着地するウェブ ページ間の継続性を提供する。
この達成基準には、リンクの目的をウェブページ上にある情報からは判断できないリンクに対して例外が認められている。そのような状況では、障害のある利用者が不利な立場にあるわけではない。リンクの目的を理解するために追加入手可能な文脈が一切ないのである。しかし、この達成基準を満たすためには、そのリンクの目的を解釈するためにそのウェブページ上で利用できる文脈はどんなものであれ、そのリンクテキストで入手可能にしなればならない。
「メカニズム」という用語を用いているのは、コンテンツ制作者がすべてのリンクを前後の文脈に関係なく完全に理解できるようにするか、あるいはそのようにする方法を提供できるようにするためである。リンクすべてをリンクテキストだけでも曖昧ではないようにすることで、ページによっては、分かりやすくなる利用者もいれば、分かりづらくなってしまう利用者もいる。リンクを（それ自身により）明らかにするか そうしないか できるようにすることは、障害のある利用者にも無い利用者にも、彼らのニーズに最も合致したフォーマットのページを使えるようにすることである。
例えば、100冊の書籍のタイトルが並んでいるページに、それぞれの書籍を HTML、PDF、DOC、TXT、MP3、又は AAC でダウンロードするリンクがある場合、たいていは書籍のタイトルの後に「HTML版」のようなリンクがある。そして、「次のバージョンも利用可能：」という文が続いていて、「HTML」、「PDF」、「DOC」、「TXT」、「MP3」、そして「AAC」という短いテキストのリンクがある。レベル AAA では、ある利用者は このようにページを見ることが選べるであろう。それぞれのリンクに書籍のタイトルがあると、分かりづらかったり、使うのに時間がかかってしまったりするからである。その他の利用者は、それぞれのリンクがそれだけで理解できるように、それぞれのリンクの一部に書籍のタイトルがあるようにページを見ることが選べるであろう。前者のグループにも後者のグループにも、いろいろな使い方をしている、又は様々な種類や度合いの障害のある、視覚又は認知の障害のある利用者が含まれるであろう。
達成基準2.4.9の具体的なメリット
運動障害のある利用者が、関心のないウェブページをスキップできるようになり、関係のないページへ行ってからまた元のページの戻ってくるような無駄なキーストロークを避けることができるようになる。
認知に制約のある利用者が必要のないコンテンツへ行ったり来たりして現在位置を見失う、ということがなくなる。
視覚障害のある利用者は、元のページに戻ってきたときコンテンツのその場所が分からなくなる、ということがなくなり恩恵を受ける。そして、リンク先が説明されているので、情報を探す上で、スクリーンリーダーのリンク一覧がより有益になる。
達成基準 2.4.9の事例
アイコンとテキストの両方が同じリンク内にある
自動投票機のアイコンと「アイルランド政府の電子選挙委員会」というテキストが、一つのリンクになっている。
書籍名のリスト
リストにある書籍が、HTML、PDF、そして mp3（人が本を読み上げているのを録音したもの）の3つのフォーマットで利用可能である。書籍のタイトルの後に、様々なフォーマットへのリンクがある。例えば、描画されるリンクテキストにはフォーマット名しかないが、それぞれのリンクに関連付けられているテキストには、例えば「ガリバー旅行記 MP3版」というように、書籍のタイトルとフォーマットの両方がある。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準2.4.9の達成方法及び不適合事例 - リンクの目的 (リンクのみ)
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
2.4.9 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 2.4.9のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準2.4.9に適合していないとみなした、よくある不適合事例である。
重要な用語
- ほとんどの利用者にとって曖昧 (ambiguous to users in general)
リンク、及びリンクと同時に利用者に提供されているウェブページのどの情報からも、そのリンクの目的を判断できない (すなわち、障害がない閲覧者でも、そのリンクを動作させるまで、そのリンクが何をするのか分からない)。
事例: 「注目すべき輸出品のひとつはグァバです」という文中にある「グァバ」という単語がリンクになっている。そのリンク先は、グァバの定義、グァバの輸出量を挙げる図表、又はグァバを収穫している人々の写真のいずれにもなり得る。リンクを動作させるまで、すべての利用者が確信を持てないため、障害のある人が不利な立場に置かれることはない。
- メカニズム (mechanism)
結果を得るためのプロセス又は手法。
注記 1:
メカニズムは、コンテンツ内で明示的に提供されることもあれば、プラットフォーム又は支援技術を含むユーザエージェントで提供されるものに 依存することもある。
注記 2:
メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。
セクション見出し:
達成基準 2.4.10 を理解する
2.4.10 セクション見出し:
セクション見出しを用いて、コンテンツが整理されている。
(レベル AAA)
注記 1:
見出しはその一般的な意味で用いられており、タイトルや様々なタイプのコンテンツに見出しを付加するその他の手段を含む。
注記 2:
この達成基準は、文書におけるセクションを対象としており、ユーザインタフェース コンポーネントは対象としていない。ユーザインタフェース コンポーネントについては、達成基準4.1.2が対象にしている。
この達成基準の意図
この達成基準の意図 は、ウェブページがセクションで構成されている際には、そのページの各セクションに見出しを提供することである。例えば、長い文章は様々な章に分かれていて、各章にはサブトピックがあり、サブトピックは様々なセクションに分かれていて、セクションには段落があって、という具合にである。そのようなセクションがある際、各セクションにはその内容を紹介する見出しがある必要がある。各セクションの見出しは、コンテンツの構造を示し、コンテンツ内でのナビゲーションを可能にし、そしてコンテンツの理解を助けるメンタルな「取っ掛かり」を提供する。ページのその他の要素（例：横罫線、囲み罫線）が見出しを引き立たせて、見栄えをより良くすることもできるが、視覚的なプレゼンテーションは文章のセクションを特定するには十分ではない。
この達成基準がレベル AAA になっているのは、すべての種類のコンテンツには適用できないのと、見出しを挿入することが常に可能であるとは限らないからである。例えば、既存の文書をウェブで公開する際、その文書の作成者が付けなかった見出しを挿入できないことがあるからである。あるいは、長い手紙には様々なトピックが書かれていることが多いが、手紙に見出しを付けるととてもおかしくなってしまう。しかし、文書を見出しの付いたセクションに分けることができるのであれば、文書は理解しやすく、ナビゲートしやすいものになる。
達成基準2.4.10の具体的なメリット
全盲の利用者が、ウェブページのあるセクションからいつ別のセクションへ移動したのかが分かるようになり、各セクションの目的が分かるようになる。
何らかの学習障害のある利用者が、見出しを使うことによって、ページ全体のコンテンツの構造をより容易に理解できるようになる。
キーボードでコンテンツをナビゲートしている利用者が、フォーカスを見出しから見出しへとジャンプできるようになり、関心のあるコンテンツを素早く見つけることができるようになる。
一部のコンテンツを更新したページでは、見出しを使うことによって、更新したコンテンツへ素早く到達できるようになる。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準2.4.10の達成方法及び不適合事例 - セクション見出し
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
2.4.10 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 2.4.10のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準2.4.10に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
重要な用語
- セクション (section)
一つ以上の関連する話題、又は考えについて書かれたコンテンツの自己完結している部分。
注記:
セクションは一つ以上の段落から成ることがあり、画像、表、リスト、及びサブセクションを含むこともある。
- ユーザインタフェース コンポーネント (user interface component)
コンテンツの一部分で、特定の機能を実現するための単一のコントロールとして利用者が知覚するもの。
注記 1:
複数のユーザインタフェース コンポーネントが、単一のプログラム要素で実装されることもある。ここでいうコンポーネントは、プログラムの手法と結びついたものではなく、利用者が別々のコントロールとして知覚するものを指す。
注記 2:
ユーザインタフェース コンポーネントには、フォーム要素、リンクだけでなく、スクリプトで生成されるコンポーネントが含まれる。
事例: アプレットには、コンテンツ内を行単位、ページ単位、又はランダムアクセスで移動するために用いられる「コントロール」がある。これらには、いずれも名前 (name) を割り当て、個別に設定できるようにする必要があるため、それぞれが「ユーザインタフェース コンポーネント」となる。
読みやすさ:
ガイドライン3.1を理解する
ガイドライン3.1:
テキストのコンテンツを読みやすく理解可能にすること。
ガイドライン 3.1 の意図
このガイドラインの意図は、利用者及び支援技術がテキストのコンテンツを読めるようにすること、そして理解するのに必要な情報を提供することである。
障害のある利用者は、テキストを様々な方法で利用している。ある利用者はテキストを視覚的に利用していたり、また聴覚的に利用していたり、あるいは触覚的に利用していたり、それ以外にも視覚と聴覚両方で利用していたりもする。書かれた文章を理解するのは困難であっても、そのテキストが音声で読み上げられたり、重要なプロセスや考えが図画によって視覚的に示されていたり、手話で通訳されていたりすると、かなり複雑で高度な内容の文書でも理解することができる利用者もいる。また、利用者によっては、前後の文脈から単語又は語句の意味を推察するのが困難なことがある。特に、その単語又は語句が一般的ではない方法で用いられていたり、特別な意味を持たせられていたりするときには困難である。そういった利用者の読解力及び理解力は、特定の定義又は頭字語あるいは略語の元の語句が参照可能かどうかにより変わってくる。ユーザエージェントは、音声読み上げソフト及びグラフィカルなアプリケーションを含めて、テキストの言語及び文字を書く方向が示されていないと、テキストを正しく提示できないことがある。ほとんどの利用者にとっては大した問題にはならないかもしれないが、障害のある利用者にとっては非常に大きな障壁となりえる。（例えば、日本語の特定の漢字など）発音に関する情報がないと言葉の意味が判断できないような場合、発音（読み）に関する情報も提供しなければならない。
ガイドライン 3.1 の参考にすべき達成方法(特定の達成基準に特有ではない達成方法)
このガイドラインにある各達成基準を満たすための達成方法は、この後に達成基準ごとに挙げられている。しかし、このガイドラインに対処するための達成方法がどの達成基準にも該当しない場合は、ここで挙げている。そういった達成方法は、どの達成基準を満たす上でも必須ではないし、十分でもないが、ウェブコンテンツの種類によってはより多くの利用者にとってよりアクセシブルにすることができるものである。
ページ中のコンテンツのうち、制作者が制御できないソースに基づくものについて、そのコンテンツに関する情報を提供する（リンク追加予定）
すべてのコンテンツは、手話による通訳を提供する（リンク追加予定）
そのコンテンツに対して適切な、最も明解で単純な表現を用いる（リンク追加予定）
テキストの中寄せを行わない（リンク追加予定）
単語間やも文字間の空白に影響を与える、テキストの均等割り付けを行わない（リンク追加予定）
テキストは、左から右へ書く原語においては左寄せし、右から左へ書く原語においては右寄せする（リンク追加予定）
テキストのコラム幅を制限する（リンク追加予定）
部分的なイタリック体を用いない（リンク追加予定）
個別のページ及びサイトの中で用いるスタイルの種類を増やしすぎない（リンク追加予定）
リンクは、他のテキストと視覚的に区別できるようにする（リンク追加予定）
画像、イラスト、動画、音声、シンボルなどを用いてコンテンツの意味を明確にする（リンク追加予定）
現実的な例を示して、コンテンツの意味を明確にする（リンク追加予定）
黒のテキストに白の背景色を用いるのではなく、明るいパステル・カラーを背景色に用いる（リンク追加予定）
必要性がない特殊なインタフェース・コントロールを用いない（リンク追加予定）
その原語におけるスペリングの規則に従って、適切な形で大文字と小文字を使い分ける（リンク追加予定）
一般的ではない外来語の使用を避ける（リンク追加予定）
コンテンツを利用する上で理解する必要がある情報、考え方、操作手順の手話版を提供する（リンク追加予定）
ウェブページ上の特定の場所を参照している場合、その場所へのリンクを提供する（リンク追加予定）
見出しやタイトルを参照する場合、完全なタイトルを含むようにする（リンク追加予定）
管理者への連絡方法を含む、ウェブページ一式に関する基本的な情報について、容易に読めるバージョンを提供する（リンク追加予定）
管理者への連絡方法を含む、ウェブページ一式に関する基本的な情報について、手話バージョンを提供する（リンク追加予定）
ページの言語:
達成基準 3.1.1 を理解する
この達成基準の意図
この達成基準の意図は、ユーザエージェントがテキスト及びその他の形式の自然言語によるコンテンツを正しく提示するために必要な情報を、コンテンツ制作者がウェブページで適切に提供するようにすることである。支援技術と従来のユーザエージェントはともに、ウェブページの言語が示されていれば、テキストをより正確に描画することができる。例えば、スクリーンリーダーは、正しい発音規則を読み込むことができ、ビジュアルブラウザは、文字や書体を正しく表示することができる。また、メディアプレーヤーは、キャプションを正しく表示できる。これにより、障害のある利用者がコンテンツをより理解できるようになる。
Internationalization Best Practices: Specifying Language in XHTML & HTML Content で述べられているように、ウェブページのデフォルトの自然言語が、デフォルトのテキスト処理言語となる。ウェブページがいくつかの言語を使用している際、デフォルトのテキスト処理言語は、最も使われている言語である（もし同じ割合で使われている際には、最初に使われている言語がデフォルトの自然言語となるはずである）。
注記: 適合レベル A を目指している多言語サイトについて、WCAG ワーキンググループはコンテンツ制作者に、レベル AA の達成基準ではあるが、達成基準 3.1.2 にも同じように適合することを強く推奨する。
達成基準3.1.1の具体的なメリット
この達成基準には、次のような利用者にメリットがある：
スクリーンリーダー又はテキストを合成音声に変換するその他の技術を使用している利用者。
例えば、文字及びアルファベットを認識したり、単語を読み取ったりすることのように、書かれたものを流暢かつ正確に読むのが困難な利用者。
テキストを音声に変換するソフトウェアを使用している、特定の認知の障害、言語の障害、及び学習障害のある利用者。
同期したメディアではキャプションを頼りにしている利用者。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準3.1.1の達成方法及び不適合事例 - ページの言語
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
3.1.1 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 3.1.1のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準3.1.1に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
重要な用語
- ウェブページ (Web page)
単一の URI から HTTP で得た埋め込まれていないリソースに加え、
レンダリングに使われる、又はユーザエージェントがこのリソースと一緒にレンダリングすることを意図しているその他のあらゆるリソースを合わせたもの。
注記 1:
どのような「その他のリソース」も主たるリソースと一緒にレンダリングされるであろうが、これらのリソースが同時にレンダリングされるとは限らない。
注記 2:
このガイドラインの適合範囲に含まれる対象となるウェブページとみなされるためには、リソースが「埋め込まれていない」リソースでなければならない。
事例 1:
すべての埋め込まれている画像とメディアを含んだウェブリソース。
事例 2:
Asynchronous JavaScript and XML (AJAX) を用いたウェブメールのプログラム。そのプログラム全体は http://example.com/mail に存在しているが、受信箱、アドレス帳、カレンダーがある。リンクまたはボタンがあり、それを押すと受信箱、アドレス帳やカレンダーを表示するが、ページの URI は全体を通して変わらない。
事例 3:
カスタマイズ可能なポータルサイトで、利用者が様々なコンテンツモジュールのセットから表示させるコンテンツを選択できるようなもの。
事例 4:
ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、 ウェブサイトの中のほんの1ページなのかもしれない。
- プログラムによる解釈 (プログラムによる解釈が可能) (programmatically determined (programmatically determinable))
支援技術
を含む様々なユーザエージェントが抽出でき、利用者に様々な感覚モダリティで提示できるような形のデータがコンテンツ制作者によって提供されたとき、そのデータがソフトウェアによって解釈されること。
事例 1:
マークアップ言語で、一般に入手可能な支援技術が直接アクセスできる要素と属性から解釈される。
事例 2:
非マークアップ言語の技術特有のデータ構造から解釈され、一般に入手可能な支援技術がサポートするアクセシビリティ API を通じて支援技術に提供される。
- 自然言語 (human language)
人間とコミュニケーションをとるための言語で、話される、書かれる、又は (視覚的あるいは触覚的な手段で) 手話にされるもの。
一部分の言語:
達成基準 3.1.2 を理解する
3.1.2 一部分の言語: コンテンツの一節、又は語句それぞれの自然言語がどの言語であるか、プログラムによる解釈が可能である。ただし、固有名詞、技術用語、言語が不明な語句、及びすぐ前後にあるテキストの言語の一部になっている単語又は語句は除く。
(レベル AA)
この達成基準の意図
この達成基準の意図は、複数の言語で書かれているコンテンツをユーザエージェントが正しく提示できるようにして、利用者がテキストを理解するのを助ける支援技術が、その言語を処理する上で必要な特有の知識及びリソースを適切に用いることができるようにすることである。これは、グラフィカルブラウザ及びスクリーンリーダー、点字ディスプレイ、そしてその他の音声ブラウザに当てはまる。
支援技術及び従来のユーザエージェントはともに、テキストを構成する節それぞれの記述に用いられている言語が示されていると、テキストをより正確に描画できる。スクリーンリーダーは、テキストの言語の発音規則を用いることができる。また、ビジュアルブラウザは文字及び書体を適切に表示することができる。左から右へ読む言語と右から左へ読む言語が切り替わる際、又はテキストが異なる種類のアルファベットを用いる言語で描画される際に、特にこれは重要である。そのウェブページで用いられているすべての言語を理解できる場合、テキストを構成する節それぞれが適切に描画されると、障害のある利用者は、コンテンツをよりよく理解できるようになる。
テキスト中の語句又は一説に何も言語が指定されていない場合、その語句や説の自然言語は、そのウェブページのデフォルトの自然言語となる（達成基準 3.1.1 を参照）。そのため、単一の言語で記述されたドキュメントの場合は、すべてのコンテンツの自然言語をプログラムが解釈できることになる。
ある言語の個々の単語又は語句が、他の言語の一部になることがある。例えば、"rendezvous" は、英語に持ち込まれたフランス語の単語で、英語の辞書にも掲載されているし、英語のスクリーンリーダーでも適切に発音される。それゆえ、英語のテキストの一節に "rendezvous" という単語が、その自然言語がフランス語であることが示されることなく含まれていることがあるが、これはこの達成基準を満たしていることになる。しばしば、テキストの自然言語が一つの単語に対してだけ変化するようなとき、その単語は周囲にあるテキストの言語の一部となっていることがある。これは、言語によっては一般的なことなので、言語を意図的に変えていることが明白でない限り、その単語は周囲にあるテキストの言語の一部であるとみなすべきである。言語を意図的に変えているかどうかが疑わしい場合は、その単語が隣接するテキストの言語で同じように発音されるかどうかを考えてみるとよいだろう（ただし、アクセントやイントネーションは除く）。
ほとんどの専門的な職業では、もともとは外国語からきた技術用語を頻繁に使うことを必要とする。そのような用語は、通常すべての言語に翻訳されるわけではない。技術用語は広く共通のものが用いられる傾向があり、専門家の間でのコミュニケーションの促進につながっている。
技術用語のよくある例としては、次のようなものがある： ホモ・サピエンス (Homo sapiens)、アルファケンタウリ (Alpha Centauri)、ヘルツ (hertz)、ヘイビアス・コーパス (habeas corpus) など。
言語の変化を示すことは、多くの理由から重要である：
点訳ソフトウェアが言語の変化に従うことができるようになる。例えば、アクセント文字を適切な符号に置き換えたり、必要な符号を挿入し、2級点字の縮字の誤りを回避したりすることができる。
複数の言語をサポートしている合成音声を用いて、テキストを適切なアクセントと正確な発音で読み上げさせることができるようになる。言語の変化が示されていない場合、合成音声のシステムはその単語をデフォルトの言語として読み上げるのに最善を尽くそうとする。したがって、フランス語で自動車を表す "voiture" は、英語をデフォルトの言語として用いている合成音声では "voyture" というような音で発音されてしまう。
言語の変化を示すことで、将来の技術の開発にも役立つことがある。例えば、複数の言語の間での翻訳をすることができない利用者が、機械翻訳を使って馴染みのない言語を扱うことができるようになるかもしれない。
また、言語の変化を示しておけば、ユーザエージェントが辞書を用いて用語の定義を提供するのを支援することもできるだろう。
達成基準3.1.2の具体的なメリット
この達成基準は、次のような利用者にメリットがある：
スクリーンリーダー又はテキストを合成音声に変換するその他の技術を使用している利用者。
例えば、文字及びアルファベットを認識したり、単語を読み取ったりすることのように、書かれたものを流暢かつ正確に読むのが困難な利用者。
テキストを音声に変換するソフトウェアを使用している、特定の認知の障害、言語の障害、及び学習障害のある利用者。
同期したメディアのコンテンツの音声トラックでの言語の変化を識別するのに、キャプションを頼りにしている利用者。
達成基準 3.1.2の事例
英語の文章中にあるドイツ語の一節
文章中に "He maintained that the DDR (German Democratic Republic) was just a ' Treppenwitz der Weltgeschichte'," とあり、ドイツ語の一節 'Treppenwitz der Weltgeschichte' がドイツ語であることが示されている。マークアップ言語によっては、特定している箇所を除いては英語を文書全体の言語として示すこともできるし、段落レベルで示すこともできる。スクリーンリーダーがドイツ語の一節を読み上げる際は、その単語を正確に発音するために、発音規則を英語からドイツ語に変更する。
代わりの言語へのリンク
ある HTML のウェブページには、そのページの他言語版へのリンクがある（例： Deutsch, Français, Nederlands, Castellanoなど）。それぞれのリンクのテキストは言語名で、その言語で書かれている。リンクの言語はそれぞれ、lang 属性で示されている。
フランス語の文章中で使われている "Podcast"
"podcast" は、次の引用ではすぐ周囲にあるテキストの言語の一部である。"A l'occasion de l'exposition "Energie eternelle. 1500 arts d'art indien", le Palais des Beaux-Arts de Bruxelles a lance son premier podcast. Vous pouvez telecharger ce podcast au format M4A et MP3," この場合、言語の変化を示す必要はない。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準3.1.2の達成方法及び不適合事例 - 一部分の言語
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
3.1.2 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 3.1.2のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準3.1.2に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
重要な用語
- プログラムによる解釈 (プログラムによる解釈が可能) (programmatically determined (programmatically determinable))
支援技術
を含む様々なユーザエージェントが抽出でき、利用者に様々な感覚モダリティで提示できるような形のデータがコンテンツ制作者によって提供されたとき、そのデータがソフトウェアによって解釈されること。
事例 1:
マークアップ言語で、一般に入手可能な支援技術が直接アクセスできる要素と属性から解釈される。
事例 2:
非マークアップ言語の技術特有のデータ構造から解釈され、一般に入手可能な支援技術がサポートするアクセシビリティ API を通じて支援技術に提供される。
- 自然言語 (human language)
人間とコミュニケーションをとるための言語で、話される、書かれる、又は (視覚的あるいは触覚的な手段で) 手話にされるもの。
一般的ではない用語:
達成基準 3.1.3 を理解する
この達成基準の意図
特定の障害によって、文字通りの意味ではない言葉の使い方や特殊な言葉の意味や使い方を利用者が理解しづらいことがある。また、比喩的な言い回し又は特殊な使い方を理解しづらくする障害もある。そのような障害のある利用者に対しては、この達成基準に適合するメカニズムを提供することが不可欠である。専門家ではない読者向けに特殊な情報を提供する際は、レベル A、又は、レベル AA での適合をしようとしている場合であっても、この達成基準にも適合することを推奨する。
達成基準3.1.3の具体的なメリット
この達成基準は、認知の障害、言語の障害、及び学習障害のある次のような利用者に役立つ：
文字から単語を復号しづらい。
単語及び語句を理解しづらい。
前後の文脈を用いて理解するのが困難である。
また、視覚障害のある次のような利用者にも役立つ：
達成基準 3.1.3の事例
一般的ではない使われ方をしている単語の定義があるテキスト
他の情報源からの情報を「カスケード表示」に表示するのではなく、定義検索で意図した定義が見つかるように、リスト又は辞書とその他のリソースの「カスケード表示」を整理する。（「カスケード表示」には、辞書及びその他の参考文献を最も正しい定義を提示しそうな順序で一覧表示する。これは、定義を検索している際に、チェックすべき順序を制御している。）
用語集に定義を掲載する
WCAG 2.0 では、「テキスト」という単語を特別な用法で用いている。そこで、WCAG 2.0 で「テキスト」という単語が使われているときは、同じウェブページにある用語集で提供されている「テキスト」の定義へリンクしている。
ページ末尾で単語の具体的な定義を提供する
ページ上の単語に、その単語の定義へのページ内リンクが提供されている。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
注記: 次のリストにある製品名又はベンダー企業名は、WCAG ワーキンググループ又は W3C の WAI による推薦を意味するものではない。このリストは、単に便宜を提供するだけのものであり、どのようなリソースが参照可能なのかを知らせるだけのものである。
達成基準3.1.3の達成方法及び不適合事例 - 一般的ではない用語
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
達成基準を満たすことのできる達成方法
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の達成方法（又は、達成方法の組合せ）がある。
3.1.3 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
特殊な意味を持つ言葉を利用者が認識できるようなマークアップや視覚的フォーマットを行う（リンク追加予定）
音声で検索できる辞書を提供し、キーボードの操作や単語を綴ることが難しい利用者が発声することで言葉の意味を検索できるようにする（リンク追加予定）
手話による辞書を提供し、聴覚障害者による言葉の意味の検索を支援する（リンク追加予定）
テキストコンテンツ中のすべての言葉の定義を検索できるようなメカニズムを提供する（リンク追加予定）
テキストコンテンツ中のすべての単語や語句について、その意味を判断するためのメカニズムを提供する（リンク追加予定）
一般的でない外来語の使用を避ける（リンク追加予定）
一連の辞書をカスケード式に表示して意味を提供する（リンク追加予定）
達成基準 3.1.3のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準3.1.3に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
重要な用語
- メカニズム (mechanism)
結果を得るためのプロセス又は手法。
注記 1:
メカニズムは、コンテンツ内で明示的に提供されることもあれば、プラットフォーム又は支援技術を含むユーザエージェントで提供されるものに 依存することもある。
注記 2:
メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。
- 一般的ではない、又は限定された用法で使われている (used in an unusual or restricted way)
そのコンテンツを正しく理解するために、どの定義で使われているのかを利用者が正確に知る必要があるような使われ方をしている言葉。
事例: "gig" という用語は、音楽コンサートの話の中で使われている場合、コンピュータのハードディスクドライブの容量に関する記事とは違うことを意味するが、適切な定義は文脈から判断できる。それに対して、「テキスト」という言葉は、WCAG 2.0では非常に特定された意味で使われており、その定義が用語集で提供されている。
- 専門用語 (jargon)
特定の分野の人々が特定の用法で用いる単語。
事例: 固定キーという用語は、支援技術やアクセシビリティの分野における専門用語である。
- 慣用句 (idiom)
個々の単語の意味からはその意味を推測できず、特定の単語を変えると意味が通じなくなる言い回し。
注記: 慣用句は、単語単位で直接翻訳すると、その (文化的あるいは言語特有の) 意味が通じなくなる。
事例 1:
英語では、"spilling the beans" (豆をこぼす) は「秘密を漏らす」という意味である。しかし、"knocking over the beans" (豆をひっくり返す) や"spilling the vegetables" (野菜をこぼす) は同じ意味にはならない。
事例 2:
日本語では、「さじを投げる」という言い回しは、逐語訳では "he throws a spoon"となるが、「どうすることもできずに諦める」という意味である。
事例 3:
オランダ語では、"Hij ging met de kippen op stok"は、逐語訳すれば「彼はニワトリとねぐらについた」となるが、「彼は早く寝た」という意味である。
略語:
達成基準 3.1.4 を理解する
この達成基準の意図
この達成基準の意図は、利用者が略語の元の語句を知ることができるようにすることである。
達成基準3.1.4の具体的なメリット
この達成基準は、次のような利用者にメリットがある：
略語は様々なかたちで利用者を混乱させることがある：
略語の中には、普通の単語のようには見えなくて、その言語の通常の規則に従って発音できないものがある。例えば、英語の単語 "room" には "rm," という略語があるが、英語のどの単語又は音素にも該当するものがない。利用者が正しく読むためには、"rm" が "room" という単語の略語であるということを知っていなければならない。
時には、同じ略語であっても、異なる文脈においては異なる意味になることがある。例えば、英語の文章 "Dr. Johnson lives on Boswell Dr.," の場合、最初の "Dr." は "Doctor" の略語で、2つめは "Drive" の略語である（「通り」という意味の単語)。利用者がその略語がどういう意味なのかを知るためには、前後の文脈を理解できなければならない。
頭字語には、よくある単語と同じスペルだが、異なる意味で使われているものがある。例えば、"JAWS" は "Job Access with Speech." というスクリーンリーダーの頭字語である。それは、顎（あご）のことを指す英語の単語でもある。この場合、頭字語がよく使われる単語とは異なる意味で用いられている。
頭字語の中には、よくある単語と同じように発音するが、綴りが異なるものもある。例えば、Synchronized Multimedia Integration Language の頭字語である S M I L は、英語の単語の "smile" と同じように発音する。
また、視覚障害のある次のような利用者にも役立つ：
達成基準 3.1.4の事例
コンテンツ中で初めて使用されているところで元の語句が提供されている略語
"World Wide Web Consortium" という名前が、ウェブページの最初の見出しとして使われている。略語の "W3C" が同じ見出しで括弧書きで示されている。
辞書検索フォーム
あるウェブサイトには、オンライン頭字語辞書サービスが提供する検索フォームが設置されている。利用者が頭字語を入力すると、検索結果として、考えられうる元の語句の一覧が表示される。
医療系ウェブサイト
医療系のあるウェブサイトは、医者と患者の両方に情報を提供している。そのサイトには、カスケード式の辞書がある。とても専門的な医学辞書が最初で、一般向けの医学辞書が二番目にある。また、カスケードには、そのサイト固有の頭字語及び略語があり、最後に普通の辞書もある。リストの最後にある普通の辞書は、テキストにあるほとんどの単語の定義を提供している。また、専門的な医学辞書は、一般的ではない医学用語の定義を提供している。複数の辞書にある単語の定義は、カスケードの順序で一覧表示される。頭字語及び略語の意味は、頭字語及び略語の一覧が提供している。
略語の元の語句
それぞれの略語の元の語句が、プログラムで判断可能な方法で提供されている。テキストを読み上げるユーザエージェントは、その元の語句を用いて略語を読み上げることができる。その他のユーザエージェントは、ツールチップ又は状況に応じたヘルプで、その略語の元の語句を提供することができるかもしれない。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準3.1.4の達成方法及び不適合事例 - 略語
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
達成基準を満たすことのできる達成方法
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の達成方法（又は、達成方法の組合せ）がある。
3.1.4 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
そのウェブページ上で一意な略語を用いる（リンク追加予定）
利用者が略語を認識しやすいような視覚的フォーマットを用いる（リンク追加予定）
音声読み上げ機能がある辞書の利用を可能にし、表示された文字情報を復号化することが困難な利用者を支援する（リンク追加予定）
音声で検索できる辞書を提供し、キーボードの操作や単語を綴ることが難しい利用者が発声することで言葉の意味を検索できるようにする（リンク追加予定）
達成基準 3.1.4のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準3.1.4に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
重要な用語
- メカニズム (mechanism)
結果を得るためのプロセス又は手法。
注記 1:
メカニズムは、コンテンツ内で明示的に提供されることもあれば、プラットフォーム又は支援技術を含むユーザエージェントで提供されるものに 依存することもある。
注記 2:
メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。
- 略語 (abbreviation)
単語、語句、又は名称の短縮形で、その略語が言語の一部になっていないもの。
注記 1:
これは、頭文字語及び頭字語を含む:
頭文字語は、その名称あるいは語句に含まれる単語や音節の頭文字による、名称あるいは語句の短縮形である。
注記 1:
すべての言語で定義されているわけではない。
事例 1:
SNCFは、フランス語の頭文字語で、フランス国有鉄道の "Societe Nationale des Chemins de Fer "の頭文字を含んでいる。
事例 2:
ESPは、"extrasensory perception"の頭文字語である。
頭字語
は、 (名称や語句の中の) 頭文字あるいは他の単語の一部から作られた省略形で、一つの単語のように発音されることがあるものである。
事例: NOAAは、米国の "National Oceanic and Atmospheric Administration" の頭文字による頭字語である。
注記 2:
頭文字語だったものを社名として採用している会社がある。そのような場合、その会社の新しい社名はその文字列であるにすぎず (例: Ecma)、その単語はもはや略語とは考えられない。
読解レベル:
達成基準 3.1.5 を理解する
3.1.5 読解レベル: 固有名詞や題名を取り除いた状態で、テキストが前期中等教育レベルを超えた読解力を必要とする場合は、補足コンテンツ又は前期中等教育レベルを超えた読解力を必要としない版が利用できる。
(レベル AAA)
この達成基準の意図
コンテンツは、可能な限り明快かつ簡潔に書かれているべきである。この達成基準の意図は以下の通りである：
この達成基準は、コンテンツ制作者が難しい又は複雑なウェブコンテンツを公開できるようにしながらも、読字障害のある利用者の手助けとなる。文章の難しさは、それを読むのに必要とされる教育の水準という観点から説明されている。教育レベルは、教育システムを国際的に比較できるようにするために作成された国際標準教育分類 [UNESCO] に従って定義している。
難しい又は複雑な文章が、想定した利用者層のほとんど（つまり、コンテンツの対象者のほとんど）に対しては適切なこともある。しかし、その分野における専門的な知識を持つ高学歴の利用者の中にも、読字障害を含めて、障害のある利用者がいる。文章をより読みやすくすることで、そういった利用者にも対処することが可能である。文章をそれ以上読みやすくすることができない場合には、補足的コンテンツが必要となる。補足的コンテンツが必要となるのは、その文章が前期中等教育レベル以上の読解力が求められる場合である。つまり、9年よりも長い学校教育を受けている必要がある場合である。補足的コンテンツが必要となるような文章は、読字障害のある利用者にとっては深刻な障壁となり、後期中等教育を修了した障害のない利用者にとっても難解であると考えられている。
書かれた単語又は印刷された単語を認識して、正しい音と関連付ける処理を文章の「復号化」という。ディスレクシア（失読症）などの読字障害は、文章の復号化をしづらくする。 復号化は、人がすらすらと読むためには、無意識に行われるものである。文章を1単語ずつ復号化しなければならない場合、多くの人が自分の読んでいるものを理解するために用ている精神的なエネルギーの多くを、この行為に消費しなければならないことになる。簡潔でよく使われる単語及び簡潔な文を用いた文章は復号化しやすく、長文及び長い単語又は馴染みのない単語を用いている文章ほどの読解力を通常は必要としないものである。
テキストのコンテンツを読むのに必要な教育レベル（リーダビリティ (readability) とも呼ばれる）は、ウェブページ上の文章から抽出した節を解析することで測定することができる。ウェブページに異なる目的で書かれた文章、又は異なるスタイルを用いた文章がある場合は、ウェブページにあるコンテンツの種類のサンプル、及びそのコンテンツが書かれている異なるスタイルのサンプルを含める（多くの場合、ウェブページには、1つの種類のテキストコンテンツしかない。例えば、技術的な文書、法律上の表示、マーケティング素材など。そして、すべてのコンテンツは同じスタイルを用いている）。
教育者もまた、テキストコンテンツを読むのに必要とされる教育レベルを測定することができる。例えば、資格のある教師は、前期中等教育の最終学年の生徒に要求される以上の読解力を必要とするかどうかを判断するために、ローカルの教育標準に従って文章を評価することができる。
人名、都市名、又はその他の固有名詞を変更して短くすることはできないため、そしてそうすることや単に代名詞でそれらを指すことは文章を理解しづらくする恐れがあるため、この達成基準では、読解力の要件を満たしているかどうかを検証する際には、固有名詞を無視するか文章から取り除くことができるとしている。タイトルは、文書、書籍、映画などの名前のことを指している。タイトルにある文言を変更してしまうと、読みやすくはなるかもしれないが、そのタイトルがどのアイテムを指しているのかが分からなくなってしまうため、分析する際にはタイトルを削除するか無視してもよい。そのため、タイトルも、明確に適用対象外となる。
ウェブページに複数の言語があるときは、リーダビリティの検証結果は、コンテンツの少なくとも5％を占めていて、全文又は段落全体で使われている言語ごとに算出すべきである（個々の単語又は語句だけというのは除く）。そして、そのページ全体のリーダビリティは、最も悪い結果を出した言語で判断しなければならない。
また、コンテンツのリーダビリティは、抽出した節にリーダビリティの計算式を適用することで判断できることもある。（すべてではないが）多くのリーダビリティの計算式は、100ワードで計算している。そのような計算式が、多くの言語に対して作られている。その節にある単語の数を数えて、単語の長さを音節の数又は文字数のどちらかを数えて判断している。ほとんどのリーダビリティ計算式は、文の長さと数も考慮に入れている。そして、コンテンツの単語及び文の平均的な長さを用いて、リーダビリティのスコアを算出している（日本語のような言語では、同じ節の中に2種類の文字が含まれていることがある。このような言語のリーダビリティ計算式は、その「連続」の数及び長さも計算に入れているかもしれない）。計算結果は、数字（例えば、0箸ｷ100の範囲）又は学年で提示される。そして、この結果を国際標準教育分類にある教育レベルを用いて評価することができる。リーダビリティの計算式は、少なくともいくつかの言語では、人気のあるソフトウェアのスペルチェック機能で利用可能で、オプションで文書のチェック完了時にリーダビリティの解析結果も表示するように指定することができる。
教育レベル| 初等教育 | 前期中等教育 | 後期中等教育 | 高等教育 |
|---|
| 学校教育の最初の6年 | 学校教育の7〜9年目 | 学校教育の10〜12年目 | 13年目以降の学校教育 |
出典： 国際標準教育分類 [UNESCO]
注記: Open Society Mental Health Initiative によれば、読みやすさの概念は万国共通ではなく、読み書きと理解に問題を抱えたすべての人の能力に合致する文章を書くことは不可能だろうといわれている。最も明快で、かつ最も簡易な言葉遣いを用いることが非常に望ましいが、WCAG ワーキンググループではそれが達成されているかどうかを検証する方法を見つけることができなかった。読解レベルを用いているのは、明快な文章を推奨する達成基準にテスト可能性を持たせるためである。認知の障害の種類や程度によっては、補足的コンテンツを提供することが効果的な達成方法の一つとなりえる。
達成基準3.1.5の具体的なメリット
この達成基準は、次のような利用者にメリットがある：
達成基準 3.1.5の事例
複雑な研究記事の読みやすい要約がある科学雑誌
ある科学雑誌には、その分野の専門家を対象とした、とても専門的な言葉遣いで書かれた記事がある。その雑誌の目次ページには、各記事の要約が平易な言葉で書かれている。その要約は、8年間の学校教育を受けた一般読者を想定している。また、雑誌のメタデータには、Dublin Core（ダブリン・コア）の仕様を用いて、記事の想定している読者の教育レベルを「高等教育」、要約の想定している読者の教育レベルを「前期中等教育」と示してある。
一般会員向けの医療情報
ある医科大学が、最近の医学的及び科学的発見を説明するウェブサイトを運営している。そのサイトの記事は、医療の知識のない人向けに書かれている。各記事では、Dublin Core（ダブリン・コア）のメタデータの仕様を用いて、想定している読者の教育レベルを「前期中等教育」と示し、その記事の Flesch Reading Ease のスコアも提供している。各ページにあるリンクをたどることで、教育レベル及びその他のメタデータを表示することができる。前期中等教育レベルの読者がその記事を読むことができるので、補足的コンテンツは必要ない。
E-ラーニング・アプリケーション
スペインの文化史に関するオンラインコースに、ムーア建築に関する単元がある。その単元のテキストは、様々な読解レベルを持った学生向けに書かれている。建築物の写真や画で、建築のコンセプト及び様式を図示している。グラフィック・オーガナイザーを用いて文章の複雑な関係性を図式化し、合成音声を用いた音声バージョンも提供している。各バージョンのメタデータでコンテンツの教育レベルを示し、スペイン語のテキスト向けに開発された計算式に基づくリーダビリティのスコアもある。この E-ラーニング・アプリケーションは、このメタデータ及び学生に関するメタデータを用いて、個々の学生のニーズに合ったバージョンの教材を提供している。
前期中等教育レベルの読解力を要する科学情報
次のテキスト（合計116ワード）は、Flesch-Kincaid 式によると、米国ではグレード 4.2 の読解力を必要とする。米国では、グレード 4.2 は初等教育レベルである。
Science is about testing ? and about looking closely. Some scientists use microscopes to take a close look. We're going to use a simple piece of paper.
Here's what you do: Print this page and cut out the square to make a "window" one inch square. (It's easiest to fold the page in half before you cut.)
Choose something interesting: a tree trunk, a leaf, flower, the soil surface, or a slice of soil from a shovel.
Put your window over the thing and look at it closely. Take your time ? this is not a race.
To help you see more details, draw a picture of what's inside your square.
Now let's think about what you've found.
（出典：Howard Hughes Medical Institute"CoolScience for Kids" Project)
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準3.1.5の達成方法及び不適合事例 - 読解レベル
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
3.1.5 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
前期中等教育レベル以上の読解力を必要としないテキストを用いて、ナビゲーション用のページとランディングページを提供する（リンク追加予定）
前期中等教育レベル以上の読解力を必要としないテキストを用いて、サイト内のページを提供する（リンク追加予定）
コンテンツの概要をメタデータの一部とし提供する（リンク追加予定）
コンテンツに適した最も明解で最も単純な表現を使用する（リンク追加予定）
RDFを用いて、補足的コンテンツと主たるコンテンツに関連づける（リンク追加予定）
サイトのホームページにそのサイトを表す分かりやすい画像を掲載する（リンク追加予定）
読みやすいように最適化されたコンテンツであることが分かるように、テキストやアイコンを用いて明示する（リンク追加予定）
冗長な単語の使い方、すなわち文の意味を変えない異なる単語を用いないで文を構成する（リンク追加予定）
二つより多い接続詞を含む文を使わない（リンク追加予定）
中等教育レベルで一般的に容認されている長さを超えない文を用いる（注記: 英語では 25 ワードである）（リンク追加予定）
複雑な単語又は語句で、より一般的な言葉で置き換えても文の意味が変わらない場合、複雑な単語や語句を含まない文を用いる（リンク追加予定）
テキストの複数の章や節の概要を提供する（リンク追加予定）
メタデータを用いて、異なる読解力を想定して作られた代替コンテンツを関連づける（リンク追加予定）
ダブリン・コアのアクセシビリティ要素を用いて、テキストコンテンツとテキスト、グラフィック、音声版の補足的コンテンツを関連づける（リンク追加予定）
ISO AFA のアクセシビリティ要素を用いて、テキストコンテンツとテキスト、グラフィック、音声版の補足的コンテンツを関連づける（リンク追加予定）
IMS のアクセシビリティ要素を用いて、テキストコンテンツとテキスト、グラフィック、音声版の補足的コンテンツを関連づける（リンク追加予定）
メタデータを利用者に見えるようにする（リンク追加予定）
サイトとページのコンテンツに進展する複雑性を与える（リンク追加予定）
達成基準 3.1.5のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準3.1.5に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
重要な用語
- 前期中等教育レベル (lower secondary education level)
6年間の学校教育卒業の後に始まり、初等教育の開始から9年後に終わる、2年、又は3年の教育期間。
注記: この定義は、"International Standard Classification of Education" [UNESCO]に基づいている。
- 補足コンテンツ (supplemental content)
元のコンテンツを説明、又はより明確にするために付加されたコンテンツ。
事例 1:
ウェブページの音声版。
事例 2:
複雑なプロセスを示したイラスト。
事例 3:
調査研究でなされた主要な成果及び提言を要約する段落。
発音:
達成基準 3.1.6 を理解する
3.1.6 発音: 文脈において、発音が分からないと単語の意味が不明瞭になる場合、その単語の明確な発音を特定するメカニズムが利用できる。
(レベル AAA)
この達成基準の意図
この達成基準の意図は、全盲の利用者、ロービジョンの利用者、及び読字障害のある利用者が、意味が発音に依存している場合に、コンテンツを理解しやすくすることである。発音（読み）が変わると、意味も異なってくる単語又は文字がある。そのような単語又は文字の意味は、文章の前後の文脈から通常は判断される。しかし、より複雑あるいは曖昧な文章の場合や、いくつかの 言語においては、読み方が分からないと、その単語の意味を容易に判断できない又は全く判断できないことがある。スクリーンリーダーが文章を読み上げている際に単語を誤った読み方で読み上げてしまうと、視覚的にその文章を読んでいる場合よりもずっと理解しづらくなってしまう可能性がある。読み方が分からない限り、その単語の意味が曖昧又ははっきりしない場合は、その読み方を何らかの手段で分かるようにする必要がある。
例えば、英語では、"desert"（見捨てる）と"desert"（砂漠）のように、スペルは同じでも発音と意味が異なる、同形異音異義語と呼ばれる単語がある。文章の前後の文脈から適切な発音を判断できる場合は、何もする必要はない。もし判断できないのであれば、適切な発音を判断することのできる何らかのメカニズムが必要となる。加えて、特定の文字に様々な読み方が存在する言語もある。例えば、日本語には、複数の読みを持つ漢字のような文字がある。スクリーンリーダーは、読み方に関する情報がないと、その文字を誤った読み方で読み上げてしまうことがある。正しく読み上げられなければ、そのコンテンツは利用者にとっては理解できないものになってしまうだろう。
達成基準3.1.6の具体的なメリット
この達成基準は、次のような利用者にメリットがある：
単語を復号化しづらい。
前後の文脈を用いて理解するのが困難である。
音声で読み上げる支援技術を使用している。
達成基準 3.1.6の事例
人名の読み方を提供
日本語のウェブコンテンツが、人名の漢字のすぐ後に読み仮名を提供している。読み仮名は、漢字の後に括弧書きで示されている。漢字で書かれた語句の読み仮名を提供することによって、画面を見ている利用者とスクリーンリーダーの両方が、その語句を正しく読む/読み上げることができるようになる。ただし、スクリーンリーダーは2回読み上げることになる。つまり、まず最初に誤った読み方かもしれない漢字を読み上げて、その後に正しい読み方を提供する読み仮名を読み上げる。
ruby 要素で読み仮名を提供
XHTML 1.1 を用いているウェブコンテンツが、語句の読み（発音）を示す ruby 要素を用いて、文字の上に読み仮名を提供している。
発音の音声ファイルを提供
ある文書に、発音が分からないとその意味を判断できない単語がある。単語にはそれぞれ、正しい発音を提供する音声ファイルへのリンクがある。利用者は、その単語の正しい発音を確認するためにそのリンクを選択することができる。
用語集で発音の情報を提供
ウェブページに用語集の章がある。用語集にある用語の中には、定義とあわせて発音の情報も提供されているものがある。そのコンテンツにある、発音が分からないと意味を判断できない単語には、用語集へのリンクがある。
いくつかの言語で共通の文字だが、発音は言語によって異なる文字の発音に関する情報があるテキスト
日本のある大学のウェブサイトに、中国語及び韓国語の学術的な文書から引用された短い節がいくつかある。その引用は、日本語のテキストと同じ文字を使って書かれている。そこで、中国語及び韓国語の文字の正しい発音を示すために、発音の情報が提供されている。
注記: 日本語では、「発音」というよりも「読み仮名」を示すためにruby 要素を用いる。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準3.1.6の達成方法及び不適合事例 - 発音
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
3.1.6 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
利用者が単語の発音を聴くことができるように、発音を音声ファイルで提供する（リンク追加予定）
テキスト・コンテンツ中で用いられているすべての外国語の発音の発音を確認するメカニズムを提供する（リンク追加予定）
テキスト・コンテンツ中のすべての単語又は語句の発音を確認するメカニズムを提供する（リンク追加予定）
達成基準 3.1.6のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準3.1.6に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
重要な用語
- メカニズム (mechanism)
結果を得るためのプロセス又は手法。
注記 1:
メカニズムは、コンテンツ内で明示的に提供されることもあれば、プラットフォーム又は支援技術を含むユーザエージェントで提供されるものに 依存することもある。
注記 2:
メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。
予測可能:
ガイドライン3.2を理解する
ガイドライン3.2:
ウェブページの表示や挙動を予測可能にすること。
ガイドライン 3.2 の意図
このガイドラインの意図は、障害のある利用者のために、複数のウェブページでコンテンツを予測可能な順序で提供すること、及び機能的でインタラクティブなコンポーネントのふるまいを予測可能にすることである。利用者がウェブページ全体の概観を把握するのが困難なことがある。例えば、スクリーンリーダーは、合成音声の一次元的な流れでコンテンツを提示するため、空間的な関係性を理解しづらくする。認知能力が低下した利用者は、コンポーネントがページによって異なる場所に表示されると混乱してしまうことがある。
例えば、画面拡大ソフトを使用している利用者は、常時画面の一部分だけしか見ていない。そのため、一貫性のあるレイアウトによって、ナビゲーションバーやその他の構成要素が見つけやすくなる。ウェブページ一式の中で、繰り返し用いられる構成要素を相対的に同じ順序で配置することにより、読字障害のある利用者が、各リンクのテキストを復号化するのに無駄な時間を費やすことなく、画面のある領域に集中することができるようになる。そして、手を十分に使えない利用者は、最少のキーストロークでタスクを完了できる方法をより容易に見つけ出すことができる。
ガイドライン 3.2 の参考にすべき達成方法(特定の達成基準に特有ではない達成方法)
このガイドラインにある各達成基準を満たすための達成方法は、この後に達成基準ごとに挙げられている。しかし、このガイドラインに対処するための達成方法がどの達成基準にも該当しない場合は、ここで挙げている。そういった達成方法は、どの達成基準を満たす上でも必須ではないし、十分でもないが、ウェブコンテンツの種類によってはより多くの利用者にとってよりアクセシブルにすることができるものである。
フォーカス時:
達成基準 3.2.1 を理解する
この達成基準の意図
この達成基準の意図は、利用者がコンテンツ内をナビゲートしている間、コンテンツの機能を予測可能にすることである。フォーカスを受け取ったときにイベントを起動することのできるすべてのコンポーネントは、コンテキストを変化させてはならない。コンポーネントがフォーカスを受け取ったときに起こるコンテキストの変化の例としては、次のようなものが挙げられる：
コンポーネントがフォーカスを受け取ると自動的に送信されてしまうフォーム。
フォーカスを受け取ると新しいウィンドウを開くコンポーネント
フォーカスを受け取ると他のコンポーネントにフォーカスを移動するコンポーネント
フォーカスはキーボード操作（例：コントロールにタブ移動する）もしくはマウス操作（例：テキストフィールドをクリックする）のいずれかによって移動させることができる。スクリプトによって実装しない限り、コントロール上にマウスを移動しても、フォーカスは移動しない。クリックすることによってコンテキストの変化を開始する可能性のある一部のコントロール（例：ボタン）に注意すべきである。
注記: ここでの"コンポーネント"が意味するものは"ユーザインタフェース エレメント"や"ユーザインタフェース コンポーネント'と呼ばれる。
達成基準 3.2.1の事例
事例 1： ドロップダウンメニュー
ページ上にあるドロップダウンメニューによって、利用者がリンク先を選択できるようになっている。利用者がキーボードを使用して下のほうにある項目を選択して（スペースキー又は Enter キーで）実行すると、新しいページへ移動する。しかし、利用者がドロップダウンメニューにある選択肢に移動した後、Escape キー又は Tab キーでそのプルダウンメニューから抜け出た場合には、フォーカスはドロップダウンの外へ移動するので、新しいページには移動しない。
不適合事例： ヘルプのダイアログ
テキストフィールドがフォーカスを受け取ると、そのテキストフィールドについての説明とオプションを提供するヘルプのダイアログウィンドウが開く。キーボードの利用者がウェブページの中を Tab キーで移動していると、利用者がそのテキストフィールドへ Tab キーで移動するたびに、キーボード・フォーカスをコントロールから奪って、ダイアログが開く。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準3.2.1の達成方法及び不適合事例 - フォーカス時
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
3.2.1 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 3.2.1のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準3.2.1に適合していないとみなした、よくある不適合事例である。
重要な用語
- コンテキストの変化 (changes of context)
ウェブページのコンテンツにおける大きな変化で、利用者が気づかないと、ウェブページ全体を一度に見ることのできない利用者を混乱させる恐れのあるもの。
コンテキストの変化には次に挙げるものの変化が含まれる:
ユーザエージェント
ビューポート
フォーカス
ウェブページの意味を変えるコンテンツ
注記: コンテンツの変化が、必ずコンテキストの変化になるとはかぎらない。アウトラインの展開、動的なメニュー、又はタブの切替などのコンテンツの変化は、それが上記のいずれか (例: フォーカス) を変更しないかぎり、コンテキストを変化させるとは限らない。
事例: 新しいウィンドウを開くこと、フォーカスを異なるコンポーネントへ移動させること、新しいウェブページへ移動すること (新しいウェブページへ移動したかのように思わせてしまうことも含む)、又はウェブページの内容を大きく再配置することなどは、コンテキストの変化の事例である。
入力時:
達成基準 3.2.2 を理解する
この達成基準の意図
この達成基準の意図は、データ入力又はフォーム・コントロールの選択の結果を予測可能にすることである。ユーザインタフェース要素の設定を変更すると、コントロールの状態を変化させ、その状態は利用者がそのユーザインタフェース要素とのやりとりを終了した後も持続する。つまり、チェックボックスを選択する、テキストフィールドにテキストを入力する、又はリストコントロールのオプションを選択すると、コンポーネントの設定を変更するが、リンク又はボタンを押下したときはそうはならない。コンテキストの変化は、その変化を知覚しづらい利用者、又は変化によって気を取られやすい利用者を混乱させてしまう恐れがある。コンテキストの変化が起こってもよいのは、そのような変化が利用者の操作に反応して起こることが明らかなときだけである。
注記: この達成基準の対象となるのは、コントロールの設定を変更したことによる状況の変化である。リンクやタブ・コントロール中のタブのクリックは、コントロールの選択・実行であり、コントロールの設定変更ではない。
注記: ここでいう”構成要素”ならびに”ユーザインタフェース構成要素”は”ユーザインタフェース要素”とも呼ばれる。
達成基準3.2.2の具体的なメリット
この達成基準は、インタラクティブなコンテンツをより予測可能にすることによって、障害のある利用者に役立つ。予期しないコンテキストの変化によって、視覚障害又は認知能力の低下している利用者はとても混乱してしまうので、コンテンツを利用できなくなってしまう。
コンテキストの変化に気づくことができない利用者は、サイトをナビゲートしている間に混乱した状態になりにくい。例えば、次のような利用者が当てはまる：
ロービジョンの利用者、読字及び知的障害のある利用者、そして視覚的な手がかりを解釈しづらい利用者は、コンテンツ制作者が手がかりを追加することによって、コンテキストの変化に気づくようになる。
達成基準 3.2.2の事例
ウェブベースのカレンダー及びスケジュール管理アプリケーションに、カレンダーへのエントリーを作成するフォームがある。件名、時刻、場所を入力する標準的なテキストフィールドとあわせて、カレンダーへのエントリーの種類を選択するラジオボタン一式がある。その種類には、会議、アポイントメント、又はリマインダなどがある。利用者が「会議」のラジオボタンを選択すると、会議の参加者を入力するためのテキストフィールドがページ上に追加で表示される。また、「リマインダ」を選択すれば、異なったテキストフィールドが表示される。この場合、入力部分だけが変化し、全体の構造は同じままなので、基本的に状況は変化していないといえる。
フォームに、米国の電話番号を入力するテキストフィールドがある。すべての電話番号には、3桁のエリアコードがあり、その後に3桁の局番、そして最後に4桁の番号があり、それぞれの番号は別々のテキストフィールドに入力するようになっている。利用者があるテキストフィールドの入力を終えて、次のテキストフィールドの最初の桁を入力しようとすると、フォーカスが自動的に次のフィールドへ移動する。このふるまいは、フォームの先頭で利用者に対して説明されている。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準3.2.2の達成方法及び不適合事例 - 入力時
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
3.2.2 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 3.2.2のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準3.2.2に適合していないとみなした、よくある不適合事例である。
重要な用語
- コンテキストの変化 (changes of context)
ウェブページのコンテンツにおける大きな変化で、利用者が気づかないと、ウェブページ全体を一度に見ることのできない利用者を混乱させる恐れのあるもの。
コンテキストの変化には次に挙げるものの変化が含まれる:
ユーザエージェント
ビューポート
フォーカス
ウェブページの意味を変えるコンテンツ
注記: コンテンツの変化が、必ずコンテキストの変化になるとはかぎらない。アウトラインの展開、動的なメニュー、又はタブの切替などのコンテンツの変化は、それが上記のいずれか (例: フォーカス) を変更しないかぎり、コンテキストを変化させるとは限らない。
事例: 新しいウィンドウを開くこと、フォーカスを異なるコンポーネントへ移動させること、新しいウェブページへ移動すること (新しいウェブページへ移動したかのように思わせてしまうことも含む)、又はウェブページの内容を大きく再配置することなどは、コンテキストの変化の事例である。
- ユーザインタフェース コンポーネント (user interface component)
コンテンツの一部分で、特定の機能を実現するための単一のコントロールとして利用者が知覚するもの。
注記 1:
複数のユーザインタフェース コンポーネントが、単一のプログラム要素で実装されることもある。ここでいうコンポーネントは、プログラムの手法と結びついたものではなく、利用者が別々のコントロールとして知覚するものを指す。
注記 2:
ユーザインタフェース コンポーネントには、フォーム要素、リンクだけでなく、スクリプトで生成されるコンポーネントが含まれる。
事例: アプレットには、コンテンツ内を行単位、ページ単位、又はランダムアクセスで移動するために用いられる「コントロール」がある。これらには、いずれも名前 (name) を割り当て、個別に設定できるようにする必要があるため、それぞれが「ユーザインタフェース コンポーネント」となる。
一貫したナビゲーション:
達成基準 3.2.3 を理解する
この達成基準の意図
この達成基準の意図は、ウェブページ一式の中で繰り返し用いられるコンテンツを利用し、特定の情報又は機能を複数回にわたって見つける必要がある利用者のために、一貫したプレゼンテーション及びレイアウトの使用を推奨することである。画面拡大ソフトを使用して一度に画面の限られた狭い領域を表示しているロービジョンの利用者は、繰り返し用いられてるコンテンツの位置を素早く確認するために、視覚的な手がかり及びページの境界線を用いていることがよくある。繰り返し用いられるコンテンツを同じ順序で提示することは、そのコンテンツの位置を確認するためにデザインの空間的記憶又は視覚的な手がかりを用いている、画面を見ている利用者に対しても重要なことである。
ここで用いている「同じ順序」という表現が、サブナビゲーション・メニューを使用してはならないとか、サブナビゲーションのブロック又はページ構造を使用してはならないという意味ではないということが重要である。そうではなく、この達成基準が意図しているのは、複数のウェブページで繰り返し用いられているコンテンツを利用している利用者が、自分の探しているコンテンツの位置を予測できるようにして、より素早く見つけることができるようにすることである。
利用者は、自分に最も有用なかたちで情報が提供されるように、ユーザエージェントを用いて、又は利用者設定を行って、順序を変更していることがある。
達成基準 3.2.3の事例
一貫して配置されているコントロール
検索のテキストフィールドが、そのサイト上のすべてのページ上で最後に配置されていて、利用者はすぐに検索機能を見つけることができる。
展開するナビゲーションメニュー
ナビゲーションメニューに、サイトの主要コーナーへの7つのリンクがある。利用者がその項目の一つを選択すると、サブナビゲーション項目のリストが、ナビゲーションメニューに挿入される。
一貫して配置されているスキップ・ナビゲーションのコントロール
ウェブサイトにあるすべてのページ上に、「本文へジャンプする」というリンクが一番最初のリンクとして配置されている。そのリンクによって、利用者はヘッダーの情報及びナビゲーション部分をスキップして、ページのメインコンテンツ部分の開始位置へ移動することができる。
ナビゲーションへのスキップリンク
ナビゲーション部分は一貫して各ページの最後にある。キーボード利用者が、必要なときに容易に見つけられるように、「本文へジャンプする」というリンクは一貫して各ページの先頭にある。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準3.2.3の達成方法及び不適合事例 - 一貫したナビゲーション
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
3.2.3 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 3.2.3のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準3.2.3に適合していないとみなした、よくある不適合事例である。
重要な用語
- ウェブページ (Web page)
単一の URI から HTTP で得た埋め込まれていないリソースに加え、
レンダリングに使われる、又はユーザエージェントがこのリソースと一緒にレンダリングすることを意図しているその他のあらゆるリソースを合わせたもの。
注記 1:
どのような「その他のリソース」も主たるリソースと一緒にレンダリングされるであろうが、これらのリソースが同時にレンダリングされるとは限らない。
注記 2:
このガイドラインの適合範囲に含まれる対象となるウェブページとみなされるためには、リソースが「埋め込まれていない」リソースでなければならない。
事例 1:
すべての埋め込まれている画像とメディアを含んだウェブリソース。
事例 2:
Asynchronous JavaScript and XML (AJAX) を用いたウェブメールのプログラム。そのプログラム全体は http://example.com/mail に存在しているが、受信箱、アドレス帳、カレンダーがある。リンクまたはボタンがあり、それを押すと受信箱、アドレス帳やカレンダーを表示するが、ページの URI は全体を通して変わらない。
事例 3:
カスタマイズ可能なポータルサイトで、利用者が様々なコンテンツモジュールのセットから表示させるコンテンツを選択できるようなもの。
事例 4:
ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、 ウェブサイトの中のほんの1ページなのかもしれない。
- ウェブページ一式 (set of Web pages)
共通の目的を共有し、同じコンテンツ制作者、グループ、又は組織により制作されたウェブページの集合。
注記: 他言語版は、異なるウェブページ一式と見なされることもある。
- 相対的に同じ順序 (same relative order)
他の項目との相対位置が同じ。
注記: 当初の順序に対して、別の項目が挿入、又は削除されていたとしても、項目は相対的に同じ順序になっていると考えられる。例えば、展開するナビゲーションメニューに詳細な追加階層が挿入される、又は、読みの順序の途中に副次的なナビゲーション部分が挿入されることがある。
一貫した識別性:
達成基準 3.2.4 を理解する
この達成基準の意図
この達成基準の意図は、ウェブページ一式で繰り返して表示される機能的なコンポーネントを一貫して識別できるようにすることである。スクリーンリーダーを使用している利用者がウェブサイトを操作する方法は、複数のウェブページで使われている機能に馴染みがあるかどうかに大きく依存している。全く同じ機能が、ウェブページによって異なるラベルを付けられていると、そのウェブサイトはかなり使いづらいものになってしまう。また、認知能力の低下している利用者にとっても、それは混乱のもとであり、認知的負荷を増大させてしまうことがある。そのため、一貫したラベルを付けることが大切である。
この一貫性という考え方は、代替テキストにも当てはまる。アイコン又はその他の非テキストコンテンツが同じ機能であれば、その代替テキストにも同様に一貫性をもたせるべきである。
ウェブページ一式の中で、もしウェブページに 2 つコンポーネントがあり、そのどちらも別のページにあるコンポーネントと同じ機能を持っているのであれば、3 つのコンポーネントは一貫していなければならない。よって、同じページにある 2 つのコンポーネントは一貫していることになる。
1つのウェブページにおいて一貫性を持つことは望ましく、かつ最善の対応策だが、3.2.4 はウェブページ一式において1ページ以上何かが繰り返される場合の一貫性の対処である。
達成基準3.2.4の具体的なメリット
サイトのあるページで機能を学習した利用者が、他のページにも同じ機能があれば見つけることができるようになる。
同じ機能を持つコンポーネントを示すために非テキストコンテンツを一貫した方法で用いることで、テキストを読むことや、代替テキストを見つけることが困難な利用者が、代替テキストを頼りにすることなくウェブコンテンツを利用することができるようになる。
代替テキストを頼りにしている利用者が、コンポーネントをより予測できるようになる。別のページでもラベルが一貫していれば、そのコンポーネントを探し出すことができる。
達成基準 3.2.4の事例
事例 1： 文書のアイコン
文書のアイコンを使って、サイト中にある文書のダウンロードを示している。そのアイコンの代替テキストは、どれも「ダウンロード」という単語で始まっていて、その後に文書のタイトルの短縮形が続いている。異なる文書の異なるタイトルを示すために、異なる代替テキストを用いることは、代替テキストを一貫して使用しているとみなされる。
事例 2： チェックマーク
チェックマークのアイコンが、あるページでは「承認済」という意味だが、別のページでは「あり」という意味で使われている。異なる意味で使われているので、代替テキストも異なっている。
事例 3： 他のページへの一貫したリンクのラベル
あるウェブサイトが、オンライン記事を発行している。各記事は複数のウェブページにわたっており、各ページには記事の最初のページ、次のページ、そして前のページへのリンクがある。もし、次のページへのリンクのラベルが、「ページ 2」、「ページ 3」、「ページ 4」などとなっていたとしても、ラベルは同一ではないが、一貫しているといえる。そのため、こういったラベルは、この達成基準の不適合事例ではない。
事例 4： 似たような機能のアイコン
E-コマース・アプリケーションは、プリンタのアイコンを使って、利用者が領収書や請求書を印刷できることを示している。アプリケーションのある部分では、プリンタのアイコンは「領収書を印刷」というラベルが付いていて、領収書を印刷するために使われている。一方で、他の部分では「請求書を印刷」というラベルで、請求書を印刷するために使われている。 ラベルの付け方（…を印刷）は一貫しているが、アイコンの異なる機能を反映してラベルは異なっている。そのため、これはこの達成基準の不適合事例ではない。
事例 5： 保存アイコン
よくある「保存する」アイコンが、サイト中で使われていて、ページを保存する機能が複数のウェブページで提供されている。
事例 6： アイコンと隣接した同じ目的地へのリンク
代替テキストの記載されたアイコン及びテキストリンクが隣接して配置されており、かつリンク先は同じである。最善の対応策は、H2: 隣り合った画像とテキストリンクを同じリンクの中に入れる (HTML)
による通り、1つのリンクにグループ化することである。しかし、もし視覚的には上下に配置されているが、ソースでは独立している場合、これは不可能であるかもしれない。この達成基準を満たすには、これら2つのリンクテキストが、同一ではなくとも、一貫していれば良い。しかし、最善の対応策は、利用者が2つ目のリンクに遭遇した時、1つ目のリンクと同じリンク先に行くことが明確であるよう、同一のリンクテキストにすることである。
事例 7 : 不適合事例
あるウェブページにある「検索」ボタンと他のページにある「探す」ボタンは、どちらもテキストフィールドに入力されたキーワードに関するそのウェブサイト上のトピックを一覧表示するためのものである。この場合、ボタンは同じ機能を持っていながら、ラベルに一貫性がない。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準3.2.4の達成方法及び不適合事例 - 一貫した識別性
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
達成基準を満たすことのできる達成方法
G197: 同じ機能を有するコンテンツに対して、一貫したラベル、識別名及び代替テキストを使用する、かつ、達成基準1.1.1を満たすことのできる達成方法かつ達成基準4.1.2を満たすことのできる達成方法 に従ってラベル、識別名、代替テキストを提供する。
注記 1:
「一貫した」代替テキストは、常に「同一」であるとは限らない。例えば、次のウェブページへリンクするグラフィカルな矢印をウェブページの下部で使うとする。代替テキストは、「4ページに移動」というふうになるだろう。当然ながら、この代替テキストをそのまま次のウェブページでも繰り返して使うのは適切ではない。次のウェブページでは「5ページへ移動」とするのがより適切なはずである。これらの代替テキストは同一ではないが、一貫しており、この達成基準に適合しているといえる。
注記 2:
単一の非テキストコンテンツのアイテムが、異なる機能のために使われることがある。そのような場合、異なる代替テキストが必要であり、用いられるべきである。チェックマーク、?マーク、そして交通標識などのアイコンを使用する際によく見られる例である。それらの機能は、ウェブページの文脈によって異なる可能性がある。チェックマークは、その状況に応じて、「承認済」、「完了」、又は「あり」という意味で使われることがある。すべてのウェブページを通じて、代替テキストを「チェックマーク」としてしまうと、利用者がそのアイコンの意味を理解することができない。同一の非テキストコンテンツが複数の機能を果たしている際は、異なる代替テキストを用いることができる。
3.2.4 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 3.2.4のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準3.2.4に適合していないとみなした、よくある不適合事例である。
重要な用語
- ウェブページ (Web page)
単一の URI から HTTP で得た埋め込まれていないリソースに加え、
レンダリングに使われる、又はユーザエージェントがこのリソースと一緒にレンダリングすることを意図しているその他のあらゆるリソースを合わせたもの。
注記 1:
どのような「その他のリソース」も主たるリソースと一緒にレンダリングされるであろうが、これらのリソースが同時にレンダリングされるとは限らない。
注記 2:
このガイドラインの適合範囲に含まれる対象となるウェブページとみなされるためには、リソースが「埋め込まれていない」リソースでなければならない。
事例 1:
すべての埋め込まれている画像とメディアを含んだウェブリソース。
事例 2:
Asynchronous JavaScript and XML (AJAX) を用いたウェブメールのプログラム。そのプログラム全体は http://example.com/mail に存在しているが、受信箱、アドレス帳、カレンダーがある。リンクまたはボタンがあり、それを押すと受信箱、アドレス帳やカレンダーを表示するが、ページの URI は全体を通して変わらない。
事例 3:
カスタマイズ可能なポータルサイトで、利用者が様々なコンテンツモジュールのセットから表示させるコンテンツを選択できるようなもの。
事例 4:
ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、 ウェブサイトの中のほんの1ページなのかもしれない。
- 同じ機能 (same functionality)
使うと同じ結果が得られること。
事例: あるウェブページ上にある "search" ボタンと他のウェブページ上にある "find" ボタンは、どちらもキーワードを入力するテキストフィールドがあり、そのウェブサイトにある入力されたキーワードに関係のあるコンテンツをリスト表示する。この場合、同じ機能を有しながらも、ラベルは一貫していないことになる。
要求による変化:
達成基準 3.2.5 を理解する
この達成基準の意図
この達成基準の意図は、コンテキストの変化を利用者が完全に制御できるようなウェブコンテンツの設計を推奨することである。この達成基準は、自動的に開く新しいウィンドウ、リストから項目を選択すると自動的に送信されるフォームなどのように、予期しないコンテキストの変化によって混乱が引き起こされる可能性を取り除くことを狙いとしている。そのような予期しないコンテキストの変化により、運動障害のある利用者、ロービジョンの利用者、全盲の利用者、及び特定の認知能力の低下している利用者には困難が生じてしまう恐れがあるからである。
コンテキストの変化の中には、利用者を混乱させず、さらに利用者にとって有用な種類のものもある。例えば、単一のスイッチを使用している利用者は、システムによるコンテキストの変化に依存しているし、ロービジョンの利用者の好みも一度にどれくらいのコンテンツを見ることができるか、どれくらいのセッション構造が作業記憶に残るかに依存している。中にはスライドショーのように、意図したユーザーエクスペリエンスを提供するために、コンテキストの変化を必要とするコンテンツもある。利用者の設定が許容する際だけ自動的に状況を変化させるコンテンツは、この達成基準に適合することができる。
注記: 複数のコンテキストの変化を同時に引き起こすことが可能である。例えば、自動的に新規ウィンドウが開くリンクをクリックするのは、コンテンツの変化に関連するコンテキストの変化であり、表示域（ウィンドウ）の変化に関連するコンテキストの変化でもある、２つに分かれた変化の一例である。この場合のコンテンツの変化は、利用者がリンクをクリックした時、彼らの要求によって開始されるが、新規ウィンドウが開くことに利用者が気づかない限り、コンテキストの変化は利用者が開始したとはみなせない。
達成基準3.2.5の具体的なメリット
コンテキストの変化を見つけることができない、又は状況が変化したことに気づかない利用者が、サイトをナビゲートしている間に混乱した状態になりにくい。例えば、次のような利用者が当てはまる：
ロービジョンの利用者、読字及び知的障害のある利用者、そして視覚的な手がかりを解釈しづらい利用者は、コンテンツ制作者が手がかりを追加することによって、コンテキストの変化に気づくようになる。
自動的なリダイレクトを、ブラウザではなくウェブサーバーによって行えば、認知能力の低下している利用者は混乱しないですむ。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準3.2.5の達成方法及び不適合事例 - 要求による変化
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
達成基準を満たすことのできる達成方法
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の達成方法（又は、達成方法の組合せ）がある。
状況 C： ウェブページがポップアップウィンドウを用いる場合：
次の達成方法の一つを用いてポップアップウィンドウを表示する：
3.2.5 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 3.2.5のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準3.2.5に適合していないとみなした、よくある不適合事例である。
重要な用語
- コンテキストの変化 (changes of context)
ウェブページのコンテンツにおける大きな変化で、利用者が気づかないと、ウェブページ全体を一度に見ることのできない利用者を混乱させる恐れのあるもの。
コンテキストの変化には次に挙げるものの変化が含まれる:
ユーザエージェント
ビューポート
フォーカス
ウェブページの意味を変えるコンテンツ
注記: コンテンツの変化が、必ずコンテキストの変化になるとはかぎらない。アウトラインの展開、動的なメニュー、又はタブの切替などのコンテンツの変化は、それが上記のいずれか (例: フォーカス) を変更しないかぎり、コンテキストを変化させるとは限らない。
事例: 新しいウィンドウを開くこと、フォーカスを異なるコンポーネントへ移動させること、新しいウェブページへ移動すること (新しいウェブページへ移動したかのように思わせてしまうことも含む)、又はウェブページの内容を大きく再配置することなどは、コンテキストの変化の事例である。
- メカニズム (mechanism)
結果を得るためのプロセス又は手法。
注記 1:
メカニズムは、コンテンツ内で明示的に提供されることもあれば、プラットフォーム又は支援技術を含むユーザエージェントで提供されるものに 依存することもある。
注記 2:
メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。
入力支援:
ガイドライン3.3を理解する
ガイドライン3.3:
利用者の間違いを防ぎ、修正を支援すること。
ガイドライン 3.3 の意図
誰でもミスをすることがある。しかし、ある種の障害のある利用者は、エラーを起こさずに入力するのがより困難である。さらに、エラーを起こしたことに気づきにくいこともある。視野が限られている、色の知覚に制限がある、又は支援技術を使用しているという理由で、エラーを指摘する一般的な方法が障害のある利用者には分かりにくいことがある。このガイドラインは、重大な又は元の状態に戻すことのできないエラーの数を減らして、利用者がすべてのエラーに気づけるようにするとともに、エラーを修正するにはどうすればよいかを利用者が分かるようにしようとするものである。
ガイドライン 3.3 の参考にすべき達成方法(特定の達成基準に特有ではない達成方法)
このガイドラインにある各達成基準を満たすための達成方法は、この後に達成基準ごとに挙げられている。しかし、このガイドラインに対処するための達成方法がどの達成基準にも該当しない場合は、ここで挙げている。そういった達成方法は、どの達成基準を満たす上でも必須ではないし、十分でもないが、ウェブコンテンツの種類によってはより多くの利用者にとってよりアクセシブルにすることができるものである。
エラーの特定:
達成基準 3.3.1 を理解する
3.3.1 エラーの特定: 入力エラーが自動的に検出された場合は、エラーとなっている箇所が特定され、そのエラーが利用者にテキストで説明される。
(レベル A)
この達成基準の意図
この達成基準の意図は、利用者がエラーの発生に気づき、何が誤っていたのかわかるようにすることである。エラーメッセージは、できる限り具体的なものであるべきである。フォームの送信がうまくいかなかった場合に、フォームを再度表示して、エラーになっているテキストフィールドを示すだけでは、エラーの発生を知覚して気がつくに不十分な利用者もいる。例えば、スクリーンリーダーの利用者は、エラー表示が読み上げられるまでは、エラーがあることに気づかない。単にそのページがうまく動作しないのだと考えて、エラーが発生していることに気づく前に、スクリーンリーダーの利用者はそのフォームを使うこと自体をあきらめてしまうかもしれない。WCAG2.0での定義より、「入力エラー」とは利用者が提供した情報で、受け付けられないものである。 以下のものが含まれる：
例えば：
利用者は、州、管区、地域、等に適切な略語を入力できない。
利用者は、有効でない州の略語を入力する。
利用者は、実在しない郵便番号を入力する。
利用者は、2年先の誕生日を入力する。
利用者は、数字のみを受け付ける電話番号蘭にアルファベットや丸括弧を入力する。
利用者は、前の入札を下回る入札または最小入札単位を下回る入札を入力する。
注記: 注記：利用者が高すぎる値、または低すぎる値を入力し、その値をページ上のコードが自動的に許容範囲内に変更した場合、達成基準によって要求されるよう、利用者の入力エラーはまだ変更したところに記載される必要がある。変更された値を人に伝えるエラーの説明などは、この達成基準（エラーの特定）及び達成基準3.3.3（エラー修正の提案）の両方を満たすことになる。
ユーザエージェント又は支援技術がエラーを特定して、エラーに関する情報を利用者に提供することのできる、プログラム的な情報を用いて、エラーがあることを示して、その内容を説明することができる。例えば、あるウェブコンテンツ技術では、利用者の入力には文字数制限があること、又はフォームのテキストフィールドが必須項目であることを明示できる。現在、このようなプログラム的な情報をサポートしているウェブコンテンツ技術はほとんどないが、この達成基準ではそういった技術の有無は問わない。
テキストによる説明に加えて、例えば画像や色などのその他の方法でもエラーを示すことは全く問題ない。
達成基準3.3.3 エラー修正の提案を理解するも参照のこと。
達成基準 3.3.1の事例
フォーム送信におけるエラーの特定
ある航空会社のウェブサイトが、格安便の特別なプロモーションを展開している。利用者は、氏名、住所、電話番号、座席指定、及び電子メール アドレスなどの個人情報をシンプルなフォームに入力することを求められる。フォームにあるテキストフィールドのいずれかが、入力されていないか入力に誤りがある場合、どのテキストフィールドが未入力又はエラーであるかを利用者に知らせるアラートが表示される。
注記: この達成基準は、エラー箇所を示すために、色又はテキストの表示スタイルを用いないほうがよいということを意味しない。単にエラー箇所がテキストでも示されていることを要求しているだけである。この事例では、色に加えて、2つのアスタリスク (*) が用いられている。
複数の手がかりの提供
利用者がフォームにある2つのテキストフィールドに入力し忘れている。エラーの説明及びそのテキストフィールドを見つけやすくするためにエラーであることを示す特定の文字列を提供するだけでなく、テキストフィールドを黄色で強調表示して、視覚的にも見つけやすくしている。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準3.3.1の達成方法及び不適合事例 - エラーの特定
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
達成基準を満たすことのできる達成方法
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の達成方法（又は、達成方法の組合せ）がある。
3.3.1 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 3.3.1のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準3.3.1に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
重要な用語
- 入力エラー (input error)
利用者が入力した情報で、受け付けられないもの。
注記: 以下のものが含まれる:
そのウェブページでは必須であるが、利用者が入力しなかった情報
利用者が入力したが、要求されたデータ形式あるいは値ではない情報
ラベル又は説明:
達成基準 3.3.2 を理解する
3.3.2 ラベル又は説明:
コンテンツが利用者の入力を要求する場合は、ラベル又は説明文が提供されている。
(レベル A)
この達成基準の意図
この達成基準の意図は、どのような入力データが期待されているのかを利用者が理解するように、フォーム内のコントロールを識別するための説明文又はラベルをコンテンツ制作者が配置することである。特に一般的なフォーマットではない場合、又は正しい入力のための特定のルールがある場合、入力欄のデータフォーマットを説明文又はラベルで明示してもよい。特に説明が長く詳細である場合、個々のコントロールがフォーカスを受け取ったときだけそのような説明文を利用者が利用できるように作ることをコンテンツ制作者は選択してもよい。
この達成基準の意図は、ページを不要な情報だらけにしてしまうことではなく、障害のある利用者に役立つ重要な手がかり及び説明文を提供することである。情報又は説明文が多すぎると、それは単に邪魔なものでしかない。目標は、利用者の混乱を最小限に抑えて、必要以上のナビゲーションを提供することなく、利用者がタスクを完了するために十分な情報を提供することである。
注記: input オブジェクトにラベルが提供されている場合、その input オブジェクトとラベル（又はラベルとして提供されている冗長なテキスト）の関係性は
達成基準1.3.1 情報及び関係性を理解するによりプログラムで決定できるか又はテキストで利用できなければならない。
達成基準3.3.2の具体的なメリット
input 要素と label 要素が関連付けられている場合、入力欄にフォーカスがあたったときにスクリーンリーダーによってラベルが読み上げられ、かつ、ラベル又はコントロールのクリックでコントロールが選択されるために、より大ききなコントロールのクリック範囲によって運動に障害のある利用者は助けられるだろう。
関連付けられたテキストフィールドのすぐ近くにラベルを置くことによって、画面拡大ソフトの利用者にとっては、そのテキストフィールド及びラベルがページを拡大した画面内に収まりやすくなる。
所定のデータフォーマットの例を提供することは、認知の障害、言語の障害、及び学習障害のある利用者が情報を正確に入力するのに役立つ。
必須項目をはっきりと示すことによって、キーボードだけで操作している利用者が、不完全なままフォームを送信して、再度表示されたフォームをナビゲートし、未入力だったテキストフィールドを見つけ出してから情報を入力することを回避できるようになる。
達成基準 3.3.2の事例
テキストフィールドがあり、利用者に米国の州名を2文字の略語で入力するように求めている。そのテキストフィールドにはリンクがあり、ポップアップウィンドウを開いて、アルファベット順に並んだ州名と略語の一覧を提供している。
日付を入力するテキストフィールドに、その日付の正確なフォーマットを示す初期値がある。
名を入力するテキストフィールドが「名」というラベルではっきりと示されていて、姓を入力するテキストフィールドには「姓」というラベルがあり、利用者がどちらを入力すべきなのか迷わないようにしている。
米国の電話番号が、エリアコード、局番、そして番号の3つのテキストフィールドに分かれている。エリアコードのテキストフィールドには括弧が付いていて、局 番と番号のテキストフィールドの間にはハイフンが入っている。この表記法は、米国の電話番号フォーマットに馴染みのある利用者には視覚的な手がかりを提供していることになるが、テキストフィールドのラベル付けとしてはこの表記法だけでは不十分である。また、「電話番号」という一つのラベルも、3つのテキストフィールドすべてをラベル付けすることはできない。これに対処するために、3つのテキストフィールドを fieldset 要素でグループ化して、legend 要素で「電話番号」というラベルを付けている。さらに、テキストフィールドに（この表記法に加えて）視覚的なラベルを提供することはデザイン上不可能なので、title 属性を用いて、3つのテキストフィールドそれぞれに視覚的には認識できないラベルを提供している。3つのテキストフィールドそれぞれの属性値は、「エリアコード」、「局番」、そして「番号」となっている。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準3.3.2の達成方法及び不適合事例 - ラベル又は説明
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
3.3.2 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 3.3.2のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準3.3.2に適合していないとみなした、よくある不適合事例である。
重要な用語
- ラベル (label)
テキスト、又はテキストによる代替を伴うコンポーネントで、ウェブコンテンツ内のコンポーネントを識別するために利用者に提示されているもの。
注記 1:
名前 (name) は隠されていて支援技術に対してだけ明らかにされる場合がある一方で、ラベルはすべての利用者に提示される。多くの場合 (すべてではないが)、名前 (name) とラベルは同じである。
注記 2:
ラベルという用語は、HTML における label 要素だけに限定されない。
エラー修正の提案:
達成基準 3.3.3 を理解する
3.3.3 エラー修正の提案: 入力エラーが自動的に検出され、修正方法を提案できる場合、その提案が利用者に提示される。ただし、セキュリティ又はコンテンツの目的を損なう場合は除く。
(レベル AA)
この達成基準の意図
この達成基準の意図は、可能であれば、利用者が入力エラーを修正するのに適切な修正方法を入手できるようにすることである。「入力エラー」のWCAG 2.0での定義は、システムによって「利用者が提供した情報で、受け付けられないもの」であるとされている。受け付けられない情報の例には、必須だが利用者によって省略された情報や、利用者によって提供されたが、必要なデータ形式や許容値の範囲外である情報が含まれる。
達成基準 3.3.1 は、入力エラー箇所を通知するためのものである。しかし、例えば、認知的な制約のある利用者は、入力エラーの修正方法を理解するのが困難なことがある。視覚障害のある利用者は、入力エラーの修正方法を正確に把握することができないことがある。フォーム送信がうまくいかなかった場合、利用者はエラーが発生したことには気づいていたとしても、そのエラーを修正する方法が分からないために、そのフォームを途中であきらめてしまうかもしれない。
コンテンツ制作者はエラーを説明することができる。又、ユーザエージェントはウェブコンテンツ技術で特定されたプログラムで判断できる情報に基づいてエラーを説明できる。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準3.3.3の達成方法及び不適合事例 - エラー修正の提案
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
注記: 2つ以上の状況が適用される場合もある。例えば、必須フィールドが特別なデータフォーマットを要求する場合である。
達成基準を満たすことのできる達成方法
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の達成方法（又は、達成方法の組合せ）がある。
3.3.3 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
G139: 利用者がエラー箇所に移動できるメカニズムを作成する
エラーメッセージを、ウェブページのその他のテキストと区別しやすくし、容易に理解できるようにする（リンク追加予定）
送信されたフォームが正しいかをサーバーで確認する（リンク追加予定）
必須の情報が入力されない場合に、必須フィールドを識別するだけでなく、正しい情報の説明と事例を提供する（リンク追加予定）
フォームフィールドと関連して、各入力エラーを訂正するための提案を繰り返し強調する（リンク追加予定）
提案するリストの各項目から、対応するフォームフィールドへスキップする方法を利用者に提供する（リンク追加予定）
変更の必要のあるフォームフィールドに対して、文脈に沿った追加のヘルプを提供する（リンク追加予定）
様々なフォーマットの入力データを受け付ける（リンク追加予定）
G199: データが問題なく送信されたことを伝えるフィードバックを提供する
利用者に提案を行う達成方法（参考）
入力エラーの数についての情報を含むテキストの説明、各項目を訂正するための提案、そして、どのように進めるべきかの指示を提供する（リンク追加予定）
コンテンツの最初の項目（あるいは最初の項目の一つ）を訂正するための提案を含むテキストの説明を提供する、又は、コンテンツの中でこの情報を強調する（リンク追加予定）
エラーを表示し、元のフォームの文脈に沿った提案をする（例えば、フォームのどこに入力エラーがあるかを再表示し、訂正のための提案がハイライトされ、元のフォームとの関連を表示する）（リンク追加予定）
達成基準 3.3.3のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準3.3.3に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
重要な用語
- 入力エラー (input error)
利用者が入力した情報で、受け付けられないもの。
注記: 以下のものが含まれる:
そのウェブページでは必須であるが、利用者が入力しなかった情報
利用者が入力したが、要求されたデータ形式あるいは値ではない情報
エラー回避 (法的、金融、データ) :
達成基準 3.3.4 を理解する
3.3.4 エラー回避 (法的、金融、データ) : 利用者にとって法律行為もしくは金融取引が生じる、利用者が制御可能なデータストレージシステム上のデータを変更もしくは削除する、又は利用者が試験の解答を送信するウェブページでは、次に挙げる事項のうち、少なくとも一つを満たしている:
(レベル AA)
取消: 送信を取り消すことができる。
チェック: 利用者が入力したデータの入力エラーがチェックされ、利用者には修正する機会が提供される。
確認: 送信を完了する前に、利用者が情報の見直し、確認及び修正をするメカニズムが利用できる。
この達成基準の意図
この達成基準の意図は、障害のある利用者が元の状態に戻すことのできないタスクを行った際、ミスをしたことによる重大な結果を未然に防ぐことができるようにすることである。例えば、払い戻し不可の航空券の購入、又は証券取引口座での株購入の注文は、重大な結果につながる金銭的な取引である。利用者が発着日を間違えれば、その利用者は交換できない誤った日付の航空券を購入したことになってしまう。利用者が購入する株式の数を間違えると、意図した数よりも多くの株式を購入したことになってしまう。どちらのミスも、すぐに処理される取引であり、後から変更することはできないものであり、また非常に高価である。同様に、旅行サービスのウェブサイトにある旅行履歴のように、後からアクセスする必要のあるデータベースのデータを無意識に修正又は削除してしまった場合、そのエラーは回復不能なことがある。「利用者が自分で制御可能な」データの変更又は削除を参照する場合、この達成基準の意図は、ファイル又はレコードの削除のようなデータの大量損失を防ぐことである。各保存コマンド又は単純な作成又はドキュメント、レコードもしくは他のデータの編集するための確認を必要とすることを意図しない。
障害のある利用者は、ミスをしてしまう可能性が高い。読字障害のある利用者は、数字と文字を取り違えてしまうことがあるし、運動障害のある利用者は間違ってキーを押してしまうことがある。元の状態に戻せるようにすることによって、利用者が重大な結果につながる恐れのあるミスを修正できるようになる。また、入力内容を確認して修正できるようにすることで、重大な結果につながることをしてしまう前に、利用者がミスに気づくことができるようになる。
利用者が自分で制御可能なデータというのは、利用者が意図的行為を通して変更及び/又は削除できる利用者が閲覧可能なデータである。そのようなデータを制御する利用者の例としては、利用者のアカウントの電話番号及び住所を更新する、又はウェブサイトから過去の請求書のレコードを削除することが挙げられる。これは、利用者が直接に表示又は情報交換できないインターネットのログ又は検索エンジンの監視データのようなものを指すものではない。
達成基準 3.3.4の事例
注文内容の確認
ある小売店がウェブでオンラインショッピングのサービスを顧客に提供している。注文が送信されると、利用者が注文内容に間違いがないかを確認できるように、注文した商品、各商品の数、送り先の住所、支払方法などの注文情報が表示される。利用者は、注文内容を確認したり、変更したりすることができる。
株式売買
ある金融サービスのウェブサイトで、利用者は株をオンラインで売買できる。利用者が株の売買の注文を送信すると、システムは市場が開いているかどうかを確認する。時間外だった場合は、利用者にその取引が時間外取引になることを知らせて、通常の取引時間外であることに伴うリスクについても伝える。そして、利用者はその注文をキャンセルするか、確認することができる。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準3.3.4の達成方法及び不適合事例 - エラー回避 (法的、金融、データ)
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
達成基準を満たすことのできる達成方法
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の達成方法（又は、達成方法の組合せ）がある。
3.3.4 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 3.3.4のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準3.3.4に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
重要な用語
- ウェブページ (Web page)
単一の URI から HTTP で得た埋め込まれていないリソースに加え、
レンダリングに使われる、又はユーザエージェントがこのリソースと一緒にレンダリングすることを意図しているその他のあらゆるリソースを合わせたもの。
注記 1:
どのような「その他のリソース」も主たるリソースと一緒にレンダリングされるであろうが、これらのリソースが同時にレンダリングされるとは限らない。
注記 2:
このガイドラインの適合範囲に含まれる対象となるウェブページとみなされるためには、リソースが「埋め込まれていない」リソースでなければならない。
事例 1:
すべての埋め込まれている画像とメディアを含んだウェブリソース。
事例 2:
Asynchronous JavaScript and XML (AJAX) を用いたウェブメールのプログラム。そのプログラム全体は http://example.com/mail に存在しているが、受信箱、アドレス帳、カレンダーがある。リンクまたはボタンがあり、それを押すと受信箱、アドレス帳やカレンダーを表示するが、ページの URI は全体を通して変わらない。
事例 3:
カスタマイズ可能なポータルサイトで、利用者が様々なコンテンツモジュールのセットから表示させるコンテンツを選択できるようなもの。
事例 4:
ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、 ウェブサイトの中のほんの1ページなのかもしれない。
- メカニズム (mechanism)
結果を得るためのプロセス又は手法。
注記 1:
メカニズムは、コンテンツ内で明示的に提供されることもあれば、プラットフォーム又は支援技術を含むユーザエージェントで提供されるものに 依存することもある。
注記 2:
メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。
- 入力エラー (input error)
利用者が入力した情報で、受け付けられないもの。
注記: 以下のものが含まれる:
そのウェブページでは必須であるが、利用者が入力しなかった情報
利用者が入力したが、要求されたデータ形式あるいは値ではない情報
- 利用者が制御可能 (user-controllable)
利用者によってアクセスされることを意図したデータ。
注記: これは、インターネットのログや検索エンジンの監視データのようなものは指していない。
事例: ユーザアカウントのための氏名と住所のフィールド。
- 法律行為 (legal commitments)
法的に拘束力のある義務あるいは利益が発生する取引。
事例: 結婚許可証、株取引 (金銭上及び法的)、遺言、ローン、採用、軍隊への入隊登録、あらゆる契約、など
ヘルプ:
達成基準 3.3.5 を理解する
この達成基準の意図
この達成基準の意図は、利用者がミスをしないようにすることである。障害のある利用者は、障害のない利用者よりもミスをする可能性が高い。状況に応じたヘルプを提供することによって、利用者は自分が実行していることの手順がわからなくなってしまうことがなく、どう操作すればよいかがわかる。
状況に応じたヘルプは、ラベルがすべての機能を説明するのに不十分なときにだけ提供すればよい。状況に応じたヘルプが提供されていることを利用者に対してはっきりと示すべきで、利用者が必要とするときにはいつでもヘルプを利用できるようにしなければならない。
コンテンツ制作者は、ヘルプの文章を提供することができる、又はユーザエージェントがウェブコンテンツ技術特有のプログラムで判断できる情報に基づいてヘルプの文章を提供することができる。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準3.3.5の達成方法及び不適合事例 - ヘルプ
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
達成基準を満たすことのできる達成方法
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の達成方法（又は、達成方法の組合せ）がある。
3.3.5 でさらに対応が望まれる達成方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。
達成基準 3.3.5のよくある不適合事例
以下に挙げるものは、WCAG ワーキンググループが達成基準3.3.5に適合していないとみなした、よくある不適合事例である。
(今のところ、文書化されている不適合事例がない)
重要な用語
- コンテキストに応じたヘルプ (context-sensitive help)
そのとき実行されている機能に関する情報を提供するヘルプのテキスト。
注記: 明解なラベルは、コンテキストに応じたヘルプとして機能しうる。
エラー回避 (すべて) :
達成基準 3.3.6 を理解する
3.3.6 エラー回避 (すべて) : 利用者に情報の送信を要求するウェブページでは、次に挙げる事項のうち、少なくとも一つを満たしている:
(レベル AAA)
取消: 送信を取り消すことができる。
チェック: 利用者が入力したデータの入力エラーがチェックされ、利用者には修正する機会が提供される。
確認: 送信を完了する前に、利用者が情報の見直し、確認及び修正をするメカニズムが利用できる。
この達成基準の意図
この達成基準の意図は、障害のある利用者が、フォームのデータを送信するときにミスをしたことによりひきおこされる重大な結果を未然に防ぐことができるようにすることである。この達成基準は、利用者が情報を送信する必要のあるフォームすべてに適用されるという点において、達成基準 3.3.4 よりも上位のレベルである。
障害のある利用者は、ミスをしてしまう可能性が高く、フォームでのエラーに気づく又は修正するのにも困難を伴うことが多い。例えば、読字障害のある利用者 は、数字と文字を取り違えてしまうことがある。そして、運動障害のある利用者は間違ってキーを押してしまうことがある。元の状態に戻せるようにすることに よって、利用者がエラーを修正することができるようになる。また、情報を確認して修正できるようにすることによって、利用者はフォームのデータを送信する前にエラーに気づくことができる。
達成基準 3.3.6の事例
(none currently documented)
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
(今のところ、文書化されていない)
達成基準3.3.6の達成方法及び不適合事例 - エラー回避 (すべて)
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。
重要な用語
- ウェブページ (Web page)
単一の URI から HTTP で得た埋め込まれていないリソースに加え、
レンダリングに使われる、又はユーザエージェントがこのリソースと一緒にレンダリングすることを意図しているその他のあらゆるリソースを合わせたもの。
注記 1:
どのような「その他のリソース」も主たるリソースと一緒にレンダリングされるであろうが、これらのリソースが同時にレンダリングされるとは限らない。
注記 2:
このガイドラインの適合範囲に含まれる対象となるウェブページとみなされるためには、リソースが「埋め込まれていない」リソースでなければならない。
事例 1:
すべての埋め込まれている画像とメディアを含んだウェブリソース。
事例 2:
Asynchronous JavaScript and XML (AJAX) を用いたウェブメールのプログラム。そのプログラム全体は http://example.com/mail に存在しているが、受信箱、アドレス帳、カレンダーがある。リンクまたはボタンがあり、それを押すと受信箱、アドレス帳やカレンダーを表示するが、ページの URI は全体を通して変わらない。
事例 3:
カスタマイズ可能なポータルサイトで、利用者が様々なコンテンツモジュールのセットから表示させるコンテンツを選択できるようなもの。
事例 4:
ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、 ウェブサイトの中のほんの1ページなのかもしれない。
- メカニズム (mechanism)
結果を得るためのプロセス又は手法。
注記 1:
メカニズムは、コンテンツ内で明示的に提供されることもあれば、プラットフォーム又は支援技術を含むユーザエージェントで提供されるものに 依存することもある。
注記 2:
メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。
- 入力エラー (input error)
利用者が入力した情報で、受け付けられないもの。
注記: 以下のものが含まれる:
そのウェブページでは必須であるが、利用者が入力しなかった情報
利用者が入力したが、要求されたデータ形式あるいは値ではない情報