WCAG 2.0 解説書

この達成基準の意図

この達成基準の意図は、非テキストコンテンツにより伝達される情報を、代替テキストを用いることによってアクセシブルにすることである。代替テキストは、利用者の要求に合わせてあらゆる感覚モダリティ（例えば、視覚、聴覚、あるいは触覚）を通じて描画可能なので、情報をアクセシブルにする上では最もよい方法である。代替テキストを提供することにより、情報が様々なユーザーエージェントによって様々な方法で描画されることが可能になる。例えば、写真を見ることのできない利用者は、合成音声を用いてその代替テキストを読み上げさせることができる。また、音声ファイルを聞くことのできない利用者は、それを読むことができるように代替テキストを表示させることができる。将来的には、代替テキストによって、情報を手話や同じ自然言語のより平易なものに、より容易に変換することができるようにもなるだろう。

CAPTCHA に関する注記

CAPTCHA は、アクセシビリティのコミュニティにおいて、議論を呼ぶトピックの一つである。Inaccessibility of CAPTCHAという参考資料 (W3C Working Group Note) でも解説されているように、CAPTCHA はもともと、機械的な自動処理を排除して、人間による操作であることを確認するためのものである。特定の障害のある利用者は、どんな種類の CAPTCHA も解釈できないであろう。しかし、CAPTCHA は広く使われており、WCAG ワーキンググループは、もし CAPTCHA が完全に禁止されてしまったとしたら、ウェブサイトでは CAPTCHA の使用を見合わせるのではなく、WCAG に適合しないという選択が行われるだろうと考えた。こうなることは、障害のある、かなり多くの利用者に対しての障壁を生むことになる。この理由から、ワーキンググループは、障害のある利用者のほとんどの要求を満たし、なおかつ ウェブサイトが採用可能だと考えられる方法で、CAPTCHA に関する要件を定めることにした。異なる2つの形態の CAPTCHA をサイト上で提供することを要件として、障害のある利用者のほとんどが自分の利用できるものを見つけられるようにしたのである。

中には、最低限の要件を満たしているサイトにもアクセスできない、障害のある利用者もいるため、ワーキンググループは追加の手段を講じることを推奨している。WCAG に適合したいと考える組織は、このトピックの重要性を認識すべきであり、可能な限りこのガイドラインの最低要件より多くの策を講じるべきである。推奨される追加の手段としては、以下のものがある：

• CAPTCHA を3つ以上のモダリティで提供する

• CAPTCHA を使用しないでもすむように、カスタマーサービスの担当者に連絡できるようにする

• 許可した利用者には CAPTCHA を要求しない

補足情報

非テキストコンテンツには様々な形態があり、この達成基準ではそれぞれをどのように扱うべきかを特定している。

以下に挙げる状況の他のどれにも該当しない非テキストコンテンツ （例：チャート、ダイアグラム、録音した音声、写真、そしてアニメーション）の場合、代替テキストは同じ情報をあらゆる感覚モダリティ（例えば、視覚、聴覚、あるいは触覚）によって描画可能な形態で入手可能にすることができる。簡潔な、及び長めの代替テキストは、非テキストコンテンツにある情報を伝達するのに必要に応じて用いられる。 収録済の音声しか含まない ファイル及び 収録済の映像しか含まない ファイルは、ここで扱われている。 ライブの音声しか含まないファイル及び ライブの映像しか含まないファイルは、以下で扱われている（この段落後にある3つ目の段落を参照のこと）。

コントロールあるいは利用者の入力を受け入れる非テキストコンテンツ （例：実行ボタンとして用いられる画像、イメージマップ、あるいは複雑なアニメーション）の場合、その非テキストコンテンツが何で、なぜそこにあるのかが、利用者にとって、少なくとも分かるようにするために、識別名を提供してその非テキストコンテンツの目的を説明する。

時間の経過に伴って変化するメディアである非テキストコンテンツは、 1.2によりアクセシブルになる。しかし、重要なのは利用者がページ上で発見したときにそれが何であるかが分かり、それにより利用者がどのようにしたいかを判断できるようにすることである。そのため、時間の経過に伴って変化するメディアを説明し、場合によってはそのタイトルを示す代替テキストを提供する。

ライブの音声しか含まないコンテンツ及びライブの映像しか含まないコンテンツの場合、それらと同等の情報を示す代替テキストを提供することは、はるかに困難なこともありうる。このようなタイプの非テキストコンテンツに対しては、代替テキストで内容の分かるラベルを提供する。

試験あるいは演習が、部分的又は全体的に非テキストのフォーマットで提示されなければならないことがある。その試験あるいは演習は聴覚や視覚を用いて行う必要があるため、テキストに変換することのできない音声あるいは視覚的な情報が提示されるからである。例えば、ヒアリングテストは、もし代替テキストが提供されたとしたら意味を成さないだろう。視覚能力向上のための演習も、テキスト形式では同様に無意味となってしまう。また、代替テキストのあるスペルの試験もあまり効果がない。このような場合には、代替テキストはその非テキストコンテンツの目的を説明するために提供されるべきである。もちろん、その代替テキストは、試験に合格するために必要な情報と同じものは提供しないことになる。

特定の感覚的な体験を生むことを主目的にしたコンテンツで、言葉では完全に表現できないものもある。例としては、交響楽団の演奏、視覚的な芸術作品などが挙げられる。そのようなコンテンツの場合、代替テキストは、内容の分かるラベルと可能ならば補足説明のテキストによって、その非テキストコンテンツを少なくとも確認できるようにする。もしそのコンテンツがそのページにある理由が明らかで、それが説明できるのであれば、そういった情報も含めると役に立つ。

利用者が人間であることを証明するために用いられる、非テキストの仕掛け。スパムロボットやその他のソフトウェアがサイトにアクセスしてくるのを回避するために、CAPTCHA と呼ばれている仕掛けが用いられる。CAPTCHA には、今日の ウェブロボットの能力を超えた視覚的あるいは聴覚的な課題が通常は用意されている。しかし、それに対して代替テキストを提供することは、ロボットでも操作可能なものにしてしまい、その目的を果たせなくなってしまう。このような場合、代替テキストは、CAPTCHA の目的を説明し、かつ、様々な障害のある利用者の要求に対処するために、異なるモダリティを用いた代替形式が提供される。

利用者が視覚的に確認したり、理解したりすることを意図していない非テキストコンテンツ。ページ上でテキストを移動させるために用いる透過画像、ログ解析のために用いる非表示の画像、情報は何も伝えていないが単に空白を埋めて見栄えをよくするための渦 (swirl) などが、この例として挙げられる。このような画像に代替テキストを記述すると、スクリーンリーダーの利用者がそのページのコンテンツを理解する妨げになるだけである。しかし、その非テキストコンテンツを全くマークアップしなければ、利用者にその非テキストコンテンツが何なのか、どんな情報を見逃してしまったのかを推測させてしまうことになる（実際には何も見逃していなかいのであるが）。そのため、このような非テキストコンテンツについては、支援技術 (AT) がそれを無視して、かつ利用者には何も提示しないような方法でマークアップあるいは実装する。

この達成基準の意図

この達成基準の意図は、収録済の音声しか含まないコンテンツ及び収録済の映像しか含まないコンテンツの伝える情報を、すべての利用者が入手できるようにすることである。テキストベースの、時間の経過に伴って変化するメディアの代替は、情報をアクセシブルにする。それは、利用者のニーズに合った、あらゆる感覚モダリティ（例えば、視覚、聴覚、あるいは触覚）を通じて、テキストが描画可能だからである。将来的には、テキストをシンボル、手話、あるいはその言語でよりシンプルな形態に変えることも可能になるのではないだろうか。

収録済の映像コンテンツの場合、コンテンツ制作者には音声トラックを提供するという選択肢がある。それにより、視覚障害の有無に関係なく、利用者はコンテンツを同時に楽しむことが可能になる。また、映像と音声の並行したプレゼンテーションを提供することにより、認知の障害、言語の障害、及び学習障害のある利用者がコンテンツを理解しやすくなることにもつながる。

達成基準 1.2.9 ライブの音声しか含まないコンテンツの代替コンテンツを理解するも参照のこと。

この達成基準の意図

この達成基準の意図は、デフ又は音声の聞こえづらい利用者が、同期したメディアのプレゼンテーションを見られるようにすることである。キャプションは、コンテンツの中で音声トラックを通じて提示されている部分の代替を提供するものである。キャプションは、発話の内容だけを含むのではなく、誰が話しているのかも示し、発話ではなく音声（意味のある効果音を含む）によって伝えられている情報も含む。

現在のところ、情報発信までに一刻を争う素材に対してキャプションを作成するのが困難であることは、一般に広く認められている。そのため、コンテンツ制作者は、キャプションの完成を待って情報発信を遅らせるか、もしくは待たずに情報を発信してしまうか、という選択を迫られることになる。いずれは、情報配信プロセスの中にキャプション作成を組み込むツールや、キャプションを付加するツールによって、そういった遅延は短縮化されるか、なくなるだろう。

ただし、同期したメディア自体が、ウェブページ上でテキストによってすでに提示されている情報の代替プレゼンテーションである際には、キャプションは必要ない。例えば、ウェブページ上の情報に同期したメディアのプレゼンテーションが付随していて、そのメディアがテキストですでに提示されている情報と同程度の情報しか提示していないが、認知の障害、言語の障害、又は学習障害のある利用者にとってはそれが理解しやすい場合がある。そのような場合には、キャプションを提供する必要はない。なぜなら、その情報は、ウェブページ上でテキスト、あるいは、（例えば、画像の）代替テキストによって、すでに提供されているからである。

