WCAG 2.0 解説書

テキストによる代替:
ガイドライン1.1を理解する

ガイドライン1.1: すべての非テキストコンテンツには、拡大印刷、点字、音声、シンボル、平易な言葉などの利用者が必要とする形式に変換できるように、テキストによる代替を提供すること。

ガイドライン 1.1 の意図

このガイドラインの目的は、すべての非テキストコンテンツが、テキストでも利用可能であるようにすることである。「テキスト」とは、電子テキストのことを指し、画像化された文字のことではない。電子テキストには、表現形態が定まらないという優れた利点がある。すなわち、テキストは、視覚的にも、聴覚的にも、触覚的にも、あるいはそれらのどのような組合せによっても描画可能だということである。つまり、電子テキストで描画される情報は、利用者のニーズを最もよく満たすどのような形態でも提供可能なのである。また、テキストは、容易に拡大することが可能であり、音声読み上げが可能なので、読字障害のある利用者にとっても理解しやすく、利用者のニーズを最もよく満たすどんな触覚的な形態でも描画可能である。

注記: コンテンツをシンボルに変換することは、発達障害や発話理解困難のある利用者のためにグラフィック・シンボルに変換することを含むが、そういったシンボルの使い方に限定するわけではない。

ガイドライン 1.1 の参考にすべき達成方法(特定の達成基準に特有ではない達成方法)

このガイドラインにある各達成基準を満たすための達成方法は、この後に達成基準ごとに挙げられている。しかし、このガイドラインに対処するための達成方法がどの達成基準にも該当しない場合は、ここで挙げている。そういった達成方法は、どの達成基準を満たす上でも必須ではないし、十分でもないが、ウェブコンテンツの種類によってはより多くの利用者にとってよりアクセシブルにすることができるものである。

音声しか含まないファイルに手話ビデオを提供する（リンク追加予定）

非テキストコンテンツ:
達成基準 1.1.1 を理解する

1.1.1 非テキストコンテンツ: 利用者に提示されるすべての非テキストコンテンツには、同等の目的を果たすテキストによる代替が提供されている。ただし、次の場合は除く: (レベル A)
コントロール、入力: 非テキストコンテンツが、コントロール又は利用者の入力を受け付けるものであるとき、その目的を説明する名前 (name) を提供している。 (コントロール及び利用者の入力を受け入れるコンテンツに関するその他の要件は、ガイドライン 4.1を参照。)
時間依存メディア: 非テキストコンテンツが、時間に依存したメディアであるとき、テキストによる代替は、少なくとも、その非テキストコンテンツを識別できる説明を提供している。 (メディアに関するその他の要件は、ガイドライン 1.2を参照。)
テスト: 非テキストコンテンツが、テキストで提示されると無効になるテスト又は演習のとき、テキストによる代替は、少なくともその非テキストコンテンツを識別できる説明を提供している。
感覚的: 非テキストコンテンツが、特定の感覚的体験を創り出すことを主に意図しているとき、テキストによる代替は、少なくともその非テキストコンテンツを識別できる説明を提供している。
CAPTCHA: 非テキストコンテンツが、コンピュータではなく人間がコンテンツにアクセスしていることを確認する目的で用いられているとき、テキストによる代替は、その非テキストコンテンツの目的を特定し、説明している。なおかつ、他の感覚による知覚に対応して出力する CAPTCHA の代替形式を提供することで、様々な障害に対応している。
装飾、整形、非表示: 非テキストコンテンツが、純粋な装飾である、見た目の整形のためだけに用いられている、又は利用者に提供されるものではないとき、支援技術が無視できるように実装されている。

この達成基準の意図

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

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.1.1の具体的なメリット

この達成基準は、視覚的なコンテンツを知覚するのが困難な利用者の役に立つ。支援技術が、テキストを読み上げたり、視覚的に提示したり、点字に変換したりすることができるようになる。
代替テキストは、写真、図面、その他の画像（例：　線画、グラフィックデザイン、絵画、3D表現）、グラフ、チャート、アニメーションなどの意味を理解するのが困難な利用者の役に立つことがある。
デフ、音声の聞こえづらい、あるいは何らかの理由で音声情報を理解するのが困難な利用者が、テキストでの表現を読むことができるようになる。テキストを手話に自動変換する研究が現在進められている。
盲ろうの利用者が、テキストを点字で読むことができるようになる。
加えて、代替テキストは非テキストコンテンツの検索を可能とし、コンテンツを様々な方法で再利用できるようにする。

達成基準 1.1.1の事例

データのグラフ
6月、7月、そして8月にどれだけの数の商品が売れたかを比較している棒グラフがある。簡潔なラベルには、「図1：　6月、7月、8月の売上」と書かれている。長めの説明には、グラフの種類が示されていて、そのグラフから見てとれるものに相当する、データの概要、傾向や意味合いが提供されている。可能な場合には、実際のデータが表で提供されている。
演説を録音した音声
「議会での議長の演説」という音声クリップへのリンクがある。そして、書き起こしテキストへのリンクが、その音声クリップへのリンクの直後に提供されている。
車のエンジンがどのように動くのかを紹介するアニメーション
車のエンジンがどのように動くのかを見せているアニメーションがある。音声はなく、そのアニメーションはエンジンがどのように動くかを解説する指導書の一部である。指導書のテキストがすでにすべてを説明しているため、そのアニメーションはテキストの代替物であり、その代替テキストにはアニメーションの簡潔な説明のみが記述されていて、代替テキストのより詳細な情報は指導書のテキストを参照している。
交通情報ウェブカメラ
利用者がある大都市の至る所に設置された様々なウェブカメラを選択することのできるウェブサイトがある。どれか一つのカメラを選択すると、画像が2分おきに更新される。簡潔な代替テキストでは、そのウェブカメラを「交通情報ウェブカメラ」と説明している。また、そのサイトでは、ウェブカメラの範囲に入るルートのそれぞれの所要時間を表で提供している。そして、その表も2分おきに更新されている。
ニュース記事にある歴史的な出来事の写真
国際サミット会議に関するニュース記事と一緒に、2人の世界的なリーダーが握手をしている写真がある。代替テキストには、「X国のX大統領が、Y国のY首相と握手している。」と記述されている。
外交関係を議論するコンテンツにある歴史的な出来事の写真
外交上の衝突におけるニュアンスを説明するために、異なる文脈で同じ写真が使われている。首相と握手している大統領の画像が、もつれた外交関係を議論しているウェブサイトに掲載されている。最初の代替テキストには、「X国のX大統領が、2009年1月2日に、Y国のY首相と握手している。」と書かれている。補足の代替テキストは、両首脳の顔の表情と2人が立っている部屋の説明をしていて、さらに、その部屋にいる他の人たちのことも示している。その補足的な説明は、写真と同じページにあるかもしれないし、リンクあるいはその他の標準的なプログラムによるメカニズムによってその画像と関連付けられた別のファイルにあるかもしれない。
記者会見を録音した音声
ウェブページに、記者会見を録音した音声へのリンクがある。リンクテキストは、録音された音声を示している。また、そのページには記者会見の書き起こしテキストへのリンクもある。書き起こしテキストには、話者が発言したすべての逐語的な記録がある。そこには、例えば、喝采、笑い、聴衆からの質問など、その録音の一部であるその他の重要な音声とあわせて、誰が話しているのかも記されている。
E-ラーニングアプリケーション
回答が正しいかどうかを示すために効果音を用いている E-ラーニングアプリケーションがある。チャイム音はその回答が正解であることを示し、ビープ音はその回答が不正解であることを示している。テキストの説明もあるため、その音を聞いたり理解したりすることができない利用者も、その回答が正解かどうかを理解することができる。
リンクのあるサムネール画像
「スモールヴィル・タイムス」のウェブサイトにリンクしている、新聞の一面のサムネール画像がある。その代替テキストには、「スモールヴィル・タイムス」と記述されている。
異なるサイトで使われている同じ画像
世界地図の画像に対する異なる代替テキストの例：旅行サイトで海外旅行コーナーへのリンクとして用いられている世界地図の画像には、「海外旅行」という代替テキストがある。同じ画像が、「国際キャンパス」という代替テキストとともに、ある大学のウェブサイトでリンクとして用いられている。
イメージマップ
ビルのフロアプランのイメージマップ画像は操作可能で、利用者が特定の部屋を選択して、その部屋に関する情報のあるページへ移動することができる。「ビルのフロアプラン。より詳細な情報は部屋を選択してください。」という簡潔な代替テキストが、そのイメージマップの画像全体と操作の目的を説明している。

達成基準1.1.1の達成方法及び不適合事例 - 非テキストコンテンツ

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組合せを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法についての情報は、達成基準を満たすための達成方法を理解するの「その他の達成方法」を参照のこと。

達成基準を満たすことのできる達成方法

使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の達成方法（又は、達成方法の組合せ）がある。

状況 A: 短い説明によって、非テキストコンテンツと同じ目的を果たし、同じ情報を提示できる場合:

次に挙げる状況 A における短いテキストによる代替の達成方法のいずれかを用いて、G94: 非テキストコンテンツに対して、それと同じ目的を果たし、同じ情報を提供する、簡潔な代替テキストを提供する:

状況 A における短いテキストによる代替の達成方法:

状況 B: 短い説明によって、非テキストコンテンツと同じ目的を果たし、同じ情報を提示できない場合（例: チャート又はダイアグラム）:

次に挙げる 状況 B における短いテキストによる代替の達成方法 のいずれか及び、 状況 B における長いテキストによる代替の達成方法 のいずれかを用いて、 G95: 非テキストコンテンツの簡単な説明を提供する、簡潔な代替テキストを提供する :

状況 B における短いテキストによる代替の達成方法:

状況 B における長いテキストによる代替の達成方法:

状況 C: 非テキストコンテンツがコントロールである、又は利用者の入力を受け入れる場合:

次に挙げる 状況 C におけるコントロールと入力のための短いテキストによる代替の達成方法 のいずれかを用いて、 G82: 非テキストコンテンツの目的を特定する代替テキストを提供する :

状況 C におけるコントロールと入力のための短いテキストによる代替の達成方法:

状況 D: 非テキストコンテンツが時間の経過に伴って変化するメディアである（ライブの映像しか含まないコンテンツ及びライブの音声しか含まないコンテンツを含む）、テキストで提示されると無効になる試験又は演習である、又は、特定の感覚的体験を創り出すことを主に意図しているコンテンツである場合:

次に挙げる 状況 D における短いテキストによる代替の達成方法のいずれかを用いて、ラベルを記述する:
次に挙げる 状況 D における短いテキストによる代替の達成方法 のいずれかを用いて、 G68: ライブの音声しか含まないコンテンツ及びライブの映像しか含まないコンテンツの目的を説明するために、簡潔な代替テキストを提供する:
次に挙げる 状況 D における短いテキストによる代替の達成方法 のいずれかを用いて、 G100: 非テキストコンテンツの一般に認められた名前又は内容が分かる名前となる簡潔な代替テキストを提供する:

状況 D における短いテキストによる代替の達成方法:

状況 E: 非テキストコンテンツが CAPTCHA である場合:

G143: 代替テキストを提供して、CAPTCHA の目的を説明する、かつ、 G144: 同じ目的を果たす、異なる感覚モダリティを用いたもう一つの CAPTCHA がウェブページにあることを確認する

状況 F: 非テキストコンテンツを支援技術が無視するようにしなければならない場合:

次に挙げる 状況 F における必須ではない代替テキストを示す達成方法 のいずれかを用いて、支援技術によって無視することができるように、非テキストコンテンツを実装またはマーク付けする:

状況 F における必須ではない代替テキストを示す達成方法:

1.1.1 でさらに対応が望まれる達成方法（参考）

適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な達成方法もあわせて検討するとよい。ただし、すべての状況において、すべての達成方法が使用可能、または効果的であるとは限らない。

非テキストコンテンツに関する一般的な達成方法（参考）

参考情報の非テキストコンテンツを識別する（リンク追加予定）
簡潔な説明を短く保つ（リンク追加予定）
テキストを含む画像を説明する（リンク追加予定）
上に挙げる長い説明のためのウェブコンテンツ技術特有の達成方法（アクセシビリティ・サポーテッドなコンテンツ技術）を用いて、説明のラベルが求められるところだけで、非テキストコンテンツのより長い説明を提供する（リンク追加予定）
非テキストコンテンツが等価でアクセシブルな代替が無い場合、大きさの異なる非テキストコンテンツを提供する（リンク追加予定）
画像化された文字の大きさを変えるサーバーサイドのスクリプトを使う（リンク追加予定）

ライブの非テキストコンテンツに関する一般的な達成方法（参考）

同程度の情報を提供するテキスト情報（例えば、交通のウェブカメラに対して、自治体の提供するテキストの交通情報へのリンク）にリンクする（リンク追加予定）

CAPTCHAの障壁を最小化する一般的な達成方法

CAPTCHAを3つ以上の感覚モダリティで提供する（リンク追加予定）
CAPTCHA を使用しないでもすむように、カスタマーサービスの担当者に連絡できるようにする（リンク追加予定）
許可した利用者には CAPTCHA を要求しない（リンク追加予定）

HTMLの達成方法（参考）

H46: embed 要素と一緒に noembed 要素を用いる (HTML)
フレームをサポートしないブラウザのために作成する（リンク追加予定）
iframe要素の代替コンテンツを提供する（リンク追加予定）
iframe要素の長い説明を使わない（リンク追加予定）
クライアントサイドイメージマップのために冗長なテキストリンクを提供する（リンク追加予定）

CSSの達成方法（参考）

C18: レイアウトデザインのためのスペーサー画像ではなく、CSS のマージンとパディング規則を使用する (CSS)
装飾のためのimg要素の代わりに、CSSのbackgroundプロパティと:beforeあるいは:afterルールを使う（リンク追加予定）
空のtable要素のセルを表示する（リンク追加予定）

WAI-ARIAの達成方法（参考）

表現のためだけの要素を示すためにARIA表示を使う（リンク追加予定）

Silverlightの達成方法（参考）

SL19: Providing User Instructions With AutomationProperties.HelpText in Silverlight (Silverlight)

メタデータの達成方法（参考）

テキストトランスクリプションと映像を関連付けるためにメタデータを使う（リンク追加予定）
テキストトランスクリプションと音声しか含まないコンテンツを関連付けるためにメタデータを使う（リンク追加予定）
- 事例：メタデータの中で、音声解説と映像のテキスト記述を指し示すURIを提供する
- 事例：メタデータの中で、音声ファイルのいくつかのテキスト記述（英語、フランス語、ドイツ語）を指し示すURIを提供する

達成基準 1.1.1のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準1.1.1に適合していないとみなした、よくある不適合事例である。

重要な用語

(この文書で用いられている) 支援技術 (assistive technology (as used in this document))

ユーザエージェントとして機能する、又は主流のユーザエージェントと一緒に機能するハードウェア及び/あるいはソフトウェアで、主流のユーザエージェントで提供されている機能以上の機能を、障害のある利用者の要求を満たすために提供するもの。

注記 1: 支援技術が提供する機能としては、代替の提示 (例: 合成音声や拡大表示したコンテンツ)、代替入力手法 (例: 音声認識)、付加的なナビゲーション又は位置確認のメカニズム、及びコンテンツ変換 (例: テーブルをよりアクセシブルにするもの) などを挙げることができる。

注記 2: 支援技術は、API を利用、監視することで、主流のユーザエージェントとデータやメッセージのやりとりをすることが多い。

注記 3: 主流のユーザエージェントと支援技術との区別は、絶対的なものではない。多くの主流のユーザエージェントは、障害者を支援する機能を提供している。基本的な差異は、主流のユーザエージェントが障害のある人もない人も含めて、広く多様な利用者を対象にしているのに対し、支援技術は、特定の障害のある利用者という、より狭く限られた人たちを対象にしているということである。支援技術により提供される支援は、対象とする利用者に特化した、よりニーズに適したものである。主流のユーザエージェントは、プログラムオブジェクトからのウェブコンテンツの抽出、マークアップの識別可能な構造への解釈といった、重要な機能を支援技術に対して提供する場合がある。

事例: この文書の文脈において重要な支援技術としては、以下のものが挙げられる:

画面拡大ソフト及びその他の視覚的な表示に関する支援技術。視覚障害、知覚障害、及び読書困難などの障害のある人が、レンダリング後のテキスト及び画像の視覚的な読みやすさを改善するために、テキストのフォント、サイズ、間隔、色、音声との同期などを変更するのに使用している。
スクリーンリーダー。全盲の人がテキスト情報を合成音声あるいは点字で読み取るために使用している。
音声変換ソフトウェア。認知障害、言語障害、及び学習障害のある人が、テキストを合成音声に変換するために使用している。
音声認識ソフトウェア。何らかの身体障害のある利用者が使用することがある。
代替キーボード。特定の身体障害のある人がキーボード操作をシミュレートするのに使用している (ヘッドポインタ、シングルスイッチ、呼気・吸気スイッチ、及びその他の特別な入力デバイスを使った代替キーボードを含む)。
代替ポインティングデバイス。特定の身体障害のある人がマウスポインタとボタンの動きをシミュレートするのに使用している。

CAPTCHA

コンピュータと人間とを判別する完全自動化されたチューリングテスト (Completely Automated Public Turing test to tell Computers and Humans Apart) の頭文字語。

注記 1: CAPTCHA のテストは多くの場合、利用者に対し、不明瞭な画像又は音声ファイルによって提示されたテキストを入力するよう求める。

注記 2: チューリングテストは、人間とコンピュータを区別することを目的としたテストの仕組みである。その名は、高名なコンピュータ科学者のアランチューリングにちなんでいる。この用語は、カーネギーメロン大学の研究者たちによる造語である。[CAPTCHA]

テキスト (text)

プログラムによる解釈が可能な文字の並びで、自然言語で何かを表現しているもの。

テキストによる代替 (text alternative)

非テキストコンテンツとプログラムで関連付けられるテキスト。又は非テキストコンテンツとプログラムで関連付けられるテキストから参照されるテキスト。プログラムで関連付けられたテキストとは、その場所を、非テキストコンテンツからプログラムによる解釈が可能なテキストである。

事例: チャートの画像があり、その直後の段落にテキストによる説明がある。チャートに対する短いテキストによる代替で後に説明があることを示している。

注記: より詳細な情報は、Understanding Text Alternativesを参照。

名前 (name)

ソフトウェアが、ウェブコンテンツのコンポーネントを利用者に識別させることができるテキスト。

注記 1: ラベルはすべての利用者に提示される一方で、名前 (name) は隠されていて、支援技術に対してだけ明らかにされる場合もある。多くの場合 (すべてではないが)、ラベルと名前 (name) は同じである。

注記 2: これは、HTML の name 属性とは関係がない。

特定の感覚的な体験 (specific sensory experience)

純粋な装飾ではなく、かつ重要な情報の伝達、又は機能の提供を主目的としない感覚的な体験。

事例: フルートのソロ演奏、視覚芸術の作品などが例として挙げられる。

純粋な装飾 (pure decoration)

見栄えのためだけのもので、情報は提供せず、機能性も備えていないもの。

注記: テキストが純粋な装飾といえるのは、単語を並べ替え、又は置き換えても意図が変わらないときだけである。

事例: 背景にとても淡い文字で単語がランダムに並んでいる辞書の表紙。

非テキストコンテンツ (non-text content)

プログラムによる解釈が可能な文字の並びではないコンテンツ、又は文字の並びが自然言語においても何をも表現していないコンテンツ。

注記: これには、 (文字による図画である) ASCII アート、顔文字、 (文字を置き換える) リートスピーク、文字を表現している画像が含まれる。

時間依存メディア:
ガイドライン1.2を理解する

ガイドライン1.2: 時間依存メディアには代替コンテンツを提供すること。

ガイドライン 1.2 の意図

このガイドラインの目的は、時間の経過に伴って変化する、同期したメディアへのアクセスを提供することである。具体的には、次のようなメディアがある：

音声しか含まない
映像しか含まない
音声と映像を含む
インタラクションを組み合わせた音声と映像、又は音声あるいは映像のどちらかを含む

コンテンツ制作者が、そのコンテンツにはどの達成基準が適用されるのかを素早く容易に判断できるように、各達成基準が適用されるメディアの種類をその簡潔な名前で示している。

音声しか含まないメディア又は映像しか含まないメディアに対しては、達成基準の名前に「音声しか含まない」又は「映像しか含まない」とあるものを適用するだけでよい。そのメディアが、音声しか含まないメディア又は映像しか含まないメディアではない場合、残りの達成基準すべてが適用される。

そして、メディアは、ライブ又は収録済のどちらかである。その達成基準がライブ又は収録済のどちらのメディアに適用されるのかが、各達成基準の簡潔な名前ではっきりと分かるようになっている。

同期したメディアは、用語集で次のように定義されている：

同期したメディア (synchronized media): 情報を提示するために、他のフォーマットと同期した音声もしくは映像、又は時間に依存するインタラクティブな構成要素と同期した音声又は映像。ただし、そのメディアがメディアによるテキストの代替であって、メディアによる代替であることが明確にラベル付けされているものは除く。

インタラクションに付随する音声ファイルは、インタラクションを伴う映像しか含まないファイルと同様に、このガイドラインの対象であることに留意されたい。これらが対象となっているのは、インタラクションが特定のタイミングで発生しなければならないからである。例えば、「より多くの情報を知るためには、今、クリックしてください」というトランスクリプトをつけるのは、全く役に立たない。なぜなら、利用者にはその音声がどのタイミングで「今」と言ったのかが分からないからである。そのため、同期したキャプションが必要となる。

時には、音声解説を発話内にある合間にぴったり収めることができないくらい沢山の発話があることがある。同期したメディアの音声解説ではなく、時間の経過に伴って変化するメディアの代替を提供するレベル A での選択肢は、同期したメディアにあるすべての情報へのアクセスを可能にすることである。また、この選択肢は、何らかの理由で音声解説が提供されていないとき、視覚的でない形態での視覚的な情報へのアクセスも可能にする。

インタラクションを伴う同期したメディアの場合、時間の経過に伴って変化するメディアの代替の中にインタラクティブな要素（例えば、リンク）を埋め込むことが可能である。

また、このガイドラインには、（レベル AAA で）同期したメディアへの手話通訳というアプローチの他に、拡張した音声解説と呼ばれるアプローチがある。拡張した音声解説では、映像を一時的に停止させて、実際に存在する発話の合間で可能な量よりも多くの音声解説を提供することができる。これは、要件を積み上げていくようにして徐々に強めていくという意図があって、低いレベルの達成基準の上にそれよりも高いレベルの達成基準を設けている一例である。

ガイドライン 1.2 の参考にすべき達成方法(特定の達成基準に特有ではない達成方法)

このガイドラインの参考にすべき達成方法はすべて、特定の達成基準に関係している。

音声のみ及び映像のみ (収録済) :
達成基準 1.2.1 を理解する

1.2.1 音声のみ及び映像のみ (収録済) : 収録済の音声しか含まないメディア及び収録済の映像しか含まないメディアは、次の事項を満たしている。ただし、その音声又は映像がメディアによるテキストの代替であって、メディアによる代替であることが明確にラベル付けされている場合は除く: (レベル A)
収録済の音声しか含まない場合:時間依存メディアに対する代替コンテンツによって、収録済の音声しか含まないコンテンツと同等の情報を提供している。
収録済の映像しか含まない場合: 時間依存メディアに対する代替コンテンツ又は音声トラックによって、収録済の映像しか含まないコンテンツと同等の情報を提供している。

この達成基準の意図

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

音声情報や利用者のインタラクションを伴わない収録済み映像の例は、サイレントムービー（無声映画）である。書き起こしテキストの目的は、視覚的に提示されるものと同等のものを提供することである。収録済の映像コンテンツの場合、コンテンツ制作者には音声トラックを提供するという選択肢がある。音声による代替の目的は、映像と同等のものになることである。それにより、視覚障害の有無に関係なく、利用者はコンテンツを同時に楽しむことが可能になる。また、映像と音声の並行したプレゼンテーションを提供することにより、認知の障害、言語の障害、及び学習障害のある利用者がコンテンツを理解しやすくなることにもつながる。

注記：音声情報がない映像に対する代替コンテンツとして提供されている音声に対しては、代替テキストは必要ない。例えば、サイレントムービーの代替コンテンツとして提供されている音声解説にキャプションを付与する必要はない。

達成基準1.2.9 音声のみ (ライブ) を理解するも参照のこと。

達成基準1.2.1の具体的なメリット

この達成基準は、視覚的なコンテンツを知覚するのが困難な利用者の役に立つ。支援技術が、代替テキストを音声で読み上げたり、視覚的に提示したり、点字に変換したりすることが可能になる。
時間の経過に伴って変化するメディアの代替は、それがテキストベースであれば、収録済の映像コンテンツの意味を理解するのが困難な利用者の役に立つことがある。
デフ、音声の聞こえづらい、あるいは何らかの理由で音声情報を理解するのが困難な利用者が、テキストでの表現を読むことができるようになる。テキストを手話に自動変換する研究が現在進められている。
盲ろうの利用者が、テキストを点字で読むことができるようになる。
加えて、テキストは、非テキストコンテンツを検索可能なものにし、コンテンツを様々な方法で再利用できるようにする。

達成基準 1.2.1の事例

演説を録音した音声
「議会での議長の演説」という音声クリップへのリンクがある。そして、書き起こしテキストへのリンクが、その音声クリップへのリンクの直後に提供されている。
記者会見を録音した音声
ウェブページに、記者会見を録音した音声へのリンクがあり、リンクテキストが録音された音声であることを示している。また、そのページには記者会見の書き起こしテキストへのリンクもある。書き起こしテキストには、話者が発言したすべての逐語的な記録がある。そこには、例えば、喝采、笑い、聴衆からの質問など、その録音の一部であるその他の重要な音声とあわせて、誰が話しているのかも記されている。
車のエンジンがどのように動くのかを紹介するアニメーション
車のエンジンがどのように動くのかを見せているアニメーションがある。音声はなく、そのアニメーションはエンジンがどのように動くかを解説する指導書の一部である。指導書のテキストがすでにすべての説明を提供しているため、そのアニメーションはテキストの代替物であり、その代替テキストにはアニメーションの簡潔な説明のみが記述されていて、より詳細な情報は指導書のテキストを参照している。
音声トラック付きの、映像しか含まないファイル
無音映画に音声トラックがあり、映像に見られる動きや振る舞いを説明している。

達成基準1.2.1の達成方法及び不適合事例 - 音声のみ及び映像のみ (収録済)

達成基準を満たすことのできる達成方法

状況 A：収録済の音声しか含まないコンテンツの場合：

状況 B：収録済の映像しか含まないコンテンツの場合：

1.2.1 でさらに対応が望まれる達成方法（参考）

H96: 音声解説を提供するために、track 要素を使用する (HTML)
事後に、ライブの音声しか含まないプレゼンテーションの書き起こしテキストを提供する（リンク追加予定）
同程度の情報を提供するテキスト情報へのリンクを提供する（例えば、交通情報ウェブカメラに対して、ある自治体ではテキストの交通情報レポートへのリンクを提供している）（リンク追加予定）

達成基準 1.2.1のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準1.2.1に適合していないとみなした、よくある不適合事例である。

重要な用語

メディアによるテキストの代替 (media alternative for text): テキストで (直接又はテキストによる代替によって) 既に提示されている情報以上のものを提示していないメディア。
注記: メディアによるテキストの代替は、テキストを代替する提示の恩恵を受ける人たちのために提供される。テキストの代替メディアになりうるのは、音声しか含まないメディア、映像しか含まない (手話の映像を含む) メディア、又は音声付映像メディアである。
収録済 (prerecorded): ライブではない情報。
映像しか含まない (video-only): 映像のみを含んだ、時間に依存する提示 (音声やインタラクションを含まない)。
時間依存メディアに対する代替コンテンツ (alternative for time-based media): 時間依存の視覚的及び聴覚的情報を正しい順序で説明したテキストを含み、あらゆる時間依存のインタラクションによる結果を得る手段を提供している文書。
注記: 同期したメディアのコンテンツを作るために用いられる脚本は、編集が終了した最終版の同期したメディアを正確に描写した脚本に修正されている場合だけ、この定義を満たす。
音声しか含まない (audio-only): 音声のみを含んだ、時間に依存する提示 (映像やインタラクションを含まない)。

キャプション (収録済) :
達成基準 1.2.2 を理解する

1.2.2 キャプション (収録済) : 同期したメディアに含まれているすべての収録済の音声コンテンツに対して、キャプションが提供されている。ただし、その同期したメディアがメディアによるテキストの代替であって、メディアによる代替であることが明確にラベル付けされている場合は除く。 (レベル A)

この達成基準の意図

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

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

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

達成基準1.2.4 キャプション (ライブ) を理解するも参照のこと。

達成基準1.2.2の具体的なメリット

デフ又は難聴の利用者が、同期したメディアのコンテンツにある音声情報を、キャプションを通じて入手することができるようになる。

達成基準 1.2.2の事例

キャプションを提供しているチュートリアル
結び目の作り方を紹介している映像があり、次のようなキャプションが提供されている。
「（音楽）
水兵、兵士、そして木こりのような人たちにとっては、
ロープを使って結び目を作るのは、重要なスキルでした。」
Whit Anderson氏による、書き起こしテキストのフォーマットのサンプルより。
複雑な法律文書には、段落ごとに同期したメディアのクリップがあり、その段落の内容を話している人を表示している。各クリップは、その対応する段落と関連付けられている。その同期したメディアには、キャプションが提供されていない。
取扱説明書で、ある部品に関しての説明とその必要な使用方法を含む取扱説明書では、その部品の正しい使用方法を紹介する同期したメディアのクリップがある。その同期したメディアのクリップには、キャプションが提供されていない。
オーケストラがコンサート映像にキャプションを提供している。台詞や歌詞を逐語的に提供するだけでなく、タイトル、楽章、作曲者などさまざまな情報を提供することで、利用者が音声の特徴を理解することを助け、歌詞のない音楽も認識できるようにしている。例えば、
「[管弦楽組曲第3番ニ長調 BWV 1068 - 第2曲 G線上のアリア]
[作曲者ヨハン・ゼバスティアン・バッハ]
♪ 遅いテンポの落ち着いたメロディ ♪」
注記: キャプションのスタイルガイドは言語によって異なる可能性がある。

達成基準1.2.2の達成方法及び不適合事例 - キャプション (収録済)

達成基準を満たすことのできる達成方法

G93: オープン・キャプション（常に表示）を提供する
クローズド・キャプションをサポートしたビデオ・プレーヤーのある、容易に利用可能なメディア・フォーマットを用いて、G87: クローズド・キャプションを提供する
次のいずれかのウェブコンテンツ技術特有の達成方法を用いて、G87: クローズド・キャプションを提供する

1.2.2 でさらに対応が望まれる達成方法（参考）

映像しか含まないクリップに対して、「このクリップには音は使われていません」というノートを提供する（リンク追加予定）
オーディオトラックのすべての言語のキャプションを提供するためにSMIL 1.0を使う（リンク追加予定）
オーディオトラックのすべての言語のキャプションを提供するためにSMIL 2.0を使う（リンク追加予定）

達成基準 1.2.2のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準1.2.2に適合していないとみなした、よくある不適合事例である。

重要な用語

キャプション (captions): そのメディアのコンテンツを理解するのに必要な、会話及び会話でない音声情報に対する、同期した視覚、又はテキストによる代替。
注記 1: キャプションは会話のみの字幕と似ているが、会話の内容だけを伝えるのではなく、その番組の内容を理解するために必要な効果音、音楽、笑い声、話者の特定、位置などを含む、会話でない音声情報と同等の内容も伝える点が異なる。
注記 2: クローズドキャプションは、音声情報と同等の内容で、プレーヤーによっては表示／非表示を切り替えることができるものを指す。
注記 3: オープンキャプションは、非表示にできないキャプションである。例えば、キャプションが同等の視覚化された文字画像で映像に埋め込まれている場合である。
注記 4: キャプションは、映像に含まれる情報を分かりにくくしたり遮ったりすべきではない。
注記 5: 国によっては、キャプションは "subtitle" と呼ばれている。
訳注： subtitleには、「字幕」の意がある。日本では、キャプションのことを一般に字幕と呼ぶことが多い。
注記 6: 音声解説にキャプションをつけることもできるが、つける必要はない。なぜなら、音声解説は既に視覚的に提示されている情報の説明だからである。
メディアによるテキストの代替 (media alternative for text): テキストで (直接又はテキストによる代替によって) 既に提示されている情報以上のものを提示していないメディア。
注記: メディアによるテキストの代替は、テキストを代替する提示の恩恵を受ける人たちのために提供される。テキストの代替メディアになりうるのは、音声しか含まないメディア、映像しか含まない (手話の映像を含む) メディア、又は音声付映像メディアである。
収録済 (prerecorded): ライブではない情報。
同期したメディア (synchronized media): 情報を提示するために、他のフォーマットと同期した音声もしくは映像、又は時間に依存するインタラクティブな構成要素と同期した音声又は映像。ただし、そのメディアがメディアによるテキストの代替であって、メディアによる代替であることが明確にラベル付けされているものは除く。
音声 (audio): 音の再生技術。
注記: 音声には、合成して作られたもの (音声合成を含む)、実世界の音を収録したもの、又はその両方が含まれる。