達成基準 1.2.4 ライブの音声コンテンツのキャプションを理解するも参照のこと。

この達成基準の意図

この達成基準の意図は、全盲又は視覚障害のある利用者が、同期したメディアのプレゼンテーションにある視覚的な情報を入手できるようにすることである。この達成基準では、2つのアプローチについて説明しているが、どちらを用いてもよい。

1つめのアプローチは、映像コンテンツの音声ガイドを提供することである。音声ガイドは、利用者が映像の情報を入手できない場合のために、利用者が必要とする情報をそのプレゼンテーションの音声部分に加えて、映像コンテンツを増補するものである。発話の合間に存在する無音部分を使って、動き、登場人物、シーンの変化、画面上の文字に関する情報のうち、コンテンツを理解する上で重要で、かつ主音声では説明されていなかったり、話されていない情報を、音声ガイドで提供する。

2つめのアプローチは、同期したメディアにある（視覚的及び聴覚的な）情報すべてをテキスト形式で提供することである。時間の経過に伴って変化するメディアの代替は、同期したメディアのコンテンツで提供されているすべての情報をそのままに提供するものである。時間の経過に伴って変化するメディアの代替は、いわば台本や書物のようなものである。音声ガイドとは異なり、映像部分の説明が、既存の発話の合間だけに制限されることはない。視覚的な状況、登場人物の動きや表情、及びその他のあらゆる視覚的なものを含めて、すべての視覚的な情報について、説明を十分に提供する。さらに、発話ではない音声（笑い声、画面の外から聞こえてくる声など）を説明し、すべての発話の書き起こしテキストを含む。そして、そういった説明と発話の書き起こしテキストの登場順は、同期したメディア自体での登場順と同じである。結果的に、時間の経過に伴って変化するメディアの代替は、同期したメディアコンテンツについて、音声ガイドだけの場合よりもずっと多くの完全な説明を提供することが可能である。

同期したメディアのプレゼンテーションの一部分として何らかのインタラクションがある場合（例えば、「質問に答えるために、今、ボタンを押してください。」）、時間の経過に伴って変化するメディアの代替は、ハイパーリンク又は同じ機能を提供するのに必要なものを提示することになる。

達成基準 1.2.5 収録済の映像コンテンツの音声ガイドを理解する、 達成基準 1.2.7 収録済の映像コンテンツの拡張した音声ガイドを理解する、及び 達成基準 1.2.8 収録済のメディアの代替コンテンツを理解するも参照のこと。

この達成基準の意図

この達成基準の意図は、デフ又は音声が聞こえにくい利用者がリアルタイムのプレゼンテーションを見られるようにすることである。キャプションは、コンテンツの中で音声トラックを通じて提示されている部分の代替を提供するものである。キャプションには、発話の内容だけを含むのではなく、誰が話しているのかも示し、また、意味のある効果音やその他の重要な音声も含める。

この達成基準の意図

この達成基準の意図は、全盲あるいは視覚障害のある利用者に、同期したメディアのプレゼンテーションにある視覚的な情報を提供することである。 音声ガイドは、利用者が映像の情報を入手できない場合のために、利用者が必要とする情報をそのプレゼンテーションの音声部分に加えて、映像コンテンツを増補するものである。 発話の合間に存在する無音部分を使って、動き、登場人物、シーンの変化、画面上の文字に関する情報のうち、コンテンツを理解する上で重要で、かつ主音声では説明されていなかったり、話されていない情報を、音声ガイドで提供する。

この達成基準の意図

この達成基準の意図は、デフ又は音声が聞こえにくい利用者で手話の分かる利用者が、同期したメディアのプレゼンテーションにおける音声トラックのコンテンツを理解できるようにすることである。例えば、キャプションに書かれているテキストというのは、第二言語であることがよくある。手話は、イントネーション、感情、及び、キャプションには反映されないが手話通訳には反映されるその他の音声情報を提供するので、手話通訳は同期したメディアの内容に対してキャプションよりも豊富でより等価な情報を提供することができる。また、手話で頻繁にコミュニケーションを図っている利用者にとっては、手話で提供された情報のほうがより早く理解できるので、同期したメディアが時間の経過に伴って変化するプレゼンテーションとなる。

この達成基準の意図

この達成基準の意図は、全盲又は視覚障害のある利用者に、同期したメディアのプレゼンテーションについての情報を標準的な音声ガイドよりも多く提供することである。同期したメディアのプレゼンテーションを一時的に停止させて、追加の音声ガイドを再生することで提供できる。その再生が終わった後に、同期したメディアのプレゼンテーションを再開する。

ただし、追加の説明を必要としない利用者にとっては、閲覧の邪魔になってしまうため、その機能のオンとオフを切り替えることのできる方法を提供する。あるいは、その代わりに、拡張した音声ガイドのあるバージョンとないバージョンとを提供してもよい。

この達成基準の意図

この達成基準の意図は、視力が弱すぎてキャプションを確実に読むことができず、なおかつ聴力も弱すぎて発話や音声ガイドを確実に聞くことができない利用者が、視聴覚のコンテンツを利用できるようにすることである。時間の経過に伴って変化するメディアの代替を提供することで、それが可能になる。

このアプローチは、同期したメディアにある（視覚的及び聴覚的な）情報すべてをテキスト形式で提供することである。時間の経過に伴って変化するメディアの代替は、同期したメディアのコンテンツで提供されているすべての情報をそのままに提供するものである。時間の経過に伴って変化するメディアの代替は、本のようなものになる。 音声ガイドとは異なり、映像部分の説明が、既存の発話の合間だけに制限されることはない。 視覚的な状況、登場人物の動きや表情、及びその他のあらゆる視覚的なものを含めて、すべての視覚的な情報について、説明を十分に提供する。さらに、発話ではない音声（笑い声、画面の外から聞こえてくる声など）を説明し、すべての発話の書き起こしテキストを含む。そして、そういった説明と発話の書き起こしテキストの登場順は、同期したメディア自体での登場順と同じである。そして、そういった説明と発話の書き起こしテキストの登場順は、同期したメディア自体での登場順と同じである。結果的に、時間の経過に伴って変化するメディアの代替は、同期したメディアコンテンツについて、音声ガイドだけでの場合よりもずっと多くの完全な説明を提供することが可能である。

同期したメディアのプレゼンテーションの一部分として何らかのインタラクションがある場合（例：「質問に、今、答えてください。」）、時間の経過に伴って変化するメディアの代替は、ハイパーリンク又は同じ機能を提供するのに必要なものを提示することになる。

視力が弱すぎてキャプションを確実に読むことができず、なおかつ聴力も弱すぎて発話を確実に聞き取ることのできない利用者は、点字ピンディスプレイを使うことによって、時間の経過に伴って変化するメディアの代替を利用することができる。

この達成基準の意図

この達成基準の意図は、例えばテレビ会議のような、ライブの音声、ライブの発話、及びラジオのウェブキャストが伝えている情報を、代替テキストを用いることによってアクセシブルにすることである。ライブのキャプション付加サービスは、デフ又は音声の聞こえづらい利用者、あるいは他のやり方で音声を聞くことのできない利用者に対してライブの音声をアクセシブルにすることが可能であろう。そういったサービスでは、訓練された人間のオペレーターが、話の内容を聞きながら、特殊なキーボードを用いてほんの少しの遅延だけでテキストを入力している。オペレーターは、かなり忠実にライブの出来事をテキストで記録することができる。また、内容を理解する上で不可欠な発話以外の音声に関する注記も挿入することができる。ライブの音声が予め用意された現行通りのものであれば、書き起こしテキストを事前に準備しておけることもある。しかし、ライブのキャプション付加サービスのほうが好まれる。なぜなら、キャプションが音声自体と同じペースで表示され、台本にはないことが起こったとしてもそれに対処できるからである。

訓練されていないオペレーターを使用したり、実際に起こっていることとは明らかに違う書き起こしテキストを提供したりしている場合は、この達成基準を満たしているとはいえない。

この達成基準の意図

この達成基準の意図は、視覚的又は聴覚的な体裁によって暗に伝えられている情報及び関係性を、その表現形式が変わったときにも保つようにすることである。例えば、コンテンツがスクリーンリーダーによって読み上げられたり、コンテンツ制作者が提供するスタイルシートがユーザー・スタイルシートに置き換えられたりしたときには、表現形式が変わる。

画面を見ている利用者は、様々な視覚的な手がかりによって構造を知覚する。例えば、見出しは大きめで太字のフォントで、次の段落とはスペースを空けて表示されていることがほとんどである。リスト項目は、その先頭に中黒等があって、字下げされていることが多い。段落と段落の間にはスペースがある。共通の特徴を有する条項は、表の行と列で整理されている。フォームの複数のテキストフィールドは、テキストのラベルを共有するグループとして配置されていることがある。異なる背景色を用いて、いくつかのアイテムが互いに関係のあることを示していることもある。特別な意味を持つ語句は、フォントの種類を変えたり、イタリック、下線付きにすることによって示されているなどである。

同様に、聴覚的な手がかりを用いることもある。例えば、チャイム音が新しい節の開始位置を示している。声のピッチや発話のスピードを変えて、重要な情報を強調したり、引用されたテキストを示したりしている、など。

そういった関係性が、ある利用者にとって知覚可能であれば、その関係性をすべての利用者が知覚できるようにすることが可能である。情報をすべての利用者にきちんと提供できたかどうかを判断する一つの方法は、その情報に様々な感覚モダリティで連続してアクセスしてみることである。

用語集にある用語へのリンクを a 要素（又は、使用している技術特有のリンク要素）を用いて実装して、異なるフォントで示していれば、スクリーンリーダーの利用者は、用語集にある用語のところで、たとえフォントの違いに関する情報は受け取れなかったとしても、それがリンクであることが音声読み上げを聞けば分かるだろう。あるオンラインカタログの価格表示では赤い大きなフォントを使用している。スクリーンリーダーの利用者は赤色の情報は得られないが、価格の前に通貨表示を記載することで情報を得ることができる。

ウェブコンテンツ技術の中には、ある種の情報及び関係性をプログラムで解釈する手段を提供していないものがある。そういった場合には、その情報及び関係性を説明するテキストを提供すべきである。例えば、「アスタリスク (*) のある項目はすべて必須項目です。」のように説明テキストを提供する。テキストによる説明は、例えば、その親要素又は隣接する要素内などのように、（そのページをリニアライズした際に）テキストが説明している情報の近くに置くべきである。

また、場合によっては、どんな情報をテキストで示すべきで、何を直接関連付ける必要があるのかは各自の判断に委ねるしかないこともあれば、ある情報を繰り返して提供することが最も適切なこともありえる（例えば、HTML のテーブルでは、そのテーブルの要約を、そのテーブルの前にある段落とそのテーブル自体の summary属性の両方で提供する）。しかし、できる限り、テキストによる説明を提供するのではなく、その情報をプログラムが解釈できるようにしなければならない。

この達成基準の意図

この達成基準の意図は、コンテンツの意味を理解するのに必要な音声読み上げの順序を保ちながら、ユーザーエージェントがコンテンツの代替表現を提供できるようにすることである。重要なのは、意味が通じるコンテンツの順序を、少なくとも一つのプログラムが解釈できることである。この達成基準を満たしていないコンテンツは、支援技術がそのコンテンツを正しくない順序で読み上げたり、代替スタイルシート又はその他の書式変更が適用されたりしたときに、利用者を困惑あるいは混乱させてしまう恐れがある。

コンテンツの並び順を変更すると、コンテンツの意味に影響を及ぼす場合、その順序には意味がある。例えば、あるページに2つの独立した記事がある場合、それらの記事の相対的な順序がそれぞれの意味に影響を及ぼす可能性はない。そのような状況においては、それらの記事自体には意味のある順序があるかもしれないが、それらの記事が入っているテキスト・コンテナには意味のある順序はないかもしれない。

ある要素のプログラムが持つ意味が、そのコンテンツに意味のある順序があるかどうかを定義している。例えば、HTMLでは、テキストには常に意味のある順序がある。テーブル及び順序付きリストには意味のある順序があるが、順序なしリストには意味のある順序がない。

コンテンツの並び順には、常に意味があるとは限らない。例えば、あるウェブページのメイン部分とナビゲーション部分の相対的な順序は、それぞれの意味には影響を及ぼさない。それらは、プログラムで解釈される音声読み上げ順序で、どちらが先にもなりえる。もう一つの例としては、雑誌の記事にはいくつかの補足記事がいくつか含まれている。記事と補足記事の順序は、それぞれの意味に影響を及ぼすことはない。このような場合においては、この達成基準を満たすことのできるウェブページには、異なる音声読み上げ順序が複数あることになる。

この達成基準の意図

この達成基準の意図は、形又は大きさを知覚できない、あるいは空間的な位置又は方向に関する情報を利用できない場合でも、すべての利用者がコンテンツを利用するための指示にアクセスできるようにすることである。コンテンツによっては、コンテンツの構造からは入手できない対象の形又は位置の知識（例えば、「円いボタン」又は「右のボタン」）に依存していることがある。障害のある利用者は、使用している支援技術の性質のために、形又は配置を知覚できないことがある。この達成基準は、このような情報に依存しているあらゆるものを明確にするために、補足の情報を提供することを要求している。

しかし、形及び/又は位置を用いて情報を提供することは、認知能力の低下している利用者を含む多くの利用者に対しては効果的な手法である。この達成基準は、その情報が他の形でも提供されている限り、形や位置の手がかりを使わないようにするものではない。

ある言語においては、「上記」はコンテンツのその地点よりも前にあるコンテンツを指し、「下記」はその地点よりも後にあるコンテンツを指すことが共通理解となっている。そういった言語では、そのように示されたコンテンツが、読み上げ順序の中で適切な位置にあり、その示し方が曖昧でなければ、「下記のリンクの中から一つ選んでください」あるいは「上記のすべて」といった記述は、この達成基準に適合していることになるだろう。

この達成基準の意図

この達成基準の意図は、色の違いによって伝えられている情報、言い換えれば、それぞれの色には割り当てられた意味があり、その色を使うことによって伝えている情報に、すべての利用者がアクセスできるようにすることである。画像（又は、その他の非テキスト形式）で色の違いによって情報を伝えている場合、色弱の利用者はその色が分からないかもしれない。この場合、色で伝えている情報を他の視覚的な手段で提供することで、色の分からない利用者もその情報を知覚することができるようになる。

色は、感覚的な訴求力、ユーザビリティ、そしてアクセシビリティを高めるため、ウェブコンテンツのデザインにおいて重要なものである。しかし、色を知覚しづらい利用者もいる。ロービジョンの利用者は、色覚に限界を感じることがよくあり、年配の利用者の多くも色がよく見えない。さらに、テキストしか表示しない、色数が制限されている、又はモノクロのディスプレイ及びブラウザを使用している利用者は、色だけで提示されている情報を知覚することができないであろう。

色の違いで伝えられている情報の例としては、「必須項目は赤字」、「赤字はエラー」、そして「赤がメアリーの売上、青がトムの売上」などが挙げられる。何が起こるかを示している例では、リンクが新しいウィンドウで開くことやデータベースの入力内容の更新が成功したことを示すのに色を使っていることがある。また、利用者の反応を促している例には、必須項目が未入力であることを示すためにフォームの入力フィールドを反転表示していることが挙げられる。

この達成基準の意図

スクリーンリーダーを使用している利用者は、同時に他の音声が再生されていると、スクリーンリーダーによる読み上げ音声が聞き取りづらくなる。スクリーンリーダーの読み上げ音声が、（今日ではほとんどがそうであるように）ソフトウェアをベースにしたもので、システム全体と同じ音量コントロールによって制御されていると、この状況はさらに悪化する。そのため、重要なのは、利用者が背景音の再生をオフにできることである。注記： 音量コントロールには、その音量をゼロまで下げられることを含む。

達成基準 1.4.7 小さい背景音又は背景音なしを理解するも参照のこと。

この達成基準の意図

この達成基準の意図は、中度のロービジョンの利用者（コントラストを強化する支援技術を使用していない利用者）がテキストを読めるように、テキストとその背景とのコントラストを十分に確保することである。色弱ではない利用者にとっては、色相及び彩度が文字の読みやすさに影響を与えることはほとんど又は全くないことが読解力による評価の結果からわかっている (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.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) に基づいている。

この達成基準及びその定義では、ウェブコンテンツが光自体を発するわけではないという事実を反映するために、「輝度」ではなく、「コントラスト比」及び「相対輝度」という用語を用いている。コントラスト比は、コンテンツが表示されたときに生じる相対輝度の評価基準（尺度）を与える（それは、比率なので、無次元である）。

この達成基準の意図

この達成基準の意図は、軽度の視覚障害のある利用者が、例えば画面拡大ソフトのような支援技術を使わずにそのまま読むことができるように、テキストベースのコントロールを含む視覚的に描画されるテキスト（ [ASCIIのようにデータとしての属性を持ち続ける文字ではなく] 視覚的に見ることができるように表示された文字）を問題なく拡大可能にすることである。利用者がメリットを享受できるのは、ウェブページ上のすべてのコンテンツを拡大できることだが、テキストが最も重要な意味を持つ。

コンテンツを拡大縮小することは、第一にユーザーエージェントが果たすべき役割である。UAAG 1.0 チェックポイント 4.1を満たしているユーザーエージェントは、利用者がテキストの拡大及び縮小を設定できるようにしている。コンテンツ制作者が果たすべき役割は、ユーザーエージェントがコンテンツを効果的に拡大縮小できるように、ウェブコンテンツを制作することである。コンテンツ制作者は、コンテンツがユーザーエージェントによるテキストベースのコントロールを含むテキストのサイズ変更を妨げていないことを確認すること、又はテキストのサイズ変更あるいはレイアウトの変更を直接可能にすることによって、この達成基準を満たすことができる。一つの例は、様々なスタイルシートを適用することができるサーバーサイドのスクリプトによって直接可能にすることができるかもしれない。

利用者がユーザーエージェントの拡大縮小機能を使用できない場合、コンテンツ制作者は、HTML コンテンツでこの達成基準を満たすのにユーザーエージェントに依存することはできない。例えば、利用者が IE 6 又は Firefox を使用する必要のある環境で仕事をしている場合などである。