音声解説、又はメディアに対する代替 (収録済) :
達成基準 1.2.3 を理解する

1.2.3 音声解説、又はメディアに対する代替 (収録済) : 同期したメディアに含まれている収録済の映像コンテンツに対して、時間依存メディアに対する代替コンテンツ又は音声解説が提供されている。ただし、その同期したメディアがメディアによるテキストの代替であって、メディアによる代替であることが明確にラベル付けされている場合は除く。 (レベル A)

この達成基準の意図

この達成基準の意図は、全盲又は視覚障害のある利用者が、同期したメディアのプレゼンテーションにある視覚的な情報を入手できるようにすることである。この達成基準では、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 メディアに対する代替 (収録済) を理解するも参照のこと。

達成基準1.2.3の具体的なメリット

この達成基準は、映像コンテンツあるいはその他の同期したメディアのコンテンツを見るのが困難な利用者の役に立つ。これには、動きのある画像を知覚したり理解したりするのが困難な利用者も含む。

達成基準 1.2.3の事例

音声解説を提供している映画
音声解説：タイトル「Teaching Evolution ケーススタディ　ボニー・チェン」くちばしが長くて薄い鳥の写真を、先生が見せている。
ボニー・チェン：「これらの写真はすべて、フロリダのエバーグレイド国立公園で撮影されたものです。」
音声解説：先生が生徒ひとりひとりに2つの平らで薄い木の棒切れを手渡ししています。
ボニー・チェン：「今日、皆さんは、こんなくちばしをした、脚の長い鳥になったふりをしてください。」
音声解説： 先生が、2つの棒切れを口にあてて、くちばしの形を作っています。
音声の書き起こしテキストは、「Teaching Evolution ケーススタディ　ボニー・チェン(copyright WGBH and Clear Blue Sky Productions, Inc.)」の冒頭の数分間に基づいいる。
ある研修ビデオでの、時間の経過に伴って変化するメディアの代替
ある企業では、従業員のための研修ビデオを購入し、その企業のイントラネット上に置いている。そのビデオでは、新しい技術の使い方を説明していて、同時にそれを説明しながら実演する人物が登場する。ビデオの発話部分の合間に、視覚的なデモの音声解説を挿入する時間的な余裕がないため、その企業では、そのデモを見ることができない人を含む従業員すべてがその内容をよりよく理解することができるように、時間の経過に伴って変化するメディアの代替を提供している。

達成基準1.2.3の達成方法及び不適合事例 - 音声解説、又はメディアに対する代替 (収録済)

達成基準を満たすことのできる達成方法

次の達成方法のどれか一つを用いて、G69: 時間の経過の伴い変化するメディアに対して代替コンテンツを提供する
- G58: 非テキストコンテンツのすぐ隣に、時間の経過に伴って変化するメディアの代替へのリンクを置く
- SL17: Providing Static Alternative Content for Silverlight Media Playing in a MediaElement (Silverlight)
次の達成方法のどれか一つを用いて、時間の経過とともに変化するメディアの代替へのリンクを提供する
- H53: object 要素のボディを使用する (HTML)
G78: 音声解説を含んだ、利用者が選択可能な副音声トラックを提供する
G78: 音声解説を含んだ、利用者が選択可能な副音声トラックを提供する、かつ、SL1: Accessing Alternate Audio Tracks in Silverlight Media (Silverlight)
次のどれか一つを用いて、G173: 映像の音声解説付きバージョンを提供する
- SM6: SMIL 1.0 で音声解説を提供する (SMIL)
- SM7: SMIL 2.0 で音声解説を提供する (SMIL)
- FLASH26: Flash ビデオに音声解説を提供する (Flash)
- SL1: Accessing Alternate Audio Tracks in Silverlight Media (Silverlight)
- 音声及び映像をサポートしているプレーヤーを用いる
次のどれか一つを用いて、G8: 拡張音声解説が付いたムービーを提供する
- SM1: SMIL 1.0 で拡張音声解説を追加する (SMIL)
- SM2: SMIL 2.0 で拡張音声解説を追加する (SMIL)
- FLASH26: Flash ビデオに音声解説を提供する (Flash)
- SL1: Accessing Alternate Audio Tracks in Silverlight Media (Silverlight)
- 音声及び映像をサポートしているプレーヤーを用いる
G203: 話者が話すのみの映像を説明するために、静的な代替テキストを使用する

1.2.3 でさらに対応が望まれる達成方法（参考）

H96: 音声解説を提供するために、track 要素を使用する (HTML)
SMIL 1.0によって多様な言語の音声解説を提供する（リンク追加予定）
SMIL 2.0によって多様な言語の音声解説を提供する（リンク追加予定）

達成基準 1.2.3のよくある不適合事例

以下に挙げるものは、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 を理解する

1.2.4 キャプション (ライブ) : 同期したメディアに含まれているすべてのライブの音声コンテンツに対してキャプションが提供されている。 (レベル AA)

この達成基準の意図

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

この達成基準は、同期したメディアの放送に適用することを意図しており、Webアプリケーションを介し2人ないしそれ以上の個人同士で行う双方向のマルチメディア電話に対し、利用者の要求の有無にかかわらずキャプションの提供を求めることは意図していない。キャプションを提供する責任は、コンテンツの提供者（電話をかけた人）または「ホスト」として電話をかけた人に課せられるもので、アプリケーションには課せられない。

達成基準1.2.4の具体的なメリット

デフ又は音声の聞こえづらい利用者が、同期したメディアのコンテンツにある音声情報を、キャプションを通じて入手することができるようになる。

達成基準 1.2.4の事例

ウェブキャスト
ニュースの配信者が、ライブのウェブキャストでキャプションを提供している。
音楽のウェブキャスト
オーケストラが、コミュニケーション・アクセス・リアルタイム・トランスレーション（CART）により、個々の演奏に対しリアルタイムでキャプションを提供している。CARTサービスは、歌詞や会話を取り込むばかりでなく、タイトルや変化、作曲者、利用者が素の音を理解するのに役立つあらゆる情報によって、歌のない音楽を識別する。

達成基準1.2.4の達成方法及び不適合事例 - キャプション (ライブ)

達成基準を満たすことのできる達成方法

G9: ライブの同期したメディアに対してキャプションを作成する、かつ、G93: オープン・キャプション（常に表示）を提供する
クローズド・キャプションをサポートするビデオ・プレーヤーのある、すぐに利用可能なメディア・フォーマットを用いて、G9: ライブの同期したメディアに対してキャプションを作成する、かつ、G87: クローズド・キャプションを提供する
次のどれか一つを用いて、G9: ライブの同期したメディアに対してキャプションを作成する、かつ、G87: クローズド・キャプションを提供する：
- SM11: SMIL 1.0 で同期したテキストストリームによるキャプションを提供する (SMIL)
- SM12: SMIL 2.0 で同期したテキストストリームによるキャプションを提供する (SMIL)

注記: キャプションは、リアルタイムのテキスト変換サービスを用いて生成できるかもしれない。

1.2.4 でさらに対応が望まれる達成方法（参考）

(まだ文書化されていない)

達成基準 1.2.4のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準1.2.4に適合していないとみなした、よくある不適合事例である。

(今のところ、文書化されている不適合事例がない)

重要な用語

キャプション (captions): そのメディアのコンテンツを理解するのに必要な、会話及び会話でない音声情報に対する、同期した視覚、又はテキストによる代替。
注記 1: キャプションは会話のみの字幕と似ているが、会話の内容だけを伝えるのではなく、その番組の内容を理解するために必要な効果音、音楽、笑い声、話者の特定、位置などを含む、会話でない音声情報と同等の内容も伝える点が異なる。
注記 2: クローズドキャプションは、音声情報と同等の内容で、プレーヤーによっては表示／非表示を切り替えることができるものを指す。
注記 3: オープンキャプションは、非表示にできないキャプションである。例えば、キャプションが同等の視覚化された文字画像で映像に埋め込まれている場合である。
注記 4: キャプションは、映像に含まれる情報を分かりにくくしたり遮ったりすべきではない。
注記 5: 国によっては、キャプションは "subtitle" と呼ばれている。
訳注： subtitleには、「字幕」の意がある。日本では、キャプションのことを一般に字幕と呼ぶことが多い。
注記 6: 音声解説にキャプションをつけることもできるが、つける必要はない。なぜなら、音声解説は既に視覚的に提示されている情報の説明だからである。
ライブ (live): 現実の出来事から取り込まれ、放送遅延以上の遅延なく受け手に送信される情報。
注記 1: 放送遅延は、短時間の (通常は自動的な) 遅れで、例えば放送局に放送のタイミングの調整や音声 (又は映像) の検閲のための時間を与えるものだが、意味のある編集ができるほどのものではない。
注記 2: もし情報が完全にコンピュータで生成されたものならば、それはライブではない。
同期したメディア (synchronized media): 情報を提示するために、他のフォーマットと同期した音声もしくは映像、又は時間に依存するインタラクティブな構成要素と同期した音声又は映像。ただし、そのメディアがメディアによるテキストの代替であって、メディアによる代替であることが明確にラベル付けされているものは除く。
音声 (audio): 音の再生技術。
注記: 音声には、合成して作られたもの (音声合成を含む)、実世界の音を収録したもの、又はその両方が含まれる。

音声解説 (収録済) :
達成基準 1.2.5 を理解する

1.2.5 音声解説 (収録済) : 同期したメディアに含まれているすべての収録済の映像コンテンツに対して、音声解説が提供されている。 (レベル AA)

この達成基準の意図

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

注記 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.5の事例

音声解説を提供している映画
音声解説：タイトル「Teaching Evolution ケーススタディボニー・チェン」くちばしが長くて薄い鳥の写真を、先生が見せている。
ボニー・チェン：「これらの写真はすべて、フロリダのエバーグレイド国立公園で撮影されたものです。」
音声解説：先生が生徒ひとりひとりに2つの平らで薄い木の棒切れを手渡ししています。
ボニー・チェン：「今日、皆さんは、こんなくちばしをした、脚の長い鳥になったふりをしてください。」
音声解説： 先生が、2つの棒切れを口にあてて、くちばしの形を作っています。
音声の書き起こしテキストは、「Teaching Evolution ケーススタディボニー・チェン(copyright WGBH and Clear Blue Sky Productions, Inc.)」の冒頭の数分間に基づいいる。

達成基準1.2.5の達成方法及び不適合事例 - 音声解説 (収録済)

達成基準を満たすことのできる達成方法

G78: 音声解説を含んだ、利用者が選択可能な副音声トラックを提供する
G78: 音声解説を含んだ、利用者が選択可能な副音声トラックを提供する、かつ、SL1: Accessing Alternate Audio Tracks in Silverlight Media (Silverlight)
次のどれか一つを用いて、G173: 映像の音声解説付きバージョンを提供する:
- SM6: SMIL 1.0 で音声解説を提供する (SMIL)
- SM7: SMIL 2.0 で音声解説を提供する (SMIL)
- FLASH26: Flash ビデオに音声解説を提供する (Flash)
- 音声及び映像をサポートしているプレーヤーを用いる
次のどれか一つを用いて、G8: 拡張音声解説が付いたムービーを提供する:
- SM1: SMIL 1.0 で拡張音声解説を追加する (SMIL)
- SM2: SMIL 2.0 で拡張音声解説を追加する (SMIL)
- FLASH26: Flash ビデオに音声解説を提供する (Flash)
- 音声及び映像をサポートしているプレーヤーを用いる
G203: 話者が話すのみの映像を説明するために、静的な代替テキストを使用する

1.2.5 でさらに対応が望まれる達成方法（参考）

H96: 音声解説を提供するために、track 要素を使用する (HTML)
SMIL 1.0によって多様な言語の音声解説を提供する（リンク追加予定）
SMIL 2.0によって多様な言語の音声解説を提供する（リンク追加予定）
ライブの同期したメディアに対して音声解説を提供する（リンク追加予定）

達成基準 1.2.5のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準1.2.5に適合していないとみなした、よくある不適合事例である。

(今のところ、文書化されている不適合事例がない)

重要な用語

収録済 (prerecorded): ライブではない情報。
同期したメディア (synchronized media): 情報を提示するために、他のフォーマットと同期した音声もしくは映像、又は時間に依存するインタラクティブな構成要素と同期した音声又は映像。ただし、そのメディアがメディアによるテキストの代替であって、メディアによる代替であることが明確にラベル付けされているものは除く。
映像 (video): 写真や画像を動かしたり、連続して表示したりする技術。
注記: 映像はアニメーション、実写、もしくはその両方で構成され得る。
音声解説 (audio description): 主音声のトラックだけでは理解できない重要で視覚的な詳細を説明するために、音声トラックに追加されたナレーション。
注記 1: 映像の音声解説は、動作、登場人物、場面の変化、画面上のテキスト、及びその他の視覚的なコンテンツに関する情報を提供する。
注記 2: 標準的な音声解説では、ナレーションが会話の合間に挿入される。 (拡張音声解説も参照。)
注記 3: 映像情報のすべてが既存の音声ですでに提供されている場合、補足の音声解説は不要である。
注記 4: "video description" や "descriptive narration" とも呼ばれる。
訳注： 日本語では「音声ガイド」とも呼ばれる。

手話 (収録済) :
達成基準 1.2.6 を理解する

1.2.6 手話 (収録済) : 同期したメディアに含まれているすべての収録済の音声コンテンツに対して、手話通訳が提供されている。 (レベル AAA)

この達成基準の意図

この達成基準の意図は、ろう者又は難聴の利用者で手話に堪能な利用者が、同期したメディアのプレゼンテーションの音声トラックコンテンツを理解できるようにすることである。例えば、字幕に書かれているようなテキストは、第二言語であることがよくある。手話は、イントネーション、感情、及び、字幕には反映されないが手話通訳には反映されるその他の音声情報を提供するので、手話通訳は同期したメディアの内容に対して字幕よりも豊富でより等価な情報を提供する。手話で頻繁にやりとりする利用者はまた、手話でより早口になり、同期したメディアは、時間依存のプレゼンテーションとなる。

達成基準1.2.6の具体的なメリット

普段使う言語が手話である利用者は、読解力に限界があることがある。そういった利用者は、字幕を読んで理解できない恐れがあり、同期したメディアのコンテンツを利用する機会を得るために手話を必要とする。

達成基準 1.2.6の事例

事例 1.ある企業が、従業員すべてに対して重要な発表をしている。総会は本社で行われていて、その模様がウェブでストリーミング配信されている。総会の場には手話通訳者がいて、ライブの映像にはプレゼンテーションをしている人物及び手話通訳者の全身が映し出されている。
事例 2.事例 1 にあるのと同じ発表が、遠隔地にいる従業員にはウェブキャストで届けられている。画面が一つしかないため、手話通訳者は画面のコーナーに映し出されている。
事例 3.ある大学が、講義をする教授の同期したメディアによるプレゼンテーションを作成して、講義のオンライン版を提供している。そのプレゼンテーションには、化学の実験を解説して実演している教授の映像がある。講義内容の手話通訳を制作して、ウェブ上で同期したメディア版とあわせて提供している。

達成基準1.2.6の達成方法及び不適合事例 - 手話 (収録済)

達成基準を満たすことのできる達成方法

1.2.6 でさらに対応が望まれる達成方法（参考）

メタデータの達成方法

メタデータを使って映像の代替である手話を対応付け、手話の選択ができるようにする（リンク追加予定）
- 事例：ウェブページの様々な英国式の手話通訳（ASL, SASL, BSL, Auslan, ISL, NZSL）を指し示すURIを、メタデータの中で、提供する

達成基準 1.2.6のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準1.2.6に適合していないとみなした、よくある不適合事例である。

(今のところ、文書化されている不適合事例がない)

重要な用語

収録済 (prerecorded): ライブではない情報。
同期したメディア (synchronized media): 情報を提示するために、他のフォーマットと同期した音声もしくは映像、又は時間に依存するインタラクティブな構成要素と同期した音声又は映像。ただし、そのメディアがメディアによるテキストの代替であって、メディアによる代替であることが明確にラベル付けされているものは除く。
手話通訳 (sign language interpretation): ある言語、通常は発話された言葉を、手話に訳すこと。
注記: 手話は、本来、同じ国や地域で話されている言葉とは関係がない独立したものである。
音声 (audio): 音の再生技術。
注記: 音声には、合成して作られたもの (音声合成を含む)、実世界の音を収録したもの、又はその両方が含まれる。

拡張音声解説 (収録済) :
達成基準 1.2.7 を理解する

1.2.7 拡張音声解説 (収録済) : 前景音の合間が、音声解説で映像の意味を伝達するのに不十分な場合、同期したメディアに含まれているすべての収録済の映像コンテンツに対して、拡張音声解説が提供されている。 (レベル AAA)

この達成基準の意図

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

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

達成基準1.2.7の具体的なメリット

全盲あるいは画面を見ることができないロービジョンの利用者、及び認知能力の低下により何が起こっているのかを視覚的に解釈しづらい利用者が、視覚的な情報についての音声解説をよく利用している。しかし、主音声の発話があまりにも多いと、音声解説では十分に説明しきれない。拡張音声解説は、映像を理解するのに必要な追加情報を提供することができる。

達成基準 1.2.7の事例

事例 1 .講義の映像。物理学の教授が講義をしている。教授は、ホワイトボードに手書きで図を描きながら、早口で話している。一つの問題を解説し終えると、教授はすぐにその図を消して、別の図を描きながらもう片方の手で身振りを交えながら話し続けている。映像は、問題と問題の間で一時停止し、教授の描いた図と身振りを説明する拡張した音声解説を提供している。そして、映像の再生が再開される。

達成基準1.2.7の達成方法及び不適合事例 - 拡張音声解説 (収録済)

達成基準を満たすことのできる達成方法

次のどれか一つを用いて、G8: 拡張音声解説が付いたムービーを提供する
- SM1: SMIL 1.0 で拡張音声解説を追加する (SMIL)
- SM2: SMIL 2.0 で拡張音声解説を追加する (SMIL)
- 音声及び映像をサポートしているプレーヤーを用いる

1.2.7 でさらに対応が望まれる達成方法（参考）

H96: 音声解説を提供するために、track 要素を使用する (HTML)
SMIL1.0で多様な言語における拡張した音声解説を追加する（リンク追加予定）
SMIL2.0で多様な言語における拡張した音声解説を追加する（リンク追加予定）

達成基準 1.2.7のよくある不適合事例

以下に挙げるものは、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.2.8 メディアに対する代替 (収録済) : すべての収録済の同期したメディア及びすべての収録済の映像しか含まないメディアに対して、時間依存メディアに対する代替コンテンツが提供されている。 (レベル AAA)

この達成基準の意図

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

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

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

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

注記 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.2.8の事例

事例 1. ある研修ビデオでの、時間の経過に伴って変化するメディアの代替
あるコミュニティセンターは、その会員向けに研修ビデオを購入し、それをセンターのイントラネットに置いている。そのビデオでは、新しい技術の使い方を説明していて、同時にそれを説明しながら実演する人物が登場している。そのコミュニティセンターでは、時間依存メディアに対して代替を提供している。ひとつの代替によって、同期したメディアの実演を見ることも、説明を聞くこともできない人を含むすべての会員が、提供されている内容をよりよく理解できるようになっている。

達成基準1.2.8の達成方法及び不適合事例 - メディアに対する代替 (収録済)

達成基準を満たすことのできる達成方法

状況 A：収録済の同期したメディアの場合：

次の達成方法のどれか一つを用いて、G69: 時間の経過の伴い変化するメディアに対して代替コンテンツを提供する
- G58: 非テキストコンテンツのすぐ隣に、時間の経過に伴って変化するメディアの代替へのリンクを置く
- SL17: Providing Static Alternative Content for Silverlight Media Playing in a MediaElement (Silverlight)
次の達成方法のどれか一つを用いて、時間の経過に伴って変化するメディアの代替へリンクする
- H53: object 要素のボディを使用する (HTML)

状況 B：収録済の映像しか含まないコンテンツの場合：

G159: 時間の経過に伴って変化するメディアの映像しか含まないコンテンツに対して代替コンテンツを提供する

1.2.8 でさらに対応が望まれる達成方法（参考）

H46: embed 要素と一緒に noembed 要素を用いる (HTML)
訂正済みのスクリプトを使う（リンク追加予定）
音声解説の詳細を追加する（リンク追加予定）

達成基準 1.2.8のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準1.2.8に適合していないとみなした、よくある不適合事例である。

F74: 達成基準 1.2.2 及び達成基準 1.2.8 の失敗例－テキストに対する代替である同期したメディアを代替コンテンツとしてラベル付けしていない

重要な用語

収録済 (prerecorded): ライブではない情報。
同期したメディア (synchronized media): 情報を提示するために、他のフォーマットと同期した音声もしくは映像、又は時間に依存するインタラクティブな構成要素と同期した音声又は映像。ただし、そのメディアがメディアによるテキストの代替であって、メディアによる代替であることが明確にラベル付けされているものは除く。
映像しか含まない (video-only): 映像のみを含んだ、時間に依存する提示 (音声やインタラクションを含まない)。
時間依存メディアに対する代替コンテンツ (alternative for time-based media): 時間依存の視覚的及び聴覚的情報を正しい順序で説明したテキストを含み、あらゆる時間依存のインタラクションによる結果を得る手段を提供している文書。
注記: 同期したメディアのコンテンツを作るために用いられる脚本は、編集が終了した最終版の同期したメディアを正確に描写した脚本に修正されている場合だけ、この定義を満たす。

音声のみ (ライブ) :
達成基準 1.2.9 を理解する

1.2.9 音声のみ (ライブ) : ライブの音声しか含まないコンテンツに対して、それと同等の情報を提示する、時間依存メディアの代替コンテンツが提供されている。 (レベル AAA)

この達成基準の意図

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

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

この達成基準は、音声の放送に適用することを意図しており、Webアプリケーションを介し2人ないしそれ以上の個人同士で行う双方向のマルチメディア電話に対し、利用者の要求の有無にかかわらずキャプションの提供を求めることは意図していない。キャプションを提供する責任は、コンテンツの提供者（電話をかけた人）または「ホスト」として電話をかけた人に課せられるもので、アプリケーションには課せられない。

達成基準 1.2.9の事例

ある広告会社が、ウェブベースのキャプションサービスを利用して、ライブのイベントのキャプションを提供している。そのサービスによるキャプションは、ストリーミングの音声制御コントロールのあるウェブページのサブフレームに表示されている。
フリンジ劇場のライブのラジオ劇が、ウェブで放送されている。俳優たちが大部分は用意された台本通りに演じていて、番組の予算が限られているため、（脚本家の許諾を得た上で）プロデューサーは劇の台本へのリンクを提供している。
ストリーミングの音声サーバーは、例えば Flash や Silverlight のように、テキスト及びグラフィックも使用可能なメディア形式を利用している。速記者が、あるイベントでライブのキャプションを書き起こしていて、それがその場で組み込まれて、メディアプレーヤーで閲覧可能なメディア配信のライブのキャプションとして使われている。
ある CEO が、ニュース速報の報道に反応して、報道メディア向けに電話による記者発表を行っている。その音声を録音して、インターネット上でも配信したが、時間の制約があって、ウェブ・キャプション付加サービスを間に合わせることができなかった。CEO がそこで読み上げる記者発表の内容は予め準備されていたので、その会社は発表内容の書き起こしテキストを同時に提供することにした。

達成基準1.2.9の達成方法及び不適合事例 - 音声のみ (ライブ)

達成基準を満たすことのできる達成方法

1.2.9 でさらに対応が望まれる達成方法（参考）

テキストトランスクリプションと音声しか含まないコンテンツを関連付けるためにメタデータを使う（リンク追加予定）
事例: 音声ファイルの様々な書き起こしテキスト（英語、フランス語、ドイツ語）を指し示すURIを、メタデータの中で、提供する。

達成基準 1.2.9のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準1.2.9に適合していないとみなした、よくある不適合事例である。

(今のところ、文書化されている不適合事例がない)

重要な用語

ライブ (live): 現実の出来事から取り込まれ、放送遅延以上の遅延なく受け手に送信される情報。
注記 1: 放送遅延は、短時間の (通常は自動的な) 遅れで、例えば放送局に放送のタイミングの調整や音声 (又は映像) の検閲のための時間を与えるものだが、意味のある編集ができるほどのものではない。
注記 2: もし情報が完全にコンピュータで生成されたものならば、それはライブではない。
時間依存メディアに対する代替コンテンツ (alternative for time-based media): 時間依存の視覚的及び聴覚的情報を正しい順序で説明したテキストを含み、あらゆる時間依存のインタラクションによる結果を得る手段を提供している文書。
注記: 同期したメディアのコンテンツを作るために用いられる脚本は、編集が終了した最終版の同期したメディアを正確に描写した脚本に修正されている場合だけ、この定義を満たす。
音声しか含まない (audio-only): 音声のみを含んだ、時間に依存する提示 (映像やインタラクションを含まない)。

適応可能:
ガイドライン1.3を理解する

ガイドライン1.3: 情報、及び構造を損なうことなく、様々な方法 (例えば、よりシンプルなレイアウト) で提供できるようにコンテンツを制作すること。

ガイドライン 1.3 の意図

このガイドラインの目的は、例えば、音声で読み上げたり、あるいはより単純なレイアウトで提示したりというように、すべての情報をすべての利用者が知覚できるように提供することである。すべての情報が、ソフトウェアによって解釈できるように提供されていれば、情報を様々な方法で（視覚的、聴覚的、触覚的、又はその他の方法で）提示することが可能である。もし、支援技術によって構造及び情報をプログラムが解釈できないような方法で、情報がある特定の表現形態で提供されていたとしたら、その情報は利用者が必要とするその他の形式では描画できない。

このガイドラインにある達成基準はすべて、ある表現形態で提供されている様々な種類の情報を、その他の感覚モダリティでも提示可能であるように提供するためのものである。

構造: ウェブページの構成要素が相互に関係して系統的に整理されている状態で、かつウェブページの集合が整理されている状態。
表現: 利用者が知覚できる形でのコンテンツの描画。

情報及び関係性:
達成基準 1.3.1 を理解する

1.3.1 情報及び関係性: 何らかの形で提示されている情報、構造、及び関係性は、プログラムによる解釈が可能である、又はテキストで提供されている。 (レベル A)

この達成基準の意図

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

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

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

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

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

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

場合によっては、関係性をプログラムで解釈できるようにすべきかテキストで提供すべきか、各自の判断に委ねるしかないこともありうる。しかし、プログラムに基づいた関係性を技術的に示すことができる場合、情報や関係性をテキストで提供するよりも、プログラムが解釈できるようにすることを強く推奨する。

注記: 色の値がプログラムが解釈可能であることは要求していない。色によって伝えられる情報は、その値を明らかにするだけでは、十分に提示することができないからである。そのため、色に特有の問題については、達成基準 1.3.1 ではなく、達成基準 1.4.1で対処している。

達成基準1.3.1の具体的なメリット

この達成基準は、ユーザエージェントが個々の利用者のニーズに応じてコンテンツに適応できるようにすることによって、様々な障害のある利用者の役に立つ。
全盲の（スクリーンリーダーを使用している）利用者が、色を用いて伝えられている情報をテキストでも得られるようになる（色を用いて情報を伝えている画像の代替テキストを含む）。
点字ピンディスプレイを使用している盲ろうの利用者は、色に依存した情報を利用できないことがある。

達成基準 1.3.1の事例

必須項目のある入力フォーム
入力フォームに、いくつかの必須項目がある。必須項目のラベルを、赤で表示している。さらに、各ラベルの最後には、アスタリスクの記号文字 (*) が付いている。フォームへの入力に関する説明文には、「すべての必須項目は赤字で示してあり、アスタリスク (*) が付いています。」と書かれていて、例が後に続いている。
必須項目を示すために色とテキストを用いている入力フォーム
入力フォームに、必須項目と任意項目の両方がある。入力フォームの先頭にある説明文には、必須項目のラベルが赤字になっていて、「必須」という代替テキストのあるアイコンも付いている。赤字とアイコンの両方が、フォームのテキストフィールドとプログラムで関連付けられているので、支援技術の利用者はどれが必須項目なのかが判断できる。
各セルの見出しをプログラムが解釈可能なバスの時刻表テーブル
バスの運行スケジュールが、1列目には縦にバス停の名前が並び、1行目には横に異なるバスが並んでいる表で示されている。各セルには、バスがそのバス停に到着する時刻が書かれている。支援技術が、各セルにある時刻がどのバスとどのバス停とに関連付けられているのかを解釈することができるように、各バス停と各バスのセルは、それぞれの対応する行又は列の見出しとして示されている。
チェックボックスのラベルをプログラムが解釈可能な入力フォーム
あるフォームでは、各チェックボックスに対するラベルが、支援技術によってプログラムが解釈可能になっている。
テキスト文書
構造をプログラムが解釈できるように、シンプルなテキスト文書は、タイトルの前に2行の空行があり、アスタリスクを使ってリスト項目を示し、その他の標準的な書式の決まりに従ってフォーマットされている。

達成基準1.3.1の達成方法及び不適合事例 - 情報及び関係性

達成基準を満たすことのできる達成方法

状況 A：ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供している場合：

状況 B：ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムが解釈可能にするセマンテックな構造を提供していない場合：

G117: テキストの表現のバリエーションによって伝えている情報を伝達するために、テキストを使用する
FLASH8: フォーム・コントロールのアクセシブルな名前にグループ名を追加する (Flash)
表現によって伝えられている情報及び関係性をプログラムが解釈可能にする、又は次の達成方法を用いてテキストで入手可能にする：

1.3.1 でさらに対応が望まれる達成方法（参考）

C22: テキストの視覚的な表現を制御するために、CSS を使用する (CSS)
ページレイアウトにはテーブルよりもCSSを用いる（リンク追加予定）
G162: ラベルを配置して、関係性を最大限に予測できるようにする
ARIA1: ユーザインターフェースコントロールに対する説明ラベルを提供するために、aria-describedby プロパティを使用する (ARIA)
ARIA2: aria-requiredプロパティによって必須項目を特定する (ARIA)
絶対的なラベルを持たないすべてのフォームコントロールにラベルを提供する（リンク追加予定）
G141: 見出しを用いてウェブページを構造化する

達成基準 1.3.1のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準1.3.1に適合していないとみなした、よくある不適合事例である。

重要な用語

プログラムによる解釈 (プログラムによる解釈が可能) (programmatically determined (programmatically determinable))

支援技術を含む様々なユーザエージェントが抽出でき、利用者に様々な感覚モダリティで提示できるような形のデータがコンテンツ制作者によって提供されたとき、そのデータがソフトウェアによって解釈されること。

事例 1: マークアップ言語で、一般に入手可能な支援技術が直接アクセスできる要素と属性から解釈される。

事例 2: 非マークアップ言語の技術特有のデータ構造から解釈され、一般に入手可能な支援技術がサポートするアクセシビリティ API を通じて支援技術に提供される。

提示 (presentation)

利用者が知覚できる形式でコンテンツをレンダリングすること。

構造 (structure)

ウェブページの各部を相互の関係性によりまとめる方法論。及び、
一連のウェブページをまとめる方法論。

関係性 (relationships)

コンテンツの異なる部分間における意味のあるつながり。

意味のある順序:
達成基準 1.3.2 を理解する

1.3.2 意味のある順序: コンテンツが提示されている順序が意味に影響を及ぼす場合には、正しく読む順序はプログラムによる解釈が可能である。 (レベル A)

この達成基準の意図

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

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

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

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

誤解のないように書くと:

特定の線形順序を提供することが要求されるのは、意味に影響を与えるときだけである。
複数の順序が（WCAG 2.0の定義する）「正しい」読み順となることもありえる。
提供する正しい読み順はひとつだけでよい。

達成基準1.3.2の具体的なメリット

この達成基準は、コンテンツを読み上げる支援技術に依存している利用者の役に立つ。デフォルトの表現における情報の並び順で明らかになる意味は、コンテンツを読み上げで提示したときも同じになるはずである。

達成基準 1.3.2の事例

事例 1：段組をしている文書において、コンテンツをリニアライズした表現は、ある段の先頭から最後へと流れていき、その後次の段の先頭へと流れていく。
事例 2： CSS を用いて、ナビゲーションバー、ページの本文、及び関連記事を配置している。それらの視覚的な表現は、プログラムが解釈できる順序とは合致していないが、そのページの意味はその見た目の順序には依存していない。

達成基準1.3.2の達成方法及び不適合事例 - 意味のある順序

達成基準を満たすことのできる達成方法

ウェブページにあるすべてのコンテンツについて、G57: コンテンツを意味のある順序で並べる
次の達成方法のどれか一つを用いて、コンテンツの並び順を意味のあるものにする、かつ、その並び順については、G57: コンテンツを意味のある順序で並べる
C27: DOM の順序を表示順序と一致させる (CSS)
FLASH15: Flash 内の論理的な読み上げ順序及びタブ順序を指定するために、tabIndex プロパティを使用する (Flash)
PDF3: PDF 文書で正しいタブ順序と読み上げ順序を確保する (PDF)
SL34: Using the Silverlight Default Tab Sequence and Altering Tab Sequences With Properties (Silverlight)

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)
注記: 色に関する要件は、ガイドライン 1.4を参照。