ユーザーエージェントが拡大縮小機能を提供していないウェブコンテンツ技術をコンテンツ制作者が使用している場合、拡大縮小機能を直接提供すること、又はユーザーエージェントの提供する機能と連携するコンテンツを提供することが、コンテンツ制作者の果たすべき役割である。ユーザーエージェントが拡大縮小機能を提供していなくても利用者がテキストの大きさを変更できる場合、テキストの大きさを変更してもコンテンツが利用できる状態のままであるようにすることが、コンテンツ制作者の果たすべき役割となる。

ラベルとしての機能を有し、コンテンツにアクセスするために利用者が起動する必要のあるユーザーインタフェース要素の中には、そのラベルのコンテンツに対応するには幅が十分でないものがある。例えば、ウェブメールのアプリケーションにおいて、考えられうる件名すべてに対応できるほど件名欄の幅が広くないことがある。しかし、件名の見出しを起動することで、利用者は件名見出しとメッセージが全部表示された状態にすることができる。また、ウェブベースの表計算ソフトでは、セルの内容が長すぎて欄の中に表示できない場合には省略され、そのセルの内容の全部は、そのセルがフォーカスを受け取ったときに利用者に提供される。ユーザーインタフェース要素のコンテンツも、利用者が欄の幅を変更できる場合には、ユーザーインタフェース要素の幅よりも広くなってしまうことがある。この種のユーザーインタフェース要素では、行の折り返しは必須ではない。ユーザーインタフェース要素がフォーカスを受け取った時、又は利用者がユーザーインタフェース要素を起動した後にすべてのコンテンツが入手可能になり、この情報はアクセス可能であるということが何らかの方法で利用者に提示されている場合には、省略は許容される。

コンテンツが200％まで、言い換えれば、幅と高さが2倍になるまで、拡大可能であれば、そのコンテンツはこの達成基準を満たしていることになる。コンテンツ制作者はそれ以上の拡大をサポートしてもよいが、コンテンツをそれ以上拡大していくにつれて、アダプティブ・レイアウトはユーザビリティの問題を引き起こす可能性がある。例えば、語句の横幅が広くなりすぎると、省略されてしまうことになる。レイアウト上の制約によって、拡大していったときに、テキストが他のコンテンツと重なり合ってしまうこともある。あるいは、文章中の一つの単語だけが各行にある状態になると、その文章が縦に表示されてしまって読みづらくなってしまう。

WCAGワーキンググループは、広範囲に及ぶデザイン及びレイアウトをサポートできるという点と、最小の拡大率が200％である古い画面拡大ソフトを補完するという点から、200％が妥当ではないかと考えている。200％を超えると、拡大（テキスト、画像、及びレイアウト領域のサイズを変更し、横スクロールと縦スクロールを必要とする可能性のある大きなキャンバスを作り出す）のほうが、テキストのサイズ変更よりも効果的かもしれない。200％を超える状況では、拡大機能専用の支援技術が通常は使用されており、コンテンツ制作者が利用者に直接提供する機能よりもより良いアクセシビリティを提供することができる。

達成基準 1.4.8 視覚的な表現を理解するも参照のこと。

この達成基準の意図

この達成基準の意図は、テキストの特定の視覚的な表現を必要とする利用者が必要に応じてテキストの表現を整えられるようにすることを、特定の視覚的な表現が可能なウェブコンテンツ技術を用いるコンテンツ制作者に推奨することである。テキストに、特定のフォントサイズ、前景色及び背景色、書体、行間、又は配置を求める利用者がいる。

もし、テキストを用いて同じ視覚的な効果が得られるのであれば、コンテンツ制作者は、情報を提示するのに画像を用いるのではなく、テキストを用いるべきである。もしも何らかの理由により、コンテンツ制作者がテキストの書式を整えても同じ効果が得られない場合、その効果が一般に入手可能なユーザーエージェントでは確実に提示できない場合、又は、この達成基準を満たすウェブコンテンツ技術を用いることが達成基準 1.4.4 などの他の達成基準を満たすことの妨げになる場合には、画像化された文字を使ってもよい。例としては、書体のサンプル、ロゴタイプ、ブランドなどのように、伝える情報にとってそのテキストの特定の表現が必要不可欠な場合が該当する。また、画像化された文字は、広く普及していない又はコンテンツ制作者が再配布する権利を持っていない特定の書体を用いる目的で使われることもある。あるいは、そのテキストがすべてのユーザーエージェントでアンチエイリアスをかけた状態になるようにする目的で使われることもある。

利用者が画像化された文字を自分の好みに合わせてカスタマイズできる場合にも、画像化された文字を用いてもよい。

この達成基準を満たすための実装方法は、達成基準 1.4.9 と同じである。ただし、その視覚的な表現がコンテンツ制作者の用いるウェブコンテンツ技術で実現可能な場合に適用されるという点だけが異なる。達成基準 1.4.9 では、利用者がカスタマイズできるときのみ、達成基準を満たすことのできる実装方法が適用される。

達成基準 1.4.9 画像化された文字（例外なし）を理解するも参照のこと。

この達成基準の意図

この達成基準の意図は、（コントラストを強化する支援技術を使用していない）中度のロービジョンの利用者がテキストを読めるように、テキストとその背景とのコントラストを十分に確保することである。色弱ではない利用者にとっては、読解力によって評価されるように (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.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) に基づいている。

この達成基準及びその定義では、ウェブコンテンツが光自体を発するわけではないという事実を反映するために、「輝度」ではなく、「コントラスト比」及び「相対輝度」という用語を用いている。コントラスト比は、コンテンツが表示されたときに生じる相対輝度の評価基準（尺度）を与える（それは、比率なので、無次元である）。

この達成基準の意図

この達成基準の意図は、発話ではないあらゆる音が、音声の聞こえづらい利用者が発話を背景音又は前景にある不要な他の発話コンテンツと区別することができるようにすることである。

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] に基づいている。

この達成基準の意図

この達成基準の意図は、視覚的に描画されるテキストを、そのレイアウトにより読みやすさを損なうことなく、知覚できるように提示することである。認知の障害、言語の障害、及び学習障害のある利用者やロービジョンの利用者は、彼らにとってテキストが読みづらい方法で提示されていると、そのテキストを知覚できなかったり、どこを読んでいるのかが分からなくなったりすることがある。

視覚障害又は認知の障害のある利用者は、テキストの色及び背景色を選択できる必要がある。彼らは、その障害のない利用者にとっては分かりにくいとも思える組合せを選んでいることがある。そして、その組合せは、コントラストがとても低いこともある。また、とても限定された色の組合せしか有効でないこともある。色又はテキストの表現におけるその他の外観を制御できるかどうかによって、そういった利用者の読解力には大きな差が生じる。

読字障害又は視覚障害のある利用者にとっては、長い行のテキストは大きな障壁となりうる。彼らは、自分が読んでいる位置を把握し続けることや、テキストの行送りを目で追うことが苦手である。テキストのブロックの幅を狭くすることで、そういった利用者はテキストのブロックを読んでいるときに次の行へ読み進めていきやすくなる。そのため、行の幅は文字又はテキストを記述する構造上の構成要素である図形記号を含めて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ページ中に複数のフォーマットが組み合わされていて、プラグイン又は埋め込みアプリケーションで描画される際によく起こる問題である。

ただし、その状態を抜け出してフォーカスを「閉じ込められない」ようにする方法を利用者が分かっているのであれば、ウェブページの機能がフォーカスの移動をコンテンツの一部分に限定しているときがあってもよいのかもしれない。

この達成基準の意図

この達成基準の意図は、すべてのコンテンツをキーボードで操作可能にすることである。例外が認められないということを除いては、達成基準 2.1.1 と同じである。ただし、その根本的な機能が単に利用者の動作の終点に依存しておらず、利用者の動作による軌跡に依存した入力を必要とするコンテンツ（つまり、達成基準 2.1.1 では例外とされていたコンテンツ）をキーボードで操作可能にするということではない。正しくは、そういったアナログで時間の経過に依存した入力を用いるコンテンツは、この達成基準に適合することができないため、ガイドライン 2.1 にレベル AAA で適合することはできないということである。

この達成基準の意図

この達成基準の意図は、障害のある利用者がウェブコンテンツを操作するのに十分な時間の提供を、可能な限り保証することである。全盲、ロービジョン、巧緻性障害、及び、認知能力の低下している利用者は、コンテンツを読んだり、オンラインフォームに記入したりするような操作を実行するのに、より長い時間を必要とする場合もある。そのため、ウェブコンテンツの機能が時間の経過に依存している場合、制限時間内に必要な操作を実行することが困難な利用者もいるだろう。このことは、サービスをそういった利用者に対してアクセシブルではないものにしてしまう。そこで、機能を時間の経過に依存しないように設計することで、障害のある利用者がその操作を完了させやすくなる。制限時間を解除する、制限時間の長さを調整する、又は時間切れになる前に制限時間を延長するための選択肢を提供することは、作業を無事に終えると見込まれているよりも多くの時間を必要とする利用者の助けになる。利用者にとって最も有用なものから順に選択肢を挙げている。時間切れになる前に制限時間を延長できるようにすることよりも、制限時間の長さを調整できるようにすることのほうが望ましく、さらにそれよりも制限時間を解除できるようにすることのほうが望ましい。

利用者による起動がなく、設定時間後又は定期的に発生する処理は、どれも制限時間を表す。コンテンツの一部又は全部の更新（例えば、ページのリフレッシュ）、コンテンツの変更、利用者が入力の要求に対応するウィンドウの有効期限などが含まれる。

また、利用者が読んだり、理解したり、又はその両方をすることができない速度で進んだり更新したりするコンテンツも含まれる。言い換えれば、アニメーションや動画のコンテンツ、動きのあるコンテンツ、又はスクロールするコンテンツは、利用者がコンテンツを読むのに制限時間を課することになる。

しかし、ある場合において、（例えば、オークション又は他のリアルタイムのイベントの）制限時間を変更することは不可能であり、それゆえこれらの場合における例外が提供されている。

サーバーの制限時間に関する注記

• 制限時間のあるサーバーのリダイレクトは、以下にある「よくある不適合事例」の中で述べられている。

• ログインの有効期限のようなサーバーによる制限時間は、達成基準 2.2.5で扱う。

• 制限時間のないサーバーのリダイレクト（例： HTTPレスポンスコード 3xx）は、時間の制限がなく、瞬時に作動するので、この達成基準は適用されない。

• この達成基準は、コンテンツ自体が設定する制限時間だけに適用される。例えば、ユーザーエージェント又はインターネット固有の要因などにより、コンテンツ以外のものが設定する制限時間は、コンテンツ制作者が制御できるものではなく、WCAG への適合要件の対象とはならない。ウェブサーバーにより設定される制限時間は、コンテンツ制作者が制御できるものであり、達成基準 2.2.5が対応している。

• デフォルトの10倍は、臨床的経験及び他のガイドラインに基づいて選んでいる。例えば、利用者が反応してスイッチを押すのに15秒間与えられていたら、たとえ問題があったとしても、150秒はすべての利用者がスイッチを押すのに十分な時間であろう。

• また、20秒間も、臨床的経験及び他のガイドラインに基づいている。「あらゆるスイッチ」を押すのに、20秒あれば、痙性（麻痺している筋肉が自分の意思に関わらず勝手に緊張して収縮する症状）のある利用者も含むほとんどすべての利用者にとって十分である。中にはそれでも足りない利用者もいるかもしれないし、時間をどれだけ延ばしても足りない利用者もいるだろう。任意の長い時間にしてしまうと、あるアプリケーションに対して障害のある利用者を含むすべての利用者を危険な状態にするため、時間の延長を要求するのに妥当な時間を定める必要がある。例えば、金融取引に用いられるキオスク端末又は端末装置は、利用者が取引を終了せずにその場を離れてしまうことが非常によくある。そのままでは、端末を次の人に不正利用されやすい状態にしておくことになる。利用者の確認をせずに休止状態を長時間与えて、長時間にわたって利用者がその場にいるという状態にしておくことは、端末を不正利用の危険にさらすことになる。何も動きがなければ、システムはそこに利用者がいるかどうかを確認しなければならない。そのため、システムは、利用者がそこにいることを確認するように求め（「どれかキーを押してください」）、誰もが応じることができるだけの長さで利用者の反応を待つべきである。「どれかキーを押してください」に対して、20秒という時間は、この条件を満たすであろう。もし利用者が自分はまだそこにいるということを示せば、その端末は利用者に確認する前と同じ状況を利用者に再び提示しなくてはならない。

• 一日に起きている時間よりも長いので、上限として20時間を選んだ。

制限時間が本質的な要件ではなく、利用者に制限時間のあるイベントを制御できるようにすることが、その結果を無価値にするような場合には、第三者がその利用者のために制限時間を調整することができる（例えば、試験に2倍の時間を与える）。

達成基準 2.2.3 制限時間なしを理解するも参照のこと。

この達成基準の意図

この達成基準の意図は、利用者がウェブページとやりとりしている間、他の事に注意をそらされないようにすることである。

「動き、点滅、スクロール」は、目に見えるコンテンツが動きの印象を伝えているコンテンツのことを指している。一般的な例は、動画、同期したメディアの表示、アニメーション、リアルタイムのゲーム、スクロールする株価表示などがある。「自動更新」は、あらかじめ設定された間隔で更新したり、消えたりするコンテンツのことを指している。一般的な時間の経過に伴って変化するコンテンツは、音声、自動的に更新される天気情報、ニュース、株価更新、及び自動進行する表示やメッセージなどがある。動き、点滅、スクロールするコンテンツと自動更新するコンテンツに対する要件は、次のものを除いて同じである：

• コンテンツが自動的に更新される際に、コンテンツ制作者が利用者に更新頻度を制御する手段を提供するという選択肢がある、

• 5秒間だけ自動更新をして，その後に停止するのはほとんど意味がないので、自動更新には5秒という例外はない。

  訳注： 原文では "three second" と記述されているが、達成基準に記載されている内容から「5秒」が正しい値であると判断し、秒数を修正している。

動きのある又は自動更新するコンテンツは、動かないテキストを素早く読むのが困難な利用者及び動きのあるオブジェクトを目で追うのが困難な利用者にとっての障壁となることがある。また、スクリーンリーダーの利用者にも問題を引き起こすことがある。

動きのあるコンテンツは、ある利用者にとっては深刻なかく乱を引き起こすことがある。特に注意力欠如障害のある利用者などは、点滅しているコンテンツに気を取られてしまい、ウェブページのそれ以外の部分に集中するのが困難になってしまう。5秒を基準として選んだのは、利用者の注意を引くには十分な長さであり、なおかつ、ページを利用することが必要であれば、利用者が気が散らされるのを待てない長さではないからである。

一時停止したコンテンツは、リアルタイムで再開するか、利用者が一時停止したところから再生を続けるかのどちらかである。

1. 一時停止した後、利用者が一時停止したところから再開することが、コンテンツを読むために一時停止したいと思う利用者にとっては最適であり、コンテンツがリアルタイムのイベント又は状態に関係のないときには最も良い方法である。

   注記： 読むための制限時間に関するその他の要件については、 達成基準 2.2.1 調整可能な制限時間を理解するを参照のこと。

2. 一時停止した後、（一時停止を解除した時に）最新の表示へ移ることが、リアルタイム又は本来の「状態」にある情報にとってよりよいことである。例えば、気象レーダー、株価表示、交通情報カメラ、又はオークションのタイマーなどは、コンテンツ再開時に一時停止したことで古い情報が表示されると、誤った情報を提供してしまうことになる。

   注記： コンテンツを非表示にすることは、一時停止した後、（一時停止を解除した時に）最新の表示へ移るのと同じ効果が得られる。

この達成基準の意図

この達成基準の意図は、制限時間のあるインタラクションを要求するコンテンツの提供を最小限にすることである。それにより、全盲、ロービジョン、認知能力の低下、又は運動障害のある利用者が、コンテンツとやりとりできるようになる。この達成基準は、唯一の例外がリアルタイムのイベントであるという点で、達成基準レベル A とは異なる。

この達成基準の意図

この達成基準の意図は、緊急を要する場合を除いて、利用者がコンテンツ制作者／サーバーからの更新を止めることができるようにすることである。緊急には、市民向け緊急警報メッセージ、又はデータを失ったり，つながりを失ったりするなどを含む、健康、安全、財産の危険を警告するその他のメッセージがある。

これにより、認知能力の低下、又は注意力欠如のある利用者が、コンテンツに集中することができるようになる。全盲又はロービジョンの利用者が、現在読んでいるコンテンツに神経を集中し続けられるようにもなる。

この達成基準の意図

この達成基準の意図は、何の作業もしていない時の制限時間又は処理を完了する途中で利用者をログアウトさせてしまうその他の状況がある、認証済の処理を、すべての利用者が完了できるようにすることである。

セキュリティ上の理由により、多くのサイトが、何の作業もせずに一定時間が経過した後の認証の制限時間を設定している。障害のある利用者は作業を完了させるのにより長く時間がかかるので、制限時間は問題を引き起こすかもしれない。

その他のサイトでは、利用者が他のコンピュータからそのウェブサイトにログインするか、その利用者がもともとログインした利用者と本当に同じかどうかに疑問を抱くようなその他の行為があった場合には、利用者を認証済のセッションからログアウトさせるだろう。処理中であったとしても利用者がログアウトさせられる際には、再認証を受けることができ、すでに入力済のデータを失うことなくその処理を継続できるようにすることが重要である。

この達成基準の意図

この達成基準の意図は、利用者が光過敏性による発作を引き起こすことなく、サイト上のすべてのコンテンツを利用できるようにすることである。

光過敏性発作の疾患のある利用者は、数回以上の閃光があり、一定の周期で閃光を放つコンテンツによって発作を引き起こされる恐れがある。他の色よりも赤色の閃光に対してさらに敏感であるため、彩度の高い赤色の閃光に対して特別な試験方法を提供している。このガイドラインは、コンテンツがより近い距離で（より大きな視角を用いて）閲覧されるコンピュータの画面にも適用されるような、放送業界向けのガイドラインに基づいている。

ディスプレイ、画像を描画するコンピュータ、又は描画されるコンテンツによって、閃光が発生する可能性がある。コンテンツ制作者には、最初の二つを制御することはできない。それらは、ディスプレイ及びコンピュータのデザインと速度によって対処することができる。この達成基準の意図は、コンテンツ自体が閃光閾値を超えて明滅しないようにすることである。例えば、連続したストロボの閃光を放つ又は立て続けに起こる爆発をクローズアップにした、ビデオクリップ又はアニメ画像がコンテンツに含まれる可能性がある。