この達成基準の意図

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

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

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

WCAG はウェブページ上に表示されたコントロールのみに該当するよう設計された。その意図は、視覚的又は聴覚的な手がかりのみを参考にコントロールを説明をすることを避けるためである。これをハードウェアコントロール（例えば、専用コンテンツのためのインターネットキオスク）を操作する時の説明に適用する時は、おそらく触知できる手がかり（例えば、矢印の形をしたキー、右側の丸いキー）が説明されるだろう。この達成基準は、指示の中で触知できる手がかりの使用を防ぐことを意図したものではない。

達成基準1.3.3の具体的なメリット

全盲の利用者及びロービジョンの利用者は、情報が形及び/又は位置によって伝えられている場合、その情報を理解できないことがある。形及び/又は位置以外の情報を補足することで、形及び/又は位置だけで伝えられている情報を理解できるようになる。

達成基準 1.3.3の事例

事例 1：重複したイベントのスケジュールに、それぞれのイベント時間を区別するために色と形を使う
テーブルの1行目に時間のリストが表示され、1列目にイベントリストが表示されている表がある。セルは、色と形で定義づけできるため、特定のイベントの時間を背景色とダイヤモンドの形をした記号で表示する。
事例 2：複数のページによるオンライン調査
複数のページによるオンライン調査では、あるページから次のページへ遷移するためのリンクに緑色の矢印のアイコンを使っていて、それをコンテンツの右下に置いている。矢印には「次へ」というラベルがはっきりと記述されていて、「次の調査へ進むには、最後の質問の右下にある『次へ』というラベルの付いた緑色の矢印のアイコンを選択してください。」という説明文が書かれている。この例では、アイコンを特定できるように、配置、色及びラベルを用いている。

達成基準1.3.3の達成方法及び不適合事例 - 感覚的な特徴

達成基準を満たすことのできる達成方法

G96: 理解すべき情報を感覚的にだけ伝えることのないように、テキストでもアイテムを特定する

1.3.3 でさらに対応が望まれる達成方法（参考）

デザイン的にグラフィカルな表現だが異なる意味を持つUnicodeフォントの代わりにグラフィカルなシンボルとして代替えテキストのある画像を用いる（リンク追加予定）

達成基準 1.3.3のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準1.3.3に適合していないとみなした、よくある不適合事例である。

判別可能:
ガイドライン1.4を理解する

ガイドライン1.4: コンテンツを、利用者にとって見やすく、聞きやすいものにすること。これには、前景と背景を区別することも含む。

ガイドライン 1.4 の意図

代替手法を用いて情報を提示できることに焦点をあてたガイドラインがいくつかあるが、このガイドラインは、デフォルトの表現を障害のある利用者にとってできる限り知覚しやすくすることに関係している。利用者が前景の情報と背景とを区別しやすくすることに主に重点を置いている。視覚的な表現の場合は、背景の上に提示されている情報とその背景とのコントラストを十分に確保しているかどうかを確認する。そして、音声による表現の場合は、前景音が背景音よりも十分に大きいかどうかを確認する。視覚及び聴覚に障害のある利用者は、前景と背景の情報を区別することがかなり困難である。

ガイドライン 1.4 の参考にすべき達成方法(特定の達成基準に特有ではない達成方法)

読みやすいフォントを用いる（リンク追加予定）
画像化されたテキストが、少なくとも14ポイント以上で、十分なコントラストを持つか確認する（リンク追加予定）
リンク又はコントロールがキーボードのフォーカスを受けるとき、可視的なメカニズムを提供する（リンク追加予定）

色の使用:
達成基準 1.4.1 を理解する

1.4.1 色の使用: 色が、情報を伝える、動作を示す、反応を促す、又は視覚的な要素を判別するための唯一の視覚的手段になっていない。 (レベル A)
注記: この達成基準は、特に色の知覚に関するものである。その他の知覚形態については、色やその他の視覚的提示のコーディングへのプログラムによるアクセスも含めて、ガイドライン 1.3で網羅されている。

この達成基準の意図

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

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

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

注記: この達成基準は、ページ上での色の使用、あるいは他の視覚的な表示と重複していても色分けすることを阻むものではない。

達成基準1.4.1の具体的なメリット

ロービジョンの利用者が、色覚の限界を感じることがよくある。
年配の利用者は、色がよく見えないかもしれない。
色弱の利用者が、色で伝えられている情報をその他の視覚的な手段で知覚できるようになる。
テキストしか表示しない、色数の制限された、又はモノクロのディスプレイを使用している利用者は、色に依存している情報を知覚することができないことがある。
色の識別に問題を抱える利用者が、テキストの手がかりを見たり、聞いたりすることができる。
点字ピンディスプレイやその他の触覚インタフェースを使用している利用者は、触覚からテキストの手がかりを読み取れる。

達成基準 1.4.1の事例

必須項目を示すために色とテキストを用いている入力フォーム
ある入力フォームには、必須項目と任意項目の両方がある。入力フォームの先頭にある説明文には、必須項目のラベルが赤字になっていて、「必須」という代替テキストのあるアイコンも付いている。赤字とアイコンの両方が、フォームのテキストフィールドとプログラムで関連付けられているので、支援技術の利用者はどれが必須項目なのかが判断できる。
試験
学生は、化学化合物の SVG 画像を見て、図に使用されている色や数字に基づいて、存在する化学の要素を識別する。各要素に関連付けられたテキストによる代替は、要素の色に名前を付けて、図で要素の位置を示している。色を知覚できない学生は、クラスメートと同じように、化合物に関する同じ情報を得る。（この達成方法は、ガイドライン 1.1 のレベル A も満たす）
使用不可になっているフォーム要素
マークアップ又はスクリプトによって使用不可になっているフォーム要素は、ユーザエージェントによってグレー表示され、使用できない。使用不可の状態では、これらの要素はフォーカスを受け取らない。支援技術は、使用不可の状態になっている要素をプログラムが解釈することが可能であろう。色の変化及びフォーカスがあたらないことによって、コントロールの状態に関する情報を視覚的に提供している。

達成基準1.4.1の達成方法及び不適合事例 - 色の使用

達成基準を満たすことのできる達成方法

状況 A：特定の語句、背景、又は他のコンテンツの色を用いて情報を示している場合：

状況 B：情報を伝える画像の中で色を用いている場合：

1.4.1 でさらに対応が望まれる達成方法（参考）

色を冗長的に使って情報を伝える（リンク追加予定）
C15: ユーザインタフェースコンポーネントがフォーカスを受けとったときの表示を変更するために、CSSを使用する (CSS)

達成基準 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の達成方法及び不適合事例 - 音声の制御

達成基準を満たすことのできる達成方法

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 というコントラスト比は、一般的に支援技術を使用していないロービジョンの利用者のコントラスト感度の低下を補い、同様に色弱の利用者に対してもコントラストを向上させる。

注記: [ISO-9241-3] 及び [ANSI-HFES-100-1988]における計算は、本文のテキストを想定したものである。それよりもずっと大きいサイズのテキストに対しては、緩いコントラスト比が提供されている。

計算式に関する注記

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の具体的なメリット

ロービジョンの利用者は、背景とのコントラストが不十分なテキストを読むのが困難なことがよくある。利用者が色弱でコントラストがさらに弱まってしまう場合には深刻になりえる。テキストと背景に最低限のコントラスト比を持たせることで、たとえ利用者がすべての色を見ることができなかったとしても、テキストをより読みやすくすることができる。また、まれであるが、全く色が見えないという利用者にとっても有用である。

達成基準 1.4.3の事例

(none currently documented)

達成基準1.4.3の達成方法及び不適合事例 - コントラスト (最低限)

達成基準を満たすことのできる達成方法

状況 A：太字でないテキストが18ポイント（日本語は22ポイント）未満、太字のテキストが14ポイント（日本語は18ポイント）未満の場合：

状況 B：太字でないテキストが少なくとも18ポイント（日本語は22ポイント）以上、太字のテキストが少なくとも14ポイント（日本語は18ポイント）以上の場合：

1.4.3 でさらに対応が望まれる達成方法（参考）

G156: 一般に入手可能なユーザエージェントで、テキストのブロックの前景及び背景を変更できるウェブコンテンツ技術を使用する
模様のついた背景色にテキストを重ねるためにより高いコントラストの値を用いる（リンク追加予定）
画像化された文字の代わりにUnicodeテキストとスタイルシートを用いる（リンク追加予定）
図表の線に、より高いコントラストの値を用いる（リンク追加予定）
赤と黒の組み合わせによる文字と背景色には、さらに大きなコントラストレベルを用いる（リンク追加予定）
主に中間のスペクトル要素からなる明るい要素とスペクトルの両端（青と赤の波長）からなる暗い要素で構成された色を用いる
両端のコントラストではなく黒文字に白の背景よりも明るいパステルの背景色を用いる（リンク追加予定）
テキストのコントラストを満たしているシンプルな線で描かれたアイコンを使う（リンク追加予定）
グラフやチャートに十分なコントラストを提供する（リンク追加予定）
デフォルトの表現に3:1のコントラスト比又はそれ以上を用いる（リンク追加予定）
空のテキストフィールドに十分な色のコントラストを提供する（リンク追加予定）

達成基準 1.4.3のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準1.4.3に適合していないとみなした、よくある不適合事例である。

重要な用語

コントラスト比 (contrast ratio)

(L1 + 0.05) / (L2 + 0.05) ここでは、

L1 は、明るいほうの色の相対輝度である。そして、
L2 は、暗いほうの色の相対輝度である。

注記 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言語のようなその他の文字については、「同等な」サイズはその言語での拡大印刷の最小サイズと拡大印刷でその次に大きな標準のサイズとなる。

訳注： 日本語の全角文字の場合は、拡大教科書普及推進会議第一次報告「第2章拡大教科書の標準的な規格について」に基づき、22ポイント又は18ポイントの太字を「同等な」サイズとみなすのが妥当である。

テキスト (text)

プログラムによる解釈が可能な文字の並びで、自然言語で何かを表現しているもの。

ユーザインタフェースコンポーネント (user interface component)

コンテンツの一部分で、特定の機能を実現するための単一のコントロールとして利用者が知覚するもの。

注記 1: 複数のユーザインタフェースコンポーネントが、単一のプログラム要素で実装されることもある。ここでいうコンポーネントは、プログラムの手法と結びついたものではなく、利用者が別々のコントロールとして知覚するものを指す。

注記 2: ユーザインタフェースコンポーネントには、フォーム要素、リンクだけでなく、スクリプトで生成されるコンポーネントが含まれる。

事例: アプレットには、コンテンツ内を行単位、ページ単位、又はランダムアクセスで移動するために用いられる「コントロール」がある。これらには、いずれも名前 (name) を割り当て、個別に設定できるようにする必要があるため、それぞれが「ユーザインタフェースコンポーネント」となる。

文字画像 (image of text)

特定の視覚的効果を得るために非テキスト形式 (例えば画像) でレンダリングされたテキスト。

注記: テキスト以外の部分が重要な視覚的コンテンツである場合、画像に含まれるテキストは該当しない。

事例: 写真に写っている人の名札にある人名。

純粋な装飾 (pure decoration)

見栄えのためだけのもので、情報は提供せず、機能性も備えていないもの。

注記: テキストが純粋な装飾といえるのは、単語を並べ替え、又は置き換えても意図が変わらないときだけである。

事例: 背景にとても淡い文字で単語がランダムに並んでいる辞書の表紙。

テキストのサイズ変更:
達成基準 1.4.4 を理解する

1.4.4 テキストのサイズ変更: キャプション及び文字画像を除き、テキストは、コンテンツ又は機能を損なうことなく、支援技術なしで 200％までサイズ変更できる。 (レベル AA)

この達成基準の意図

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

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

利用者が、拡大機能を持つユーザエージェントを利用できない場合、制作者は、HTML コンテンツに対するこの達成基準を満たすためにユーザエージェントに依存することはできない。例えば、利用者が、IE6を使用する必要のある環境で作業をしている場合である。

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

ラベルとして機能し、コンテンツにアクセスするために利用者によるアクティベーションを必要とするいくつかのユーザインタフェースコンポーネントは、ラベルコンテンツを収容するのに十分な幅がない。例えば、ウェブメールアプリケーションにおける件名のカラムは、全ての実行可能な件名の見出しを収容するために十分な幅でなくてもよいが、件名の見出しをアクティブにすることで、利用者は、完全な件名の見出しを伴う完全なメッセージを得る。ウェブベースのスプレッドシートでは、カラム内に表示するには長すぎるセルのコンテンツは切り落とされ、そのセルの全コンテンツは、セルがフォーカスを受け取ったとき、利用者に提供される。ユーザインタフェースコンポーネントのコンテンツは、利用者がカラムの幅の幅を変更することができるユーザインタフェースでも同様に、広くなるかもしれない。コンポーネントの完全なコンテンツが、フォーカスを置く又は利用者のアクティベーションの後に利用可能であり、この情報にアクセスすることができることが示され、それが切り捨てられるという事実の他にいずれかの方法で利用者へ提供される場合、切り捨ては許容される。

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

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

注記: 画像化された文字は、画素に分解されてしまうので、テキストと同じように拡大できない。そのため、可能な限り、テキストを用いることを勧める。また、画像化された文字の前景と背景のコントラスト及び色の組合せを変更することを必要とする利用者もいるが、テキストよりも困難である。

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

達成基準1.4.4の具体的なメリット

この達成基準により、テキストのサイズを変更できるようにすることで、ロービジョンの利用者がコンテンツのテキストを読むことができるようになる。

達成基準 1.4.4の事例

視覚障害のある利用者が、ウェブページのテキストの大きさをブラウザで 1 em から 1.2 em に変更している。その利用者は小さいテキストを読むことはできないが、大きいテキストは読むことができる。テキストの大きさが大きくなっても、ページ上のすべての情報は表示されている。
ページを拡大縮小するためのコントロールがウェブページにある。異なる設定を選択すると、そのサイズで最適なデザインとなるようにページのレイアウトが変更される。
利用者が、ユーザエージェントの拡大縮小機能を使って、コンテンツのサイズを変更している。すべてのコンテンツは均一に拡大し、必要に応じてユーザエージェントがスクロールバーを提供している。

達成基準1.4.4の達成方法及び不適合事例 - テキストのサイズ変更

達成基準を満たすことのできる達成方法

G142: ズーム機能をサポートする一般に入手可能なユーザエージェントのあるウェブコンテンツ技術を使用する
SL22: Supporting Browser Zoom in Silverlight (Silverlight)
SL23: Using A Style Switcher to Increase Font Size of Silverlight Text Elements (Silverlight)
テキストのサイズを変更した際に、テキスト・コンテナもサイズ変更するようにする、かつ、次の達成方法の一つ以上を用いて、コンテンツにあるその他の大きさと相対的な大きさにする
- C28: em 単位を用いて、テキストコンテナのサイズを指定する (CSS)
- 相対的な大きさの達成方法：
- テキスト・コンテナのサイズを可変にする達成方法：
  - SCR34: テキストサイズに応じて拡大するように、サイズ及びポジションを定める (Scripting)
  - G146: リキッドレイアウトを使用する
G178: 利用者がウェブページ上のすべてのテキストを 200％まで徐々に変更できるコントロールをウェブページ上で提供する
G179: 文字サイズを変更しても、テキストコンテナの幅が変更されない際に、コンテンツ又は機能が損なわれないようにする

1.4.4 でさらに対応が望まれる達成方法（参考）

デフォルトで大きなフォントを提供する（リンク追加予定）
ページ比率のコンテナーサイズを用いる（リンク追加予定）
ユーザエージェントのデフォルトよりも小さなサイズのフォント尺度を使わない（リンク追加予定）
注記: コンテンツ制作者は本当のフォントサイズを知ることはできないが、100%よりも小さな値の尺度を避けるべきである
両端揃えは避ける（リンク追加予定）
十分なスペースを持った行間を提供する（リンク追加予定）
アクセシブルな選択肢が提供できない場合、非テキストコンテンツは異なるサイズを提供する（リンク追加予定）
ビットマップ（ラスター画像）の文字の利用を避ける（リンク追加予定）
画像化された文字のサイズ変更にサーバーサイトスクリプトを用いる（リンク追加予定）
C17: テキストを含むフォームの要素を拡大する (CSS)
少なくとも18ポイント以上のビットマップ（ラスター画像）の文字を保証する（リンク追加予定）
文字サイズを50％に縮小する（リンク追加予定）
C20: カラム幅に相対サイズを用いて、ブラウザの画面サイズを変更しても各行の文字数が平均 80 字（日本語は 40 字）以下を維持できるようにする (CSS)
C22: テキストの視覚的な表現を制御するために、CSS を使用する (CSS)
拡大するメカニズムをもつキャプションを提供する（リンク追加予定）

達成基準 1.4.4のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準1.4.4に適合していないとみなした、よくある不適合事例である。

重要な用語

(この文書で用いられている) 支援技術 (assistive technology (as used in this document))

注記 2: 支援技術は、API を利用、監視することで、主流のユーザエージェントとデータやメッセージのやりとりをすることが多い。

事例: この文書の文脈において重要な支援技術としては、以下のものが挙げられる:

画面拡大ソフト及びその他の視覚的な表示に関する支援技術。視覚障害、知覚障害、及び読書困難などの障害のある人が、レンダリング後のテキスト及び画像の視覚的な読みやすさを改善するために、テキストのフォント、サイズ、間隔、色、音声との同期などを変更するのに使用している。
スクリーンリーダー。全盲の人がテキスト情報を合成音声あるいは点字で読み取るために使用している。
音声変換ソフトウェア。認知障害、言語障害、及び学習障害のある人が、テキストを合成音声に変換するために使用している。
音声認識ソフトウェア。何らかの身体障害のある利用者が使用することがある。
代替キーボード。特定の身体障害のある人がキーボード操作をシミュレートするのに使用している (ヘッドポインタ、シングルスイッチ、呼気・吸気スイッチ、及びその他の特別な入力デバイスを使った代替キーボードを含む)。
代替ポインティングデバイス。特定の身体障害のある人がマウスポインタとボタンの動きをシミュレートするのに使用している。

キャプション (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の具体的なメリット

ロービジョンの利用者（コンテンツ制作者の指定した書体、サイズ、及び/又は色では、テキストが読みづらいことがある）
視線移動に問題のある利用者（コンテンツ制作者の指定した行間及び/又は配置では、テキストが読みづらいことがある）
読字に影響を及ぼす認知の障害のある利用者

達成基準 1.4.5の事例

スタイルを指定した見出し
特定のフォント及びサイズで見出しを提示するために、ビットマップ画像を用いるのではなく、コンテンツ制作者はCSSを用いて同じ見栄えにしている。
動的に生成された画像
あるウェブページでは、サーバーサイドのスクリプトを用いてテキストを画像として提示している。そのページには、利用者が生成される画像のフォントサイズ及び前景色と背景色を調節することのできるコントロールがある。
引用
あるウェブページに引用がある。その引用部分自体は、イタリックのテキストで、左側をインデントした状態で提示されている。その引用した部分の人名が、引用の下に1.5倍の行間を空けて、左側からさらにインデントした状態になっている。そのテキストの配置、行間スペースの指定、そしてテキストの書体・サイズ・色及び装飾には、CSS を用いている。
ナビゲーション
ウェブページに、ナビゲーション・リンクのメニューがあり、アイコンとテキストの両方でリンク先を示している。CSSを用いて、テキストの書体、サイズ、前景色及び背景色、そしてナビゲーション・リンク間の間隔を指定している。
文字を含んだロゴ
あるウェブサイトには、各ウェブページの左上のコーナーに組織のロゴがある。そのロゴには、ロゴタイプ（ロゴの一部又は全部に文字）がある。文字の視覚的な表現は、そのロゴのアイデンティティに不可欠であり、その文字の特徴を変更することができないGIF画像である。そして、その画像には、代替テキストがある。
書体のサンプル
ウェブページに、特定の書体に関する情報がある。その書体を他の書体に置き換えると、サンプルとしての目的が損なわれてしまう。そのサンプルは、その文字の特徴を変更することができない JPEG 画像である。そして、その画像には代替テキストがある。
手紙の写し
ウェブページに、手紙の原本を描写したものがある。オリジナルの体裁でその手紙を見せることが、その手紙の書かれた時代に関する情報を伝える上で不可欠である。その手紙は、その文字の特徴を変更することができない GIF 画像である。そして、その画像には、代替テキストがある。
記号的な文字
利用者がテキストのブロックを入力できるフォームがある。そのフォームは、テキストのスタイル指定やスペルチェックなどの機能のボタンをたくさん提供している。ボタンの中には文字を用いたものがあり、その文字に自然言語で何かを表現する並び順はない。例えば、フォントを太字にする機能には"B"、テキストをイタリックにする機能には"I"、そしてスペルチェックの機能には"ABC"が使われている。その記号的な文字は、その文字の特徴を変更することができない GIF 画像としてボタンになっている。そして、そのボタンには代替テキストがある。
画像化された文字のカスタマイズ可能なフォント設定
あるウェブサイトでは、利用者がフォントを設定できるようになっており、このウェブサイトのすべての画像化された文字は、その設定に基づいて提供される。

達成基準1.4.5の達成方法及び不適合事例 - 文字画像

達成基準を満たすことのできる達成方法

1.4.5 でさらに対応が望まれる達成方法（参考）

非テキストコンテンツ向けの一般的な達成方法

情報を提供する非テキストコンテンツを識別する（リンク追加予定）

CSS による達成方法

C12: フォントサイズにパーセントを使用する (CSS)
C13: フォントサイズにキーワードを使用する (CSS)
C14: フォントサイズに em 単位を使用する (CSS)
C8: 単語内の文字間隔を調整するために、CSS の letter-spacing プロパティを使用する (CSS)
C6: 構造を示すマークアップをした上で、コンテンツを配置する (CSS)
1文字以内でデザインされるテキスト文字を避ける（リンク追加予定）

達成基準 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] を参照のこと。

注記: [ISO-9241-3]、及び、[ANSI-HFES-100-1988]における計算は、本文のテキストを想定したものである。それよりもずっと大きいサイズのテキストに対しては、緩いコントラスト比が提供されている。

計算式に関する注記

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]の標準規格に基づいている。

注記 1: コントラスト比を用いてウェブコンテンツのコントラストを分析するツールの一覧は、関連リソースを参照のこと。

注記 2: キーボード・フォーカスを示すための達成方法については、 達成基準2.4.7 フォーカスの可視化を理解するも参照のこと。

達成基準1.4.6の具体的なメリット

ロービジョンの利用者は、背景とのコントラストが不十分なテキストを読むのが困難なことがよくある。利用者が色弱でコントラストがさらに弱まってしまう場合には深刻になりえる。テキストと背景に最低限のコントラスト比を持たせることで、たとえ利用者がすべての色を見ることができなかったとしても、テキストをより読みやすくすることができる。また、まれであるが、全く色が見えないという利用者にとっても有用である。

達成基準 1.4.6の事例

(none currently documented)

達成基準1.4.6の達成方法及び不適合事例 - コントラスト (高度)

達成基準を満たすことのできる達成方法

状況 A：太字でないテキストが18ポイント（日本語は22ポイント）未満、太字のテキストが14ポイント（日本語は18ポイント）未満の場合：

状況 B：太字でないテキストが少なくとも18ポイント（日本語は22ポイント）以上、太字のテキストが少なくとも14ポイント（日本語は18ポイント）以上の場合：

1.4.6 でさらに対応が望まれる達成方法（参考）

G156: 一般に入手可能なユーザエージェントで、テキストのブロックの前景及び背景を変更できるウェブコンテンツ技術を使用する
模様のある背景にはよりハイコントラストな値の文字を用いる（リンク追加予定）
画像化された文字の代わりにUnicodeテキストとスタイルシートを用いる（リンク追加予定）
ダイヤグラムの線にハイコントラストな値を用いる（リンク追加予定）
赤と黒の組み合わせによる文字と背景色には、さらに大きなコントラストレベルを用いる
主に中間のスペクトル要素からなる明るい要素とスペクトルの両端（青と赤の波長）からなる暗い要素で構成された色を用いる
両端のコントラストではなく、黒文字に白の背景よりも明るいパステルの背景色を用いる（リンク追加予定）
テキストのコントラスト規定を満たしているシンプルな線で描かれたアイコンを使う（リンク追加予定）
グラフやチャートに十分な色コントラストを提供する（リンク追加予定）
デフォルトから3:1のコントラスト比又はそれよりも高い比率を用いる（リンク追加予定）
空のテキストフィールドに十分な色のコントラストを提供する（リンク追加予定）

達成基準 1.4.6のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準1.4.6に適合していないとみなした、よくある不適合事例である。

重要な用語

コントラスト比 (contrast ratio)

(L1 + 0.05) / (L2 + 0.05) ここでは、

L1 は、明るいほうの色の相対輝度である。そして、
L2 は、暗いほうの色の相対輝度である。

注記 1: コントラスト比は、1～21の範囲になりうる (通常は、1:1～21:1 と記述される)。

サイズの大きな (テキスト) (large scale (text))

少なくとも18ポイント、又は14ポイントの太字。あるいは、中国語、日本語、及び韓国語 (CJK) のフォントは、それと同等の文字サイズ。

注記 2: ここでいう文字サイズは、コンテンツが提供される際のサイズであり、利用者によるサイズ変更は含まれない。

テキスト (text)

プログラムによる解釈が可能な文字の並びで、自然言語で何かを表現しているもの。

ユーザインタフェースコンポーネント (user interface component)

コンテンツの一部分で、特定の機能を実現するための単一のコントロールとして利用者が知覚するもの。

注記 2: ユーザインタフェースコンポーネントには、フォーム要素、リンクだけでなく、スクリプトで生成されるコンポーネントが含まれる。

文字画像 (image of text)

特定の視覚的効果を得るために非テキスト形式 (例えば画像) でレンダリングされたテキスト。

注記: テキスト以外の部分が重要な視覚的コンテンツである場合、画像に含まれるテキストは該当しない。

事例: 写真に写っている人の名札にある人名。

純粋な装飾 (pure decoration)

見栄えのためだけのもので、情報は提供せず、機能性も備えていないもの。

注記: テキストが純粋な装飾といえるのは、単語を並べ替え、又は置き換えても意図が変わらないときだけである。

事例: 背景にとても淡い文字で単語がランダムに並んでいる辞書の表紙。

小さな背景音、又は背景音なし:
達成基準 1.4.7 を理解する

1.4.7 小さな背景音、又は背景音なし: 収録済の音声しか含まないコンテンツで、(1) 前景に主として発話を含み、(2) 音声CAPTCHA 又は音声ロゴではなく、かつ、(3) 例えば、歌やラップなどのように、主として音楽表現を意図した発声ではないものについては、次に挙げる事項のうち、少なくとも一つを満たしている: (レベル AAA)
背景音なし: 音声は背景音を含まない。
消音: 背景音を消すことができる。
20デシベル: 背景音は、前景にある発話のコンテンツより少なくとも20デシベルは低い。ただし、継続時間が2秒以内で発生頻度が低い背景音は除く。
注記: デシベルの定義によれば、この要件を満たす背景音は、前景にある発話のコンテンツの約4分の1の大きさになる。

この達成基準の意図

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

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の具体的なメリット

音声の聞こえづらい利用者は、発話と背景音を区別しづらいことがしばしばある。

達成基準 1.4.7の事例

(none currently documented)

達成基準1.4.7の達成方法及び不適合事例 - 小さな背景音、又は背景音なし

達成基準を満たすことのできる達成方法

G56: 発話ではない音が発話の音声コンテンツより少なくとも 20 デシベル以上低くなるように、音声ファイルを編集する

1.4.7 でさらに対応が望まれる達成方法（参考）

前景音と背景音のレベルを独立して調節できる方法を提供する（リンク追加予定）
発話より少なくとも20デシベル低い背景音を含む同期したメディアに対して、音声トラックを提供する（リンク追加予定）

達成基準 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」、「→」（矢印の記号）、そして「さ」（日本語の文字）などが挙げられる。

達成基準1.4.8の達成方法及び不適合事例 - 視覚的提示

達成基準を満たすことのできる達成方法

使用法：これは複数の要件から成る達成基準なので、次の要件それぞれについて、番号付きの項目の中から1つを満たさなければならない。

要件 1：前景色及び背景色を利用者が選択可能にする達成方法：

要件 2：幅が図形記号を含めて80文字以下（全角の場合は40文字以下）になるようにする達成方法：

要件 3：テキストを均等割り付け（左右両端揃え）にしないようにする達成方法：

要件 4：段落内の行送り幅（行間隔）が少なくとも1.5文字分、及び段落の間隔がその行送り幅の少なくとも1.5倍になるようにする達成方法：

要件 5：利用者が全画面表示にしたウィンドウで1行のテキストを読む際に横スクロールする必要がない状態で、支援技術を用いなくてもテキストを200％までサイズ変更できるようにする達成方法：

G204: 閲覧画面の幅を狭めたときに、ユーザエージェントによるテキストの折り返しを妨げない、又は、
G146: リキッドレイアウトを使用する、かつ、次の達成方法の一つ以上を用いて、コンテンツにあるその他の大きさと相対的な大きさにする：
- C12: フォントサイズにパーセントを使用する (CSS) 、又は、
- C13: フォントサイズにキーワードを使用する (CSS) 、又は、
- C14: フォントサイズに em 単位を使用する (CSS) 、又は、
- C24: コンテナのサイズに CSS のパーセント値を使用する (CSS) 、又は、
- FLASH33: Flash オブジェクトのサイズに相対値を使用する (Flash) 、又は、
- SCR34: テキストサイズに応じて拡大するように、サイズ及びポジションを定める (Scripting)
G206: レイアウトを切り替えるオプションをコンテンツの中で提供して、利用者が横スクロールをしなくてもテキストの行を読めるようにする

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.4.9の事例

引用
あるウェブページに引用がある。その引用部分自体は、イタリックのテキストで、左側をインデントした状態で提示されている。その引用した部分の人名が、引用の下に1.5倍の行間を空けて、左側からさらにインデントした状態になっている。そのテキストの配置、行間スペースの指定、そしてテキストの書体・サイズ・色及び装飾には、CSS を用いている。
ナビゲーション
ウェブページに、ナビゲーション・リンクのメニューがあり、アイコンとテキストの両方でリンク先を示している。CSSを用いて、テキストの書体、サイズ、前景色及び背景色、そしてナビゲーション・リンク間の間隔を指定している。
文字を含んだロゴ
あるウェブサイトには、各ウェブページの左上のコーナーに組織のロゴがある。そのロゴには、ロゴタイプ（ロゴの一部又は全部に文字）がある。文字の視覚的な表現は、そのロゴのアイデンティティに不可欠であり、その文字の特徴を変更することができないGIF画像である。そして、その画像には、代替テキストがある。
書体のサンプル
ウェブページに、特定の書体に関する情報がある。その書体を他の書体に置き換えると、サンプルとしての目的が損なわれてしまう。そのサンプルは、その文字の特徴を変更することができない JPEG 画像である。そして、その画像には、代替テキストがある。
手紙の写し
ウェブページに、手紙の原本を描写したものがある。オリジナルの体裁でその手紙を見せることが、その手紙の書かれた時代に関する情報を伝える上で不可欠である。その手紙は、その文字の特徴を変更することができない GIF 画像である。そして、その画像には、代替テキストがある。
記号的な文字
利用者がテキストのブロックを入力できるフォームがある。そのフォームは、テキストのスタイル指定やスペルチェックなどの機能のボタンをたくさん提供している。ボタンの中には文字を用いたものがあり、その文字に自然言語で何かを表現する並び順はない。例えば、フォントを太字にする機能には"B"、テキストをイタリックにする機能には"I"、そしてスペルチェックの機能には"ABC"が使われている。その記号的な文字は、その文字の特徴を変更することができない GIF 画像としてボタンになっている。そして、そのボタンには代替テキストがある。

達成基準1.4.9の達成方法及び不適合事例 - 文字画像 (例外なし)

達成基準を満たすことのできる達成方法

1.4.9 でさらに対応が望まれる達成方法（参考）

非装飾コンテンツに関する一般的な達成方法

画像化された文字サイズを変更するサーバーサイドスクリプトを用いる（リンク追加予定）

CSSの達成方法

C12: フォントサイズにパーセントを使用する (CSS)
C13: フォントサイズにキーワードを使用する (CSS)
C14: フォントサイズに em 単位を使用する (CSS)
C8: 単語内の文字間隔を調整するために、CSS の letter-spacing プロパティを使用する (CSS)
C6: 構造を示すマークアップをした上で、コンテンツを配置する (CSS)
1文字以内でデザインされるテキスト文字を避ける（リンク追加予定）

達成基準 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の達成方法及び不適合事例 - キーボード

達成基準を満たすことのできる達成方法

G202: すべての機能をキーボードだけでも操作可能にする
次の達成方法の一つを用いて、キーボードで操作できることを保証する。
次の達成方法の一つを用いて、 G90: キーボードがトリガーとなるイベント・ハンドラを提供する :
FLASH17: Flash オブジェクトをキーボードで操作可能にして、キーボードトラップを回避する (Flash) 　かつ、必要に応じて次の達成方法を用いる：

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の具体的なメリット