この達成基準は、広い周波数帯域（3～50ヘルツ）内のあらゆる閃光（1ピクセルでさえも）許容していなかった、WCAG 1.0 のずっと厳しい基準に置き換わるものである。この達成基準は、英国及び諸国でテレビ放送向けに用いられていて、コンピュータのディスプレイでの閲覧にも適用されてきた、既存の仕様に基づいている。そして、1024 x 768 ピクセルの画面を評価の基準となる画面解像度として用いている。 341 x 256 ピクセルの矩形が、標準的な視距離からの視野角10度に相当するものとしている（10度の視野角は、既存の仕様から取り出した数字で、人が光の刺激に対して最も敏感である、眼の中心視野に相当する）。

同時に、かつ隣接して存在する閃光を組み合わせた領域は、実質的には同時に閃光を放っている総面積を意味する。その領域は、任意の視角10度以内で同時に閃光を放っている隣接した領域を合計して算出される。

この達成基準の意図

この達成基準の意図は、光過敏性発作を引き起こす可能性をさらに引き下げることである。とても過敏な利用者もいるため、光過敏性発作の可能性を完全に取り除くことはできない。しかし、画面のあらゆる領域にわたって1秒間に3回閃光を放つものをすべて取り除くことにより、利用者が発作を起こす可能性は、達成基準 2.3.1でそうしているように、単に今日の国際的な標準規格で通常用いられている基準を満たしているときよりも、さらに引き下げられる。

達成基準 2.3.1 では、十分に薄暗い又は領域が十分に小さい閃光を許容しているが、達成基準 2.3.2 は、その明るさ又はサイズに関係なく、1秒間に3回よりも多く閃光を放つことを認めていない。結果として、1ピクセルの閃光であっても、この達成基準には反することになる。その意図は、1ピクセルよりも大きい閃光を防ぐことにあるが、コンテンツ制作者が知る術のない画面拡大又はハイコントラストの設定が適用されているかもしれないため、あらゆる閃光を禁じているのである。

この達成基準の意図

この達成基準の意図は、コンテンツ内を一つずつ順を追って行き来している利用者がウェブページのメインコンテンツへ直接移動できるようにすることである。 ウェブページ及びウェブアプリケーションには、他のページ又は画面でも現れるコンテンツがしばしばある。コンテンツの中で繰り返されているブロックの例としては、ナビゲーション・リンク、見出しのグラフィック、そして広告を表示するフレームなどが挙げられる。個々の単語、フレーズ、又は単独のリンクなどの小さな繰り返される部分は、この達成基準の趣旨においては、ブロックとしてみなされない。

このことは、画面を見ている利用者が、画面の中央（通常は、メインコンテンツがあるところ）に意識を集中することによって、繰り返しているコンテンツを無視することができることや、マウスを使用している利用者が、目的のリンクの前にあるすべてのリンク又はフォームのコントロールと出くわさずに、1回のクリックでそのリンクを選択できることと対照的である。

この達成基準の意図は、コンテンツ制作者にユーザーエージェントが提供している機能と重複する手段を提供するように求めることではない。ほとんどのウェブブラウザは、利用者がフォーカスをページの先頭に戻すことのできるキーボード・ショートカットを提供しているので、ナビゲーション・リンク一式をウェブページの下部で提供している場合は、いわゆる「スキップ」リンクを提供する必要はないかもしれない。

この達成基準の意図

この達成基準の意図は、各ウェブページにその内容を示すページタイトルを付けることによって、利用者がコンテンツを見つけやすく、自分の現在位置を確認しやすくすることである。タイトルがあれば、利用者はページのコンテンツを読んだり解釈したりすることなく、現在位置を確認することができる。タイトルがサイトマップ又は検索結果のリストに表示されたときに、利用者は自分の求めているコンテンツをより素早く確認できるようになる。ユーザーエージェントは、利用者がそのページを確認できるように、ページのタイトルを容易に見つけられるようにする。例えば、ユーザーエージェントは、そのページタイトルをウィンドウのタイトルバーに表示するか、又はそのページを表示しているタブの名前として表示する。

この達成基準の意図

この達成基準の意図は、利用者がコンテンツ内を一つずつ順を追いながら行き来している際に、キーボードにより操作可能な順序でコンテンツの意味に添って、情報と出会うようにすることである。このことにより、利用者のコンテンツに対するメンタルモデルを一貫したものとし、利用者が困惑する可能性を引き下げる。コンテンツの論理的な関係性を反映した異なる順序になることもある。例えば、テーブルのある行又は列にある構成要素内を一度に移動する際には、行を移動する際も列を移動する際もコンテンツにおける関係性を反映した順序になる。どちらの順序もこの達成基準を満たすことができる 。

ウェブコンテンツでのナビゲーションの順番が決まる方法は、コンテンツで用いるウェブコンテンツ技術によって定義されている。例えば、シンプルな HTML は、タブ移動順序によってナビゲーション順序を定義している。動的な HTML では、フォーカスを他の要素にも割り当てることができるように tabindex 属性を付加して、スクリプトを用いてナビゲーション順序を修正することができる。スクリプトも、tabindex 属性も使用していない場合、ナビゲーション順序は、コンポーネントがコンテンツの流れの中で表れる順序になる（HTML 4.01 仕様書の 17.11 "Giving focus to an element"： 日本語訳は「17.11 ある要素にフォーカスを合わせる」を参照のこと）。

この達成基準で対処しているナビゲーション順序ではない、キーボード・ナビゲーションの一例は、ツリー・コンポーネントを行き来するための矢印キーを用いたナビゲーションである。利用者は、上下の矢印キーを使って、ツリーのノードからノードへと移動することができる。左向き矢印キー（訳注：正しくは、右向き矢印キーと思われる）を押下するとノードを展開して、それから下向き矢印キーを押下すると新しく展開されたノードへと移動していく。アイテムが展開されたり閉じられたりするたびに、ナビゲーション順序に追加されたり削除されたりするので、このナビゲーション順序は、ツリー・コントロールで予期される順序に従っている。そして、アイテムが展開されたり閉じられたりするたびに、ナビゲーション順序に追加されたり削除されたりする。

利用者はウェブページを理解して操作できているが、フォーカス順序がプログラムが解釈する音声読み上げ順序（達成基準 1.3.2 を参照）とは一致しないかもしれない。 コンテンツに対して考えられうる論理的な音声読み上げ順序が数通りあり、フォーカス順序はそのうちのどれかと合致するのかもしれない。 しかし、特定のプレゼンテーションにおける順序が、プログラムが解釈する音声読み上げ順序とは異なるとき、複数あるプレゼンテーションの一つを使う利用者は、そのウェブページを理解したり操作したりするのを難しいと感じるかもしれない。 コンテンツ制作者は、ウェブページを設計する際に、すべての利用者のことを注意深く考慮すべきである。

例えば、画面を見ているキーボードの利用者が、ウェブページの視覚的なプレゼンテーションの順序で情報をやりとりしているのに対し、スクリーンリーダーの利用者は、プログラムで判断される音声読み上げ順序で情報をやりとりしている。フォーカス順序が双方の利用者にとって意味が通じるようにし、どちらかがコンテンツ内をランダムに飛び回るようなことのないように、注意すべきである。

この達成基準の意図

この達成基準の意図は、利用者がそのリンク先へ行きたいかどうかを決めることができるように、各リンクの目的を理解しやすくすることである。可能な限り、その他の文脈が必要ないように、リンクの目的を示すリンクテキストを提供するとよい。 支援技術は、そのウェブページにあるリンクの一覧を利用者に提供することが可能である。リンクテキストにできる限り意味を持たせることで、利用者はこのリンクの一覧から選びやすくなる。また、意味のあるリンクテキストは、リンクからリンクへと Tab キーで移動したい利用者にとっても役に立つ。そして、意味のあるリンクは、そのリンク先のページを理解するのに面倒な方法をとることなく、利用者がリンクを選びやすくなるのである。

ある状況においては、コンテンツ制作者は、リンクの説明の一部を、そのリンクの文脈を提供する論理的に関係のあるテキストで提供したいことがある。この場合、利用者がリンクからフォーカスを移動させずに、そのリンクの目的を確認できなければならない。言い換えれば、利用者があるリンクにやってきて、その位置にいたままで、リンクに関するより多くの情報を探し出すことができる必要がある。これは、同じ文、段落、リスト項目、そのリンクの直前にある見出し、リンクであるテーブルのセル、又はデータテーブル内にあるリンクの見出しセルに、リンクの説明を置くことで可能である。なぜなら、それらはリンク自体と直接関連付けられているからである。

こういった文脈は、リンクの前にあると、最も使いやすいだろう（例えば、曖昧なリンクテキストを使わなければならない場合、その曖昧な語句をリンクの行き先を説明する文章の初めに置くよりも、リンクの行き先を説明する文章の最後に置いたほうが分かりやすい）。リンクの後に説明がきてしまうと、ウェブページを（先頭から最後まで）順に読んでいるスクリーンリーダーの利用者が、困惑したり、理解しづらかったりする可能性がある。

リンク先が同じリンクには、（達成基準 3.2.4により）同じ説明があるべきだが、異なる目的で異なるリンク先であるリンクには異なる説明があるべきである。

この達成基準には、リンクの目的をウェブページ上にある情報からは判断できないリンクに対して例外が認められている。そのような状況では、障害のある利用者が不利な立場にあるわけではない。リンクの目的を理解するために追加入手可能な文脈が一切ないのである。しかし、ウェブページ上でリンクの目的を解釈するために どんな量であれ文脈が 利用できるなら、この達成基準を満たすためには リンクテキスト内で利用できるか、又はプログラム的にリンクと関連付けられるか、ができなければいけない。

達成基準 2.4.9 リンクの目的を理解するも参照のこと。

この達成基準の意図

この達成基準の意図は、利用者が自分のニーズに最も合う方法によってコンテンツを見つけることができるようにすることである。コンテンツを見つける手段が複数あれば、利用者は、自分にとって使いやすい又は分かりやすい手段を選ぶことができる。

小規模なサイトであっても、利用者に複数の探索手段を提供すべきである。すべてのページがサイトのホームからリンクされている3～4ページのサイトでは、ホームから各ページへのリンクと、各ページからホームへのリンクを提供するだけで十分かもしれない。ホームにあるリンクがサイトマップのような役割も果たすからである。

この達成基準の意図

この達成基準の意図は、ウェブページにどんな情報があるのか、及びその情報がどのように構成されているのかを、利用者が理解しやすくすることである。見出しが明快で内容を説明していれば、利用者は自分の探している情報をより容易に見つけことができる。また、利用者はコンテンツ内の様々な部分間の関係性をより容易に理解することができる。また、ラベルが分かりやすければ、利用者はコンテンツ内にある特定のコンポーネントを識別しやすくなる。

ラベル及び見出しを長くする必要があるわけではない。単語一つ又は一文字だけであっても、コンテンツを見つけてナビゲートする手がかりとして適切であれば、それだけで十分なこともある。

この達成基準の意図

この達成基準の意図は、キーボード・フォーカスの表示が視覚的に確認できる操作モードが少なくとも一つあるようにすることである。

この達成基準の意図

この達成基準の意図は、集中力が長く持たない利用者がウェブページ一式、ウェブサイト、又はウェブアプリケーションの中で自分のいる位置を確認することができ、関連する情報を見つけることができるようにすることである。

この達成基準の意図

この達成基準の意図は、利用者がそのリンク先に行きたいかどうかを判断できるように、コンテンツにあるそれぞれのリンクの目的を理解しやすくすることである。（達成基準 3.2.4 により）リンク先が同じリンクは同じ記述であるべきだが、目的やリンク先が異なるリンクはその記述も異なるようにすべきである。リンクの目的はそのリンクテキストによって確認できれば、例えばユーザーエージェントがページ上の全てのリンクの一覧を提供する際のように、前後の文脈に関係ない状態でも、利用者はリンクを理解することができるようになる。

この達成基準には、リンクの目的をウェブページ上にある情報からは判断できないリンクに対して例外が認められている。そのような状況では、障害のある利用者が不利な立場にあるわけではない。リンクの目的を理解するために追加入手可能な文脈が一切ないのである。しかし、この達成基準を満たすためには、そのリンクの目的を解釈するためにそのウェブページ上で利用できる文脈はどんなものであれ、そのリンクテキストで入手可能にしなればならない。

「メカニズム」という用語を用いているのは、コンテンツ制作者がすべてのリンクを前後の文脈に関係なく完全に理解できるようにするか、あるいはそのようにする方法を提供できるようにするためである。リンクすべてをリンクテキストだけでも曖昧ではないようにすることで、ページによっては、分かりやすくなる利用者もいれば、分かりづらくなってしまう利用者もいる。リンクを（それ自身により）明らかにするか そうしないか できるようにすることは、障害のある利用者にも無い利用者にも、彼らのニーズに最も合致したフォーマットのページを使えるようにすることである。

例えば、100冊の書籍のタイトルが並んでいるページに、それぞれの書籍を HTML、PDF、DOC、TXT、MP3、又は AAC でダウンロードするリンクがある場合、たいていは書籍のタイトルの後に「HTML版」のようなリンクがある。そして、「次のバージョンも利用可能：」という文が続いていて、「HTML」、「PDF」、「DOC」、「TXT」、「MP3」、そして「AAC」という短いテキストのリンクがある。レベル AAA では、ある利用者は このようにページを見ることが選べるであろう。それぞれのリンクに書籍のタイトルがあると、分かりづらかったり、使うのに時間がかかってしまったりするからである。その他の利用者は、それぞれのリンクがそれだけで理解できるように、それぞれのリンクの一部に書籍のタイトルがあるようにページを見ることが選べるであろう。前者のグループにも後者のグループにも、いろいろな使い方をしている、又は様々な種類や度合いの障害のある、視覚又は認知の障害のある利用者が含まれるであろう。

この達成基準の意図

この達成基準の意図 は、ウェブページがセクションで構成されている際には、そのページの各セクションに見出しを提供することである。例えば、長い文章は様々な章に分かれていて、各章にはサブトピックがあり、サブトピックは様々なセクションに分かれていて、セクションには段落があって、という具合にである。そのようなセクションがある際、各セクションにはその内容を紹介する見出しがある必要がある。各セクションの見出しは、コンテンツの構造を示し、コンテンツ内でのナビゲーションを可能にし、そしてコンテンツの理解を助けるメンタルな「取っ掛かり」を提供する。ページのその他の要素（例：横罫線、囲み罫線）が見出しを引き立たせて、見栄えをより良くすることもできるが、視覚的なプレゼンテーションは文章のセクションを特定するには十分ではない。

この達成基準がレベル AAA になっているのは、すべての種類のコンテンツには適用できないのと、見出しを挿入することが常に可能であるとは限らないからである。例えば、既存の文書をウェブで公開する際、その文書の作成者が付けなかった見出しを挿入できないことがあるからである。あるいは、長い手紙には様々なトピックが書かれていることが多いが、手紙に見出しを付けるととてもおかしくなってしまう。しかし、文書を見出しの付いたセクションに分けることができるのであれば、文書は理解しやすく、ナビゲートしやすいものになる。

この達成基準の意図

この達成基準の意図は、ユーザーエージェントがテキスト及びその他の形式の自然言語によるコンテンツを正しく提示するために必要な情報を、コンテンツ制作者がウェブページで適切に提供するようにすることである。支援技術と従来のユーザーエージェントはともに、ウェブページの言語が示されていれば、テキストをより正確に描画することができる。例えば、スクリーンリーダーは、正しい発音規則を読み込むことができ、ビジュアルブラウザは、文字や書体を正しく表示することができる。また、メディアプレーヤーは、キャプションを正しく表示できる。これにより、障害のある利用者がコンテンツをより理解できるようになる。

Internationalization Best Practices: Specifying Language in XHTML & HTML Content で述べられているように、ウェブページのデフォルトの自然言語が、デフォルトのテキスト処理言語となる。ウェブページがいくつかの言語を使用している際、デフォルトのテキスト処理言語は、最も使われている言語である（もし同じ割合で使われている際には、最初に使われている言語がデフォルトの自然言語となるはずである）。

この達成基準の意図

この達成基準の意図は、複数の言語で書かれているコンテンツをユーザーエージェントが正しく提示できるようにして、利用者がテキストを理解するのを助ける支援技術が、その言語を処理する上で必要な特有の知識及びリソースを適切に用いることができるようにすることである。これは、グラフィカルブラウザ及びスクリーンリーダー、点字ディスプレイ、そしてその他の音声ブラウザに当てはまる。

支援技術及び従来のユーザーエージェントはともに、テキストを構成する節それぞれの記述に用いられている言語が示されていると、テキストをより正確に描画できる。スクリーンリーダーは、テキストの言語の発音規則を用いることができる。また、ビジュアルブラウザは文字及び書体を適切に表示することができる。左から右へ読む言語と右から左へ読む言語が切り替わる際、又はテキストが異なる種類のアルファベットを用いる言語で描画される際に、特にこれは重要である。そのウェブページで用いられているすべての言語を理解できる場合、テキストを構成する節それぞれが適切に描画されると、障害のある利用者は、コンテンツをよりよく理解できるようになる。

テキスト中の語句又は一説に何も言語が指定されていない場合、その語句や説の自然言語は、そのウェブページのデフォルトの自然言語となる（達成基準 3.1.1 を参照）。そのため、単一の言語で記述されたドキュメントの場合は、すべてのコンテンツの自然言語をプログラムが解釈できることになる。

ある言語の個々の単語又は語句が、他の言語の一部になることがある。例えば、"rendezvous" は、英語に持ち込まれたフランス語の単語で、英語の辞書にも掲載されているし、英語のスクリーンリーダーでも適切に発音される。それゆえ、英語のテキストの一節に "rendezvous" という単語が、その自然言語がフランス語であることが示されることなく含まれていることがあるが、これはこの達成基準を満たしていることになる。しばしば、テキストの自然言語が一つの単語に対してだけ変化するようなとき、その単語は周囲にあるテキストの言語の一部となっていることがある。これは、言語によっては一般的なことなので、言語を意図的に変えていることが明白でない限り、その単語は周囲にあるテキストの言語の一部であるとみなすべきである。言語を意図的に変えているかどうかが疑わしい場合は、その単語が隣接するテキストの言語で同じように発音されるかどうかを考えてみるとよいだろう（ただし、アクセントやイントネーションは除く）。