全盲の利用者及び身体障害のある利用者など、キーボード又はキーボード・インタフェースだけを使用している利用者がウェブコンテンツを利用できるようになる。

達成基準 2.1.2の事例

カレンダーのプログラム
カレンダーのプログラムは、利用者がキーボードを用いてそのカレンダーに項目の追加、削除又は更新することができるようになっている。プログラムにあるコントロールは、ウェブページ内の Tab キーによるフォーカス移動の一つで、あらゆるリンク又はコントロールと同様に利用者がプログラムのコントロールもTabキーで移動できる。
パズルのアプレット
利用者が Tab キーでフォーカスをアプレットの中に入れると、そこから先のフォーカス移動及びその他の打けんはアプレットが処理することになる。そして、そのアプレットから抜け出すのに用いる打けんに関する命令は、そのアプレットの中にあるのと同様に、アプレットに入る前に提供されている。
モーダル・ダイアログボックス
ウェブアプリケーションが、ダイアログボックスを立ち上げる。そのダイアログボックスの下部には、「キャンセル」と「OK」の二つのボタンがある。ダイアログボックスが開くと、フォーカスはそのダイアログボックスから外へ抜け出せなくなる。ダイアログボックスの最後のコントロールで Tab キーを押すと、フォーカスはダイアログボックスの最初のコントロールへ移動する。「キャンセル」ボタン又は「OK」ボタンを押下すると、そのダイアログボックスは閉じられる。

達成基準2.1.2の達成方法及び不適合事例 - キーボードトラップなし

達成基準を満たすことのできる達成方法

2.1.2 でさらに対応が望まれる達成方法（参考）

(まだ文書化されていない)

達成基準 2.1.2のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準2.1.2に適合していないとみなした、よくある不適合事例である。

F10: 達成基準 2.1.2 及び適合要件 5 の失敗例－利用者が一つのフォーマットの中に閉じ込められてしまうように、複数のコンテンツ・フォーマットを組み合わせている

重要な用語