ほとんどの専門的な職業では、もともとは外国語からきた技術用語を頻繁に使うことを必要とする。そのような用語は、通常すべての言語に翻訳されるわけではない。技術用語は広く共通のものが用いられる傾向があり、専門家の間でのコミュニケーションの促進につながっている。

技術用語のよくある例としては、次のようなものがある： ホモ・サピエンス (Homo sapien)、アルファケンタウリ (Alpha Centauri)、ヘルツ (hertz)、ヘイビアス・コーパス (habeas corpus) など。

言語の変化を示すことは、多くの理由から重要である：

• 点訳ソフトウェアが言語の変化に従うことができるようになる。例えば、アクセント文字を適切な符号に置き換えたり、必要な符号を挿入し、2級点字の縮字の誤りを回避したりすることができる。

• 複数の言語をサポートしている合成音声を用いて、テキストを適切なアクセントと正確な発音で読み上げさせることができるようになる。言語の変化が示されていない場合、合成音声のシステムはその単語をデフォルトの言語として読み上げるのに最善を尽くそうとする。したがって、フランス語で自動車を表す "voiture" は、英語をデフォルトの言語として用いている合成音声では "voyture" というような音で発音されてしまう。

• 言語の変化を示すことで、将来の技術の開発にも役立つことがある。例えば、複数の言語の間での翻訳をすることができない利用者が、機械翻訳を使って馴染みのない言語を扱うことができるようになるかもしれない。

• また、言語の変化を示しておけば、ユーザーエージェントが辞書を用いて用語の定義を提供するのを支援することもできるだろう。

この達成基準の意図

特定の障害によって、文字通りの意味ではない言葉の使い方や特殊な言葉の意味や使い方を利用者が理解しづらいことがある。また、比喩的な言い回し又は特殊な使い方を理解しづらくする障害もある。そのような障害のある利用者に対しては、この達成基準に適合するメカニズムを提供することが不可欠である。専門家ではない読者向けに特殊な情報を提供する際は、レベル A、又は、レベル AA での適合をしようとしている場合であっても、この達成基準にも適合することを推奨する。

この達成基準の意図

この達成基準の意図は、利用者が略語の元の語句を知ることができるようにすることである。

この達成基準の意図

コンテンツは、可能な限り明快かつ簡潔に書かれているべきである。この達成基準の意図は以下の通りである：

• 難解又は複雑な文章を理解しやすくするために、補足的コンテンツを提供すること。

• そのような補足的コンテンツがどういうときに必要なのかを示すテスト可能な基準を定めること。

この達成基準は、コンテンツ制作者が難しい又は複雑なウェブコンテンツを公開できるようにしながらも、読字障害のある利用者の手助けとなる。文章の難しさは、それを読むのに必要とされる教育の水準という観点から説明されている。教育レベルは、教育システムを国際的に比較できるようにするために作成された国際標準教育分類 [UNESCO] に従って定義している。

難しい又は複雑な文章が、想定した利用者層のほとんど（つまり、コンテンツの対象者のほとんど）に対しては適切なこともある。しかし、その分野における専門的な知識を持つ高学歴の利用者の中にも、読字障害を含めて、障害のある利用者がいる。文章をより読みやすくすることで、そういった利用者にも対処することが可能である。文章をそれ以上読みやすくすることができない場合には、補足的コンテンツが必要となる。補足的コンテンツが必要となるのは、その文章が前期中等教育レベル以上の読解力が求められる場合である。つまり、9年よりも長い学校教育を受けている必要がある場合である。補足的コンテンツが必要となるような文章は、読字障害のある利用者にとっては深刻な障壁となり、後期中等教育を修了した障害のない利用者にとっても難解であると考えられている。

書かれた単語又は印刷された単語を認識して、正しい音と関連付ける処理を文章の「復号化」という。ディスレクシア（失読症）などの読字障害は、文章の復号化をしづらくする。 復号化は、人がすらすらと読むためには、無意識に行われるものである。文章を1単語ずつ復号化しなければならない場合、多くの人が自分の読んでいるものを理解するために用ている精神的なエネルギーの多くを、この行為に消費しなければならないことになる。簡潔でよく使われる単語及び簡潔な文を用いた文章は復号化しやすく、長文及び長い単語又は馴染みのない単語を用いている文章ほどの読解力を通常は必要としないものである。

テキストのコンテンツを読むのに必要な教育レベル（リーダビリティ (readability) とも呼ばれる）は、ウェブページ上の文章から抽出した節を解析することで測定することができる。ウェブページに異なる目的で書かれた文章、又は異なるスタイルを用いた文章がある場合は、ウェブページにあるコンテンツの種類のサンプル、及びそのコンテンツが書かれている異なるスタイルのサンプルを含める（多くの場合、ウェブページには、1つの種類のテキストコンテンツしかない。例えば、技術的な文書、法律上の表示、マーケティング素材など。そして、すべてのコンテンツは同じスタイルを用いている）。

教育者もまた、テキストコンテンツを読むのに必要とされる教育レベルを測定することができる。例えば、資格のある教師は、前期中等教育の最終学年の生徒に要求される以上の読解力を必要とするかどうかを判断するために、ローカルの教育標準に従って文章を評価することができる。

人名、都市名、又はその他の固有名詞を変更して短くすることはできないため、そしてそうすることや単に代名詞でそれらを指すことは文章を理解しづらくする恐れがあるため、この達成基準では、読解力の要件を満たしているかどうかを検証する際には、固有名詞を無視するか文章から取り除くことができるとしている。タイトルは、文書、書籍、映画などの名前のことを指している。タイトルにある文言を変更してしまうと、読みやすくはなるかもしれないが、そのタイトルがどのアイテムを指しているのかが分からなくなってしまうため、分析する際にはタイトルを削除するか無視してもよい。そのため、タイトルも、明確に適用対象外となる。

ウェブページに複数の言語があるときは、リーダビリティの検証結果は、コンテンツの少なくとも5％を占めていて、全文又は段落全体で使われている言語ごとに算出すべきである（個々の単語又は語句だけというのは除く）。そして、そのページ全体のリーダビリティは、最も悪い結果を出した言語で判断しなければならない。

また、コンテンツのリーダビリティは、抽出した節にリーダビリティの計算式を適用することで判断できることもある。（すべてではないが）多くのリーダビリティの計算式は、100ワードで計算している。そのような計算式が、多くの言語に対して作られている。その節にある単語の数を数えて、単語の長さを音節の数又は文字数のどちらかを数えて判断している。ほとんどのリーダビリティ計算式は、文の長さと数も考慮に入れている。そして、コンテンツの単語及び文の平均的な長さを用いて、リーダビリティのスコアを算出している（日本語のような言語では、同じ節の中に2種類の文字が含まれていることがある。このような言語のリーダビリティ計算式は、その「連続」の数及び長さも計算に入れているかもしれない）。計算結果は、数字（例えば、0箸ｷ100の範囲）又は学年で提示される。そして、この結果を国際標準教育分類にある教育レベルを用いて評価することができる。リーダビリティの計算式は、少なくともいくつかの言語では、人気のあるソフトウェアのスペルチェック機能で利用可能で、オプションで文書のチェック完了時にリーダビリティの解析結果も表示するように指定することができる。

出典： 国際標準教育分類 [UNESCO]

この達成基準の意図

この達成基準の意図は、全盲の利用者、ロービジョンの利用者、及び読字障害のある利用者が、意味が発音に依存している場合に、コンテンツを理解しやすくすることである。発音（読み）が変わると、意味も異なってくる単語又は文字がある。そのような単語又は文字の意味は、文章の前後の文脈から通常は判断される。しかし、より複雑あるいは曖昧な文章の場合や、いくつかの 言語においては、読み方が分からないと、その単語の意味を容易に判断できない又は全く判断できないことがある。スクリーンリーダーが文章を読み上げている際に単語を誤った読み方で読み上げてしまうと、視覚的にその文章を読んでいる場合よりもずっと理解しづらくなってしまう可能性がある。読み方が分からない限り、その単語の意味が曖昧又ははっきりしない場合は、その読み方を何らかの手段で分かるようにする必要がある。

例えば、英語では、"desert"（見捨てる）と"desert"（砂漠）のように、スペルは同じでも発音と意味が異なる、同形異音異義語と呼ばれる単語がある。文章の前後の文脈から適切な発音を判断できる場合は、何もする必要はない。もし判断できないのであれば、適切な発音を判断することのできる何らかのメカニズムが必要となる。加えて、特定の文字に様々な読み方が存在する言語もある。例えば、日本語には、複数の読みを持つ漢字のような文字がある。スクリーンリーダーは、読み方に関する情報がないと、その文字を誤った読み方で読み上げてしまうことがある。正しく読み上げられなければ、そのコンテンツは利用者にとっては理解できないものになってしまうだろう。

この達成基準の意図

この達成基準の意図は、利用者がコンテンツ内をナビゲートしている間、コンテンツの機能を予測可能にすることである。フォーカスを受け取ったときにイベントを起動することのできるすべてのコンポーネントは、状況を変化させてはならない。コンポーネントがフォーカスを受け取ったときに起こる状況の変化の例としては、次のようなものが挙げられる：

• コンポーネントがフォーカスを受け取ると自動的に送信されてしまうフォーム。

• フォーカスを受け取ると新しいウィンドウを開くコンポーネント

• フォーカスを受け取ると他のコンポーネントにフォーカスを移動するコンポーネント