キーボードインタフェース (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の達成方法及び不適合事例 - キーボード (例外なし)

達成基準を満たすことのできる達成方法

この達成基準には、特に追加された達成方法があるわけではない。達成基準 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の達成方法及び不適合事例 - タイミング調整可能

達成基準を満たすことのできる達成方法

状況 A：セッションの制限時間がある場合：

状況 B：制限時間がページ上のスクリプトで制御されている場合：

状況 C：コンテンツを読むのに制限時間がある場合：

2.2.1 でさらに対応が望まれる達成方法（参考）

制限時間がある場合、サーバーに問いかけるためにスクリプトを使用し、利用者に通知する。（リンク追加予定）(Scripting)
利用者の注意を集中させるために音を使用する。（リンク追加予定）

達成基準 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秒間だけ自動更新をして，その後に停止するのはほとんど意味がないので、自動更新には5秒という例外はない。
訳注： 原文では "three second" と記述されているが、達成基準に記載されている内容から「5秒」が正しい値であると判断し、秒数を修正している。

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

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

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

一時停止した後、利用者が一時停止したところから再開することが、コンテンツを読むために一時停止したいと思う利用者にとっては最適であり、コンテンツがリアルタイムのイベント又は状態に関係のないときには最も良い方法である。
注記: 読むための制限時間に関するその他の要件については、 達成基準2.2.1 タイミング調整可能を理解するを参照のこと。
一時停止した後、（一時停止を解除した時に）最新の表示へ移ることが、リアルタイム又は本来の「状態」にある情報にとってよりよいことである。例えば、気象レーダー、株価表示、交通情報カメラ、又はオークションのタイマーなどは、コンテンツ再開時に一時停止したことで古い情報が表示されると、誤った情報を提供してしまうことになる。
注記: コンテンツを非表示にすることは、一時停止した後、（一時停止を解除した時に）最新の表示へ移るのと同じ効果が得られる。

メカニズムが「利用者が一時停止するためのメカニズム」と判断されるためには、それが利用者に一時停止の手段として提供されつつも、利用者やフォーカスをそこに縛り付けてページが使用できなくなるようなものではない必要がある。ここでの「一時停止」という単語は「一時停止ボタン」という意味で使われているが、ボタンではないほかのメカニズムを使用することもできる。利用者がフォーカスしている時だけアニメーションが停止する(そしてフォーカスを解除し次第再開する)ようなものは、その過程でページが使い物にならなくするため「利用者が一時停止するためのメカニズム」とは判断されず、この達成基準も満たさないだろう。

注記: 「点滅」と「閃光」は、同じコンテンツを指すこともあることに注意することが重要である。

「点滅」は、利用者の注意を散漫にさせる問題を引き起こすコンテンツを指している。点滅は、それを停止する（又は停止させることができる）限り、短時間であれば許容することができる。
「閃光」は、（1秒間に3回よりも多く、大きさと明るさが十分な場合には）光過敏性発作を引き起こす恐れのあるコンテンツを指している。これは、光過敏性発作を引き起こす恐れがあるため、たとえ1秒間だけであったとしても許容されない。光過敏性発作は利用者が止める前に引き起こす恐れがあるため、閃光を止めることも選択肢にはならない。
通常、点滅は1秒間に3回以上の頻度では起こらないが、点滅を1秒間に3回以上の頻度で起こすこともできる。点滅が1秒間に3回以上の頻度で起こる場合には、それも閃光とみなされるであろう。

達成基準2.2.2の具体的なメリット

5秒後に点滅を停止するコンテンツを提供すること、又は利用者が点滅するコンテンツを停止できるメカニズムを提供することで、特定の障害のある利用者がウェブページと情報のやりとりをできるようになる。
点滅するコンテンツの一つの使い方は、そのコンテンツへ利用者の注意を引くことである。これは画面を見ているすべての利用者に対して効果的な達成方法ではあるが、点滅が続くとある利用者に対しては問題を引き起こす恐れがある。読み書き能力の低い利用者、読字障害及び知的障害のある利用者、及び注意力欠如障害のある利用者などにとっては、点滅するコンテンツは残りのウェブページとの情報のやりとりを困難にしたり、ときには不可能にしてしまうことがある。

達成基準 2.2.2の事例

利用者の行動に影響を与えずに一時停止できる基本的なアニメーション
あるウェブサイトは、プロセスを説明するアニメーションによって、利用者が「どのように機能するか」を理解するための手助けをしている。アニメーションには「一時停止」と「再開」のボタンがある。
株式相場表示機
株式相場表示機には、「一時停止」と「再開」のボタンがある。株式相場表示機を一時停止すると、現在表示している株価のところで一時停止する。再開すると、株式相場表示機は停止したところから再開するが、表示が遅れていることを示す注意書きが表示される。株式相場表示機の目的は、通常はリアルタイムの情報を提供することなので、株式相場表示機を最新の取引株価に進めるボタンもあるかもしれない。
利用者がリアルタイムで競い合うのではなく、交代で行うように設計されたゲーム
一つのグループが、ゲームの競争での形勢を無効にすることなく、ゲームを一時停止することができる。
ウェブ広告
広告は、閲覧者の注意を引くために点滅するが、5秒後に停止する。
フォームのプロンプト
フォームは、利用者がフォームへの記入を終えても送信ボタンを押下しないと、送信ボタンの近くにある矢印が点滅する。その点滅は5秒後に停止する。
アニメーション
アニメーションはページの上部で再生されるが、アニメーションの下側には「アニメーションを一時停止する」ボタンがある。
「読み込み中」のアニメーション
再生を開始するまでに大容量のファイルの何パーセントまでがダウンロードされたかを要求するページ上に、読み込み中であることを示すアニメーションが表示されている。ページ上のコンテンツはそのアニメーションだけで、映像を読み込んでいる間、利用者にしばらく待つ必要があることを知らせている。接続回線の遅い利用者に対してアニメーションが5秒以上再生されていたとしても、その動きのあるコンテンツは他のコンテンツと同時に表示されていないので、アニメーションを一時停止、停止、又は非表示にするメカニズムを提供する必要はない。
全面広告
サイトは、利用者がサイトで利用できる無料コンテンツにアクセスする前に、すべての利用者に15秒の広告を閲覧することを要求している。広告を閲覧することはすべての利用者に対する要求であり、他のコンテンツと同時に表示されていないので、広告を一時停止、停止、又は非表示にするメカニズムを提供する必要はない。

達成基準2.2.2の達成方法及び不適合事例 - 一時停止、停止、非表示

達成基準を満たすことのできる達成方法

2.2.2 でさらに対応が望まれる達成方法（参考）

ウェブページ内で点滅するすべてのコンテンツを止めるメカニズムを提供する（リンク追加予定）
5秒以内に自動的に止まるとしても、利用者が動きのあるコンテンツを止めるための手段を提供する。（リンク追加予定）

達成基準 2.2.2のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準2.2.2に適合していないとみなした、よくある不適合事例である。

重要な用語

一時停止 (paused): 利用者の要求により停止し、利用者の要求があるまで再開しない。
必要不可欠 (essential): もし取り除いてしまうと、コンテンツの情報あるいは機能を根本的に変えてしまい、かつ、適合する他の方法では情報及び機能を実現できない。
点滅 (blinking): 注意を引く意図で、二つの視覚的な状態を交互に切り替えること。
注記: 閃光も参照。ある程度の面積をもち、ある程度の明るさ、特定の頻度で点滅するものは、閃光に分類されることもありうる。

タイミング非依存:
達成基準 2.2.3 を理解する

2.2.3 タイミング非依存: タイミングは、コンテンツによって提示されるイベント又は動作の必要不可欠な部分ではない。ただし、インタラクティブではない同期したメディア及びリアルタイムのイベントは除く。 (レベル AAA)

この達成基準の意図

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

注記: 手話のような映像しか含まないコンテンツはガイドライン 1.1で取り上げられている。

達成基準2.2.3の具体的なメリット

身体障害のある利用者は、反応したり、入力したり、タスクを完了したりするのに、より長い時間を要することが多い。ロービジョンの利用者は、画面上で何かを探したり、読んだりするのに時間がかかる。全盲でスクリーンリーダーを使用している利用者は、画面のレイアウトを理解したり、情報を見つけたり、そしてコントロールを操作したりするのに時間がかかるかもしれない。認知能力の低下、又は言語の障害のある利用者は、読んだり、理解したりするのに時間がかかる。音声が聞こえなくて手話でコミュニケーションしている利用者は、（彼らにとっては第二言語のようなものかもしれない）テキストで書かれた情報を読むのに時間がかかるかもしれない。
手話通訳者が、デフの利用者に音声コンテンツを通訳しているような状況では、制限時間を制御できることも重要である。

達成基準 2.2.3の事例

試験を完了する時間が採点に影響しないように設計された試験
制限時間を用いてオンライン試験の結果を評価するのではなく、制限時間がないときの点数をもとに試験の結果を評価している。
利用者がリアルタイムで競い合うのではなく、交代で行うように設計されたゲーム
1つのグループが、ゲームの競争時の形勢を無効にすることなく、ゲームを一時停止することができる。

達成基準2.2.3の達成方法及び不適合事例 - タイミング非依存

達成基準を満たすことのできる達成方法

G5: 利用者が制限時間なしでタスクを完了できるようにする

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の具体的なメリット

注意力欠如障害のある利用者が、注意散漫にならずにコンテンツに集中できるようになる。
ロービジョンの利用者又はスクリーンリーダーを使用している利用者は、（ある話題を読み始め、別の話題で読み終わる場合、話の内容が支離滅裂になり、誤解をしてしまうような）コンテンツを閲覧している間はコンテンツが更新されない。

達成基準 2.2.4の事例

事例 1. 利用者設定
緊急時の警告を除き、ウェブポータルの設定ページは、現在のセッションが終了まで、すべての更新及び警告を延長する選択肢がある。

達成基準2.2.4の達成方法及び不適合事例 - 割り込み

達成基準を満たすことのできる達成方法

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の達成方法及び不適合事例 - 再認証

達成基準を満たすことのできる達成方法

次の実装技術の一つを使用することでデータを損うことなく継続することができる選択肢を提供する:
- G105: 利用者が再認証した後に利用できるようにデータを保存する
- G181: 利用者のデータを、再認証したページで非表示データ又は暗号化されたデータとしてエンコードする

注記: 制限時間について通知を提供することに関連した達成方法のための達成基準 2.2.1 の取組みのための達成方法を参照のこと。

2.2.5 でさらに対応が望まれる達成方法（参考）

(まだ文書化されていない)

達成基準 2.2.5のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準2.2.5に適合していないとみなした、よくある不適合事例である。

F12: 達成基準 2.2.5 の失敗例－利用者の入力を保存し再認証時にその情報を回復させるメカニズムがない状態で、セッションの制限時間がある

発作の防止:
ガイドライン2.3を理解する

ガイドライン2.3: 発作を引き起こすようなコンテンツを設計しないこと。

ガイドライン 2.3 の意図

光過敏性発作の疾患のある利用者は、閃光を放つ視覚的なコンテンツによって発作を引き起こす恐れがある。ほとんどの利用者は、発作が起こすまでは自分がこの疾患を持っていることに気づいていない。1997年に、日本でテレビのアニメ番組が700人以上の子どもたちを病院に搬送させる事態を招き、そのうち約500人が発作を引き起こした。利用者は警告をよく見逃すので、警告はあまり効果がない。特に、それを実際に読むことができない子どもに対してはそうである。

このガイドラインの意図は、WCAG 2.0 に適合しているとされるコンテンツが、1～2秒間であってもそれを見た利用者が発作を引き起こしそうな閃光の類を避けるようにすることである。

ガイドライン 2.3 の参考にすべき達成方法(特定の達成基準に特有ではない達成方法)

コンテンツは空間分布の閾値を超えないように注意する（リンク追加予定）

3回の閃光、又は閾値以下:
達成基準 2.3.1 を理解する

2.3.1 3回の閃光、又は閾値以下: ウェブページには、どの1秒間においても3回を超える閃光を放つものがない、又は閃光が一般閃光閾値及び赤色閃光閾値を下回っている。 (レベル A)
注記: この達成基準を満たさないコンテンツでは、利用者がそのウェブページ全体を使用できない恐れがあるため、ウェブページ上のすべてのコンテンツは他の達成基準を満たすために用いられているか否かにかかわらず、この達成基準を満たさなければならない。達成基準 5: 非干渉を参照。

この達成基準の意図

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

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

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

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

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

注記: 「点滅」と「閃光」は、同じコンテンツを指すこともある。

「点滅」は、利用者の注意を散漫にさせる問題を引き起こすコンテンツを指している。点滅は、それを停止する（又は停止させることができる）限り、短時間であれば許容することができる。
「閃光」は、（1秒間に3回よりも多く、大きさ及び明るさが十分な場合には）光過敏性発作を引き起こす恐れのあるコンテンツを指している。これは、光過敏性発作を引き起こす恐れがあるため、たとえ1秒間だけであったとしても許容されない。そして、光過敏性発作は利用者が閃光を止める前に引き起こす恐れがあるため、閃光を止めることも選択肢にはならない。
通常、点滅は1秒間に3回以上の頻度では起こらないが、そうすることもできる。点滅が1秒間に3回以上の頻度で起こる場合には、それも閃光とみなされるであろう。

達成基準2.3.1の具体的なメリット

閃光を放つコンテンツを閲覧しているときに光過敏性発作を起こす可能性のある利用者は、発作を起こすことなく、そして代替テキストでは限定されてしまうようなコンテンツの完全な体験を逃すことなく、サイト上のすべてのコンテンツを閲覧することが可能になる。これは、その他の光過敏性発作の疾患のある利用者と同様に、光過敏性てんかんのある利用者も含まれる。

達成基準 2.3.1の事例

ウェブサイトには、閃光を放つ機関銃の銃火の映像があるが、閃光を発する画像のサイズは閃光閾値のサイズを下回る画面のほんの一部に限定している。
とても明るい稲妻の閃光のシーンのある映画は、稲妻が任意の1秒間に3回だけ閃光を放つように編集されている。

達成基準2.3.1の達成方法及び不適合事例 - 3回の閃光、又は閾値以下

達成基準を満たすことのできる達成方法

2.3.1 でさらに対応が望まれる達成方法（参考）

閃光を放つあらゆるコンテンツに対してコントラストを下げる（リンク追加予定）
閃光を放つあらゆるコンテンツに対して赤色閃光閾値を完全に避ける（リンク追加予定）
閾値を超えていなかったとしても、閃光の数を減少させる（リンク追加予定）
閃光を放ち始める前に、閃光を放つあらゆるコンテンツを抑制するメカニズムを提供する（リンク追加予定）
（フラッシュバルブのような）素早い閃光を避けるためにライブの素材は速度を落とす（リンク追加予定）
1秒間に3回の閃光が検出される場合、一時的に画像を静止させる（リンク追加予定）
1秒間に3回の閃光が検出される場合、コントラスト比を落とす（リンク追加予定）
利用者が閃光の速度制限を任意に設定できるようにする（リンク追加予定）

達成基準 2.3.1のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準2.3.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ページなのかもしれない。

一般閃光閾値及び赤色閃光閾値 (general flash and red flash thresholds)

次のいずれかに該当していれば、連続した閃光、又は急速に変化する画像の連続は、閾値を下回っている (すなわち、コンテンツは基準を満たしている) ことになる:

あらゆる1秒間において、 一般閃光及び／又は赤色閃光 は3回以下である。もしくは、
一般的な閲覧距離で、同時に生じている閃光が占める領域の合計が、画面上のどの視野10度においても、合計0.006ステラジアン (画面上の視野10度の25％) よりも多くを占めていない。

ここで:

一般閃光とは、暗いほうの相対輝度が0.80未満であるときの、最大相対輝度の10%以上の相対輝度の交互の変化のことである。ここでいう「交互の変化」とは、増加した後に減少する、又は減少した後に増加するものを指す。そして、
赤色閃光とは、彩度の高い赤色を含んだ交互の遷移のことである。

例外: ホワイトノイズ又は1辺が (典型的な閲覧距離における視野の) 0.1度未満の市松模様のように、細かくて整っている模様の閃光は、閾値を超えることにはならない。

注記 1: 一般的なソフトウェアやウェブコンテンツでは、コンテンツを 1024 × 768 ピクセルの解像度で閲覧している際の画面上での 341 × 256 ピクセルの矩形が、標準的な画面サイズ及び画面からの距離 (例: 22～26インチの距離で、15～17インチの画面) における視野角10度に該当する (同じコンテンツでも高解像度のディスプレイでは小さく安全になるので、閾値を定めるには低解像度が用いられている)。

注記 2: 遷移とは、相対輝度 (赤色閃光の相対輝度/色) の計測値を時間軸でプロットしたときの隣接する山と谷の間における相対輝度 (赤色閃光の相対輝度/色) の変化である。閃光は、ひと組の逆方向の遷移から成る。

注記 3: 「彩度の高い赤色を含む相反する遷移の組合せ」の現時点での定義は、各遷移に含まれる状態の一方又は双方とも、R / (R＋G＋B) >= 0.8 で、(R－G－B) × 320 の値の変化が双方の遷移において 20 より大きい (ただし、(R－G－B) × 320 が負の値になるときはゼロとする)。R、G、B の値は、相対輝度の定義で定められているように 0～1 の範囲である。[HARDING-BINNIE]

注記 4: ビデオの画面キャプチャから分析を行うツールを利用できる。しかし、閃光があらゆる1秒間の間隔において3回以下であれば、ツールでこの条件を満たしているかどうかを確認する必要はない。コンテンツは自動的に条件を満たしたことになるからである (上記 1. 及び 2. を参照)。

閃光 (flash)

相対輝度の交互の変化で、ある程度の面積と特定の頻度によって、一部の人の発作を誘発する恐れがあるもの。

注記 1: 許容されない閃光の種類に関する情報は、一般閃光閾値及び赤色閃光閾値を参照。

注記 2: 点滅も参照。

3回の閃光:
達成基準 2.3.2 を理解する

2.3.2 3回の閃光: ウェブページには、どの1秒間においても3回を超える閃光を放つものがない。 (レベル AAA)

この達成基準の意図

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

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

注記: 場合によっては、WCAG ワーキンググループが「点滅」と称しているものと「閃光」と称しているものが、わずかに重なり合うことがあるかもしれない。この二つに対して異なる用語を用いているのは、「点滅」は利用者を注意散漫にさせる問題を引き起こすが、停止する（又は停止させることが可能である）限り、短い間であれば許容できるのに対して、「閃光」は発作を引き起こすものであり、許容できないものだからである。発作は、ほとんどの利用者が閃光をオフにすることができるのよりも早く起こるものである。そのため、「点滅」はゆっくりと繰り返す変化で、利用者が気を取られるものを指している。そして、「閃光」は十分に明るい又は十分に長く持続すると発作を引き起こす恐れのある変化を指している。通常、点滅は1秒間に3回以上の速度にはならないし、点滅と閃光が部分的に一致することもまずない。しかし、点滅が1秒間に3回以上の速度の場合には、部分的に一致することもありえる。点滅に関するより詳細な情報は、 達成基準2.2.2 一時停止、停止、非表示を理解するを参照のこと。

達成基準2.3.2の具体的なメリット

閃光を放つコンテンツを閲覧している際に光過敏性発作を起こす可能性のある利用者が、発作を起こすことなく、そして代替テキストでは限定されてしまうようなコンテンツの完全な体験を逃すことなく、サイト上のすべてのコンテンツを閲覧することが可能になる。これには、光過敏性てんかん及び光過敏性発作の疾患のある利用者も含まれる。

達成基準 2.3.2の事例

非常に明るい稲妻の閃光のシーンがある映画は、稲妻が任意の1秒間に3回しか閃光を放たないように編集されている。

達成基準2.3.2の達成方法及び不適合事例 - 3回の閃光

達成基準を満たすことのできる達成方法

G19: どの 1 秒間においても、コンテンツに 3 回よりも多く閃光を放つコンポーネントがないことを確認する

2.3.2 でさらに対応が望まれる達成方法（参考）

閃光を放つあらゆるコンテンツに対してコントラストを下げる（リンク追加予定）
閃光を放つあらゆるコンテンツに対して赤色閃光閾値を完全に避ける（リンク追加予定）
閾値を超えていなかったとしても、閃光の数を減少させる（リンク追加予定）
（フラッシュバルブのような）素早い閃光を避けるためにライブの素材は速度を落とす（リンク追加予定）
1秒間に3回の閃光が検出される場合、一時的に画像を静止させる（リンク追加予定）
1秒間に3回の閃光が検出される場合、コントラスト比を落とす（リンク追加予定）

達成基準 2.3.2のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準2.3.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ページなのかもしれない。
閃光 (flash): 相対輝度の交互の変化で、ある程度の面積と特定の頻度によって、一部の人の発作を誘発する恐れがあるもの。
注記 1: 許容されない閃光の種類に関する情報は、一般閃光閾値及び赤色閃光閾値を参照。
注記 2: 点滅も参照。

ナビゲーション可能:
ガイドライン2.4を理解する

ガイドライン2.4: 利用者がナビゲートしたり、コンテンツを探し出したり、現在位置を確認したりすることを手助けする手段を提供すること。

ガイドライン 2.4 の意図

このガイドラインの意図は、利用者が必要とするコンテンツを見つけるのを手助けして、自分の現在位置を確認し続けられるようにすることである。こういったタスクは、障害のある利用者にとってはより困難であることがしばしばである。発見、ナビゲーション及び位置確認において重要なのは、利用者が現在位置はどこなのかを確かめられることである。ナビゲーションにおいては、考えられうる行き先に関する情報を入手可能にする必要がある。スクリーンリーダーは、コンテンツを合成音声に変換するが、それは音声なので、合成音声は線形順序で提示されなければならない。このガイドラインにある達成基準では、スクリーンリーダーの利用者がコンテンツを無事にナビゲートできるようにするために、どの条項に対応する必要があるのかを説明しているものがある。また、利用者がより容易にナビゲーションバー及びページの見出しを認識できるようにして、そういった繰り返されているコンテンツを通過できるようにする達成基準もある。一般的ではないユーザインタフェースの機能又はふるまいは、認知の障害のある利用者を困惑させてしまうことがある。

Motive Web Design Glossaryで説明されているように、ナビゲーションには、主に2つの機能がある：

利用者に自分がどこにいるのかを知らせる
利用者が他のどこかへ行けるようにする

このガイドラインは、同様にナビゲーションの鍵を握り、コンテンツのあらゆる構造を知覚可能にするためのガイドライン 1.3 と密接に連動している。見出しは、利用者がコンテンツ内での自分の現在位置を確認して、ナビゲートしていく上で、特に重要なメカニズムである。情報を走り読みして、コンテンツの様々なセクションを容易に見つける際、支援技術の利用者の多くは適切な見出しを頼りにしている。見出しに関して、達成基準 1.3.1 に適合することは、同時にガイドライン 2.4 にも部分的に対処していることになる。

ガイドライン 2.4 の参考にすべき達成方法(特定の達成基準に特有ではない達成方法)

1ページあたりのリンクの数を限定する（リンク追加予定）
ウェブページのコンテンツの異なるセクションにナビゲートするメカニズムを提供する（リンク追加予定）
視覚的に異なるリンクを用いる（リンク追加予定）
検索ワードをハイライト表示する（リンク追加予定）

ブロックスキップ:
達成基準 2.4.1 を理解する

2.4.1 ブロックスキップ: 複数のウェブページ上で繰り返されているコンテンツのブロックをスキップするメカニズムが利用できる。 (レベル A)

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

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

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

注記: この達成基準は、複数のページ上で繰り返されているコンテンツのブロックを取り扱っているが、WCAG ワーキンググループは、達成基準 1.3.1 にあるように、個々のページで構造をマークアップすることも強く奨励する。

この達成基準は、「ウェブページ一式において」という語を用いていないものの、ひとまとまりに属するウェブページという考え方を示唆している。制作者は、「共通の目的を共有し、同じコンテンツ制作者、グループ、又は組織により制作されたウェブページの集合」（ウェブページ一式の定義）ではない、何かしら相互に関係のあるウェブページにおいて起こり得る、いかなるコンテンツの重複も避けることを求められてはいない。

注記: たとえひとまとまりに属さないウェブページであっても、同じページ中に繰り返されるテキストのブロックがあったとき、それらをスキップする手段を提供することは、有用かもしれない（必要というわけではない）。

この達成基準を満たしていないと、何らかの障害のある利用者がウェブページのメインコンテンツへ素早くかつ容易に到達するのが困難になることがある。
同じサイト上でいくつかのページを訪れるスクリーンリーダーの利用者が、メインコンテンツが読み上げられる前にある、どのページにもあるすべての見出しのグラフィック及びたくさんのナビゲーション・リンクを聞かなくてすむようになる。
キーボード又はキーボード・インタフェースだけを使用している利用者が、より少ないキーストロークだけでコンテンツに到達できるようになる。そうでなければ、メインコンテンツ部分にあるリンクに到達するまでにたくさんのキーストロークが必要になってしまうかもしれない。これには長い時間がかかってしまう恐れがあり、利用者によっては深刻な肉体的苦痛を伴うことがある。
画面拡大ソフトを使用している利用者が、新しいページへ来るたびに、どこからメインコンテンツが始まるのかを見つけようとして、同じ見出し又はその他の情報のブロックの中を探し回らなくてもすむようになる。
リンクがリストにまとめられていると、認知に制約のある利用者及びスクリーンリーダーを使用している利用者のためになることがある。

ニュースを配信する組織のホームページには、広告、検索、その他のサービスのためのたくさんのブロック及びサイドバーに囲まれて、ページの中央にメインの記事がある。ページの先頭に、そのメインの記事へジャンプするリンクがある。このリンクを使わないと、キーボードを使用している利用者は、メインの記事へ到達するまでに Tab キーを押下しながら40前後のリンクを通り抜ける必要があり、る。また、スクリーンリーダーの利用者は、200の単語を聞かなければならない。そして、画面拡大ソフトの利用者は、メインの記事の場所を探し回らなければならなくなる。

リソースは、情報提供のみを目的としており、推奨を意味するものではない。

次の達成方法の中から一つを用いて、繰り返されるブロックをスキップするリンクを作成する：
次の達成方法の中から一つを用いて、スキップ可能な方法で繰り返されるブロックをグループ化する：

重要なリンク及びフォーム制御へのキーボードアクセスを提供する（リンク追加予定）
ページナビゲーションに拡張したスキップリンクを提供する（リンク追加予定）
アクセスキーを提供する（リンク追加予定）
ユーザエージェント及び支援技術による構造化されたナビゲーションを与えるアクセシビリティサポート技術を使う（リンク追加予定）
C6: 構造を示すマークアップをした上で、コンテンツを配置する (CSS)

以下に挙げるものは、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.2 ページタイトル: ウェブページには、主題又は目的を説明したタイトルがある。 (レベル A)

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

ページが文書又はウェブアプリケーションの場合、文書又はウェブアプリケーションの名称はページの目的を説明するのに十分だろう。ここで注意すべきなのは、文書又はウェブアプリケーションの名称を使用することを求められていないことである。他の要素によってページの目的又は主題が説明される場合もあるだろう。

達成基準 2.4.4 及び 2.4.9 はリンクの目的を取り扱い、その多くはウェブページへのリンクである。ここでも、リンクされた文書又はウェブアプリケーションの名称がリンクの目的を説明するのに十分だろう。リンクとタイトルが一致する、又は非常に類似したものであることはよい習慣であり、「クリックされた」リンクと利用者が到達するウェブページとの間に連続性を与える。

この達成基準により、そのウェブページにある情報が自分のニーズに関係があるかどうかを、すべての利用者が素早くかつ容易に確認できるようになる。
視覚障害のある利用者が、複数のページが開いているとき、コンテンツを区別できるようになる。
認知の障害、短期記憶障害、及び読字障害のある利用者も、そのページタイトルでコンテンツを確認できるようになる。
この達成基準は、重度の運動障害があり、ウェブページ間を行き来するとき操作モードを音声に依存する利用者にも役立つ。

HTML のウェブページ
HTML で制作したウェブページの内容を示したタイトルが、ユーザエージェントのタイトルバーに表示されるように、title 要素でマークアップされている。
文書
訳注： 以下、英文原文例をそのまま日本語にした。英文では2005年のWCAGドラフト（英語）が参考にされた模様。
WCAG 2.0 解説書のページタイトルが、「ウェブコンテンツアクセシビリティガイドライン 2.0」となっている。
- 主要なページのページタイトルが、「ガイドライン X を理解する」や「達成基準 X を理解する」となっている。
- ドキュメントのページタイトルが、「WCAG 2.0 ガイドライン」となっている。
- 附録 A のページタイトルが、「用語集」となっている。
- 附録 B のページタイトルが、「謝辞」となっている。
- 附録 C のページタイトルが、「参考文献」となっている。
ウェブアプリケーション
あるインターネット銀行のアプリケーションでは、利用者が自分の銀行口座をチェックしたり、過去の明細を確認したり、振込をしたりすることができる。そのウェブアプリケーションは、ウェブページごとにページタイトルを動的に生成している。例えば、「ジョン・スミスさんの講座： XYZ 銀行」、「口座番号 1234-5678 の取引明細－ 2005年12月： XYZ 銀行」などである。

リソースは、情報提供のみを目的としており、推奨を意味するものではない。

Writing Better Web Page Titles How to write titles for Web pages that will enhance search engine effectiveness.
Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen Readers. Theofanos, M.F., and Redish, J. (2003). Interactions, Volume X, Issue 6, November-December 2003, pages 38-51, http://dl.acm.org/citation.cfm?doid=947226.947227

G88: ウェブページに対して、コンテンツの内容が分かるページタイトルを提供する、かつ、後述のテクニックの一つを使ってウェブページにタイトルを結びつける：
- H25: title 要素を用いて、ページタイトルを提供する (HTML)
- PDF18: PDF 文書の文書情報辞書内の Title エントリを使用して文書のタイトルを指定する (PDF)

G127: 技術特有の達成方法を用いて、そのウェブページとその他の多くのウェブページとの関係を示す
ウェブページの主題を特定する（リンク追加予定）
フレームを特定するため意味のある名前を提供する（リンク追加予定）
ウェブページに一意なタイトルを使う（リンク追加予定）
説明的な内容を説明したトップレベルページの見出しを提供する（リンク追加予定）

以下に挙げるものは、WCAG ワーキンググループが達成基準2.4.2に適合していないとみなした、よくある不適合事例である。

F25: 達成基準 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つは提供される必要がある。

これらの達成方法は、コンテンツ内を順番に行き来していて、フォーカス順序が音声読み上げ順序と一致しているものと考えている、キーボードの利用者の役に立つ。

論理的で、使いやすいフォーカス順序は、ページの操作をキーボード使用に依存している運動障害のある利用者の役に立つ。
字を読むのが困難な障害のある利用者は、Tab キーを押下してフォーカスが予期しないどこかへ移動してしまうと、迷子のようになってしまう恐れがある。彼らは論理的なフォーカス順序の恩恵を受けている。
視覚障害のある利用者は、Tab キーを押下してフォーカスが予期しないどこかへ移動してしまったり、インタラクティブな要素に囲まれているコンテンツを容易に見つけることができなかったりすると、迷子のようになってしまう恐れがある。
画面拡大ソフトを使用していて、拡大率を高くしている利用者には、ページのごく小さい一部分だけしか見えないことがある。そのような利用者は、フォーカス順序が論理的でないと、誤った文脈でコンテンツの一部分を解釈してしまう恐れがある。

インタラクティブなコントロールのツリーがあるウェブページ上で、利用者は上下の矢印キーを使って、ツリーのノードからノードへと移動することができる。右向き矢印キーを押下するとノードを展開して、それから下矢印キーを押下すると新しく展開されたノードへと移動していく。
あるウェブページは、スクリプトでモードレス・ダイアログ（ダイアログボックスを閉じなくても作業が続行できるタイプのダイアログボックス）を実装している。起動ボタンを押下すると、ダイアログが開く。ダイアログ内にあるインタラクティブな要素が、起動ボタンのすぐ後のフォーカス順序の位置に挿入される。ダイアログが開いているときには、フォーカス順序は、その起動ボタンからダイアログ内の要素へ移動し、それから起動ボタンの後にあるインタラクティブな要素へと移動する。ダイアログが閉じているときは、フォーカス順序は起動ボタンからその次に続いている要素へ移動する。
あるウェブページは、スクリプトでモーダル・ダイアログ（ダイアログボックスの中だけで強制的に作業をさせるダイアログボックスで、それが閉じられない限り作業の続行ができない）を実装している。起動ボタンを押下すると、ダイアログが開き、そのダイアログにある最初のインタラクティブな要素にフォーカスがあたる。ダイアログが開いている限り、フォーカスはダイアログ内の要素だけに限定される。ダイアログが閉じられると、フォーカスはボタン又はボタンの次にある要素へ戻る。
HTML で制作されたウェブページには、左側にナビゲーションがある。そのナビゲーションは、HTML ではメインコンテンツの後にあり、CSS を用いてページの左側に表示されるように指定されている。tabindex 属性又はJavaScriptを用いずに、フォーカスがメインコンテンツへ移動できるようにするためである。
注記: この事例は達成基準を満たしているが、必ずしもすべての CSS による配置が当てはまるとはかぎらない。配置が複雑な例では、意味及び操作性を保持できることもあれば、できないこともある。
次の例は、この達成基準を満たさない：
ある企業のウェブサイトに、マーケティングデータを収集するフォームがあり、利用者がその企業の発行するいくつかのニュースレターに登録できるようになっている。マーケティングデータを収集するためのフォームのセクションには、氏名、郵便番号、県、市町村、番地などのテキストフィールドがある。フォームのその他のセクションには、利用者が配信してほしいニュースレターを指定することができるようにいくつかのチェックボックスがある。しかし、そのフォームのタブ移動順序は、フォームにおける異なるセクションのフィールドを行ったり来たりする。そのため、フォーカスは、氏名のテキストフィールドからあるチェックボックスへ、次に番地のテキストフィールドへ、そしてまた別のチェックボックスへというふうに移動してしまう。

リソースは、情報提供のみを目的としており、推奨を意味するものではない。

(今のところ、文書化されていない)

G59: コンテンツ内の順番及び関係に従った順序で、インタラクティブな要素を配置する
次の達成方法の一つを用いて、コンテンツ内の順序及び関係性に従った順序でフォーカスを要素に与える：
次の達成方法の一つを用いて、ウェブページを動的に変化させる：

キーボードフォーカスを受け取ったリンクもしくはコントロールが、強調され非常に目立つメカニズムを提供する（リンク追加予定）
代替となるプレゼンテーション順序を作り出す（リンク追加予定）

以下に挙げるものは、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 を理解する

2.4.4 リンクの目的 (コンテキスト内) : それぞれのリンクの目的が、リンクのテキスト単独で、又はリンクのテキストとプログラムによる解釈が可能なリンクのコンテキストから判断できる。ただし、リンクの目的がほとんどの利用者にとって曖昧な場合は除く。 (レベル A)

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

リンクのテキスト又はリンクに関連付けられたテキストは、リンクの目的を説明することを意図している。リンクが文書又はウェブアプリケーションに遷移する場合、その文書又はウェブアプリケーションの名称は、（その文書又はウェブアプリケーションへ遷移する）リンクの目的を説明するのに十分だろう。ここで注意すべきなのは、文書又はウェブアプリケーションの名称の使用が必要とされないことである。他のものがリンクの目的を説明する場合もあるだろう。

達成基準 2.4.2 は、ページのタイトルを取り扱っている。ここでも、ページに表示されている、文書又はウェブアプリケーションの名称は、ページの目的を説明するのに十分だろう。リンクとタイトルが一致する、又は非常に類似したものであることはよい習慣であり、「クリックされた」リンクと利用者が到達するウェブページとの間に連続性を与える。

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

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

同じ宛先のリンクには一貫した説明があることがベストプラクティスとなる（これは、達成基準 3.2.4によるセットでページの要件である）。さまざまな目的や目的地を持つリンクが異なる記述を持つこともベストプラクティスとなる。

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

注記: リンクの目的が未知のものである又は隠されているというのが当然であるという状況もありえる。例えば、ゲームにはドア 1、ドア 2、そしてドア 3とだけしか示されていないリンクがある可能性もある。こういう場合は、リンクの目的がすべての利用者をドキドキさせることなので、それらはリンクテキストとして十分であると考えてよい。

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

この達成基準により、運動障害のある利用者が、リンク先のコンテンツへ行って、また元へ戻ってくるという無駄なキーストロークなしに、必要のないリンクをスキップすることができるようになる。
認知に制約のある利用者が必要のないコンテンツへ行ったり来たりして現在位置を見失う、ということがなくなる。
視覚障害のある利用者が、リンクの文脈を探ることによって、リンクの目的を判断できるようになる。

リンクがリンク先の URI にある情報を説明するテキストを含んでいる
あるページに、「中世の歴史には大量の虐殺があった」という文がある。そして、「中世の歴史」がリンクである。
リンクの前にリンク先の URI にある情報を説明するテキストがある
あるページに、「アイルランド政府の電子選挙委員会に関する詳細を『投票に行こう！』で見る」という文がある。そして、「投票に行こう！」がリンクである。
アイコンとテキストの両方が同じリンク内にある
自動投票機のアイコンと「アイルランド政府の電子選挙委員会」というテキストが、一つのリンクになっている。リンクの目的がアイコンの隣にあるリンクのテキストで説明されているので、そのアイコンの代替テキストは空である。
書籍名のリスト
リストにある書籍が、HTML、PDF、そして mp3（人が本を読み上げているの音声を録音したもの）の3つのフォーマットで利用可能である。各書籍のタイトルを3回（フォーマットごとに1回）聞かないですむように、各書籍の最初のリンクが書籍のタイトルで、2つめのリンクは「PDF」、3つめのリンクは「mp3」となっている。
ニュース記事の要約
あるウェブサイトに、ニュース記事が集められている。メインページでは、各記事の最初の部分が少しだけあって、その後に「続きを読む」というリンクがある。スクリーンリーダーでは、現在の段落を読むためのコマンドによって、リンクの目的を解釈するための文脈が得られる。

リソースは、情報提供のみを目的としており、推奨を意味するものではない。

G91: リンクの目的を説明したリンクテキストを提供する
H30: a 要素のリンクの目的を説明するリンクテキストを提供する (HTML)
H24: イメージマップの area 要素に代替テキストを提供する (HTML)
FLASH27: ボタンの目的を説明するラベルを提供する (Flash)
次に挙げる達成方法の一つを用いて、利用者が簡潔なリンクテキスト又は長いリンクテキストを選べるようにする：
G53: リンクテキストとそれが含まれている文章中のテキストとを組み合わせて、リンクの目的を特定する
次に挙げる達成方法の一つを用いて、リンクの目的の説明を補足する：
- H33: title 属性を用いて、リンクテキストの文言を補足する (HTML)
- C7: リンクテキストの一部を非表示にするために、CSS を使用する (CSS)
次に挙げる達成方法の一つを用いて、プログラムで判断されるリンクの文脈と一緒にリンクの目的を特定する：
G91: リンクの目的を説明したリンクテキストを提供するかつ次の達成方法の一つを用いてセマンティックにリンクを示す：

以下に挙げるものは、WCAG ワーキンググループが達成基準2.4.4に適合していないとみなした、よくある不適合事例である。

ほとんどの利用者にとって曖昧 (ambiguous to users in general): リンク、及びリンクと同時に利用者に提供されているウェブページのどの情報からも、そのリンクの目的を判断できない (すなわち、障害がない閲覧者でも、そのリンクを動作させるまで、そのリンクが何をするのか分からない)。
事例: 「注目すべき輸出品のひとつはグァバです」という文中にある「グァバ」という単語がリンクになっている。そのリンク先は、グァバの定義、グァバの輸出量を挙げる図表、又はグァバを収穫している人々の写真のいずれにもなり得る。リンクを動作させるまで、すべての利用者が確信を持てないため、障害のある人が不利な立場に置かれることはない。
プログラムによる解釈が可能なリンクのコンテキスト (programmatically determined link context): リンクとの関係性からプログラムによる解釈が可能であり、リンクテキストと結びつけることができ、様々な感覚モダリティで利用者に提示することができる付加的情報。
事例: HTMLでは、英語で記述されたリンクからプログラムによる解釈が可能な情報には、そのリンクと同じ段落、リスト、又はテーブルのセルにあるテキスト、あるいはリンクのあるテーブルのセルと関連付けられたテーブルの見出しセルにあるテキストなどがある。
注記: スクリーンリーダーは句読点を解釈するので、フォーカスが文中のリンクにある場合は、その文からコンテキストを提供することも可能である。
リンクの目的 (link purpose): ハイパーリンクを動作させたときに得られる結果の本質。

複数の手段:
達成基準 2.4.5 を理解する

2.4.5 複数の手段: ウェブページ一式の中で、あるウェブページを見つける複数の手段が利用できる。ただし、ウェブページが一連のプロセスの中の1ステップ又は結果である場合は除く。 (レベル AA)

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

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

サイトをナビゲートする手段を複数提供することによって、利用者が情報をより早く見つけることができるようになる。視覚障害のある利用者は、画面拡大ソフト又はスクリーンリーダーを用いながら長いナビゲーションバーからを使って探していくよりも、検索機能を使用してサイト内の適切な部分へナビゲートしていくほうが容易なことがある。認知の障害のある利用者は、いくつものウェブページを読んだり行き来したりするよりも、サイト全体を見渡すことのできる目次又はサイトマップを好むことがある。中には、サイトのコンセプトやレイアウトを最もよく理解できるように、ウェブページからウェブページへと順番に移動しながらサイト内を探索するのを好む利用者もいるかもしれない。
認知に制約のある利用者は、階層構造を用いたナビゲーション・スキームは分かりづらいことがあるため、検索機能を使うほうがより容易なことがある。

検索メカニズム
大手の食品加工企業のサイトには、その製品を用いたレシピがある。そのサイトは、特定の食材を使ったレシピを検索できる検索メカニズムを提供している。あらに、食品のいろいろなカテゴリを挙げたリストボックスも提供している。その企業のスープ製品から作るレシピの一覧があるページへ行くためには、利用者は検索のキーワードに「スープ」と入力してもよいし、又はリストボックスから「スープ」を選択してもよい、その企業のスープ製品から作るレシピの一覧があるページへ行くことができる。
ウェブページ間のリンク
あるヘアサロンが、サービスを宣伝するためにウェブサイトを制作した。そのサイトは5ページしかない。各ページには、ウェブページ間を順に前後へ移動できるリンクがある。さらに、各ウェブページには、その他のウェブページへ移動するリンクの一覧がある。
コンテンツがプロセス又はタスクの結果である場合 - 送金確認
あるオンライン銀行サイトでは、ウェブを通じて口座間の送金ができる。口座の名義人が送金を完了する以外には、送金確認ページを見つける方法はない。
コンテンツがプロセス又はタスクの結果である場合 - 検索エンジンの検索結果
ある検索エンジンが、利用者の入力に応じた検索結果を提供している。その検索プロセスを行う以外に、その検索結果ページを見つける方法はない。

リソースは、情報提供のみを目的としており、推奨を意味するものではない。

(今のところ、文書化されていない)

次の達成方法のうち2つ以上を用いる：

H59: link 要素及びナビゲーションツールを使用する (HTML)
コンテンツ及びコンセプトマップの表にプレゼンテーションモードについての情報を含める（リンク追加予定）

以下に挙げるものは、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 情報及び関係性を理解するを達成してなければならない。

分かりやすい見出しは、読む速度が遅くなる障害のある利用者及び短期記憶に制約のある利用者に特に役立つ。そのような利用者にとっては、それぞれのセクションの内容を予測できるようにセクションの見出しが記述されていると役立つ。
求めているコンテンツへたどりつくまでに必要なキーストローク数を減少することが、手を使いづらい利用者又は手を使うことに苦痛を伴う利用者に役立つ。
この達成基準は、例えば目次のように、前後に関係なく、ラベル及び見出しだけを読み上げたとき、又はページ内の見出しから見出しへ移動したときに、ラベル及び見出しが分かりやすいようにすると、スクリーンリーダーを使用している利用者に役立つ。
また、この達成基準は、一度にほんの少しの単語しか見ることのできない、ロービジョンの利用者にも役立つ。

ニュースサイト
ニュースサイトのホームに、その時間帯のトップニュースの見出しが並んでいる。それぞれの見出しの下には、記事の冒頭の35ワードと、記事の全文へのリンクがある。そして、見出しはどれも、記事の主題を明快に伝えている。
上手な文章の書き方ガイド
文章の書き方に関するガイドに、次のようなセクション見出しがある。「上手な文章の書き方」、「無駄な語句を取り除く」、「不要な語句を見つけ出す」、などである。これらのセクション見出しは明快かつ簡潔で、情報の構造が見出しの構造にも反映されている。
様々な記事での一貫した見出し
ウェブサイトには、ある学会の会議での論文が掲載されている。その学会の会議への投稿する論文は、次のような構成とすることが必須となっている：　要約、イントロダクション、（その論文に固有なその他のセクション）、結論、筆者略歴、用語集、そして参考文献。そうして、論文の独自性とセクション見出しの一貫性とのバランスをうまくとりながら、各ウェブページのタイトルはそのページにある論文をはっきりと特定している。
利用者に氏名を要求するフォーム
利用者に氏名を要求するフォーム。姓と名を要求する二つのテキストフィールドから成る。最初のフィールドは「姓」、次のフィールドは「名」とラベルづけされる。

リソースは、情報提供のみを目的としており、推奨を意味するものではない。

How Users Read on the Web A study showing that most users scan Web pages rather than reading them word by word.
Applying Writing Guidelines to Web Pages A report on the effects of making Web sites concise, easy to scan, and objective.

注記: 達成基準 1.3.1 により、見出し及びラベルは、プログラムで判断できなければならない。

ウェブページに一意なセクション見出しを用いる（リンク追加予定）
一意な情報からセクション見出しをはじめる（リンク追加予定）

以下に挙げるものは、WCAG ワーキンググループが達成基準2.4.6に適合していないとみなした、よくある不適合事例である。

(今のところ、文書化されている不適合事例がない)

ラベル (label): テキスト、又はテキストによる代替を伴うコンポーネントで、ウェブコンテンツ内のコンポーネントを識別するために利用者に提示されているもの。
注記 1: 名前 (name) は隠されていて支援技術に対してだけ明らかにされる場合がある一方で、ラベルはすべての利用者に提示される。多くの場合 (すべてではないが)、名前 (name) とラベルは同じである。
注記 2: ラベルという用語は、HTML における label 要素だけに限定されない。

フォーカスの可視化:
達成基準 2.4.7 を理解する

2.4.7 フォーカスの可視化: キーボード操作が可能なあらゆるユーザインタフェースには、フォーカスインジケータが見える操作モードがある。 (レベル AA)

この達成基準の意図は、キーボードフォーカスを持っている要素を利用者が認識しやすくすることである。

この達成基準の意図は、複数の要素のうち、どの要素がキーボードフォーカスを持っているか利用者が認識しやすくすることである。スクリーン上にキーボード操作可能な要素が1つだけある場合には、視覚的にはキーボード操作可能な要素を1つだけ提示するため、達成基準が満たされることになる。

注記: キーボードのフォーカスインジケータは異なる形態をとることができる点に注意すべきである。一般的な方法の1つとして、テキストフィールドがキーボードフォーカスを持っていることを示すための、テキストフィールド内のキャレット表示がある。別の方法としては、ボタンがキーボードフォーカスを持っていることを示すために、ボタンを視覚的に変化させるといった方法がある。

キーボードだけでそのページを操作している利用者が、キーボードで操作しているコンポーネントを視覚的に常時確認できるようになる。
注意力欠如、短期記憶の制約、又は遂行機能における制限のある利用者が、フォーカスがどこにあるのかを見つけることができるようになる。

テキストフィールドがフォーカスを受け取ると、縦の棒がテキストフィールド内に表示されて、利用者がテキストを挿入入力できることを示す。もしくは、すべてのテキストがハイライト表示され、利用者がそのテキストを上書きできることを示す。
ユーザインタフェースのコントロールがフォーカスを受け取ると、その周りに視覚的に認識できる枠線が表示される。

リソースは、情報提供のみを目的としており、推奨を意味するものではない。

Styling form controls with CSS, revisited

リンクもしくはコントロールのそばにマウスが来たとき強調する（リンク追加予定）
キーボードフォーカスを受け取ったときリンクもしくはコントロールが強調され非常に目立つメカニズムを提供する（リンク追加予定）

以下に挙げるものは、WCAG ワーキンググループが達成基準2.4.7に適合していないとみなした、よくある不適合事例である。

現在位置:
達成基準 2.4.8 を理解する

2.4.8 現在位置: ウェブページ一式の中での利用者の位置に関する情報が利用できる。 (レベル AAA)

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

この達成基準は、あるウェブページへたどり着くまでに幾つもの段階を経てナビゲートしているうちに困惑してしまう、集中力の続かない利用者に役立つ。また、利用者がリンクで深い階層にあるページへ直接移動した際に、そのページのコンテンツを理解したり、関連するその他の情報を探したりするために、そのウェブサイト内を行き来する必要があるときなどにも役立つ。

利用者がサイト内での自分の現在位置を確認しやすくするリンク
ある大学の教育学部に研究会がある。研究会のウェブサイトのホームには、学部のウェブサイトのホーム及び大学のウェブサイトのホームへのリンクがある。
パンくずリスト
ポータルウェブサイトは、トピックをカテゴリごとに整理している。利用者がカテゴリ及びサブカテゴリ内を行き来していると、パンくずリストがカテゴリの階層における現在位置を示してくれる。また、各ページには、ポータルのホームへのリンクもある。

リソースは、情報提供のみを目的としており、推奨を意味するものではない。

The Sound of the Accessible Title Tag Separator

G65: パンくずリストを提供する
G63: サイトマップを提供する
G128: ナビゲーションバー内で現在位置を示す
次に挙げる達成方法の一つを用いて、G127: 技術特有の達成方法を用いて、そのウェブページとその他の多くのウェブページとの関係を示す
- H59: link 要素及びナビゲーションツールを使用する (HTML)

PDF14: PDF 文書内に連続するヘッダとフッタを提供する (PDF)
PDF17: PDF 文書に一貫性のあるページ番号を指定する (PDF)
HOMEページもしくは主要なページへのリンクを提供する（リンク追加予定）
ウェブページの集合の編成について読みやすいバージョンの情報を提供する（リンク追加予定）
ウェブページの集合の編成について手話バージョンの情報を提供する（リンク追加予定）（リンク追加予定）
コンテンツの各セクションの最初に読みやすい概要を提供する（リンク追加予定）

以下に挙げるものは、WCAG ワーキンググループが達成基準2.4.8に適合していないとみなした、よくある不適合事例である。

(今のところ、文書化されている不適合事例がない)

ウェブページ一式 (set of Web pages): 共通の目的を共有し、同じコンテンツ制作者、グループ、又は組織により制作されたウェブページの集合。
注記: 他言語版は、異なるウェブページ一式と見なされることもある。

リンクの目的 (リンクのみ) :
達成基準 2.4.9 を理解する

2.4.9 リンクの目的 (リンクのみ) : それぞれのリンクの目的を、リンクのテキスト単独で特定できるメカニズムが利用できる。ただし、リンクの目的がほとんどの利用者にとって曖昧な場合は除く。 (レベル AAA)

この達成基準の意図は、利用者がコンテンツ内にある各リンクの目的を理解するのを手助けすることで、彼らはそれを辿ることを望むかどうかを、彼らが決めることができる（同じ機能を持っているコンポーネントの識別に一貫性を求めるための達成基準 3.2.4 も見よ）。リンクの目的は、そのリンクテキストから識別されることができるので、ユーザエージェントが、ページ上にある全てのリンクの一覧を提供するときのように、リンクは、それらが文脈の中にあるとき、理解することができる。

リンク内のテキストは、リンクの目的を説明するように意図されている。リンクが、文書又はウェブアプリケーションの一つへ導く場合は、文書またはウェブアプリケーションの名前は、（文書またはウェブアプリケーションにあなたを導く）リンクの目的を説明するのに十分であろう。文書又はウェブアプリケーションの名前を使用する必要がないことに注意されたい。他のものが、リンクの目的を説明することもできる。

達成基準 2.4.2は、ページのタイトルに取り組んでいる。ここでもまた、ページに表示されている文書とウェブアプリケーションの名前は、ページの目的を説明するのに十分であろう。リンクとタイトルが一致する又はとても似ていることは、良い習慣であり、リンクの「クリック」と利用者が着地するウェブページ間の継続性を提供する。

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

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

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

運動障害のある利用者が、関心のないウェブページをスキップできるようになり、関係のないページへ行ってからまた元のページの戻ってくるような無駄なキーストロークを避けることができるようになる。
認知に制約のある利用者が必要のないコンテンツへ行ったり来たりして現在位置を見失う、ということがなくなる。
視覚障害のある利用者は、元のページに戻ってきたときコンテンツのその場所が分からなくなる、ということがなくなり恩恵を受ける。そして、リンク先が説明されているので、情報を探す上で、スクリーンリーダーのリンク一覧がより有益になる。

アイコンとテキストの両方が同じリンク内にある
自動投票機のアイコンと「アイルランド政府の電子選挙委員会」というテキストが、一つのリンクになっている。
書籍名のリスト
リストにある書籍が、HTML、PDF、そして mp3（人が本を読み上げているのを録音したもの）の3つのフォーマットで利用可能である。書籍のタイトルの後に、様々なフォーマットへのリンクがある。例えば、描画されるリンクテキストにはフォーマット名しかないが、それぞれのリンクに関連付けられているテキストには、例えば「ガリバー旅行記　MP3版」というように、書籍のタイトルとフォーマットの両方がある。

リソースは、情報提供のみを目的としており、推奨を意味するものではない。

ARIA8: リンクの目的を示すために aria-label を使用する (ARIA)
G91: リンクの目的を説明したリンクテキストを提供する
H30: a 要素のリンクの目的を説明するリンクテキストを提供する (HTML)
H24: イメージマップの area 要素に代替テキストを提供する (HTML)
FLASH27: ボタンの目的を説明するラベルを提供する (Flash)
次の達成方法の一つを用いて、利用者が短めのリンクテキスト又は長めのリンクテキストを選べるようにする:
次の達成方法の一つを用いて、リンクの目的を補足説明する:
- C7: リンクテキストの一部を非表示にするために、CSS を使用する (CSS)
次の達成方法の一つを用いて、セマンティックにリンクを示す:

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

全盲の利用者が、ウェブページのあるセクションからいつ別のセクションへ移動したのかが分かるようになり、各セクションの目的が分かるようになる。
何らかの学習障害のある利用者が、見出しを使うことによって、ページ全体のコンテンツの構造をより容易に理解できるようになる。
キーボードでコンテンツをナビゲートしている利用者が、フォーカスを見出しから見出しへとジャンプできるようになり、関心のあるコンテンツを素早く見つけることができるようになる。
一部のコンテンツを更新したページでは、見出しを使うことによって、更新したコンテンツへ素早く到達できるようになる。

メニューに様々なコース料理の様々なセクションがある。各セクションには、前菜、サラダ、スープ、メイン料理、デザートという見出しがある。
あるウェブアプリケーションには、設定ページがあり、関連する設定ごとのグループに分けられている。各セクションには各グループを説明する見出しがある。

リソースは、情報提供のみを目的としており、推奨を意味するものではない。

ライブリージョンを特定する'live'プロパティを使う（リンク追加予定）(ARIA)
ウェブページのコンテンツの異なるセクションにナビゲートするメカニズムを提供する（リンク追加予定）

以下に挙げるものは、WCAG ワーキンググループが達成基準2.4.10に適合していないとみなした、よくある不適合事例である。

(今のところ、文書化されている不適合事例がない)

セクション (section): 一つ以上の関連する話題、又は考えについて書かれたコンテンツの自己完結している部分。
注記: セクションは一つ以上の段落から成ることがあり、画像、表、リスト、及びサブセクションを含むこともある。
ユーザインタフェースコンポーネント (user interface component): コンテンツの一部分で、特定の機能を実現するための単一のコントロールとして利用者が知覚するもの。
注記 1: 複数のユーザインタフェースコンポーネントが、単一のプログラム要素で実装されることもある。ここでいうコンポーネントは、プログラムの手法と結びついたものではなく、利用者が別々のコントロールとして知覚するものを指す。
注記 2: ユーザインタフェースコンポーネントには、フォーム要素、リンクだけでなく、スクリプトで生成されるコンポーネントが含まれる。
事例: アプレットには、コンテンツ内を行単位、ページ単位、又はランダムアクセスで移動するために用いられる「コントロール」がある。これらには、いずれも名前 (name) を割り当て、個別に設定できるようにする必要があるため、それぞれが「ユーザインタフェースコンポーネント」となる。

読みやすさ:
ガイドライン3.1を理解する

ガイドライン3.1: テキストのコンテンツを読みやすく理解可能にすること。

ガイドライン 3.1 の意図

このガイドラインの意図は、利用者及び支援技術がテキストのコンテンツを読めるようにすること、そして理解するのに必要な情報を提供することである。

障害のある利用者は、テキストを様々な方法で利用している。ある利用者はテキストを視覚的に利用していたり、また聴覚的に利用していたり、あるいは触覚的に利用していたり、それ以外にも視覚と聴覚両方で利用していたりもする。書かれた文章を理解するのは困難であっても、そのテキストが音声で読み上げられたり、重要なプロセスや考えが図画によって視覚的に示されていたり、手話で通訳されていたりすると、かなり複雑で高度な内容の文書でも理解することができる利用者もいる。また、利用者によっては、前後の文脈から単語又は語句の意味を推察するのが困難なことがある。特に、その単語又は語句が一般的ではない方法で用いられていたり、特別な意味を持たせられていたりするときには困難である。そういった利用者の読解力及び理解力は、特定の定義又は頭字語あるいは略語の元の語句が参照可能かどうかにより変わってくる。ユーザエージェントは、音声読み上げソフト及びグラフィカルなアプリケーションを含めて、テキストの言語及び文字を書く方向が示されていないと、テキストを正しく提示できないことがある。ほとんどの利用者にとっては大した問題にはならないかもしれないが、障害のある利用者にとっては非常に大きな障壁となりえる。（例えば、日本語の特定の漢字など）発音に関する情報がないと言葉の意味が判断できないような場合、発音（読み）に関する情報も提供しなければならない。

ガイドライン 3.1 の参考にすべき達成方法(特定の達成基準に特有ではない達成方法)

ページ中のコンテンツのうち、制作者が制御できないソースに基づくものについて、そのコンテンツに関する情報を提供する（リンク追加予定）
すべてのコンテンツは、手話による通訳を提供する（リンク追加予定）
そのコンテンツに対して適切な、最も明解で単純な表現を用いる（リンク追加予定）
テキストの中寄せを行わない（リンク追加予定）
単語間やも文字間の空白に影響を与える、テキストの均等割り付けを行わない（リンク追加予定）
テキストは、左から右へ書く原語においては左寄せし、右から左へ書く原語においては右寄せする（リンク追加予定）
テキストのコラム幅を制限する（リンク追加予定）
部分的なイタリック体を用いない（リンク追加予定）
個別のページ及びサイトの中で用いるスタイルの種類を増やしすぎない（リンク追加予定）
リンクは、他のテキストと視覚的に区別できるようにする（リンク追加予定）
画像、イラスト、動画、音声、シンボルなどを用いてコンテンツの意味を明確にする（リンク追加予定）
現実的な例を示して、コンテンツの意味を明確にする（リンク追加予定）
黒のテキストに白の背景色を用いるのではなく、明るいパステル・カラーを背景色に用いる（リンク追加予定）
必要性がない特殊なインタフェース・コントロールを用いない（リンク追加予定）
その原語におけるスペリングの規則に従って、適切な形で大文字と小文字を使い分ける（リンク追加予定）
一般的ではない外来語の使用を避ける（リンク追加予定）
コンテンツを利用する上で理解する必要がある情報、考え方、操作手順の手話版を提供する（リンク追加予定）
ウェブページ上の特定の場所を参照している場合、その場所へのリンクを提供する（リンク追加予定）
見出しやタイトルを参照する場合、完全なタイトルを含むようにする（リンク追加予定）
管理者への連絡方法を含む、ウェブページ一式に関する基本的な情報について、容易に読めるバージョンを提供する（リンク追加予定）
管理者への連絡方法を含む、ウェブページ一式に関する基本的な情報について、手話バージョンを提供する（リンク追加予定）

ページの言語:
達成基準 3.1.1 を理解する

3.1.1 ページの言語: それぞれのウェブページのデフォルトの自然言語がどの言語であるか、プログラムによる解釈が可能である。 (レベル A)

この達成基準の意図

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

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

注記: 適合レベル A を目指している多言語サイトについて、WCAG ワーキンググループはコンテンツ制作者に、レベル AA の達成基準ではあるが、達成基準 3.1.2 にも同じように適合することを強く推奨する。

達成基準3.1.1の具体的なメリット

この達成基準には、次のような利用者にメリットがある：

スクリーンリーダー又はテキストを合成音声に変換するその他の技術を使用している利用者。
例えば、文字及びアルファベットを認識したり、単語を読み取ったりすることのように、書かれたものを流暢かつ正確に読むのが困難な利用者。
テキストを音声に変換するソフトウェアを使用している、特定の認知の障害、言語の障害、及び学習障害のある利用者。
同期したメディアではキャプションを頼りにしている利用者。

達成基準 3.1.1の事例

2つの言語で書かれたコンテンツのあるウェブページ
ドイツ語で制作され、HTML でコーディングされているウェブページに、ドイツ語と英語の両方で書かれたコンテンツがあるが、コンテンツのほとんどはドイツ語で書かれている。デフォルトの自然言語は、html 要素にある lang 属性によって、ドイツ語 (de)であることが示されている。

達成基準3.1.1の達成方法及び不適合事例 - ページの言語

達成基準を満たすことのできる達成方法

3.1.1 でさらに対応が望まれる達成方法（参考）

SVR5: HTTP ヘッダーで主たる自然言語を指定する (SERVER)
http 又は Content-Language メタ・タグを用いてメタデータを指定する（リンク追加予定）

達成基準 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の達成方法及び不適合事例 - 一部分の言語

達成基準を満たすことのできる達成方法

3.1.2 でさらに対応が望まれる達成方法（参考）

SL27: Using Language/Culture Properties as Exposed by Silverlight Applications and Assistive Technologies (Silverlight)
そのウェブページのデフォルトの自然言語とは異なる言語で記述されているテキストを視覚的に区別できるようにする（リンク追加予定）
外国語で記述された節や語句で用いられているすべての原語の名前を表示する（リンク追加予定）
固有名詞の原語をマークアップして、スクリーンリーダが正しく発音できるようにする（リンク追加予定）

達成基準 3.1.2のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準3.1.2に適合していないとみなした、よくある不適合事例である。

(今のところ、文書化されている不適合事例がない)

重要な用語

プログラムによる解釈 (プログラムによる解釈が可能) (programmatically determined (programmatically determinable)): 支援技術を含む様々なユーザエージェントが抽出でき、利用者に様々な感覚モダリティで提示できるような形のデータがコンテンツ制作者によって提供されたとき、そのデータがソフトウェアによって解釈されること。
事例 1: マークアップ言語で、一般に入手可能な支援技術が直接アクセスできる要素と属性から解釈される。
事例 2: 非マークアップ言語の技術特有のデータ構造から解釈され、一般に入手可能な支援技術がサポートするアクセシビリティ API を通じて支援技術に提供される。
自然言語 (human language): 人間とコミュニケーションをとるための言語で、話される、書かれる、又は (視覚的あるいは触覚的な手段で) 手話にされるもの。
注記: 手話も参照。

一般的ではない用語:
達成基準 3.1.3 を理解する

3.1.3 一般的ではない用語: 慣用句及び専門用語を含めて、一般的ではない、又は限定された用法で使われている単語、又は語句の、明確な定義を特定するメカニズムが利用できる。 (レベル AAA)

この達成基準の意図

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

達成基準3.1.3の具体的なメリット

この達成基準は、認知の障害、言語の障害、及び学習障害のある次のような利用者に役立つ：

文字から単語を復号しづらい。
単語及び語句を理解しづらい。
前後の文脈を用いて理解するのが困難である。

また、視覚障害のある次のような利用者にも役立つ：

画面拡大ソフトで拡大していて前後の文脈を見失っている。

達成基準 3.1.3の事例

一般的ではない使われ方をしている単語の定義があるテキスト
他の情報源からの情報を「カスケード表示」に表示するのではなく、定義検索で意図した定義が見つかるように、リスト又は辞書とその他のリソースの「カスケード表示」を整理する。（「カスケード表示」には、辞書及びその他の参考文献を最も正しい定義を提示しそうな順序で一覧表示する。これは、定義を検索している際に、チェックすべき順序を制御している。）
用語集に定義を掲載する
WCAG 2.0 では、「テキスト」という単語を特別な用法で用いている。そこで、WCAG 2.0 で「テキスト」という単語が使われているときは、同じウェブページにある用語集で提供されている「テキスト」の定義へリンクしている。
ページ末尾で単語の具体的な定義を提供する
ページ上の単語に、その単語の定義へのページ内リンクが提供されている。

達成基準3.1.3の達成方法及び不適合事例 - 一般的ではない用語

達成基準を満たすことのできる達成方法

状況 A：単語又は語句にそのウェブページ特有の意味がある場合：

ウェブページ上で単語や語句の初出時に、以下のいずれかの方法でG101: 一般的ではない、又は限定された用法で用いられている単語や語句の定義を提供する:
- G55: 定義にリンクする
  - H40: 記述リストを使用する (HTML)
  - H60: 用語集にリンクするために、link 要素を使用する (HTML)
- G112: インラインの定義を使用する
  - H54: 単語の定義対象を特定するために、dfn 要素を使用する (HTML)
以下のいずれかの方法を用いて、その単語又は語句がウェブページ上に出現する度にG101: 一般的ではない、又は限定された用法で用いられている単語や語句の定義を提供する:

状況 B：単語又は語句の意味が、同じウェブページ内で異なる場合：

以下のいずれかの方法を用いて、その単語又は語句がウェブページ上に出現する度にG101: 一般的ではない、又は限定された用法で用いられている単語や語句の定義を提供する:
- G55: 定義にリンクする
  - H40: 記述リストを使用する (HTML)
  - H60: 用語集にリンクするために、link 要素を使用する (HTML)
- G112: インラインの定義を使用する
  - H54: 単語の定義対象を特定するために、dfn 要素を使用する (HTML)

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 略語: 略語の元の語、又は意味を特定するメカニズムが利用できる。 (レベル AAA)

この達成基準の意図

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

達成基準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の達成方法及び不適合事例 - 略語

達成基準を満たすことのできる達成方法

状況 A：略語がそのウェブページ内で一つの意味しか持たない場合：

ウェブページ上で略語の初出時に、以下のいずれかの方法でG102: 略語の元の語又は説明を提供する:
以下のいずれかの方法を用いて、その略語がウェブページ上に出現する度にG102: 略語の元の語又は説明を提供する:

状況 B：略語が同じウェブページで異なるものを意味している場合：

以下のいずれかの方法を用いて、その略語がウェブページ上に出現する度にG102: 略語の元の語又は説明を提供する:

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 のアクセシビリティ要素を用いて、テキストコンテンツとテキスト、グラフィック、音声版の補足的コンテンツを関連づける（リンク追加予定）
メタデータを利用者に見えるようにする（リンク追加予定）
- 事例：新しい科学的発見に関する高等レベルの記事の初頭レベル以下及び初頭レベルの版へのURIをメタデータとして提供する
サイトとページのコンテンツに進展する複雑性を与える（リンク追加予定）

達成基準 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の達成方法及び不適合事例 - 発音

達成基準を満たすことのできる達成方法

G120: 単語のすぐ後に発音（読み）を提供する
G121: 発音（読み）にリンクする
そのコンテンツ特有の発音があったり、発音で意味が変わるような単語の発音に関する情報を含むG62: 用語集を提供する
G163: オフにすることが可能な標準的な発音区別符号を使用する
H62: ruby 要素を使用する (HTML) (XHTML 1.1)

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 フォーカス時: いずれのコンポーネントも、フォーカスを受け取ったときにコンテキストの変化を引き起こさない。 (レベル A)

この達成基準の意図

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

コンポーネントがフォーカスを受け取ると自動的に送信されてしまうフォーム。
フォーカスを受け取ると新しいウィンドウを開くコンポーネント
フォーカスを受け取ると他のコンポーネントにフォーカスを移動するコンポーネント

フォーカスはキーボード操作（例：コントロールにタブ移動する）もしくはマウス操作（例：テキストフィールドをクリックする）のいずれかによって移動させることができる。スクリプトによって実装しない限り、コントロール上にマウスを移動しても、フォーカスは移動しない。クリックすることによってコンテキストの変化を開始する可能性のある一部のコントロール（例：ボタン）に注意すべきである。

注記: ここでの"コンポーネント"が意味するものは"ユーザインタフェースエレメント"や"ユーザインタフェースコンポーネント'と呼ばれる。

達成基準3.2.1の具体的なメリット

この達成基準は、コンテキストの変化が予期せず起こる可能性を少なくすることによって、視覚障害、認知能力の低下、及び運動障害のある利用者に役立つ。

達成基準 3.2.1の事例

事例 1：ドロップダウンメニュー
ページ上にあるドロップダウンメニューによって、利用者がリンク先を選択できるようになっている。利用者がキーボードを使用して下のほうにある項目を選択して（スペースキー又は Enter キーで）実行すると、新しいページへ移動する。しかし、利用者がドロップダウンメニューにある選択肢に移動した後、Escape キー又は Tab キーでそのプルダウンメニューから抜け出た場合には、フォーカスはドロップダウンの外へ移動するので、新しいページには移動しない。
不適合事例：ヘルプのダイアログ
テキストフィールドがフォーカスを受け取ると、そのテキストフィールドについての説明とオプションを提供するヘルプのダイアログウィンドウが開く。キーボードの利用者がウェブページの中を Tab キーで移動していると、利用者がそのテキストフィールドへ Tab キーで移動するたびに、キーボード・フォーカスをコントロールから奪って、ダイアログが開く。

達成基準3.2.1の達成方法及び不適合事例 - フォーカス時

達成基準を満たすことのできる達成方法

G107: 状況の変化に対するトリガーとして、"focus" ではなく、"activate" を使用する

注記: コンテンツの変化が常にコンテキストの変化であるとは限らない。コンテンツの変化がコンテキストの変化ではない場合、この達成基準は自動的に満たされていることになる。

3.2.1 でさらに対応が望まれる達成方法（参考）

コンポーネントがフォーカスを受け取ったときに持続的な状態又は値の変更を発生させない、又はあらゆる変更をリセットするための代替手段を提供する（リンク追加予定）
G200: 必要なときにだけリンク先を新しいウィンドウおよびタブで開く
G201: 新しいウィンドウを開くときには利用者に事前に知らせる

達成基準 3.2.1のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準3.2.1に適合していないとみなした、よくある不適合事例である。

重要な用語

コンテキストの変化 (changes of context)

ウェブページのコンテンツにおける大きな変化で、利用者が気づかないと、ウェブページ全体を一度に見ることのできない利用者を混乱させる恐れのあるもの。

コンテキストの変化には次に挙げるものの変化が含まれる:

注記: コンテンツの変化が、必ずコンテキストの変化になるとはかぎらない。アウトラインの展開、動的なメニュー、又はタブの切替などのコンテンツの変化は、それが上記のいずれか (例: フォーカス) を変更しないかぎり、コンテキストを変化させるとは限らない。

事例: 新しいウィンドウを開くこと、フォーカスを異なるコンポーネントへ移動させること、新しいウェブページへ移動すること (新しいウェブページへ移動したかのように思わせてしまうことも含む)、又はウェブページの内容を大きく再配置することなどは、コンテキストの変化の事例である。

入力時:
達成基準 3.2.2 を理解する

3.2.2 入力時: ユーザインタフェースコンポーネントの設定を変更することが、コンテキストの変化を自動的に引き起こさない。ただし、利用者が使用する前にその挙動を知らせてある場合を除く。 (レベル A)

この達成基準の意図

この達成基準の意図は、データ入力又はフォーム・コントロールの選択の結果を予測可能にすることである。ユーザインタフェース要素の設定を変更すると、コントロールの状態を変化させ、その状態は利用者がそのユーザインタフェース要素とのやりとりを終了した後も持続する。つまり、チェックボックスを選択する、テキストフィールドにテキストを入力する、又はリストコントロールのオプションを選択すると、コンポーネントの設定を変更するが、リンク又はボタンを押下したときはそうはならない。コンテキストの変化は、その変化を知覚しづらい利用者、又は変化によって気を取られやすい利用者を混乱させてしまう恐れがある。コンテキストの変化が起こってもよいのは、そのような変化が利用者の操作に反応して起こることが明らかなときだけである。

注記: この達成基準の対象となるのは、コントロールの設定を変更したことによる状況の変化である。リンクやタブ・コントロール中のタブのクリックは、コントロールの選択・実行であり、コントロールの設定変更ではない。

注記: ここでいう”構成要素”ならびに”ユーザインタフェース構成要素”は”ユーザインタフェース要素”とも呼ばれる。

達成基準3.2.2の具体的なメリット

この達成基準は、インタラクティブなコンテンツをより予測可能にすることによって、障害のある利用者に役立つ。予期しないコンテキストの変化によって、視覚障害又は認知能力の低下している利用者はとても混乱してしまうので、コンテンツを利用できなくなってしまう。
コンテキストの変化に気づくことができない利用者は、サイトをナビゲートしている間に混乱した状態になりにくい。例えば、次のような利用者が当てはまる：
- 全盲の利用者、又はロービジョンの利用者は、新しいウィンドウがポップアップで開くなどのように、視覚的な状況の変化がいつ起こるのかを把握するのが困難なことがある。この場合、前もって利用者に状況の変化が起こることを知らせておくと、利用者が「戻る」ボタンがいつものように動作しないことに気づいたときの混乱を最小限に抑えることができる。
ロービジョンの利用者、読字及び知的障害のある利用者、そして視覚的な手がかりを解釈しづらい利用者は、コンテンツ制作者が手がかりを追加することによって、コンテキストの変化に気づくようになる。

達成基準 3.2.2の事例

ウェブベースのカレンダー及びスケジュール管理アプリケーションに、カレンダーへのエントリーを作成するフォームがある。件名、時刻、場所を入力する標準的なテキストフィールドとあわせて、カレンダーへのエントリーの種類を選択するラジオボタン一式がある。その種類には、会議、アポイントメント、又はリマインダなどがある。利用者が「会議」のラジオボタンを選択すると、会議の参加者を入力するためのテキストフィールドがページ上に追加で表示される。また、「リマインダ」を選択すれば、異なったテキストフィールドが表示される。この場合、入力部分だけが変化し、全体の構造は同じままなので、基本的に状況は変化していないといえる。
フォームに、米国の電話番号を入力するテキストフィールドがある。すべての電話番号には、3桁のエリアコードがあり、その後に3桁の局番、そして最後に4桁の番号があり、それぞれの番号は別々のテキストフィールドに入力するようになっている。利用者があるテキストフィールドの入力を終えて、次のテキストフィールドの最初の桁を入力しようとすると、フォーカスが自動的に次のフィールドへ移動する。このふるまいは、フォームの先頭で利用者に対して説明されている。

達成基準3.2.2の達成方法及び不適合事例 - 入力時

達成基準を満たすことのできる達成方法

3.2.2 でさらに対応が望まれる達成方法（参考）

G201: 新しいウィンドウを開くときには利用者に事前に知らせる

達成基準 3.2.2のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準3.2.2に適合していないとみなした、よくある不適合事例である。

重要な用語

コンテキストの変化 (changes of context)

コンテキストの変化には次に挙げるものの変化が含まれる:

ユーザインタフェースコンポーネント (user interface component)

コンテンツの一部分で、特定の機能を実現するための単一のコントロールとして利用者が知覚するもの。

注記 2: ユーザインタフェースコンポーネントには、フォーム要素、リンクだけでなく、スクリプトで生成されるコンポーネントが含まれる。

一貫したナビゲーション:
達成基準 3.2.3 を理解する

3.2.3 一貫したナビゲーション: ウェブページ一式の中にある複数のウェブページ上で繰り返されているナビゲーションのメカニズムは、繰り返されるたびに相対的に同じ順序で出現する。ただし、利用者が変更した場合は除く。 (レベル AA)

この達成基準の意図

この達成基準の意図は、ウェブページ一式の中で繰り返し用いられるコンテンツを利用し、特定の情報又は機能を複数回にわたって見つける必要がある利用者のために、一貫したプレゼンテーション及びレイアウトの使用を推奨することである。画面拡大ソフトを使用して一度に画面の限られた狭い領域を表示しているロービジョンの利用者は、繰り返し用いられてるコンテンツの位置を素早く確認するために、視覚的な手がかり及びページの境界線を用いていることがよくある。繰り返し用いられるコンテンツを同じ順序で提示することは、そのコンテンツの位置を確認するためにデザインの空間的記憶又は視覚的な手がかりを用いている、画面を見ている利用者に対しても重要なことである。

ここで用いている「同じ順序」という表現が、サブナビゲーション・メニューを使用してはならないとか、サブナビゲーションのブロック又はページ構造を使用してはならないという意味ではないということが重要である。そうではなく、この達成基準が意図しているのは、複数のウェブページで繰り返し用いられているコンテンツを利用している利用者が、自分の探しているコンテンツの位置を予測できるようにして、より素早く見つけることができるようにすることである。

利用者は、自分に最も有用なかたちで情報が提供されるように、ユーザエージェントを用いて、又は利用者設定を行って、順序を変更していることがある。

達成基準3.2.3の具体的なメリット

繰り返し用いられているコンテンツを、サイトの各ページで同じ順序で提示することによって、利用者が各ページのどこにそれがあるのかを予測できるようになり、快適に利用できるようになる。これは、認知能力の低下している利用者、ロービジョンの利用者、知的障害のある利用者に加えて、全盲の利用者にも役立つ。

達成基準 3.2.3の事例

一貫して配置されているコントロール
検索のテキストフィールドが、そのサイト上のすべてのページ上で最後に配置されていて、利用者はすぐに検索機能を見つけることができる。
展開するナビゲーションメニュー
ナビゲーションメニューに、サイトの主要コーナーへの7つのリンクがある。利用者がその項目の一つを選択すると、サブナビゲーション項目のリストが、ナビゲーションメニューに挿入される。
一貫して配置されているスキップ・ナビゲーションのコントロール
ウェブサイトにあるすべてのページ上に、「本文へジャンプする」というリンクが一番最初のリンクとして配置されている。そのリンクによって、利用者はヘッダーの情報及びナビゲーション部分をスキップして、ページのメインコンテンツ部分の開始位置へ移動することができる。
ナビゲーションへのスキップリンク
ナビゲーション部分は一貫して各ページの最後にある。キーボード利用者が、必要なときに容易に見つけられるように、「本文へジャンプする」というリンクは一貫して各ページの先頭にある。

達成基準3.2.3の達成方法及び不適合事例 - 一貫したナビゲーション

達成基準を満たすことのできる達成方法

G61: 繰り返される一連のコンポーネントは毎回同じ相対的順序で提示する

3.2.3 でさらに対応が望まれる達成方法（参考）

PDF14: PDF 文書内に連続するヘッダとフッタを提供する (PDF)
PDF17: PDF 文書に一貫性のあるページ番号を指定する (PDF)
複数のウェブページの間で一貫性を保つためにテンプレートを利用する（リンク追加予定）
レイアウト、位置、階層、配置を作る（リンク追加予定）

達成基準 3.2.3のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準3.2.3に適合していないとみなした、よくある不適合事例である。

F66: 達成基準 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 を理解する

3.2.4 一貫した識別性: ウェブページ一式の中で同じ機能を有するコンポーネントは、一貫して識別できる。 (レベル AA)

この達成基準の意図

この達成基準の意図は、ウェブページ一式で繰り返して表示される機能的なコンポーネントを一貫して識別できるようにすることである。スクリーンリーダーを使用している利用者がウェブサイトを操作する方法は、複数のウェブページで使われている機能に馴染みがあるかどうかに大きく依存している。全く同じ機能が、ウェブページによって異なるラベルを付けられていると、そのウェブサイトはかなり使いづらいものになってしまう。また、認知能力の低下している利用者にとっても、それは混乱のもとであり、認知的負荷を増大させてしまうことがある。そのため、一貫したラベルを付けることが大切である。

この一貫性という考え方は、代替テキストにも当てはまる。アイコン又はその他の非テキストコンテンツが同じ機能であれば、その代替テキストにも同様に一貫性をもたせるべきである。

ウェブページ一式の中で、もしウェブページに 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の達成方法及び不適合事例 - 一貫した識別性

達成基準を満たすことのできる達成方法

G197: 同じ機能を有するコンテンツに対して、一貫したラベル、識別名及び代替テキストを使用する、かつ、達成基準1.1.1を満たすことのできる達成方法かつ達成基準4.1.2を満たすことのできる達成方法に従ってラベル、識別名、代替テキストを提供する。

注記 1: 「一貫した」代替テキストは、常に「同一」であるとは限らない。例えば、次のウェブページへリンクするグラフィカルな矢印をウェブページの下部で使うとする。代替テキストは、「4ページに移動」というふうになるだろう。当然ながら、この代替テキストをそのまま次のウェブページでも繰り返して使うのは適切ではない。次のウェブページでは「5ページへ移動」とするのがより適切なはずである。これらの代替テキストは同一ではないが、一貫しており、この達成基準に適合しているといえる。

注記 2: 単一の非テキストコンテンツのアイテムが、異なる機能のために使われることがある。そのような場合、異なる代替テキストが必要であり、用いられるべきである。チェックマーク、?マーク、そして交通標識などのアイコンを使用する際によく見られる例である。それらの機能は、ウェブページの文脈によって異なる可能性がある。チェックマークは、その状況に応じて、「承認済」、「完了」、又は「あり」という意味で使われることがある。すべてのウェブページを通じて、代替テキストを「チェックマーク」としてしまうと、利用者がそのアイコンの意味を理解することができない。同一の非テキストコンテンツが複数の機能を果たしている際は、異なる代替テキストを用いることができる。

3.2.4 でさらに対応が望まれる達成方法（参考）

コンポーネントの機能及びそのコンポーネントを利用者が実行したときに何が起こるかが確実に分かるような代替テキストを用いる（リンク追加予定）
可能な限り、特定の機能を表す非テキストコンテンツは同じものにする（リンク追加予定）

達成基準 3.2.4のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準3.2.4に適合していないとみなした、よくある不適合事例である。

F31: 達成基準 3.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ページなのかもしれない。
同じ機能 (same functionality): 使うと同じ結果が得られること。
事例: あるウェブページ上にある "search" ボタンと他のウェブページ上にある "find" ボタンは、どちらもキーワードを入力するテキストフィールドがあり、そのウェブサイトにある入力されたキーワードに関係のあるコンテンツをリスト表示する。この場合、同じ機能を有しながらも、ラベルは一貫していないことになる。

要求による変化:
達成基準 3.2.5 を理解する

3.2.5 要求による変化: コンテキストの変化は利用者の要求によってだけ生じるか、又は、そのような変化を止めるメカニズムが利用できる。 (レベル AAA)

この達成基準の意図

この達成基準の意図は、コンテキストの変化を利用者が完全に制御できるようなウェブコンテンツの設計を推奨することである。この達成基準は、自動的に開く新しいウィンドウ、リストから項目を選択すると自動的に送信されるフォームなどのように、予期しないコンテキストの変化によって混乱が引き起こされる可能性を取り除くことを狙いとしている。そのような予期しないコンテキストの変化により、運動障害のある利用者、ロービジョンの利用者、全盲の利用者、及び特定の認知能力の低下している利用者には困難が生じてしまう恐れがあるからである。

コンテキストの変化の中には、利用者を混乱させず、さらに利用者にとって有用な種類のものもある。例えば、単一のスイッチを使用している利用者は、システムによるコンテキストの変化に依存しているし、ロービジョンの利用者の好みも一度にどれくらいのコンテンツを見ることができるか、どれくらいのセッション構造が作業記憶に残るかに依存している。中にはスライドショーのように、意図したユーザーエクスペリエンスを提供するために、コンテキストの変化を必要とするコンテンツもある。利用者の設定が許容する際だけ自動的に状況を変化させるコンテンツは、この達成基準に適合することができる。

注記: 複数のコンテキストの変化を同時に引き起こすことが可能である。例えば、自動的に新規ウィンドウが開くリンクをクリックするのは、コンテンツの変化に関連するコンテキストの変化であり、表示域（ウィンドウ）の変化に関連するコンテキストの変化でもある、２つに分かれた変化の一例である。この場合のコンテンツの変化は、利用者がリンクをクリックした時、彼らの要求によって開始されるが、新規ウィンドウが開くことに利用者が気づかない限り、コンテキストの変化は利用者が開始したとはみなせない。

達成基準3.2.5の具体的なメリット

コンテキストの変化を見つけることができない、又は状況が変化したことに気づかない利用者が、サイトをナビゲートしている間に混乱した状態になりにくい。例えば、次のような利用者が当てはまる：
- 全盲の利用者、又はロービジョンの利用者は、新しいウィンドウがポップアップで開くなどのように、視覚的なコンテキストの変化がいつ起こるのかを把握するのが困難なことがある。この場合、前もって利用者にコンテキストの変化が起こることを知らせておくと、利用者が「戻る」ボタンがいつものように動作しないことに気づいたときの混乱を最小限に抑えることができる。
ロービジョンの利用者、読字及び知的障害のある利用者、そして視覚的な手がかりを解釈しづらい利用者は、コンテンツ制作者が手がかりを追加することによって、コンテキストの変化に気づくようになる。
自動的なリダイレクトを、ブラウザではなくウェブサーバーによって行えば、認知能力の低下している利用者は混乱しないですむ。

達成基準 3.2.5の事例

「今、更新する」ボタン
コンテンツを自動的に更新するかわりに、コンテンツの更新を要求する「今、更新する」ボタンをコンテンツ制作者が提供している。
自動リダイレクト
リダイレクトが起こったことに絶対気づかない方法で、古いページから新しいページへ利用者が自動的にリダイレクトされる。

達成基準3.2.5の達成方法及び不適合事例 - 要求による変化

達成基準を満たすことのできる達成方法

3.2.5 でさらに対応が望まれる達成方法（参考）

新しいウィンドウを開く際、target属性を用いず一般的なハイパーリンクを提供する。（リンク追加予定）これは、多くのユーザエージェントではリンクを別のウィンドウ又は別のタブで開く機能を提供しているためである。
G200: 必要なときにだけリンク先を新しいウィンドウおよびタブで開く

達成基準 3.2.5のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準3.2.5に適合していないとみなした、よくある不適合事例である。

重要な用語

コンテキストの変化 (changes of context)

コンテキストの変化には次に挙げるものの変化が含まれる:

メカニズム (mechanism)

結果を得るためのプロセス又は手法。

注記 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の具体的なメリット

入力エラーに関する情報をテキストで提供することによって、全盲の利用者又は色弱の利用者はエラーが発生したことを知覚できるようになる。
この達成基準は、アイコン及びその他の視覚的な手がかりで示された意味を理解するのが困難な、認知の障害、言語の障害、及び学習障害のある利用者にも役立つことがある。

達成基準 3.3.1の事例

フォーム送信におけるエラーの特定
ある航空会社のウェブサイトが、格安便の特別なプロモーションを展開している。利用者は、氏名、住所、電話番号、座席指定、及び電子メールアドレスなどの個人情報をシンプルなフォームに入力することを求められる。フォームにあるテキストフィールドのいずれかが、入力されていないか入力に誤りがある場合、どのテキストフィールドが未入力又はエラーであるかを利用者に知らせるアラートが表示される。
注記: この達成基準は、エラー箇所を示すために、色又はテキストの表示スタイルを用いないほうがよいということを意味しない。単にエラー箇所がテキストでも示されていることを要求しているだけである。この事例では、色に加えて、2つのアスタリスク (*) が用いられている。
複数の手がかりの提供
利用者がフォームにある2つのテキストフィールドに入力し忘れている。エラーの説明及びそのテキストフィールドを見つけやすくするためにエラーであることを示す特定の文字列を提供するだけでなく、テキストフィールドを黄色で強調表示して、視覚的にも見つけやすくしている。

達成基準3.3.1の達成方法及び不適合事例 - エラーの特定

達成基準を満たすことのできる達成方法

状況 A：フォームが利用者からの情報が必須である入力フィールドを含む場合

状況 B：利用者によって提供される情報が、特別なデータフォーマットか特定の値であることが求められる場合

3.3.1 でさらに対応が望まれる達成方法（参考）

G139: 利用者がエラー箇所に移動できるメカニズムを作成する
送信されたフォームが正しいかをサーバーで確認する（リンク追加予定）
エラーの要約とともにフォームを再度表示する（リンク追加予定）
利用者が情報を入力したときにエラーを通知する（リンク追加予定）
ページタイトルにエラーを通知する情報を含める（リンク追加予定）
エラーが起きた場所をハイライトするか視覚的に強調する（リンク追加予定）
エラーを報告する際に、非テキストコンテンツにテキストを補足する（リンク追加予定）
G199: データが問題なく送信されたことを伝えるフィードバックを提供する
利用者の注意を集中させるために音を使う（リンク追加予定）

達成基準 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の達成方法及び不適合事例 - ラベル又は説明

達成基準を満たすことのできる達成方法

注記: 上記のリストの一番最後にある達成方法は、「最後の手段」として考え、その他の達成方法をページに適用することができないときだけに用いるべきである。より広範囲の利用者層にとってのアクセシビリティを向上させるという意味でも、一番最後の達成方法以外の達成方法を推奨する。

3.3.2 でさらに対応が望まれる達成方法（参考）

G13: 状況の変化を引き起こすフォームのコントロールが変化する前に、何が起こるのかを説明する
SL19: Providing User Instructions With AutomationProperties.HelpText in Silverlight (Silverlight)
線形なフォームのデザインを提供し、同様の項目をグループ化する（リンク追加予定）

達成基準 3.3.2のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準3.3.2に適合していないとみなした、よくある不適合事例である。

F82: 達成基準 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の具体的なメリット

入力エラーを修正する方法に関する情報を提供することによって、学習障害のある利用者がフォームに問題なく入力できるようになる。そして、全盲の利用者又は視覚に障害のある利用者が、入力エラーの内容及びその修正方法をもっと容易に理解できるようになる。また、運動障害のある利用者は、入力内容を変更せざるを得なくなる回数を減らすことができる。

達成基準 3.3.3の事例

入力エラーを修正するためのヘルプの追加
うまく送信されなかったフォームのエラー画面で、そのページで起こった入力エラーを正しい入力方法とあわせて説明していて、入力エラーになったテキストフィールドのヘルプを追加で提供している。
制限のある値の提示
月の名前を入力するテキストフィールドがある。利用者が「12」と入力すると、修正する方法が提示される。
- 入力可能な値の一覧。例えば、「どれか一つを選んでください： January, February, March, April, May, June, July, August, September, October, November, December」。
- 入力すべき値を説明する。例えば、「月の名前を入力してください。」
- 入力されたデータを異なるフォーマットに変換して提示する。例えば、「もしかして 'December' ですか?」

達成基準3.3.3の達成方法及び不適合事例 - エラー修正の提案

注記: 2つ以上の状況が適用される場合もある。例えば、必須フィールドが特別なデータフォーマットを要求する場合である。

達成基準を満たすことのできる達成方法

状況 A：必須のフィールドに情報が入力されていない場合：

状況 B：フィールドの情報に、特別のデータフォーマットが要求される場合：

状況 C：利用者の入力する情報は、複数の限定された値のうちの一つであることが要求される場合：

3.3.3 でさらに対応が望まれる達成方法（参考）

G139: 利用者がエラー箇所に移動できるメカニズムを作成する
エラーメッセージを、ウェブページのその他のテキストと区別しやすくし、容易に理解できるようにする（リンク追加予定）
送信されたフォームが正しいかをサーバーで確認する（リンク追加予定）
必須の情報が入力されない場合に、必須フィールドを識別するだけでなく、正しい情報の説明と事例を提供する（リンク追加予定）
フォームフィールドと関連して、各入力エラーを訂正するための提案を繰り返し強調する（リンク追加予定）
提案するリストの各項目から、対応するフォームフィールドへスキップする方法を利用者に提供する（リンク追加予定）
変更の必要のあるフォームフィールドに対して、文脈に沿った追加のヘルプを提供する（リンク追加予定）
様々なフォーマットの入力データを受け付ける（リンク追加予定）
G199: データが問題なく送信されたことを伝えるフィードバックを提供する

利用者に提案を行う達成方法（参考）

入力エラーの数についての情報を含むテキストの説明、各項目を訂正するための提案、そして、どのように進めるべきかの指示を提供する（リンク追加予定）
コンテンツの最初の項目（あるいは最初の項目の一つ）を訂正するための提案を含むテキストの説明を提供する、又は、コンテンツの中でこの情報を強調する（リンク追加予定）
エラーを表示し、元のフォームの文脈に沿った提案をする（例えば、フォームのどこに入力エラーがあるかを再表示し、訂正のための提案がハイライトされ、元のフォームとの関連を表示する）（リンク追加予定）

HTMLの達成方法（参考）

必須のフォームフィールドで最初のテキストとして、データとデータフォーマットについて「正しい事例」を提供する（リンク追加予定）
正しいテキストを示唆するリンクをフォームフィールドの「近くで」提供するか、正しいテキストを示唆するテキスト自体をウェブページ上のフォームフィールドの「隣に」直接配置する（リンク追加予定）

クライアントサイドのスクリプトの達成方法（参考）

SCR18: クライアントサイドのバリデーション及びアラートを提供する (Scripting)
クライアントサイドのバリデーションを提供し、DOMを介してエラーテキストを追加する（リンク追加予定）
フォームの送信動作をきっかけにクライアントサイドのバリデーションの機能を呼び出す（リンク追加予定）

達成基準 3.3.3のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準3.3.3に適合していないとみなした、よくある不適合事例である。

(今のところ、文書化されている不適合事例がない)

重要な用語

入力エラー (input error)

利用者が入力した情報で、受け付けられないもの。

注記: 以下のものが含まれる:

そのウェブページでは必須であるが、利用者が入力しなかった情報
利用者が入力したが、要求されたデータ形式あるいは値ではない情報

エラー回避 (法的、金融、データ) :
達成基準 3.3.4 を理解する

3.3.4 エラー回避 (法的、金融、データ) : 利用者にとって法律行為もしくは金融取引が生じる、利用者が制御可能なデータストレージシステム上のデータを変更もしくは削除する、又は利用者が試験の解答を送信するウェブページでは、次に挙げる事項のうち、少なくとも一つを満たしている: (レベル AA)
取消: 送信を取り消すことができる。
チェック: 利用者が入力したデータの入力エラーがチェックされ、利用者には修正する機会が提供される。
確認: 送信を完了する前に、利用者が情報の見直し、確認及び修正をするメカニズムが利用できる。

この達成基準の意図

この達成基準の意図は、障害のある利用者が元の状態に戻すことのできないタスクを行った際、ミスをしたことによる重大な結果を未然に防ぐことができるようにすることである。例えば、払い戻し不可の航空券の購入、又は証券取引口座での株購入の注文は、重大な結果につながる金銭的な取引である。利用者が発着日を間違えれば、その利用者は交換できない誤った日付の航空券を購入したことになってしまう。利用者が購入する株式の数を間違えると、意図した数よりも多くの株式を購入したことになってしまう。どちらのミスも、すぐに処理される取引であり、後から変更することはできないものであり、また非常に高価である。同様に、旅行サービスのウェブサイトにある旅行履歴のように、後からアクセスする必要のあるデータベースのデータを無意識に修正又は削除してしまった場合、そのエラーは回復不能なことがある。「利用者が自分で制御可能な」データの変更又は削除を参照する場合、この達成基準の意図は、ファイル又はレコードの削除のようなデータの大量損失を防ぐことである。各保存コマンド又は単純な作成又はドキュメント、レコードもしくは他のデータの編集するための確認を必要とすることを意図しない。

障害のある利用者は、ミスをしてしまう可能性が高い。読字障害のある利用者は、数字と文字を取り違えてしまうことがあるし、運動障害のある利用者は間違ってキーを押してしまうことがある。元の状態に戻せるようにすることによって、利用者が重大な結果につながる恐れのあるミスを修正できるようになる。また、入力内容を確認して修正できるようにすることで、重大な結果につながることをしてしまう前に、利用者がミスに気づくことができるようになる。

利用者が自分で制御可能なデータというのは、利用者が意図的行為を通して変更及び/又は削除できる利用者が閲覧可能なデータである。そのようなデータを制御する利用者の例としては、利用者のアカウントの電話番号及び住所を更新する、又はウェブサイトから過去の請求書のレコードを削除することが挙げられる。これは、利用者が直接に表示又は情報交換できないインターネットのログ又は検索エンジンの監視データのようなものを指すものではない。

達成基準3.3.4の具体的なメリット

ミスによる重大な結果を未然に防ぐ手段を提供することによって、ミスをする可能性の高い障害のある利用者すべてに役立つ。

達成基準 3.3.4の事例

注文内容の確認
ある小売店がウェブでオンラインショッピングのサービスを顧客に提供している。注文が送信されると、利用者が注文内容に間違いがないかを確認できるように、注文した商品、各商品の数、送り先の住所、支払方法などの注文情報が表示される。利用者は、注文内容を確認したり、変更したりすることができる。
株式売買
ある金融サービスのウェブサイトで、利用者は株をオンラインで売買できる。利用者が株の売買の注文を送信すると、システムは市場が開いているかどうかを確認する。時間外だった場合は、利用者にその取引が時間外取引になることを知らせて、通常の取引時間外であることに伴うリスクについても伝える。そして、利用者はその注文をキャンセルするか、確認することができる。

達成基準3.3.4の達成方法及び不適合事例 - エラー回避 (法的、金融、データ)

達成基準を満たすことのできる達成方法

状況 A：アプリケーションで、購入又は所得税申告の提出のように、法的なトランザクションが発生する場合：

状況 B：利用者のアクションによって情報が削除される可能性がある場合：

状況 C：ウェブページに試験を実施するアプリケーションがある場合：

3.3.4 でさらに対応が望まれる達成方法（参考）

どのような不可逆のアクションが起きそうになっているかを利用者に知らせる（リンク追加予定）
SCR18: クライアントサイドのバリデーション及びアラートを提供する (Scripting)
SL35: Using the Validation and ValidationSummary APIs to Implement Client Side Forms Validation in Silverlight (Silverlight)
エラーを含むフィールドにフォーカスを置く（リンク追加予定）
プルダウンメニューの各項目の最初では、同じ用語や同じ文字の組み合わせの使用を避ける（リンク追加予定）
G199: データが問題なく送信されたことを伝えるフィードバックを提供する

達成基準 3.3.4のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準3.3.4に適合していないとみなした、よくある不適合事例である。

(今のところ、文書化されている不適合事例がない)

重要な用語

ウェブページ (Web page)

事例 1: すべての埋め込まれている画像とメディアを含んだウェブリソース。

メカニズム (mechanism)

結果を得るためのプロセス又は手法。

注記 2: メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。

入力エラー (input error)

利用者が入力した情報で、受け付けられないもの。

注記: 以下のものが含まれる:

そのウェブページでは必須であるが、利用者が入力しなかった情報
利用者が入力したが、要求されたデータ形式あるいは値ではない情報

利用者が制御可能 (user-controllable)

利用者によってアクセスされることを意図したデータ。

注記: これは、インターネットのログや検索エンジンの監視データのようなものは指していない。

事例: ユーザアカウントのための氏名と住所のフィールド。

法律行為 (legal commitments)

法的に拘束力のある義務あるいは利益が発生する取引。

事例: 結婚許可証、株取引 (金銭上及び法的)、遺言、ローン、採用、軍隊への入隊登録、あらゆる契約、など

ヘルプ:
達成基準 3.3.5 を理解する

3.3.5 ヘルプ: コンテキストに応じたヘルプが利用できる。 (レベル AAA)

この達成基準の意図

この達成基準の意図は、利用者がミスをしないようにすることである。障害のある利用者は、障害のない利用者よりもミスをする可能性が高い。状況に応じたヘルプを提供することによって、利用者は自分が実行していることの手順がわからなくなってしまうことがなく、どう操作すればよいかがわかる。

状況に応じたヘルプは、ラベルがすべての機能を説明するのに不十分なときにだけ提供すればよい。状況に応じたヘルプが提供されていることを利用者に対してはっきりと示すべきで、利用者が必要とするときにはいつでもヘルプを利用できるようにしなければならない。

コンテンツ制作者は、ヘルプの文章を提供することができる、又はユーザエージェントがウェブコンテンツ技術特有のプログラムで判断できる情報に基づいてヘルプの文章を提供することができる。

達成基準3.3.5の具体的なメリット

テキスト入力のヘルプを提供することによって、フォーム又はテキスト入力を必要とするその他のコンテンツでテキストを書くのが困難なことがよくある、書字障害のある利用者及び読字障害、知的障害のある利用者に役立つ。
さらに、このようなヘルプによる支援は、加齢によって、テキスト入力及び/又はマウス操作に同じような困難を伴う利用者にも役立つ。

達成基準 3.3.5の事例

オンライン求職
はじめての利用者にとっては分かりにくい質問がいくつかある。各質問の横にあるヘルプのリンクが、その質問の説明を提供している。

達成基準3.3.5の達成方法及び不適合事例 - ヘルプ

達成基準を満たすことのできる達成方法

状況 A：フォームがテキスト入力を求める場合：

状況 B：フォームが所定のデータフォーマットでのテキスト入力を求める場合：

3.3.5 でさらに対応が望まれる達成方法（参考）

H89: コンテキストに応じたヘルプを提供するために、title 属性を使用する (HTML)
文字のバイト数をチェックし、適切なバイト数へと自動変換する（リンク追加予定）

達成基準 3.3.5のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準3.3.5に適合していないとみなした、よくある不適合事例である。

(今のところ、文書化されている不適合事例がない)

重要な用語

コンテキストに応じたヘルプ (context-sensitive help): そのとき実行されている機能に関する情報を提供するヘルプのテキスト。
注記: 明解なラベルは、コンテキストに応じたヘルプとして機能しうる。

エラー回避 (すべて) :
達成基準 3.3.6 を理解する

3.3.6 エラー回避 (すべて) : 利用者に情報の送信を要求するウェブページでは、次に挙げる事項のうち、少なくとも一つを満たしている: (レベル AAA)
取消: 送信を取り消すことができる。
チェック: 利用者が入力したデータの入力エラーがチェックされ、利用者には修正する機会が提供される。
確認: 送信を完了する前に、利用者が情報の見直し、確認及び修正をするメカニズムが利用できる。

この達成基準の意図

この達成基準の意図は、障害のある利用者が、フォームのデータを送信するときにミスをしたことによりひきおこされる重大な結果を未然に防ぐことができるようにすることである。この達成基準は、利用者が情報を送信する必要のあるフォームすべてに適用されるという点において、達成基準 3.3.4 よりも上位のレベルである。

障害のある利用者は、ミスをしてしまう可能性が高く、フォームでのエラーに気づく又は修正するのにも困難を伴うことが多い。例えば、読字障害のある利用者は、数字と文字を取り違えてしまうことがある。そして、運動障害のある利用者は間違ってキーを押してしまうことがある。元の状態に戻せるようにすることによって、利用者がエラーを修正することができるようになる。また、情報を確認して修正できるようにすることによって、利用者はフォームのデータを送信する前にエラーに気づくことができる。

達成基準3.3.6の具体的なメリット

ミスによる重大な結果を未然に防ぐ手段を提供することによって、ミスをする可能性の高い障害のある利用者すべてに役立つ。

達成基準 3.3.6の事例

(none currently documented)

達成基準3.3.6の達成方法及び不適合事例 - エラー回避 (すべて)

達成基準を満たすことのできる達成方法

利用者に情報の送信を要求するすべてのフォームにおいて、達成基準 3.3.4 を満たすことのできる達成方法に従うこと。

重要な用語

ウェブページ (Web page)

事例 1: すべての埋め込まれている画像とメディアを含んだウェブリソース。

メカニズム (mechanism)

結果を得るためのプロセス又は手法。

注記 2: メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。

入力エラー (input error)

利用者が入力した情報で、受け付けられないもの。

注記: 以下のものが含まれる:

そのウェブページでは必須であるが、利用者が入力しなかった情報
利用者が入力したが、要求されたデータ形式あるいは値ではない情報

互換性:
ガイドライン4.1を理解する

ガイドライン4.1: 現在及び将来の、支援技術を含むユーザエージェントとの互換性を最大化すること。

ガイドライン 4.1 の意図

このガイドラインの目的は、現在及び将来のユーザエージェントの互換性、特に支援技術との互換性をサポートすることである。これは、1）コンテンツ制作者が支援技術の機能を損なうようなこと（例：形式が整えられていないマークアップ）、又は支援技術をだますようなこと（例：奇抜なマークアップ又はソースコードを用いる）をしないようにして、2）支援技術が認識して情報のやりとりができる標準的な方法によって、コンテンツにある情報を支援技術に引き渡すようにすることで実現することができる。技術の変化は早く、支援技術の開発者が急速に変化する技術に追従していくのは大きな困難を伴うので、支援技術が容易に新しい技術にも対応していけるように、コンテンツが規則に従っていてAPIとの互換性が確保されていることが重要である。

ガイドライン 4.1 の参考にすべき達成方法(特定の達成基準に特有ではない達成方法)

W3Cが策定した技術仕様の中で非推奨とされている機能の使用を避ける（リンク追加予定）
その技術がオフになっている、又はサポートされていないとき、アクセシビリティ・サポーテッドではない技術に依存したコンテンツを表示しない。

構文解析:
達成基準 4.1.1 を理解する

4.1.1 構文解析: マークアップ言語を用いて実装されているコンテンツにおいては、要素には完全な開始タグ及び終了タグがあり、要素は仕様に準じて入れ子になっていて、要素には重複した属性がなく、どの ID も一意的である。ただし、仕様で認められているものを除く。 (レベル A)
注記: 開始及び終了タグに重要な記号が欠けている場合、例えば、タグを閉じる山括弧がない、又は属性値の引用符が一致していない場合は、完全とはいえない。

この達成基準の意図

この達成基準の意図は、支援技術を含むユーザエージェントが、コンテンツを正確に解釈して解析できることを確実にするものである。コンテンツをデータ構造に解析できない場合、別のユーザエージェントがそのコンテンツを異なって提示するかもしれない、又はコンテンツを全く解析できないかもしれない。ユーザエージェントの中には、品質の低いソースコードを描画するために「修復技術」を用いるものもある。

修復技術はユーザエージェントの間で異なるため、コンテンツがそのウェブコンテンツ技術の正式な文法で定義される規則に従って制作されない限り、コンテンツ制作者は、コンテンツがデータ構造へ正確に解析される、又はコンテンツが支援技術を含む特殊なユーザエージェントによって正しく描画されるものと仮定できない。マークアップ言語においては、要素及び属性における構文エラー、並びに適切な入れ子にした開始タグ及び終了タグを提供できないことは、ユーザエージェントがコンテンツを確実に解析することを妨げるエラーを導く。したがって、この達成基準は、コンテンツが正式な文法の規則のみを用いて解析できることを要件としている。

注記 1: 「整形式 (well formed)」の概念は、この達成基準で要件としているものに近い。しかし、正確な解析に求められる要件は、マークアップ言語によって異なる。そして、ほとんどの非 XML ベース言語は、整形式であることの要件を明確には定義していない。したがって、マークアップ言語に一般的に適用可能にするために、この達成基準でより明確にする必要があった。用語「整形式 (well formed)」用語は XML でのみ定義され、かつ有効 (valid) な HTML は整形式のソースコードを要求しない（終了タグは任意の場合もある）ため、この達成基準では「整形式 (well formed)」という用語を用いていない。

注記 2: 一つの達成基準（ 達成基準1.4.4 テキストのサイズ変更を理解する テキストのサイズ変更、達成基準で指定された効果が支援技術に依存せずに達成されなければならないと具体的に述べている）を除き、存在しかつ利用者に役立つ場合に、利用者が支援技術（又はユーザエージェントにあるアクセス機能）を利用することを仮定することで、コンテンツ制作者はコンテンツを達成基準に適合できる。

達成基準4.1.1の具体的なメリット

ウェブページに完全な開始タグ及び終了タグがあり、仕様に準じて入れ子になっているようにすることで、支援技術がコンテンツを問題なく正確に解析できるようになる。

達成基準 4.1.1の事例

(none currently documented)

達成基準4.1.1の達成方法及び不適合事例 - 構文解析

達成基準を満たすことのできる達成方法

G134: ウェブページをバリデートする
G192: 仕様に完全に準拠する
H88: 仕様に準じて HTML を使用する (HTML)
以下のいずれかの方法で、ウェブページが正しく解析できることを確認する:
- H74: 開始タグ及び終了タグを仕様に準じて使用していることを確認する (HTML) かつH93: ウェブページの id 属性値が一意的（ユニーク）であるようにする (HTML) かつH94: 要素には重複した属性がないようにする (HTML)
- H75: ウェブページが well-formed であることを確認する (HTML)
SL33: Using Well-Formed XAML to Define a Silverlight User Interface (Silverlight)

4.1.1 でさらに対応が望まれる達成方法（参考）

(まだ文書化されていない)

達成基準 4.1.1のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準4.1.1に適合していないとみなした、よくある不適合事例である。

名前 (name) ・役割 (role) 及び値 (value) :
達成基準 4.1.2 を理解する

4.1.2 名前 (name) ・役割 (role) 及び値 (value) : すべてのユーザインタフェースコンポーネント (フォームを構成する要素、リンク、スクリプトが生成するコンポーネントなど) では、名前 (name) 及び役割 (role) は、プログラムによる解釈が可能である。又、状態、プロパティ、利用者が設定可能な値はプログラムによる設定が可能である。そして、支援技術を含むユーザエージェントが、これらの項目に対する変更通知を利用できる。 (レベル A)
注記: この達成基準は、主に独自のユーザインタフェースコンポーネントを開発、又はスクリプトで実装するコンテンツ制作者に向けたものである。例えば、標準的な HTML のコントロールを仕様に沿って使用していれば、既にこの達成基準を満たしていることになる。

この達成基準の意図

この達成基準の意図は、支援技術がコンテンツにあるユーザインタフェースコントロールの状態に関する情報を収集する、その状態をアクティブにする（又は設定する）、及び最新の状態を保つように保証することである。

アクセシブルなウェブコンテンツ技術由来の標準コントロールを使用するとき、このプロセスはごく簡単である。ユーザインタフェース要素を仕様に準じて使用している場合、この達成基準に適合したことになる。（下記の達成基準4.1.2の事例を参照のこと）

しかし、カスタムコントロールを作成する、すなわちインタフェースコンポーネントに通常とは異なる役割、及び/又は機能を持たせるように（ソースコード又はスクリプトに）プログラムする場合、コントロールが支援技術に重要な情報を提供し、支援技術がそのコントロールを制御可能にすることを保証する追加の手段を取る必要がある。

特に重要なユーザインタフェース・コントロールの状態は、フォーカスを持つかどうかである。コントロールのフォーカス状態は、プログラムによる解釈が可能であり、フォーカスの変化に関する通知は、ユーザエージェント及び支援技術に送られる。ユーザインタフェース・コントロールのステータスのその他の例としては、チェックボックス又はラジオボタンが選択されているかどうか、又は折り畳み可能なツリー若しくはリストが展開されている又は折り畳まれているかどうかが挙げられる。

注記: 達成基準 4.1.2 は、すべてのユーザインタフェースコンポーネントに対して、プログラムによる解釈が可能な名前を要求する。名前は、可視であっても、不可視であってもよい。名前がラベルと見なされる場合に、名前は可視でなければならない。より詳しい情報については、用語集にある名前及びラベルの定義を参照のこと。

達成基準4.1.2の具体的なメリット

すべてのユーザインタフェースコンポーネントに、役割、状態、及び値の情報を持たせることによって、例えば、スクリーンリーダー、画面拡大ソフトウェア、及び音声認識ソフトウェアなどの、障害のある利用者が使用する支援技術との互換性を保つことを可能にする。

達成基準 4.1.2の事例

アクセシビリティ API
Java アプレットは、Java 言語で定義されたアクセシビリティ API を用いている。

達成基準4.1.2の達成方法及び不適合事例 - 名前 (name) ・役割 (role) 及び値 (value)

達成基準を満たすことのできる達成方法

状況 A：マークアップ言語（例えば HTML）で標準的なユーザインタフェースコンポーネントを使用している場合：

状況 B：スクリプト又はコードを用いて、マークアップ言語の標準的なユーザインタフェースコンポーネント再定義する場合：

名前及び役割をユーザエージェントに提供し、利用者が設定可能なプロパティを直接設定可能にし、変化を通知する
- ARIA16: ユーザインターフェースコントロールの名前（name）を提供するために、aria-labelledby を使用する (ARIA)

状況 C：プログラミング技術で標準的なユーザインタフェースコンポーネントを用いる場合：

下記の達成方法固有の技術を用いて、G135: 名前及び役割をユーザエージェントに提供し、利用者が設定可能なプロパティを直接設定可能にし、変化を通知するために、ウェブコンテンツ技術のアクセシビリティ API を使用する。:

状況 D：プログラミング言語で独自のインタフェース・コンポーネントを作成する場合：

下記の達成方法固有の技術を用いて、G10: 識別名及び役割を取得し、利用者が設定可能なプロパティを直接設定可能にし、変化を通知するためにユーザエージェントが動作する、プラットフォームのアクセシビリティ API 機能をサポートするウェブコンテンツ技術を用いて、コンポーネントを作成する:

4.1.2 でさらに対応が望まれる達成方法（参考）

暗黙のラベルを持たないすべてのフォームコントロールにラベルを付加する（リンク追加予定）

達成基準 4.1.2のよくある不適合事例

以下に挙げるものは、WCAG ワーキンググループが達成基準4.1.2に適合していないとみなした、よくある不適合事例である。

重要な用語

(この文書で用いられている) 支援技術 (assistive technology (as used in this document))

注記 2: 支援技術は、API を利用、監視することで、主流のユーザエージェントとデータやメッセージのやりとりをすることが多い。

事例: この文書の文脈において重要な支援技術としては、以下のものが挙げられる:

画面拡大ソフト及びその他の視覚的な表示に関する支援技術。視覚障害、知覚障害、及び読書困難などの障害のある人が、レンダリング後のテキスト及び画像の視覚的な読みやすさを改善するために、テキストのフォント、サイズ、間隔、色、音声との同期などを変更するのに使用している。
スクリーンリーダー。全盲の人がテキスト情報を合成音声あるいは点字で読み取るために使用している。
音声変換ソフトウェア。認知障害、言語障害、及び学習障害のある人が、テキストを合成音声に変換するために使用している。
音声認識ソフトウェア。何らかの身体障害のある利用者が使用することがある。
代替キーボード。特定の身体障害のある人がキーボード操作をシミュレートするのに使用している (ヘッドポインタ、シングルスイッチ、呼気・吸気スイッチ、及びその他の特別な入力デバイスを使った代替キーボードを含む)。
代替ポインティングデバイス。特定の身体障害のある人がマウスポインタとボタンの動きをシミュレートするのに使用している。

プログラムによる解釈 (プログラムによる解釈が可能) (programmatically determined (programmatically determinable))

事例 1: マークアップ言語で、一般に入手可能な支援技術が直接アクセスできる要素と属性から解釈される。

プログラムによる設定 (programmatically set)

支援技術を含むユーザエージェントがサポートしている手法を用いて、ソフトウェアによって設定されること。

ユーザインタフェースコンポーネント (user interface component)

コンテンツの一部分で、特定の機能を実現するための単一のコントロールとして利用者が知覚するもの。

注記 2: ユーザインタフェースコンポーネントには、フォーム要素、リンクだけでなく、スクリプトで生成されるコンポーネントが含まれる。

ユーザエージェント (user agent)

ウェブコンテンツを取得して利用者に提示するあらゆるソフトウェア。

事例: ウェブブラウザ、メディアプレーヤ、プラグイン、及びその他のプログラム。その他のプログラムには、ウェブコンテンツの取得、レンダリング、やり取りを支援する支援技術を含む。

名前 (name)

ソフトウェアが、ウェブコンテンツのコンポーネントを利用者に識別させることができるテキスト。

注記 2: これは、HTML の name 属性とは関係がない。

役割 (role)

ウェブコンテンツに含まれるコンポーネントの機能を、ソフトウェアが識別するために用いることができるテキストや数字。

事例: 画像の機能が、ハイパーリンク、コマンドボタン、又はチェックボックスのどれなのかを示している数字。

WCAG 2.0への適合を理解する

すべての WCAG 2.0 の達成基準は、客観的にコンテンツがその基準を満たしているかどうかを判断できるように、テスト可能な基準として記述されている。達成基準のテストでは、自動的なテストと人間による判断を組合せる必がある。コンテンツをテストするのは、様々な障害のある人がウェブをどのように使っているのかを理解している人でなければならない。

ここでいうテストやテスト可能というのは、機能面のテストのことを指している。つまり、コンテンツが想定していた通りに機能することを確認するということである。あるいは、ここでは、達成基準を満たしていることを確認するといってもよい。コンテンツがすべての達成基準を満たしていたとしても、それでも様々な障害のある利用者がそのコンテンツを使うことができるとは限らない。そのため、必要とされる機能面のテストに加えて、ユーザビリティ・テストを実施することも推奨している。ユーザビリティ・テストの目的は、利用者が想定した目的に沿ってそのコンテンツをどこまで使うことができるかを確認することである。ユーザビリティ・テストを実施する際には、テスト参加者に障害のある利用者を含めることを推奨する。

適合とは何を意味するのか？

基準への適合とは、その基準の「要件」に合っている、あるいは満たしていることを意味する。WCAG 2.0 において、「要件」となるのは達成基準である。WCAG 2.0に適合するためには、達成基準を満たす必要がある。つまり、達成基準に反するコンテンツがないということである。

注記: ある達成基準について、適用対象となるコンテンツを含まないコンテンツにおいては、その達成基準は満たされているということを意味する。

ほとんどの標準には、適合レベルは一つしかない。しかし、より高いレベルのアクセシビリティを要求したり可能にしたりする様々な状況に対応するために、WCAG 2.0 には3つの適合レベルがあり、そのため達成基準にも3つのレベルがある。

適合要件を理解する

コンテンツが WCAG 2.0 に「適合している」とみなされるためには、満たさなければならない5つの要件がある。この節では、それらの要件に関する簡単な注釈を提供する。なお、この節は、今後寄せられる質問に対処するため、あるいは様々な適合要件を満たす方法の新しい事例を提供するために、時間とともに拡充されていく予定である。

適合要件 1 を理解する

1. 適合レベル: 以下に挙げる適合レベルの一つを完全に満たしていること。
レベル A:レベル A (適合の最低レベル) で適合するには、ウェブページがレベル A 達成基準のすべてを満たすか、又は適合している代替版を提供する。
レベル AA:レベル AA で適合するには、ウェブページはレベル A 及びレベル AA 達成基準のすべてを満たすか、又はレベル AA に適合している代替版を提供する。
レベル AAA:レベル AAA で適合するには、ウェブページがレベル A、レベル AA、及びレベル AAA 達成基準のすべてを満たすか、又はレベル AAA に適合している代替版を提供する。
注記 1: ウェブページは、記載したレベルでのみ WCAG 2.0 に適合できるが、コンテンツ制作者は、その適合レベルよりも高いレベルの達成基準の達成状況を (表明の中で) 示すことを推奨される。
注記 2: コンテンツの中には、レベル AAA 達成基準のすべてを満たすことのできないものもあるため、サイト全体の一般的な方針としてレベル AAA での適合を要件とすることは推奨されない。

最初の要件は、適合レベルに関するものである。基本的には、ページ上のすべての情報が適合している、もしくは、そのページから利用可能な適合している代替版があるということである。また、この要件は、少なくともレベル A の達成基準すべてを満たさなければどのレベルでも適合することはできないということも説明している。

注記が指摘しているのは、特定のレベルでの適合に留まらずに、より高いレベルの適合に向けても取り組み、もし自分たちが望むのであればその進捗状況を報告することをコンテンツ制作者に推奨するということである。

また、「適合している代替版」を提供する達成方法を紹介している「適合している代替版を理解する」も参照のこと。

適合要件 2 を理解する

2. ウェブページ全体: 適合 (及び適合レベル) はウェブページ全体に対するもののみであり、ウェブページの一部が除外されている場合には適合にならない。
注記 1: 適合の判断をするときに、例えば、詳細な説明又は映像の代替の提示のように、代替となるものがそのページから直接得られる場合は、ページのコンテンツの一部に対する代替コンテンツはそのページの一部であるとみなされる。
注記 2: コンテンツ制作者が制御できないコンテンツがあるために適合できないウェブページについては、部分適合に関する記述を行うことを検討するとよい。

この要件は、ページ全体が適合することを単に求めている。「ページの一部が適合している」という適合宣言をすることはできないのである。

あるページ上の情報への補足情報が他のページで提供されることがある。HTML の longdesc 属性がその一例である。longdesc 属性を用いると、その画像のあるページから利用者が移動できる別のページで画像の長い説明文を提供することができる。この注記では、そのような別ページのコンテンツも元のページの一部であると考えて、単一のウェブページであるとみなされる複数のウェブページによって適合要件 2 が満たされるということを明確にしている。また、代替を同一ページ上で提供することも可能である。例としては、ユーザインタフェースのコントロールと等価なものを作成することが挙げられる。

注記 1: 適合要件 5 により、たとえページの一部分でアクセシビリティ・サポーテッドではないウェブコンテンツ技術を用いていたとしても、それがページの残りの部分の利用を妨げず、すべての情報及び機能がそのページ又はそのページから移動できる別ページのどこかで提供されている限り、ページ全体が適合できる。

注記 2: 適合していないコンテンツを含めることが可能である。「適合要件 5を理解する」を参照のこと。

適合要件 3 を理解する

3. プロセス全体: ウェブページがプロセスを提示する一連の流れのウェブページ群 (つまり、ある目的を達成するために完了させる必要のある一連の手順) に含まれる場合、そのプロセス中のすべてのウェブページが指定したレベル又はそれ以上のレベルで適合している (もし、プロセス中のウェブページが一つでも特定のレベル又はそれ以上のレベルに適合していない場合、そのレベルに適合できない)。
事例: あるオンラインストアには、製品を選択して購入するための一連のウェブページがある。このプロセスに含まれるあるウェブページが適合するためには、最初から最後 (支払い) までのすべてのウェブページが適合していなければならない。

この要件では、プロセス全体が適合していない場合、そのプロセスの一部であるウェブページは適合しているとはみなされないことを述べている。例えば、ショッピングサイトでは、支払あるいはショッピング及び購入プロセスの一部であるその他のサイトの機能が適合していなかったとしたら、そのショッピングサイトは適合していることにならないということである。

適合要件 4 を理解する

4. 技術のアクセシビリティサポーテッドな使用方法だけ: 達成基準を満たすために、用いる技術のアクセシビリティサポーテッドな使用方法だけに依存している。アクセシビリティサポーテッドではない方法で提供されている情報又は機能は、アクセシビリティサポーテッドな方法でも利用できる (Understanding accessibility support を参照)。

この適合要件は、後述の「アクセシビリティ・サポート」を理解するで説明されている。

適合要件 5 を理解する

5. 非干渉: 技術がアクセシビリティサポーテッドではない方法で用いられている場合、又は適合しない方法で用いられている場合、利用者がウェブページの他の部分へアクセスすることを妨げていない。加えて、全体としてウェブページは、以下のそれぞれの条件の下で適合要件を満たしていること:
依存していない技術がユーザエージェントで有効になっているとき
依存していない技術がユーザエージェントで無効になっているとき、及び
依存していない技術がユーザエージェントでサポートされていないとき
さらに、適合するために依存していないコンテンツも含めて、ページ上のすべてのコンテンツには以下の達成基準が適用される。なぜならば、これらを満たしていないことにより、ページの利用を妨げる可能性があるためである。
1.4.2 - 音声制御、
2.1.2 - フォーカス移動、
2.3.1 - 3回の閃光、又は閾値以下、及び
2.2.2 - 一時停止、停止、非表示

この要件は、基本的に、すべての情報がアクセシビリティ・サポーテッドであるウェブコンテンツ技術を用いても利用可能である限り、なおかつ、アクセシビリティ・サポーテッドではないコンテンツが妨げとなっていない限り、アクセシビリティ・サポーテッドではないウェブコンテンツ技術を用いることができるということを述べている。

すべての情報がアクセシビリティ・サポーテッドであるウェブコンテンツ技術を用いた適合する方法でも利用可能で、なおかつ、アクセシビリティ・サポーテッドではないコンテンツが妨げとなっていない限り、アクセシビリティ・サポーテッドではないウェブコンテンツ技術を適合していない方法で用いることができる。

特にページ利用の妨げとなる問題に対処する4つの達成基準がある。これら4つの達成基準は、注記に示されている。各達成基準の注記では、アクセシビリティ・サポーテッドではないウェブコンテンツ技術を用いて制作したコンテンツを含むすべてのコンテンツが、これらの達成基準を満たさなければならないことを示している。

事例: あるウェブページが "ZAP" というインタラクティブなグラフィックの新技術を組み込んでいたとする。ZAP はアクセシビリティ・サポーテッドではあるが、ZAP を用いて提示されている情報が、HTML のページでも提示されている。そのため、ZAP には依存していないことになる。その場合、このページは適合要件 1 を満たしている。しかし、もし利用者が ZAP のコンテンツを Tab キーで移動しようとして、フォーカスが ZAP のオブジェクトの中に入るとそこから抜け出せなくなる。一度中に入ると、利用者はフォーカスを外に出すことができなくなってしまう。そうすると、キーボード利用者は、ページの残り半分を利用することができない。また、ZAP のコンテンツは、様々な速度で明るく閃光を放ち続けていて、静止しない。それにより、注意力欠如（発達障害）のある利用者は気が散ってしまい、光感受性発作疾患のある利用者は発作を起こしてしまう可能性がある。適合要件 5 は、適合しているページ上でこういった状況が起こらないようにするためのものである。

適合宣言を理解する

適合する上では、適合宣言をすることは必須ではない。しかし、適合宣言をする際には、従わなければならないルールがある。

ある日付以降に追加されたコンテンツだけに適合宣言を行いたいことがあるかもしれない。あるいは、ある日付までのコンテンツには WCAG 1.0 への適合宣言を行い、その日付以降に制作又は更新したコンテンツには WCAG 2.0 への適合宣言したいこともあるかもしれない。WCAG 2.0 では、どのページが WCAG のどのバージョンに対して適合宣言をしているのかが明確である限り、そういった適合宣言を禁止していない。

注記 1: 「依存」している技術について言及する際、それはウェブコンテンツ技術（HTML、CSS、JavaScript、など）のことであり、ユーザエージェント（ブラウザ、支援技術、など）のことではない。

注記 2: 適合宣言は、通常適合の範囲内にある各ウェブページ上に表示しない。

第三者によるコンテンツに伴う部分的な適合宣言

第三者によるコンテンツの実装を、制作者が用いる判断をする場合、WCAG の要件を満たしたものを選択するべきである。ページ上のすべてのコンテンツ（第三者によるコンテンツを含む）が WCAG のすべての達成基準を満たすのであれば、そのページは WCAG に適合していると言える。しかし、制作者の制御が及ばない正当な理由のみによってページが WCAG に適合できない場合は、制作者は部分適合を宣言することができる。ただしこれは不適合であることの声明であり、ページ上の一部のコンテンツにアクセスできないユーザーがいるかもしれないことを認識することが重要である。

コンテンツに対して制作者の制御が及ばない理由のひとつは、そのコンテンツが第三者（ブログ、ポータル、ニュースサイト）によって供給されるからである。また、ウェブページに第三者製のライブラリやプラグイン、ウィジェットが含まれる場合もある。

ウェブページ制作者の承認なく変更される可能性があるコンテンツはすべて監視し、適合していたページが突然不適合に陥ることのないようにすること。監視したり第三者によるコンテンツを修正することが不可能な場合は、そのページの不適合箇所をユーザーに明示する必要がある。当該箇所以外が WCAG に適合するウェブページであれば、そのページは部分適合宣言の資格を持つ。

達成基準以上に施した追加措置に関する情報

適合宣言の任意要素の一つに、「アクセシビリティをさらに向上させるために、達成基準以上に施した追加措置に関する情報」がある。これには、適合しているその他の達成基準、実装した参考達成方法、特定の障害者のアクセス又はニーズを助けるために用いた追加の措置に関する情報などが含まれる。利用者がそのページのアクセシビリティを把握する上で役に立つあらゆる情報を含めるとよい。

適合宣言を報告するためのメタデータの使用

コンテンツに適合宣言を添付する最も有用な方法は、機械的に読み取り可能な標準のフォーマットで添付することだろう。この方法が広く普及すれば、検索ツールや特別なユーザエージェントがよりアクセシブルなコンテンツを探して提供するためにこの情報を利用することができるし、ユーザエージェントがコンテンツに適応することができるようになる。適合宣言を行うためのオプションに基づいたメタデータが数多く開発中であり、コンテンツ制作者及びツール開発者にはそれらをサポートすることを推奨する。

加えて、ひとたびレベル A での適合が達成されれば、個々の達成基準への適合を報告するために、メタデータを用いることが可能である。

また、例えば、現在開発中で、適合に関する詳細な情報を機械的に読み取り可能なフォーマットを提供できる Evaluation and Report Language (EARL) のように、プログラムによる報告のフォーマットもある。報告のフォーマットが形式化されて、そのサポートが進めば、ここに追記される予定である。

適合宣言の例

適合宣言の必須要素の例

事例 1: 2009年9月20日時点で、http://www.example.com にあるすべてのウェブページは、http://www.w3.org/TR/2008/REC-WCAG20-20081211/ にある WCAG 2.0 にレベル A で適合しています。

この適合宣言において依存している、アクセシビリティ・サポーテッドなコンテンツ技術の文書化された一式は、http://ISA.example.gov/AsCTsets/AS2-2008 にある ISA- AsCTset#1-2008 の一部である。

事例 2: （正規表現を用いて）2009年8月12日時点で、http://www.example.com/(marketing|sales|contact)/* のパターンに合致するページ群は、http://www.w3.org/TR/2008/REC-WCAG20-20081211/ にある WCAG 2.0 にレベル AA で適合しています。

このコンテンツが「依存」している技術： XHTML 1.0 Transitional、CSS 2.0、及び JavaScript 1.2。

事例 3: （ブール論理を用いて） 2009年1月6日時点で、（http://example.com/archive/ 又は http://example.com/publications/archive/を除く）http://example.com/は、http://www.w3.org/TR/2008/REC-WCAG20-20081211/ にある WCAG 2.0 にレベル AA で適合しています。

この適合宣言において依存している、アクセシビリティ・サポーテッドなコンテンツ技術の文書化された一式には、http://ISA.example.gov/AsCTsets/AS2-2008 にある ISA- AsCTset#1-2008 の XHTML 1.0 及び SMIL があります。

任意要素を含めた適合宣言の例

事例 1: 2009年5月5日時点で、「G7: イントロダクション」のページ (http://telcor.example.com/nav/G7/intro.html) は、http://www.w3.org/TR/2008/REC-WCAG20-20081211/ にある WCAG 2.0 にレベル AA で適合しています。

次の達成基準も追加で満たしています： 1.1.2、1.2.5、及び 1.4.3。
この適合宣言において依存している、アクセシビリティ・サポーテッドなコンテンツ技術の文書化された一式は、http://UDLabs.org/AsCTset#1-2006.html にある AsCTset#1-2006 です。
このコンテンツが「依存」している技術： XHTML 1.0 (Strict) 及び Real Video。
このコンテンツが「使用しているが依存はしていない」技術： JavaScript 1.2、CSS2。

事例 2: 2009年6月21日時点で、http://example.com/nav 及び http://example.com/docs という URI で始まるすべてのコンテンツは、http://www.w3.org/TR/2008/REC-WCAG20-20081211/ にある WCAG 2.0 にレベル AAA で適合しています。

この適合宣言において依存している、アクセシビリティ・サポーテッドなコンテンツ技術の文書化された一式は、http://smithreports.example.com/AsCTsets/AS2-2008 にある SMITH- AsCTset#2-2008 です。
このコンテンツが「依存」している技術： XHTML 1.0 (Strict)、CSS2、JavaScript 1.2、JPEG、PNG。
このコンテンツを検証したユーザエージェント（支援技術を含む）は、http://example.com/docs/WCAG20/test/technologies.html で確認することができます。

事例 3: 2009年3月23日時点で、http://www.wondercall.example.com にあるサーバー上で利用可能なすべてのコンテンツは、http://www.w3.org/TR/2008/REC-WCAG20-20081211/ にある WCAG 2.0 にレベル A で適合しています。

このコンテンツが「依存」している技術： HTML 4.01。
このコンテンツが「使用しているが依存はしていない」技術： CSS2 及び gif。
このコンテンツは、次のユーザエージェント及び支援技術を用いて検証しました： Windows Vista上のFirefox 1.5及びスクリーンリーダー X 4.0、Windows XP SP2上のFirefox 1.5及びスクリーンリーダー X 3.5、Windows 2000 SP4上のIE 6.0及びスクリーンリーダー Y 5.0、Windows 2000 SP4上のIE 6.0及びスクリーンリーダー Z 2.0、Windows XP SP2上のFirefox 1.5及びスクリーンリーダー X 4.0、OS X 10.44上のSafari 2.0

適合宣言のための達成方法

参考達成方法

ダブリン・コアの要素を用いてWCAG 2.0への適合宣言を示す（リンク追加予定）

適合レベルを理解する

まず、達成基準であるとみなされるには、満たさなければならない数多くの諸条件がある。次のことが含まれる：

すべての達成基準は、すべての利用者が直面する可能性があるユーザビリティ問題という側面以上に、障害のある利用者にとって重要なアクセス上の問題でなければならない。言い換えれば、アクセシビリティの問題として考慮されるためには（そして、このようなアクセシビリティ・ガイドラインでカバーされるためには）、アクセス上の問題は、障害のない利用者に対して引き起こされる問題よりも、障害のある利用者に対して割合から言ってより重大な問題を引き起こすものでなければならない。
すべての達成基準は、テスト可能でなければならない。このことは重要である。なぜなら、テスト可能でなければ、あるページが達成基準に適合しているのか、もしくは適合していないのかを判断することができなくなるからである。達成基準が満たされているかどうかを高い信頼水準で判断することが可能である限り、その達成基準は、機械と人間の評価を組み合わせることによってテストすることができる。

ワーキンググループが広範囲に及ぶ相互作用する問題を考慮した後に、達成基準には、3つの適合レベルの中から1つが割り当てられた。レベルを定めた際に用いられた共通の指標には、次のようなものが含まれていた：

その達成基準が必要不可欠かどうか（言い換えれば、もしその達成基準が満たされなかったとしたら、支援技術でさえもコンテンツをアクセシブルにすることができない）。
その達成基準が適用されるすべてのウェブサイト及びコンテンツの種類（例：様々な主題、コンテンツの種類、ウェブコンテンツ技術の種類）が、その達成基準を満たすことができるかどうか。
その達成基準が必要とするスキルは、コンテンツ制作者が無理なく習得できるものかどうか（つまり、その達成基準を満たすための知識及びスキルは、1週間あるいはそれ以下のトレーニングによって習得できるか）。
その達成基準が、「ルック＆フィール」及び/又はウェブページの機能に制限（機能、プレゼンテーション、表現の自由、デザイン又は審美的な面において、その達成基準がコンテンツ制作者にかける制限）を強いるかどうか。
その達成基準が満たされない場合、次善策がないかどうか。

アクセシビリティ・サポートを理解する

達成基準の多くは、支援技術あるいは主流のユーザエージェントが提供する特別なアクセシビリティ機能（例えば、メディアプレーヤーが提供する「キャプションを表示」というオプション）を通じて、アクセシビリティを提供することを論じている。つまり、達成基準は、支援技術がコンテンツの情報を問題なく利用者に提示することができるように、ウェブコンテンツにおいてなすべきことを要求している。例を挙げると、あるトピックへ移動するためにクリックすべき画像は、支援技術を含むユーザエージェントがそれを見つけて利用者に示すことができるように代替テキストが提供されていなければ、全盲の利用者にとってはアクセシブルとはいえない。ここで重要なのは、代替テキストが、支援技術を含むユーザエージェントが理解できて使用できるような方法、すなわち「アクセシビリティ・サポーテッド」な方法で提供されていなければならないということである。

もう一つ例を挙げるとするならば、ウェブページにある独自のコントロールがある。この場合、標準的なユーザエージェントは、利用者にその代替物を提示できるとはかぎらない。しかし、もしそのコントロールの識別名、役割、値、設定方法といった情報が、支援技術が理解できて制御可能な方法で提供されていれば、支援技術の利用者はそのコントロールを使用することができるであろう。

新しい技術が登場するときには、支援技術の利用者がそれを使用できるようにするために、次の2つを想定しなければならない。まず、支援技術を含むユーザエージェントが利用者にコンテンツを提示する必要のある情報すべてにアクセスできるように、その技術が設計されていなければならない。次に、ユーザエージェント及び支援技術には、その新しい技術に対応するために変更あるいは修正を行う必要が生じることがある。

「アクセシビリティ・サポーテッド」というのは、このどちらもが既になされていて、その技術がユーザエージェント及び支援技術によって利用者が使用可能であることを意味する。

「アクセシビリティ・サポーテッド」とするのに必要な支援技術によるサポートのレベル

このトピックは、あるウェブ技術が「アクセシビリティ・サポーテッド」であるとみなすには、どれだけ多くの、あるいはどの支援技術がそのウェブ技術をサポートしていなければならないのか、という疑問を生む。WCAG ワーキンググループ及び W3C は、ウェブ技術がアクセシビリティ・サポーテッドであるとみなすために、どれだけ多くの、あるいはどの支援技術がそのウェブ技術をサポートしていなければならないということについては特に定めない。なぜなら、これは複雑な要素が絡むことであり、環境や言語の両方によっても異なるからである。このことに関しては、WCAG ワーキンググループ及び W3C だけにとどまらず、広範囲かつ国際的な議論が必要である。このトピックを理解し調査するのに役立つ留意点には、次のようなことが挙げられる：

ウェブ技術のアクセシビリティ・サポートは環境により異なる。
- ウェブ技術は、企業内で配備される特定のユーザーエージェント及び支援技術によってのみサポートされていればよいこともある。（これらのユーザーエージェント及び支援技術は、古いバージョンである場合もあれば、最新バージョンである場合もある。）
- 一般に公開されているウェブコンテンツは、古いバージョンを含む、より広範囲のユーザエージェント及び支援技術で利用可能である必要がある。
ウェブ技術のアクセシビリティ・サポートは、言語（及び方言）により異なる。
- 古い支援技術のサポートのレベルは、言語及び国によって様々である。中には、無償の支援技術が提供されている環境や国もある。
新しい技術は、古い支援技術ではサポートされない。
- 新しい技術が既存の支援技術全てによってサポート可能でないことは明らかであり、その技術をすべての支援技術によってサポートされるように求めることは不可能である。
一つの古い支援技術によるサポートだけでは、通常は十分とはいえない。
- （ある障害に対して）たった一つの支援技術だけがサポートしていることは、通常は十分とはいえない。コンテンツへアクセスするためにその支援技術を必要とする利用者のほとんどがそれを持っていなくて、その支援技術を購入する金銭的な余裕がない場合は、特にそうである。例外といえるのは、全員がある一つの支援技術を使用している会社の従業員へ配信される情報のみである。
一般の利用者が入手可能な現在の支援技術は、機能が不足していることが多い。
- 障害のある一般の利用者が利用できないコンテンツを制作することは避けなければならない。多くの場合、支援技術を購入するコストは、それを必要とする利用者にとっては高額すぎる。また、無償あるいは低コストの支援技術は、今日では機能が非常に不足していることが多く、これらの支援技術に合わせて非常に低い（もしくは中程度の）レベルに制限する形でウェブコンテンツを制作するのは現実的ではない。このことが、対処していく必要のある、とても困難なジレンマを生んでいる。

そのため、ワーキンググループは、何をもってサポートしているとするかを定義するに留め、どこまで、どれだけ多くの、あるいはどの支援技術がそのウェブ技術をサポートしていなければならないかという判断については、組織、調達、地域社会などにとっての要件を定める各々の状況により近いところにいる地域や団体に委ねることとした。

一般に入手可能で、なおかつ堅牢な支援技術の不足は、利用者、技術開発者、そしてコンテンツ制作者にマイナスの影響を及ぼす問題であり、ワーキンググループは公開の場にてこのトピックについてより多くの議論がなされることを奨励する。

「アクセシビリティ・サポート」の技術的な定義

基本的に、ウェブコンテンツ技術は、利用者の使用している支援技術が対応していて、かつ、主流なユーザエージェントのアクセシビリティ機能が対応していれば、"アクセシビリティ・サポーテッド" である。具体的に言うと、アクセシビリティ・サポーテッドな技術であるとみなすには、その技術において次のことが当てはまらなければならない：

アクセシビリティサポーテッド (accessibility supported)

利用者の支援技術と、ブラウザ及びその他のユーザエージェントにあるアクセシビリティ機能でサポートされていること。

あるウェブコンテンツ技術 (あるいは、ある技術の機能) の使用方法がアクセシビリティサポーテッドであると認められるためには、そのウェブコンテンツ技術 (あるいは、機能) について、次の 1. と 2. の両方が満たされていなければならない:

そのウェブコンテンツ技術の使用方法が、利用者の支援技術によりサポートされていなければならない。これは、その技術の使用方法が、そのコンテンツの自然言語における利用者の支援技術との相互運用性について検証されていることを意味する。
かつ
そのウェブコンテンツ技術には、アクセシビリティサポーテッドで、利用者が利用できるユーザエージェントがなければならない。これは、少なくとも次の4つのうち一つを満たしていることを意味する:
1. その技術が (HTML や CSS のように)、広く配布されているアクセシビリティサポーテッドなユーザエージェントに標準でサポートされている。
  又は、
2. その技術が、広く配布されているアクセシビリティサポーテッドなプラグインでサポートされている。
  又は、
3. そのコンテンツが、大学あるいは企業内ネットワークのような閉じた環境で利用できるものであり、その技術に必要とされていて、その組織で使用されているユーザエージェントがアクセシビリティサポーテッドである。
  又は、
4. その技術をサポートするユーザエージェントが、アクセシビリティサポーテッドであって、次のようにダウンロードあるいは購入できる:
  - 障害のある人に障害のない人よりも時間や労力がかかるようなことはなく、かつ、
  - 障害のある人も障害のない人と同じくらい容易に探して入手することができる。

注記 1: WCAG Working Group ならびに W3C は、あるウェブ技術のある特定の使用方法がアクセシビリティサポーテッドであると分類するために、そのウェブ技術の特定の使用方法に対して、どの支援技術によるどれだけのサポートが必要なのかを定めない (Level of Assistive Technology Support Needed for "Accessibility Support"を参照)。

注記 2: そのウェブ技術に依存しておらず、達成基準 4: 技術のアクセシビリティサポーテッドな使用方法だけ及び達成基準 5: 非干渉を含む適合要件をウェブページ全体が満たしている場合は、そのウェブ技術をアクセシビリティサポーテッドではない方法で用いることができる。

注記 3: ウェブ技術がアクセシビリティサポーテッドな方法で用いられている場合、その技術全体、又はその技術の使用方法すべてがアクセシビリティサポーテッドであるということを暗に示すわけではない。ほとんどの技術は、HTML を含めてアクセシビリティサポーテッドではない機能、又は使用方法が少なくとも一つある。ウェブページが WCAG に適合するのは、依存する技術のアクセシビリティサポーテッドな使用方法を用いて WCAG の要件を満たしている場合だけである。

注記 4: 複数のバージョンを有するウェブコンテンツ技術を挙げる際は、アクセシビリティサポーテッドなバージョンを特定すべきである。

注記 5: コンテンツ制作者が技術のアクセシビリティサポーテッドな使用方法を見つける方法の一つは、アクセシビリティサポーテッドであることが文書化されている使用方法の資料を参考にすることである (Understanding Accessibility-Supported Web Technology Usesを参照)。コンテンツ制作者、企業、技術ベンダー、あるいはその他の者が、ウェブコンテンツ技術のアクセシビリティサポーテッドな使用方法を文書化してもよい。しかし、文書中の技術の使用方法すべては、前述のアクセシビリティサポーテッドなウェブコンテンツ技術の定義を満たしていなければならない。

ウェブ技術のアクセシビリティ・サポーテッドな使用法を理解する

どのウェブ技術のどの使用法が、支援技術及びユーザエージェントのどのバージョンによって実際にサポートされているかを判断するのに必要な検証作業のすべてを、個々のコンテンツ制作者が行うことは通常不可能である。そのため、コンテンツ制作者は、どの支援技術がどのウェブ技術のどの使用法をサポートしているかについて文書化している公開資料に頼ってもよい。「公開」というのは、必ずしも公的機関によって作成されたものを指すわけではなく、一般に入手可能であるということのみを意味している。誰もが「ウェブ技術の使用法及びそのアクセシビリティ・サポート」という公開資料を作成することが可能である。資料作成者は、資料を作成し、コンテンツ制作者が参考資料として示すことのできる名前をつけてもよい。その資料が公開されている限り、コンテンツ制作者あるいは利用者などは、ニーズに合った使用法を容易に選択することが可能である。利用者やその他の者は、いずれかの時点で自分の環境又は言語に合致したウェブ技術を選んで、コンテンツを制作すべきウェブ技術を特定することができる。コンテンツ制作者には、精度と有用性において評価されている情報源を用いることを強く推奨する。そして、技術開発者には、その技術のアクセシビリティ・サポートに関する情報を提供することを強く推奨する。WCAGワーキンググループは、正確な情報を提供し、コンテンツ制作者と利用者双方にメリットのある文書のみが、長期的に市場の評価を得るものと考えている。

WCAG においては、公開された資料を用いたり、そのような資料にある技術の使用法のみを用いたりすることを要件にしていない。公開された資料は、適合において重要だが少々複雑な部分を、支援技術のサポートに関する専門家ではない（あるいは、単に主流のユーザエージェント及び支援技術の進化を把握する時間がない）コンテンツ制作者にとってより容易にする手法としてのみ説明されている。

コンテンツ制作者や企業などは、アクセシビリティ・サポーテッドな技術の使用に関する資料を独自に作成して用いたいと考えるかもしれないし、それは WCAG に適合する上では認められている。一方、利用者、企業などは、用いた独自の資料あるいは公開資料から、その技術の使用法を特定してもよい。「附録 B ウェブコンテンツ技術の使用法のアクセシビリティ・サポートを文書化する」を参照のこと。

アクセシビリティ・サポートに関する記述

アクセシビリティ・サポートを明文化する適合宣言の方法の例には、次のようなものがある：

この適合宣言は、コンテンツの言語でのユーザエージェント A、ユーザエージェント B、ユーザエージェント C、及び支援技術 X、支援技術 Y そして支援技術 Z によるコンテンツの検証に基づいた、アクセシビリティ・サポートの要件を満たしています。これは、それらの製品を用いて、WCAG 2.0 のレベル A の達成基準すべてを満たすことができたことを意味します。
この適合宣言は、Techniques for WCAG 2.0 に記述されている達成方法及びユーザエージェント・ノートに基づいて、コンテンツの言語でのアクセシビリティ・サポートの要件を満たしています。また、（適合する上で依存した）技術のアクセシビリティ・サポート文書にも基づいており、「組織 XYZ によるアクセシビリティ・サポート文書」で参照可能です。
この適合宣言は、「WCAG 2.0 のための技術 Z のアクセシビリティ・サポーテッドな達成方法」で文書化されている技術 Z の使用法を基にして、コンテンツの言語でのアクセシビリティ・サポートの要件を満たしています。
この適合宣言は、技術 A のアクセシビリティ・ガイドライン及び技術 B のアクセシビリティ・ガイドラインにある使用法を基にして、コンテンツの言語でのアクセシビリティ・サポートの要件を満たしています。ユーザエージェント及び支援技術のサポート情報は、それらのガイドラインに記述されている「製品 XYZ アクセシビリティ・サポート要件」で確認することができます。

「プログラムが解釈」を理解する

いくつもの達成基準で、コンテンツ（又は、コンテンツの特定の部分）が「プログラムが解釈」できることを要件としている。これは、コンテンツが、支援技術を含むユーザエージェントがその情報にアクセスできるような方法で制作されていることを意味する。

ウェブコンテンツ技術（例えば、HTML、CSS、PDF、GIF、MPEG、Flash など）を用いて制作されたコンテンツが、様々なタイプの障害のある利用者にとってアクセシブルであるためには、用いられているウェブコンテンツ技術が、支援技術を含むユーザエージェント及びその他のユーザエージェントのアクセシビリティ機能と連携することが必要不可欠である。コンテンツを「プログラムが解釈」できることを要件としている達成基準に適合するためには、支援技術をサポートしているウェブコンテンツ技術を用いてコンテンツを実装する必要がある。

「プログラムが解釈」できるコンテンツは、（支援技術を含むユーザエージェントによって、）個々の利用者が必要とする様々な感覚（例：視覚、聴覚）のフォーマット又はプレゼンテーションのスタイルに変換することが可能である。既存の支援技術が変換できない場合には、その情報は「プログラムが解釈」できるとはいえない。

この用語を用いているのは、情報が支援技術（及び、アクセシビリティを支援するその他のユーザエージェント）に対してアクセシブルでなければならない部分を、アクセシブルにするために具体的にどのような方法を用いるかという点に言及せずに、WCAG ワーキンググループがはっきりと特定できるようにするためである。技術が絶え間なく変化しているということを考えると、これは重要なことである。この用語によって、ガイドラインを満たすために、何を「プログラムが解釈」できるようにする必要があるのかをガイドライン中で特定できるようになる。そして、時間とともに更新可能な文書群（WCAG 2.0を満たす方法、WCAG 2.0解説書、及び、WCAG 2.0達成方法の文書）を別に用意することができて、ユーザエージェント及び支援技術のサポート状況に基づき、いずれかの時点で目的通りに機能して、十分であると考えられる特定の達成方法を挙げることが可能になる。

「アクセシビリティ・サポーテッド」vs.「プログラムが解釈」

「アクセシビリティ・サポーテッド」は、ユーザエージェント（支援技術を含む）によるウェブコンテンツ技術の特定の使い方に対するサポートと関係がある。ウェブコンテンツ技術のアクセシビリティ・サポーテッドな使い方は、支援技術及び主流なユーザエージェント（ブラウザ及びプレーヤーなど）のアクセシビリティ機能と連携するものである。

「プログラムが解釈」は、ウェブコンテンツにある情報と関係がある。アクセシビリティ・サポーテッドなウェブコンテンツ技術が適切に用いられているならば、支援技術及びユーザエージェントはコンテンツにある情報にアクセスする（すなわち、コンテンツにある情報をプログラムが解釈する）ことができて、その情報を利用者に提示することができる。

情報が支援技術を含むユーザエージェントによって利用者に提示可能であるようにするために、この2つの概念は関連しているものである。コンテンツ制作者は、ウェブコンテンツ技術のアクセシビリティ・サポーテッドな使い方に依存しなければならない。そして、情報をプログラムが解釈できるようにするために、その使い方を適切に用いなければならない。そうすることで、情報は支援技術及びユーザエージェントによって障害のある利用者に提示できるようになる。

適合している代替版を理解する

適合要件 1 は、適合している代替版がある限り、適合していないページを適合の範囲内に含めることを許容している。適合している代替版は、次のように定義されている：

適合している代替版 (conforming alternate version)

以下の事項を満たす版のことを指す:

指定されたレベルで適合しており、かつ
同じ情報及び機能のすべてを同一の自然言語で提供しており、かつ
不適合コンテンツと同時に更新されていて、かつ
以下に挙げる事項のうち少なくとも一つを満たしていること:
1. アクセシビリティサポーテッドなメカニズムを用いて、不適合ページから適合版へ到達できる。もしくは、
2. 不適合版に到達できるのは、適合版からのみである。
3. 不適合版に到達できるのは、適合版に到達するメカニズムも提供している適合ページからのみである。

注記 1: この定義において、「到達できるのは……からのみ」とは、利用者が適合版から来ていない限り、不適合ページに「到達する」 (読み込む) のを防ぐ条件付きリダイレクトのような何らかのメカニズムがある、ということを意味する。

注記 2: 代替版は、元のページと一対一で対応している必要はない (例えば、適合している代替版は複数のページであってもよい)。

注記 3: 複数の言語版が利用できる場合、各言語版に対して、適合している代替版を提供する必要がある。

注記 4: 様々な技術環境、又は利用者層に対応するために、複数の代替版を提供してもよい。この場合、各版は可能なかぎり適合したものでなければならず、適合要件 1を満たすためには、そのうちの一つの版が完全に適合したものでなければならない。

注記 5: 不適合版と同じように自由に利用可能であるかぎり、適合している代替版は、適合宣言の範囲に含まれている必要はなく、同一のウェブサイト上で提供されている必要もない。

注記 6: 代替版は、元のページを補助して理解を高める補足コンテンツと混同されないようにすべきである。

注記 7: コンテンツ内で利用者が設定を行うことで適合版が作り出される仕組みは、その利用者の設定に用いられている手法がアクセシビリティサポーテッドであるかぎり、代替版への到達メカニズムとして条件を満たしているといえる。

これにより、適合宣言の範囲内にあるページ上のすべての情報及びすべての機能は、適合しているウェブページ上で利用可能になる。

なぜ代替版を容認するのか？

なぜ WCAG では、適合宣言に含まれるウェブページの適合している代替版を容認するのか？　言い換えれば、なぜ適合又は適合宣言の範囲内にあって、その適合レベルにある達成基準に適合していないページを含めるのか？

時には、ウェブページが、まだアクセシビリティ・サポーテッドではないウェブコンテンツ技術を用いることがある。新しいウェブコンテンツ技術が登場する際、支援技術によるサポートは遅れをとる、又はターゲットとする利用者だけが利用可能になる。そのため、コンテンツ制作者は、すべての利用者に対して新しい技術だけに依存してコンテンツを提供することはできないことがある。しかし、新しい技術を使用することには、その他の利点があるかもしれない。例えば、より良いパフォーマンス、広範囲の感覚モダリティで利用可能、など。代替版の要件は、アクセシブルな代替版をアクセシビリティ・サポーテッドなウェブコンテンツ技術で提供することによって、コンテンツ制作者がそのような新しい技術を用いたウェブページをウェブサイトに含めることができるようにするためのものである。十分にサポートされている新しいウェブコンテンツ技術を利用できる人は、その新しいバージョンの利点を享受する。将来のアクセシビリティ・サポートを見据えているコンテンツ制作者は、代替版のページを提供することによって、今の時点でも達成基準に適合することが可能である。また、支援技術がサポートするようになった際のことを考えて、新しいウェブコンテンツ技術を用いるページでアクセシビリティ機能を組み込んでおくこともできる。
様々な理由から、ウェブページ上のコンテンツを修正できないこともある。例えば、
- 法的又は歴史的な理由で、文書の見た目をそのままコピーしたものを含めることが重要な意味を持っていることがある。
- そのウェブページはあるウェブサイト内にあるが、そのサイトの所有者には元のページにあるコンテンツを修正できる法的な権利がないかもしれない。
- 企業は、過去に公開したものを削除又は部分的に修正するのが法的に不可能なことがある。
- コンテンツ制作者が、他の部署、政府機関、又は企業から、文書を部分的にでも変更するための許可を得ていないかもしれない。
時には、ある障害に特別に対応するウェブページを制作することによって、その障害がある利用者にとっての最高の体験を提供することがある。そのような場合、すべての達成基準に適合することによって、ウェブページをすべての障害に対応させることは不可能又は非現実的かもしれない。完全に適合している「代替版」のページがある限り、代替版の要件はそのような特別なページを適合宣言の範囲内に含めることを容認している。
アクセシビリティに取り組んでいるサイトの多くには、大量の古いウェブページがある。情報はアクセシブルなフォーマットで入手可能になってきているものの、そういったファイルを大量に削除するには、組織的な抵抗がかなり強かったり、手続き上の障壁があったりするものである。特に政府機関などのように、従来の印刷志向のプロセスを優先している組織もある。こういった組織はインターネットでの情報配信に適応し、アクセシブルなフォーマットの必要性も認識しているにもかかわらず、それでもなお紙の発想のままで、「第一の」バージョンとして紙印刷のために設計されたフォーマットにこだわっている（電子的にしか「発行」されたことのない文書に対してもである）。ワーキンググループは、こういったアプローチは今後廃止されていくべきだと考えるが、アクセシブルなバージョンがすぐに入手可能である限りは、禁止できるものではないと考えている。

達成基準に適合していないウェブページを容認する際の懸念事項としては、障害のある利用者がそういった適合していないウェブページに遭遇し、そのコンテンツを利用することができずに、「適合している代替版」も見つけることができない恐れがあることが挙げられる。そのため、代替版の要件で鍵となるのは、適合していないウェブページに遭遇した際に、そのウェブページから適合しているページ（代替版）を見つけられるようにすることである。よって、代替ページを容認する適合要件は、利用者が複数の代替版の中からアクセシブルなバージョンを見つけることができる方法を提供することも要求している。

注意してほしいのは、代替版を提供することは、WCAG に適合するための最後の選択肢であって、望ましい適合方法はすべてのコンテンツをそのままアクセシブルにすることであるという点である。

適合している代替版を提供するための達成方法

適合している代替版を提供する上で最も重要なのは、適合していないバージョンから適合している代替版を見つけるメカニズムを提供することである。ある特定の達成方法が特定のウェブコンテンツ又は状況において常に可能であるとは限らないため、これには数多くの様々な方法がある。例えば、コンテンツ制作者がサーバーを制御できる場合には、利用者が常に前もって選択できるかなり効果的な達成方法がいくつかある。しかし、多くの場合、コンテンツ制作者はウェブサーバー上のサービスを制御することはできない。そういう場合には、他の達成方法がある。適合していないページでリンクを提供するのも効果的な達成方法だが、すべての適合していないウェブコンテンツ技術がハイパーテキストリンクをサポートしているわけではない。

次に挙げるのは、今までに確認されてきた達成方法である。WCAG ワーキンググループでは、時間とともにその他の達成方法も考案されることを期待している。そして、支援技術を含むユーザエージェントによってサポートされていることが実証されれば、それらのアプローチがここに追加されていくだろうと考えている。例えば、支援技術がアクセスできない新しいウェブコンテンツ技術の開発者は、代替版へのリンクを利用者に自動的に提示する機能をそのウェブコンテンツ技術に組み込んでもよい。

ウェブページの適合している代替版を提供する適合要件を満たすことができる達成方法

次の番号付き項目はいずれも、WCAG ワーキンググループが適合している代替版を提供するのに十分であると考えた達成方法又は達成方法の組合せである。

ワーキンググループが確認したよくある適合要件を満たしていない事例

F19: 適合基準 1 の失敗例－適合していないウェブページの代替となる適合しているバージョンを利用者が見つけられる手段を提供していない

ウェブページの適合している代替版を提供する適合要件でさらに対応が望まれる達成方法（参考）

適合しているバージョンと不適合のバージョンのバージョン間の相互リンクを提供する（リンク追加予定）
不適合のコンテンツが検索結果に表示されないようにする（リンク追加予定）
コンテンツ・ニゴシエーションを利用する（リンク追加予定）
その技術がオフになっている場合、又はサポートされていない場合は、アクセシビリティ・サポーテッドでない技術に依存しているコンテンツを表示しない（リンク追加予定）
メタデータを用いて、適合していないページのURIから適合している代替版を発見できるようにする（リンク追加予定）

適合している代替版の事例

複数のバージョンのサイトがあるイントラネット
ある大企業が、イントラネットのサイト上で新しいウェブコンテンツ技術を使うことによって、異なる技術をベースにしている様々な拠点、及び広範囲に及ぶユーザエージェント及び支援技術を使用している個々の従業員のニーズに対処しづらくなるかもしれないという懸念を抱いていた。この懸念を解消するために、その企業は、使用するウェブコンテンツ技術のアクセシビリティ・サポーテッドな使用法を限定して、すべてのレベル A 達成基準に適合している代替版のコンテンツを制作した。2つのバージョンは相互にリンクされている。
広報互換性を維持している情報サイト
ある情報サイトは、広範囲に及ぶ話題を網羅していて、利用者が自分の探しているトピックをすぐに見つけ出すことができるようにしたいと考えている。そうするために、そのサイトは、人気のある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ページなのかもしれない。

WCAGでは、「ウェブページ」という言葉が、静的な HTML ページよりもずっと多くのものを含むものを指していることに注意することが重要である。このガイドラインで用いられている「ウェブページ」という用語によって、ガイドラインがより理解可能なものになる。しかし、この用語の意味は、ウェブコンテンツ技術の進化とともに拡大し、完全に 'ページのようなもの' ではないものが多い、広範囲に及ぶウェブコンテンツ技術を包含するようになってきている。バーチャルでインタラクティブなコミュニティ全体を提示することのできる「ページ」を包含しながら、ウェブ上に登場してますます増えている動的なウェブページも含んでいる。例えば、「ウェブページ」という用語には、単一の URI で提供される、実体験のようにインタラクティブな映画のような体験も含まれている。

「代替テキスト」を理解する

代替テキストとは、非テキストコンテンツを視覚的に認識できない利用者のために、その非テキストコンテンツの代わりに用いられるテキストのことである。非テキストコンテンツには、写真、図、アプレット、音声ファイルなどがある。例えば、見ることができない利用者は、写真又は図で提示されている情報を見ることができない。代替テキストはそのために提供されていて、利用者がその情報（代替テキスト）を音声に変換することができるようになる。将来は、情報をテキストで持っておくことで、その情報を手話、画像、又は、より平易なテキストに変換できるようになるかもしれない。

障害のある利用者が、このテキストを利用できるようにするためには、テキストは「プログラムが解釈」できなければならない。つまり、テキストは、障害のある利用者の使用している支援技術（及び、ブラウザのアクセシビリティ機能）が読むことができて、利用できるものでなければならない。

また、支援技術を使用している利用者が利用することのできない非テキストコンテンツに遭遇した際に、その代替テキストを見つけ出すことが可能でなければならない。そのためには、テキストがその非テキストコンテンツと「プログラムで関連付け」られていなければならない。つまり、利用者が（自分が使えない）非テキストコンテンツを見つけたら、利用者は自分の支援技術を用いて（自分が利用できる）代替テキストを見つけることができなければならない。

WCAG 2.0 解説書

WCAG 2.0 を理解して実装するためのガイド

W3C ワーキンググループ・ノート 2016 年 3 月 17 日

概要

この文書のステータス