代替テキスト：
ガイドライン 1.1 を理解する
ガイドライン 1.1：代替テキスト： すべての非テキストコンテンツには代替テキストを提供して、拡大印刷、点字、音声、シンボル、平易な言葉などのような、利用者が必要とする形式に変換できるようにする。
ガイドライン 1.1 の意図
このガイドラインの目的は、すべての非テキストコンテンツが、テキストでも利用可能であるようにすることである。"テキスト" とは、電子テキストのことを指し、画像化された文字のことではない。電子テキストには、表現形態がニュートラルであるというユニークな利点がある。すなわち、"テキスト" は、視覚的にも、聴覚的にも、触覚的にも、あるいはそれらの組合せによってもレンダリング可能だということである。つまり、電子テキストでレンダリングされる情報は、利用者のニーズを最もよく満たすどんな形態でも提供可能なのである。また、"テキスト" は、容易に拡大することが可能であり、音声読み上げが可能なので読字障害のある人にとっても理解しやすく、利用者のニーズを最もよく満たすどんな触覚形態でもレンダリング可能である。
注記： コンテンツをシンボルに変換することには、発達障害や発話理解困難のある人のためのグラフィック・シンボルに変換することを含むが、そういったシンボルに限定するわけではない。
ガイドライン 1.1 の参考にすべき実装方法（特定の達成基準に特有ではない実装方法）
このガイドラインにある各達成基準を満たすための実装方法は、この後に達成基準ごとに挙げられている。しかし、このガイドラインに対処するための実装方法がどの達成基準にも該当しない場合は、ここで挙げている。そういった実装方法は、どの達成基準を満たす上でも必須ではないし、十分でもないが、ウェブコンテンツの種類によってはより多くの利用者にとってよりアクセシブルにすることができるものである。
非テキストコンテンツ：
達成基準 1.1.1 を理解する
1.1.1 非テキストコンテンツ： 利用者に提示されるすべての非テキストコンテンツには、同等の目的を果たす代替テキストがある。ただし、以下に挙げる場合は除く （レベル A）：
コントロール、入力： 非テキストコンテンツが、コントロールまたは利用者の入力を受け入れるものである場合、代替テキストは、その目的を説明する識別名を提供している。（コントロールおよび利用者の入力を受け入れるコンテンツに関するその他の要件は、ガイドライン 4.1 を参照のこと。）
時間の経過に伴って変化するメディア： 非テキストコンテンツが、時間の経過に伴って変化するメディアである場合、代替テキストは、少なくとも、その非テキストコンテンツを識別できる説明を提供している。（メディアに関するその他の要件は、ガイドライン 1.2 を参照のこと。）
試験： 非テキストコンテンツが、テキストで提示されると無効になる試験あるいは演習の場合、代替テキストは、少なくともその非テキストコンテンツを識別できる説明を提供している。
感覚的： 非テキストコンテンツが、特定の感覚的体験を創り出すことを主に意図している場合、代替テキストは、少なくともその非テキストコンテンツを識別できる説明を提供している。
CAPTCHA： 非テキストコンテンツが、コンピュータではなく人間がコンテンツにアクセスしていることを確認する目的で用いられている場合、代替テキストは、その非テキストコンテンツの目的を特定し、説明している。なおかつ、他の感覚による知覚に対応して出力するCAPTCHAの代替形式を提供することで、様々な障害に対応している。
装飾、整形、非表示： 非テキストコンテンツが、装飾だけを目的にしている、あるいは見た目の整形のためだけに用いられている、または利用者に提供されるものではない場合、支援技術が無視できるように実装されている。
この達成基準の意図
この達成基準の意図は、非テキストコンテンツにより伝達される情報を、代替テキストを用いることによってアクセシブルにすることである。代替テキストは、利用者のニーズに合わせてあらゆる感覚のモダリティ（例えば、視覚、聴覚、あるいは触覚）を通じてレンダリング可能なので、情報をアクセシブルにする上では最もよい方法である。代替テキストを提供することにより、情報がさまざまなユーザエージェントによってさまざまな方法でレンダリングされることが可能になる。例えば、写真を見ることのできない利用者は、合成音声を用いてその代替テキストを読み上げさせることができる。また、音声ファイルを聞くことのできない利用者は、代替テキストが表示されれば、それを読むことができる。将来的には、代替テキストによって、情報を手話や同じ自然言語のより平易なものにより容易に変換することができるようにもなるだろう。
CAPTCHA に関する注記
CAPTCHA は、アクセシビリティのコミュニティにおいて、議論を呼ぶトピックの一つである。"Inaccessibility of CAPTCHA" という参考資料（W3C Working Group Note）でも解説されているように、CAPTCHA はもともと機械的な自動処理を排除して、人間による操作であることを確認するためのものである。特定の障害のある利用者は、どんな種類の CAPTCHA も解決できないであろう。しかし、CAPTCHA は広く使われており、WCAG ワーキンググループはもし CAPTCHA が完全に禁止されてしまったとしたら、Web サイトは CAPTCHA の使用を見合わせるのではなく、WCAG に適合しないという選択をするだろうと考えた。このことは、障害のある利用者のかなり多くに対してのバリアを生むことになる。この理由から、ワーキンググループは、障害のある利用者のほとんどのニーズを満たし、なおかつ Web サイトが採用可能だと考えられる方法で、CAPTCHA に関する要件を定めることにした。異なる2つの形態の CAPTCHA をサイト上で提供することを要件として、障害のある利用者のほとんどが自分の利用できるものを見つけられるようにしたのである。
中には、最低限の要件を満たしているサイトにはアクセスできない、障害のある利用者もいるため、ワーキンググループは追加の手段を講じることを推奨している。WCAG に適合したいと考える組織は、このトピックの重要性を認識すべきであり、可能なかぎりこのガイドラインの最低要件以上の策を講じるべきである。推奨される追加の手段としては、以下のものがある：
補足情報
非テキストコンテンツには、さまざまな形態があり、この達成基準ではそれぞれをどのように扱うべきかについて特定している。
以下に挙げる状況の他のどれにも該当しない非テキストコンテンツ （例：チャート、ダイアグラム、録音した音声、写真、そしてアニメーション）の場合、代替テキストは同じ情報をあらゆるモダリティ（例えば、視覚、聴覚、あるいは触覚）によってレンダリング可能な形態で入手可能にすることができる。簡潔および長めの代替テキストは、非テキストコンテンツにある情報を伝達するのに必要なだけ用いられる。収録済の音声しか含まないファイルおよび収録済の映像しか含まないファイルは、ここでカバーされていることになる。ライブの音声しか含まないファイルおよびライブの映像しか含まないファイルは、以下でカバーされている（この段落後にある3つ目の段落を参照のこと）。
コントロールあるいは利用者の入力を受け入れる非テキストコンテンツ （例：実行ボタンとして用いられる画像、イメージマップ、あるいは複雑なアニメーション）の場合、識別名を提供してその非テキストコンテンツの目的を説明することで、利用者はその非テキストコンテンツが何で、なぜそこにあるのかが少なくとも分かるようになる。
時間に伴って変化するメディアである非テキストコンテンツは、ガイドライン 1.2 によりアクセシブルになる。しかし、重要なのは利用者がページ上で発見したときにそれが何であるかが分かり、それにより利用者がどのようにしたいかを判断できるようにすることである。そのため、時間に伴って変化するメディアを説明し、場合によってはそのタイトルを提供する代替テキストを提供する。
ライブの音声しか含まないコンテンツ及びライブの映像しか含まないコンテンツの場合、それらと同等の情報を提供する代替テキストを提供することは、ずっとはるかに困難なこともありうる。このようなタイプの非テキストコンテンツに対しては、代替テキストで内容の分かるラベルを提供する。
試験あるいは演習が、部分的または全体的に非テキストのフォーマットで提示されなければならないことがある。その試験あるいは演習が聴覚や視覚を用いて行う必要があるため、テキストに変換することのできない音声あるいは視覚的な情報が提示されるからである。例えば、ヒアリングテストは、もし代替テキストが提供されたとしたら、意味を成さないだろう。視覚能力向上のための演習も、テキスト形式では同様に無意味となってしまう。また、代替テキストのあるスペリングテストも効果がない。このような場合には、代替テキストはその非テキストコンテンツの目的を説明するために提供されるべきである。もちろん、その代替テキストは、試験に合格するために必要な情報と同じものは提供しないことになる。
特定の感覚的な体験を生むことを主目的にしたコンテンツで、言葉では完全に表現できないものもある。例としては、交響楽団の演奏、視覚芸術の作品などが挙げられる。そのようなコンテンツの場合、代替テキストは、内容の分かるラベルと可能ならば補足説明のテキストによって、その非テキストコンテンツを少なくとも確認できるようにする。もしそのコンテンツがそのページにある理由が明らかで、それが説明できるのであれば、そういった情報も含めると役に立つ。
利用者が人間であることを証明するために用いられる、非テキストの仕掛け。スパムロボットやその他のソフトウェアがサイトにアクセスしてくるのを回避するために、CAPTCHA と呼ばれている仕掛けが用いられる。CAPTCHA には、今日の Web ロボットの能力を超えた視覚的あるいは聴覚的なタスクが通常は用意されている。しかし、それに対して代替テキストを提供することは、ロボットでも操作可能なものにしてしまい、その目的を果たせなくなってしまう。こういう場合、代替テキストは、CAPTCHA の目的を説明し、かつ異なるモダリティを用いた代替形式を提供して、さまざまな障害の利用者のニーズに対処していくことになる。
利用者が視覚的に確認したり、理解したりすることを意図していない非テキストコンテンツ。ページ上でテキストを移動させるために用いる透過画像、ログ解析のために用いる非表示の画像、情報は何も伝えていないが単に空白を埋めて見栄えをよくするための渦（swirl)などが、この例として挙げられる。このような画像に代替テキストを記述すると、スクリーンリーダーの利用者がそのページのコンテンツを理解する妨げになるだけである。しかし、その非テキストコンテンツを全くマークアップしなければ、利用者はその非テキストコンテンツが何なのか、どんな情報を見逃してしまったのかを推測させてしまうことになる（実際には何も見逃していなかったとしてもである）。そのため、このような非テキストコンテンツについては、支援技術が無視して、かつ利用者には何も提供しないような方法でマークアップするか、実装する。
達成基準 1.1.1 の具体的なメリット:
この達成基準は、視覚的なコンテンツを知覚するのが困難な利用者の役に立つ。支援技術が、テキストを読み上げたり、視覚的に提示したり、点字に変換したりすることができるようになる。
代替テキストは、写真、図面、その他の画像（例： 線画、グラフィックデザイン、絵画、3D表現）、グラフ、チャート、アニメーションなどの意味を理解するのが困難な利用者の役に立つこともある。
耳が聞こえない、耳が聞こえづらい、あるいは何らかの理由で音声情報を理解するのが困難な人が、テキストでの表現を読むことができるようになる。テキストを手話に自動変換する研究が現在進行中である。
視聴覚の両方に障害のある利用者は、テキストを点字で読むことができるようになる。
加えて、代替テキストは非テキストコンテンツの検索を可能とし、コンテンツをさまざまな方法で再利用できるようにする。
達成基準 1.1.1 の事例
データのグラフ
6月、7月、そして8月にどれだけの数の商品が売れたかを比較している棒グラフがある。簡潔なラベルには、「図1：6月、7月、8月の売上」と書かれている。長めの説明には、グラフの種類が示されていて、そのグラフから見てとれるものに相当する、データの概要、傾向や意味合いが提供されている。可能なところでは、実際のデータがテーブルで提供されている。
演説を録音した音声
「議会での議長の演説」という音声クリップへのリンクがある。そして、テキストのトランスクリプトへのリンクが、その音声クリップへのリンクの直後に提供されている。
車のエンジンがどのように動くのかを紹介するアニメーション
車のエンジンがどのように動くのかを見せているアニメーションがある。音声はなく、そのアニメーションはエンジンがどのように動くかを解説するチュートリアルの一部である。チュートリアルのテキストがすでに全ての説明を提供しているため、そのアニメーションはテキストの代替物であり、その代替テキストにはアニメーションの簡潔な説明のみが記述されていて、より詳細な情報はチュートリアルのテキストを参照している。
交通情報ウェブカメラ
利用者がある大都市の至る所に設置されたさまざまな Web カメラを選択することのできる Web サイトがある。どれか一つのカメラを選択すると、画像が2分おきに更新される。簡潔な代替テキストでは、その Web カメラを 「交通情報 Web カメラ」と説明している。また、そのサイトでは、Web カメラがカバーしているルートのそれぞれの所要時間を表で提供している。そして、その表も2分おきに更新されている。
ニュース記事にある歴史的な出来事の写真
国際サミット会議に関するニュース記事と一緒に、2人の世界的なリーダーが握手をしている写真がある。代替テキストには、「X国のX大統領が、Y国のY首相と握手している」と記述されている。
外交関係を議論するコンテンツにある歴史的な出来事の写真
外交上の衝突におけるニュアンスを説明するための異なる文脈で同じ写真が使われている。首相と握手している大統領の画像が、もつれた外交関係を議論している Web サイトに登場している。最初の代替テキストには、「X国のX大統領が、2009年1月2日に、Y国のY首相と握手している」と書かれている。補足の代替テキストは、両首脳の顔の表情と二人が立っている部屋の説明をしていて、さらにその部屋にいる他の人たちのことも示している。その補足的な説明は、写真と同じページにあるかもしれないし、リンクあるいはその他の標準的なプログラムによるメカニズムによってその画像と関連付けられた別のファイルにあるかもしれない。
記者会見を録音した音声
ウェブページに、記者会見を録音した音声へのリンクがある。リンクテキストは、録音された音声を示している。また、そのページには記者会見のテキストのトランスクリプトへのリンクもある。トランスクリプトには、話者が発言した全ての逐語的な記録がある。そこには、例えば、喝采、笑い、聴衆からの質問など、その録音の一部であるその他の重要な音声とあわせて、誰が話しているのかも記されている。
E-ラーニングアプリケーション
回答が正しいかどうかを示すために効果音を用いている E-ラーニングアプリケーションがある。チャイム音はその回答が正解であることを示し、ビープ音はその回答が正解ではないことを示している。テキストの説明もあり、その音を聞いたり理解したりすることができない利用者も、その回答が正解かどうかを理解することができる。
リンクのあるサムネール画像
「スモールヴィル・タイムス」のウェブサイトにリンクしている、新聞の一面のサムネール画像がある。その代替テキストには、「スモールヴィル・タイムス」と記述されている。
異なるサイトで使われている同じ画像
世界地図の画像に対する異なる代替テキストの例： 旅行サイトで海外旅行コーナーへのリンクとして用いられている世界地図の画像には、「海外旅行」という代替テキストがある。同じ画像が、「国際キャンパス」という代替テキストとともに、ある大学のウェブサイトでリンクとして用いられている。
イメージマップ
ビルのフロアプランのイメージマップ画像はインタラクティブで、利用者が特定の部屋を選択して、その部屋に関する情報のあるページへ移動することができる。「ビルのフロアプラン。より詳細な情報は部屋を選択してください。」という簡潔な代替テキストが、そのイメージマップの画像全体とインタラクションの目的を説明している。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準 1.1.1 の実装方法及び不適合事例 － 非テキストコンテンツ
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
達成基準を満たすことのできる実装方法
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の実装方法（又は、実装方法の組合せ）がある。
状況 F： 非テキストコンテンツを支援技術が無視するようにしなければならない場合：
次に挙げるウェブコンテンツ技術特有の実装方法を用いて、支援技術が非テキストコンテンツを無視するように実装する、又はマークアップする。
達成基準 1.1.1 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
General Techniques for Informative Non-Text Content (Advisory)
Identifying informative non-text content （リンク追加予定）
Keeping short descriptions short （リンク追加予定）
Describing images that include text （リンク追加予定）
Providing a longer description of the non-text content where only a descriptive label is required using a technology-specific technique (for an accessibility-supported content technology) for long description listed
above （リンク追加予定）
Providing different sizes for non-text content when it cannot have an equivalent accessible alternative （リンク追加予定）
Using server-side scripts to resize images of text （リンク追加予定）
General Techniques for Live Non-Text Content (Advisory)
General techniques to minimize the barrier of CAPTCHAs
Providing more than two modalities of CAPTCHAs （リンク追加予定）
Providing access to a human customer service representative who can bypass CAPTCHA （リンク追加予定）
Not requiring CAPTCHAs for authorized users （リンク追加予定）
HTML Techniques (Advisory)
CSS Techniques (Advisory)
ARIA Techniques (Advisory)
Metadata Techniques (Advisory)
達成基準 1.1.1 のよくある不適合事例
以下に挙げているのは、WCAG ワーキンググループが達成基準 1.1.1 に適合していないとみなした、よくある不適合事例である。
重要な用語
- （この文書で用いられている）支援技術
ユーザエージェントとして機能する、あるいは主流のユーザエージェントと一緒に機能するハードウェアおよび/あるいはソフトウェアで、主流のユーザエージェントで提供されている機能以上である障害者利用者の要求を満たすために機能を提供するもの。
注記 1： 代替のプレゼンテーション（例：合成音声や拡大表示したコンテンツ）、代替入力手法（例：音声認識）、付加的なナビゲーションあるいは位置確認のメカニズム、およびコンテンツ変換（例：テーブルをよりアクセシブルにするもの）を含めて支援技術により提供される機能。
注記 2： 支援技術は、API を用いて監視することで、主流のユーザエージェントとデータやメッセージのやりとりをすることが多い。
注記 3: 主流のユーザエージェントと支援技術とを区別するのに、絶対的な基準などはない。多くの主流のユーザエージェントは、障害者を支援する機能を提供している。基本的な差異は、主流のユーザエージェントが障害のある人もない人も含めて、広く多様な利用者をターゲットにしているのに対し、支援技術は、特定の障害のある利用者という狭義の限られた人たちをターゲットにしているということだ。支援技術により提供される支援は、そのターゲット利用者のニーズにより特化しており適切なものである。主流のユーザエージェントは、プログラムのオブジェクトからウェブコンテンツを取り出したり、マークアップを識別可能な構造に解釈したりするようにして、重要な機能を支援技術に提供することができる。
事例： この文書の文脈において重要な支援技術としては、以下のものが挙げられる：
画面拡大ソフトおよびその他の視覚的な表示に関する支援技術。視覚障害、知覚障害、および読書困難などの障害のある人が、レンダリング後のテキストおよび画像の視覚的な読みやすさを改善するために、テキストのフォント、サイズ、間隔、色、音声との同期などを変更するのに使用している。
スクリーンリーダー。全盲の人がテキスト情報を合成音声あるいは点字で読み取るために使用している。
音声変換ソフトウェア。認知障害、言語障害、および学習障害のある人が、テキストを合成音声に変換するために使用している。
音声認識ソフトウェア。何らかの身体障害のある利用者が使用することがある。
代替キーボード。特定の身体障害のある人がキーボードを擬似操作するのに使用している（ヘッドポインタ、シングルスイッチ、呼気・吸気スイッチ、およびその他の特別な入力デバイスを使った代替キーボードを含む）。
代替ポインティングデバイス。特定の身体障害のある人がマウスポインタとボタンを擬似操作するのに使用している。
- CAPTCHA
"Completely Automated Public Turing test to tell Computers and Humans Apart"（コンピュータと人間とを判別する完全自動化されたチューリングテスト）の頭文字語。
注記 1： CAPTCHA テストは、不明瞭な画像あるいは音声ファイルで提示される文字を利用者に入力するよう求めることが多い。
注記 2： チューリングテストは、人間とコンピュータを判別するために設計されたテストの仕組みである。その名は、これを考案した有名なコンピュータ科学者のアラン・チューリングにちなんで名付けられた。この用語は、カーネギーメロン大学の研究者たちによる造語であった。 [CAPTCHA]
- 識別名
ソフトウェアがウェブコンテンツ内の構成要素を利用者に識別させることのできるテキスト
注記 1： 識別名は隠されていて、支援技術に対してのみ明らかにされるが、ラベルはすべての利用者に提示される。多くの場合（すべてではないが）、ラベルと識別名は同じである。
注記 2： これは、HTML の name 属性とは関係がない。
- 非テキストコンテンツ
プログラムで解釈できる文字の並びではないコンテンツ、あるいはその文字の並びが自然言語で何も表現していないコンテンツ。
注記： これには、（文字で作る模様である）ASCII アート、顔文字、（当て字を用いる）リート語、そして文字を表現している画像が含まれる。
- 装飾だけを目的
美的な目的だけを果たしていて、情報は提供せず、機能性も備えていない。
注記： その単語を手直ししたり置き換えたりしてもその目的が変わらないのであれば、テキストは単に装飾だけを目的にしたものといえる。
事例： 辞書の表紙には、その背景にとても淡い文字で単語がランダムに並んでいる。
- 特定の感覚的な体験
単に装飾だけを目的にしたものではなく、また第一に重要な情報を伝えたり機能を提供したりするものではない感覚的な体験。
事例： フルートのソロ演奏、視覚芸術の作品などが例として挙げられる。
- テキスト
プログラムで解釈できる文字の連続で、その連続が自然言語で何かを表現しているもの。
- 代替テキスト
非テキストコンテンツとプログラムで関連付けられている、あるいは非テキストコンテンツとプログラムで関連付けられているテキストから参照されるテキスト。プログラムで関連付けられたテキストとは、その場所が非テキストコンテンツからプログラムで定めることのできるテキストである。
事例： チャートの画像は、チャートの直後にある段落でテキストで説明されている。チャートの簡潔な代替テキストは、説明が後に続くことを示している。
時間の経過に伴って変化するメディア：
ガイドライン 1.2 を理解する
ガイドライン 1.2： 時間の経過に伴って変化するメディアには代替コンテンツを提供する。
ガイドライン 1.2 を理解する
このガイドラインの目的は、時間の経過に伴って変化する、同期したメディアへのアクセスを提供することである。具体的には、次のようなメディアがある：
コンテンツ制作者が、そのコンテンツにはどの達成基準が適用されるのかを素早く容易に判断できるように、各達成基準が適用されるメディアの種類をその簡潔な名前で示している。
映像しか含まないメディア又は映像しか含まないメディアに対しては、達成基準の名前に "映像しか含まない" 又は "映像しか含まない" とあるものを適用するだけでよい。そのメディアが、映像しか含まないメディア又は映像しか含まないメディアではない場合、残りの達成基準すべてが適用される。
そして、メディアは、ライブ又は収録済のどちらかである。その達成基準がライブ又は収録済のどちらのメディアに適用されるのかが、各達成基準の簡潔な名前ではっきりと分かるようになっている。
同期したメディアは、用語集で次のように定義されている：
- 同期したメディア
情報や時間経過をベースにしたインタラクティブな構成要素を提示するために、他のフォーマットと同期した音声または映像。ただし、そのメディアがテキストの代替メディアではっきりとそのようにラベル付けされているものは除く。
インタラクションに付随する音声ファイルは、インタラクションを伴う映像しか含まないファイルと同様に、このガイドラインでカバーされている。これらがカバーされているのは、インタラクションが特定のタイミングで発生しなければならないからである。例えば、「より多くの情報は、今クリックしてください」というテキストのトランスクリプトをつけるのは、全く役に立たない。なぜなら、利用者にはその音声がどのタイミングで「今」と言ったのかが分からないからである。そのため、同期したキャプションが必要となる。
時には、音声ガイドを会話内にある合間にぴったり収めることができないくらい沢山の会話があることがある。同期したメディアの音声ガイドではなく、時間の経過に伴って変化するメディアの代替を提供するレベル A でのオプションは、同期したメディアにある全ての情報へのアクセスを可能にする。また、このオプションは、何らかの理由で音声ガイドが提供されていないとき、非視覚的な形態での視覚的な情報へのアクセスも可能にする。
インタラクションを伴う同期したメディアの場合、時間の経過に伴って変化するメディアの代替の中にインタラクティブな要素（例えば、リンク）を埋め込むことが可能である。
また、このガイドラインには、（レベル AAA で）拡張した音声ガイドとよばれるアプローチとあわせて、同期したメディアへの手話通訳がある。拡張した音声ガイドでは、映像を一時的に停止させて、実際に存在する会話の合間で可能な量よりも多くの音声ガイドを提供することができる。これは、要件を積み上げていくようにして徐々に強めていくという意図があって、低いレベルの達成基準の上にそれよりも高いレベルの達成基準を設けている一例である。
ガイドライン 1.2 の参考にすべき実装方法（特定の達成基準に特有ではない実装方法）
このガイドラインにある各達成基準を満たすための実装方法は、この後に達成基準ごとに挙げられている。 しかし、このガイドラインに対処するための実装方法がどの達成基準にも該当しない場合は、ここで挙げている。そういった実装方法は、どの達成基準を満たす上でも必須ではないし、十分でもないが、ウェブコンテンツの種類によってはより多くの利用者にとってよりアクセシブルにすることができるものである。
- このガイドラインの参考にすべき実装方法はすべて、特定の達成基準に関係している。
収録済の音声しか含まないメディア及び収録済の映像しか含まないメディア：
達成基準 1.2.1 を理解する
この達成基準の意図は、収録済の音声しか含まないコンテンツ及び収録済の映像しか含まないコンテンツの伝える情報を、すべての利用者が入手できるようにすることである。時間の経過に伴って変化するメディアの代替は、それがテキストベースであれば、情報をアクセシブルにする。それは、利用者のニーズに合った、あらゆる感覚のモダリティ（例えば、視覚、聴覚、又は触覚）を通じて、テキストがレンダリング可能だからである。将来的には、テキストをシンボル、手話、あるいはその言語でよりシンプルなかたちに変えることも可能になるのではないだろうか。
収録済の映像コンテンツの場合、コンテンツ制作者には音声トラックを提供するというオプションがある。それにより、視覚障害の有無に関係なく、利用者はコンテンツを同時にコンテンツを楽しむことが可能になる。また、映像と音声の並行したプレゼンテーションを提供することにより、認知障害、言語障害、及び学習障害のある利用者がコンテンツを理解しやすくなることにもつながる。
「達成基準 1.2.9 ライブの音声しか含まないコンテンツの代替」を理解するも参照のこと。
この達成基準は、視覚的なコンテンツを知覚するのが困難な利用者の役に立つ。支援技術が、代替テキストを音声で読み上げたり、視覚的に提示したり、点字に変換したりすることが可能になる。
時間の経過に伴って変化するメディアの代替は、それがテキストベースであれば、収録済の映像コンテンツの意味を理解するのが困難な利用者の役に立つことがある。
音声が聞こえない、音声が聞こえにくい、又は何らかの理由で音声情報を理解しづらい利用者が、テキストのプレゼンテーションを読むことができるようになる。また、テキストを手話に自動通訳する研究が現在進められている。
視聴覚の両方に障害のある利用者が、テキストを点字で読むことができるようになる。
加えて、テキストは、非テキストコンテンツを検索可能なものにし、コンテンツをさまざまな方法で再利用できるようにする。
演説を録音した音声
「議会での議長の演説」という音声クリップへのリンクがある。そして、テキストによるトランスクリプトへのリンクが、その音声クリップへのリンクの直後に提供されている。
記者会見を録音した音声
ウェブページに、記者会見を録音した音声へのリンクがあり、リンクテキストが録音された音声であることを示している。また、そのページには記者会見のテキストのトランスクリプトへのリンクもある。トランスクリプトには、話者が発言した全ての逐語的な記録がある。そこには、例えば、喝采、笑い、聴衆からの質問など、その録音の一部であるその他の重要な音声とあわせて、誰が話しているのかも記されている。
車のエンジンがどのように動くのかを紹介するアニメーション
車のエンジンがどのように動くのかを見せているアニメーションがある。音声はなく、そのアニメーションはエンジンがどのように動くかを解説するチュートリアルの一部である。チュートリアルのテキストがすでに全ての説明を提供しているため、そのアニメーションはテキストの代替物であり、その代替テキストにはアニメーションの簡潔な説明のみが記述されていて、より詳細な情報はチュートリアルのテキストを参照している。
音声トラック付きの、映像しか含まないファイル
無音映画に音声トラックがあり、映像に見られる動きや振る舞いを説明している。
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の実装方法（又は、実装方法の組合せ）がある。
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
Providing a transcript of a live audio only presentation after the fact （リンク追加予定）
Linking to textual information that provides comparable information (e.g., for a traffic Webcam, a municipality could provide a link to the text traffic report.) （リンク追加予定）
以下に挙げているのは、WCAG ワーキンググループが達成基準 1.2.1 に適合していないとみなした、よくある不適合事例である。
- 時間の経過に伴って変化するメディアの代替
時間に伴って変化する視覚的および聴覚的情報のトランスクリプトを含み、時間に伴って変化する情報のやりとりの結果を得る手段を提供する文書。
注記： 同期したメディアのコンテンツを作るために用いられる脚本は、編集後の最終的な同期したメディアを正確に描写したものに訂正されている場合のみ、この定義を満たすことになる。
- 音声しか含まない
音声のみを含んだ、時間の経過に伴って変化する表現（映像やインタラクションを含まない）。
- テキストの代替メディア
テキストで（直接あるいは代替テキストによって）既に提示されている情報以上のものは提示していないメディア。
注記： テキストの代替メディアは、テキストの代替プレゼンテーションの恩恵を受ける人たちのために提供される。テキストの代替メディアになるのは、音声しか含まないメディア、映像しか含まないメディア（手話の映像を含む）、あるいは音声付映像メディアである。
- 収録済
ライブではない情報。
- 映像しか含まない
映像しか含まない、時間の経過に伴って変化する表現（音声を含まず、インタラクションも含まない）。
収録済の音声コンテンツのキャプション:
達成基準 1.2.2 を理解する
この達成基準の意図は、音声が聞こえない、又は音声が聞こえにくい利用者が、同期したメディアのプレゼンテーションを見られるようにすることである。キャプションは、コンテンツの中で音声トラックを通じて提示されている部分の代替を提供するものである。キャプションには、会話の内容だけを含むのではなく、誰が話しているのかも示し、また、発話ではなく、音声（意味のある効果音を含む）によって伝えられている情報も含める。
現在のところ、一刻を争う素材に対してキャプションを作成するのが困難であることは、一般に広く認められている。そのため、コンテンツ制作者は、キャプションの完成を待って情報発信を遅らせるか、もしくは待たずに情報を発信してしまうか、という選択を迫られることになる。いずれは、情報配信プロセスの中にキャプション作成を組み込むツールや、キャプションを付加するツールによって、そういった遅延は短縮化されるか、なくなるだろう。
ただし、同期したメディア自体が、ウェブページ上でテキストによってすでに提示されている情報の代替プレゼンテーションである際には、キャプションは必要ない。例えば、ページ上の情報に同期したメディアのプレゼンテーションが付随していて、そのメディアがテキストですでに提示されている情報以上のものは提示していないが、認知障害、言語障害、又は学習障害のある利用者にとってはそれが理解しやすい場合がある。そのような場合には、キャプションを提供する必要はない。なぜなら、その情報は、ページ上でテキストあるいは（画像の）代替テキストによって、すでに提供されているからである。
「達成基準 1.2.4 ライブの音声コンテンツのキャプション」を理解するも参照のこと。
キャプションを提供しているチュートリアル
結び目の作り方を紹介している映像があり、次のようなキャプションが提供されている。
"（音楽）
水兵、兵士、そして木こりのような人たちにとっては、
ロープを使って結び目を作るのは、重要なスキルでした。"
Whit Anderson氏による、トランスクリプトのフォーマットのサンプルより。
複雑な法律文書には、段落ごとに同期したメディアクリップがあり、その段落の内容を話している人がいる。各クリップは、その対応する段落と関連付けられていて、その同期したメディアには、キャプションが提供されていない。
取扱説明書で、ある部品に関して記述されていて、その使用方法の説明部分には同期したメディアクリップがあり、その部品の正しい使用方法を紹介している。その同期したメディアには、キャプションが提供されていない。
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
Providing a note saying "No sound is used in this clip" for video-only clips （リンク追加予定）
Using SMIL 1.0 to provide captions for all languages for which there are audio tracks （リンク追加予定）
Using SMIL 2.0 to provide captions for all languages for which there are audio tracks （リンク追加予定）
以下に挙げているのは、WCAG ワーキンググループが達成基準 に適合していないとみなした、よくある不適合事例である。 1.2.2 by the WCAG Working Group.
- 音声
音声再生の技術。
注記： 音声は、合成的に生成されたものであったり（音声合成を含む）、実世界で録音したものであったり、またその両方もありうる。
- キャプション
そのメディアのコンテンツを理解するのに必要な、発話および発話ではない音声情報の両方に対する、同期した視覚的表現あるいは代替テキスト。
注記 1：Captions are similar to dialogue-only subtitles except captions convey not only the content of spoken dialogue, but also equivalents for non-dialogue audio information needed to understand the program content, including sound effects, music, laughter, speaker identification and location.
注記 2：クローズド・キャプションは、プレーヤーによっては ON/OFF を切り替えることのできる等価物である。
注記 3:オープン・キャプションは、OFFにすることのできないキャプションである。例えば、キャプションが映像に埋め込まれた、視覚的に等価な画像化された文字である場合がある。
注記 4: キャプションは、映像の関連情報を分かりにくくしたり遮ったりすべきではない。
注記 5: 国によっては、キャプションはサブタイトル（字幕）と呼ばれている。
注記 6:音声ガイドは既に視覚的に提示されている情報の説明なので、キャプションにしてもよいが、そうする必要があるわけではない。
- テキストの代替メディア
テキストで（直接あるいは代替テキストによって）既に提示されている情報以上のものは提示していないメディア。
注記： テキストの代替メディアは、テキストの代替プレゼンテーションの恩恵を受ける人たちのために提供される。テキストの代替メディアになるのは、音声しか含まないメディア、映像しか含まないメディア（手話の映像を含む）、あるいは音声付映像メディアである。
- 収録済
ライブではない情報。
- 同期したメディア
情報や時間経過をベースにしたインタラクティブな構成要素を提示するために、他のフォーマットと同期したまたは映像。ただし、そのメディアがテキストの代替メディアではっきりとそのようにラベル付けされているものは除く。
収録済の映像コンテンツの音声ガイド又は代替:
達成基準 1.2.3 を理解する
この達成基準の意図は、全盲または視覚障害のある利用者が、同期したメディアのプレゼンテーションにある視覚的な情報を入手できるようにすることである。この達成基準では、2つのアプローチを記述しており、どちらを用いてもよい。
1つめのアプローチは、映像コンテンツの音声ガイドを提供することである。音声ガイドは、利用者が映像の情報を入手できない場合のために、利用者が必要とする情報をそのプレゼンテーションの音声部分に加えて、映像コンテンツを増補するものである。発話の合間に存在する無音部分を使って、動き、登場人物、シーンの変化、画面上の文字に関する情報のうち、コンテンツを理解する上で重要で、かつ主音声では説明されていなかったり、話されていない情報を、音声ガイドで提供する。
2つめのアプローチは、同期したメディアにある（視覚的及び聴覚的な）情報全てをテキスト形式で提供することである。時間の経過に伴って変化するメディアの代替は、同期したメディアのコンテンツで提供されているすべての情報をそのままに提供するものである。時間の経過に伴って変化するメディアの代替は、いわば台本や書物のようなものである。音声ガイドとは異なり、映像部分の説明が、既存の発話の合間だけに制限されることはない。視覚的な状況、登場人物の動きや表情、及びその他のあらゆる視覚的なものを含めて、全ての視覚的な情報について、説明を十分に提供する。さらに、発話ではない音声（笑い声、画面の外から聞こえてくる声など）を説明し、すべての発話のトランスクリプトを含む。そして、そういった説明と発話のトランスクリプトの登場順は、同期したメディア自体での登場順と同じである。結果的に、時間の経過に伴って変化するメディアの代替は、同期したメディアコンテンツについて、音声ガイドだけでの場合よりもずっと多くの完全な説明を提供することが可能である。
同期したメディアのプレゼンテーションの一部分として何らかのインタラクションがある場合（例："質問に今答えてください"）、時間の経過に伴って変化するメディアの代替は、ハイパーリンク又は同じ機能を提供するのに必要なものを提示することになる。
注記 1： 達成基準 1.2.3、1.2.5、及び 1.2.7 では、映像トラックにある情報のすべてが音声トラックですでに提供されている場合には、音声ガイドを必要としない。
注記 2： 達成基準 1.2.3、1.2.5、及び 1.2.8 は、お互いに重なり合う部分がある。これは、最低限の適合レベルではコンテンツ制作者に選択肢を与え、より高い適合レベルでは付加的な要件を提示するためである。達成基準 1.2.3 のレベル A では、コンテンツ制作者には、音声ガイド又は完全な代替テキストのどちらかを提供するという選択肢がある。レベル AA で適合したい場合、達成基準 1.2.5 において、コンテンツ制作者は音声ガイドを提供しなければならない。もし達成基準 1.2.3 を満たすための代替コンテンツとして音声ガイドを選択していれば、レベル AA の要件をすでに満たしていることになるが、そうでなければこれは付加的な要件ということになる。達成基準 1.2.8 のレベル AAA では、コンテンツ制作者は拡張したテキストの説明を提供しなければならない。達成基準 1.2.3 及び 1.2.5 において音声ガイドだけを提供することで要件を満たしていた場合には、達成基準 1.2.8 が付加的な要件ということになる。しかし、達成基準 1.2.3 をテキストの説明による代替を提供することで満たし、なおかつ達成基準 1.2.5 の音声ガイドの要件を満たしている場合には、達成基準 1.2.8 は新しい要件を付加することにはならない。
達成基準 1.2.5 収録済の映像コンテンツの音声ガイド」を理解する、「達成基準 1.2.7 収録済の映像コンテンツの拡張した音声ガイド」を理解する、及び「達成基準 1.2.8 収録済のメディアの代替」を理解するも参照のこと。
音声ガイドを提供している映画
音声ガイド： タイトル "Teaching Evolution ケーススタディ ボニー・チェン" くちばしが長くて薄い鳥の写真を、先生が見せている。
ボニー・チェン： "これらの写真はすべて、フロリダのエバーグレイド国立公園で撮影されたものです。"
音声ガイド： 先生が生徒一人ひとりに2つの平らで薄い木の棒切れを手渡ししています。
ボニー・チェン： "今日、皆さんは、こんなくちばしをした、脚の長い鳥になったふりをしてください。"
音声ガイド： 先生が、2つの棒切れを口にあてて、くちばしの形を作っています。
音声のトランスクリプトは、"Teaching Evolution ケーススタディ ボニー・チェン"(copyright WGBH and Clear Blue Sky Productions, Inc.) の冒頭の数分間に基づいいる。
ある研修ビデオでの、時間の経過に伴って変化するメディアの代替
ある企業が、従業員のための研修ビデオを購入し、その企業のイントラネット上に置いている。そのビデオでは、新しい技術の使い方を説明していて、同時にそれを説明しながら実演する人物が登場している。ビデオの発話部分の合間に、視覚的なデモの音声ガイドを挿入する時間的な余裕がないため、その企業では、そのデモを見ることができない人を含む従業員すべてがその内容をよりよく理解することができるように、時間の経過に伴って変化するメディアに代替コンテンツを提供している。
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
以下に挙げているのは、WCAG ワーキンググループが達成基準 1.2.3 に適合していないとみなした、よくある不適合事例である。
（今のところ、文書化されている不適合事例がない）
- 時間の経過に伴って変化するメディアの代替
時間に伴って変化する視覚的および聴覚的情報のトランスクリプトを含み、時間に伴って変化する情報のやりとりの結果を得る手段を提供する文書。
注記： 同期したメディアのコンテンツを作るために用いられる脚本は、編集後の最終的な同期したメディアを正確に描写したものに訂正されている場合のみ、この定義を満たすことになる。
- 音声ガイド
音声トラックに追加されたナレーションで、主音声のトラックだけでは理解できない重要で視覚的な細部を説明するもの。
注記 1： 映像の音声ガイドは、動作やしぐさ、登場人物、場面の変化、画面上の文字、およびその他の視覚的なコンテンツに関する情報を提供する。
注記 2： 標準的な音声ガイドでは、ナレーションが会話の合間に追加されている。（拡張した音声ガイドも参照のこと。）
注記 3:すべての映像の情報がすでに既存の音声で提供されている場合、補足の音声ガイドは不要である。
注記 4: "ビデオ説明" や "説明ナレーション" とも呼ばれる。
- テキストの代替メディア
テキストで（直接あるいは代替テキストによって）既に提示されている情報以上のものは提示していないメディア。
注記： テキストの代替メディアは、テキストの代替プレゼンテーションの恩恵を受ける人たちのために提供される。テキストの代替メディアになるのは、音声しか含まないメディア、映像しか含まないメディア（手話の映像を含む）、あるいは音声付映像メディアである。
- 収録済
ライブではない情報。
- 同期したメディア
情報や時間経過をベースにしたインタラクティブな構成要素を提示するために、他のフォーマットと同期した音声または映像。ただし、そのメディアがテキストの代替メディアではっきりとそのようにラベル付けされているものは除く。
- 映像
連続した写真や画像を動かす技術。
注記： 映像は、アニメあるいは写真の画像、もしくはその両方で構成可能である。
ライブの音声コンテンツのキャプション:
達成基準 1.2.4 を理解する
この達成基準の意図は、音声が聞こえない、あるいは音声が聞こえにくい利用者がリアルタイムのプレゼンテーションを見られるようにすることである。キャプションは、コンテンツの中で音声トラックを通じて提示されている部分の代替を提供するものである。キャプションには、会話の内容だけを含むのではなく、誰が話しているのかも示し、また、意味のある効果音やその他の重要な音声も含める。
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
（まだ文書化されていない）
以下に挙げているのは、WCAG ワーキンググループが達成基準 に適合していないとみなした、よくある不適合事例である。 1.2.4 by the WCAG Working Group.
（今のところ、文書化されている不適合事例がない）
- 音声
音声再生の技術。
注記： 音声は、合成的に生成されたものであったり（音声合成を含む）、実世界で録音したものであったり、またその両方もありうる。
- キャプション
そのメディアのコンテンツを理解するのに必要な、発話および発話ではない音声情報の両方に対する、同期した視覚的表現あるいは代替テキスト。
注記 1： キャプションは、発話のみの字幕と似ているが、次の点において異なる。キャプションは、発話コンテンツだけでなく、その番組コンテンツを理解するのに必要な、発話ではない音声情報と等価な内容も伝える。つまり、効果音、音楽、笑い声、話者の特定、そして位置なども含まれるのである。
注記 2： クローズド・キャプションは、プレーヤーによっては ON/OFF を切り替えることのできる等価物である。
注記 3: オープン・キャプションは、OFFにすることのできないキャプションである。例えば、キャプションが映像に埋め込まれた、視覚的に等価な画像化された文字である場合がある。
注記 4: キャプションは、映像の関連情報を分かりにくくしたり遮ったりすべきではない。
注記 5: 国によっては、キャプションはサブタイトル（字幕）と呼ばれている。
注記 6: 音声ガイドは既に視覚的に提示されている情報の説明なので、キャプションにしてもよいが、そうする必要があるわけではない。
- ライブ
実世界のイベントから取り込まれ、放送による遅延があるだけで受け手に送信される情報。
注記 1： 放送の遅延は、時間的に短い（通常は自動的な）遅れで、例えば放送局に音声（あるいは映像）を待ち行列に入れる、あるいは検閲する時間を与えるために用いられるものだが、編集できるほどの長さではない。
注記 2： もし情報が完全にコンピュータで生成されたものならば、それはライブではない。
- 同期したメディア
情報や時間経過をベースにしたインタラクティブな構成要素を提示するために、他のフォーマットと同期した音声または映像。ただし、そのメディアがテキストの代替メディアではっきりとそのようにラベル付けされているものは除く。
収録済の映像コンテンツの音声ガイド:
達成基準 1.2.5 を理解する
この達成基準の意図は、全盲あるいは視覚障害のある利用者に、同期したメディアのプレゼンテーションにある視覚的な情報を提供することである。 音声ガイドは、利用者が映像の情報を入手できない場合のために、利用者が必要とする情報をそのプレゼンテーションの音声部分に加えて、映像コンテンツを増補するものである。 発話の合間に存在する無音部分を使って、動き、登場人物、シーンの変化、画面上の文字に関する情報のうち、コンテンツを理解する上で重要で、かつ主音声では説明されていなかったり、話されていない情報を、音声ガイドで提供する。
注記 1：達成基準 1.2.3、1.2.5、及び 1.2.7 では、映像トラックにある情報のすべてが音声トラックですでに提供されている場合には、音声ガイドを必要としない。
注記 2： 達成基準 1.2.3、1.2.5、及び 1.2.8 は、お互いに重なり合う部分がある。これは、最低限の適合レベルではコンテンツ制作者に選択肢を与え、より高い適合レベルでは付加的な要件を提示するためである。達成基準 1.2.3 のレベル A では、コンテンツ制作者には、音声ガイド又は完全な代替テキストのどちらかを提供するという選択肢がある。 レベル AA で適合したい場合、達成基準 1.2.5 において、コンテンツ制作者は音声ガイドを提供しなければならない。もし達成基準 1.2.3 を満たすための代替コンテンツとして音声ガイドを選択していれば、レベル AA の要件をすでに満たしていることになるが、そうでなければこれは付加的な要件ということになる。 達成基準 1.2.8 のレベル AAA では、コンテンツ制作者は拡張したテキストの説明を提供しなければならない。達成基準 1.2.3 及び 1.2.5 において音声ガイドだけを提供することで要件を満たしていた場合には、達成基準 1.2.8 が付加的な要件ということになる。 しかし、達成基準 1.2.3 をテキストの説明による代替を提供することで満たし、なおかつ達成基準 1.2.5 の音声ガイドの要件を満たしている場合には、達成基準 1.2.8 は新しい要件を付加することにはならない。
音声ガイドを提供している映画
音声ガイド： タイトル "Teaching Evolution ケーススタディ Bonnie Chen" くちばしが長くて薄い鳥の写真を、先生が見せている。
ボニー・チェン： "これらの写真はすべて、フロリダのエバーグレイド国立公園で撮影されたものです。"
音声ガイド： 先生が生徒一人ひとりに2つの平らで薄い木の棒切れを手渡ししています。
ボニー・チェン： "今日、皆さんは、こんなくちばしをした、脚の長い鳥になったふりをしてください。"
音声ガイド： 先生が、2つの棒切れを口にあてて、くちばしの形を作っています。
音声のトランスクリプトは、"Teaching Evolution ケーススタディ ボニー・チェン"(copyright WGBH and Clear Blue Sky Productions, Inc.) の冒頭の数分間に基づいいる。
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
Providing audio description in multiple languages in SMIL 1.0 （リンク追加予定）
Providing audio description in multiple languages in SMIL 2.0 （リンク追加予定）
Providing audio description for live synchronized media （リンク追加予定）
以下に挙げているのは、WCAG ワーキンググループが達成基準 1.2.5 に適合していないとみなした、よくある不適合事例である。
（今のところ、文書化されている不適合事例がない）
- 音声ガイド
音声トラックに追加されたナレーションで、主音声のトラックだけでは理解できない重要で視覚的な細部を説明するもの。
注記 1：映像の音声ガイドは、動作やしぐさ、登場人物、場面の変化、画面上の文字、およびその他の視覚的なコンテンツに関する情報を提供する。
注記 2： 標準的な音声ガイドでは、ナレーションが会話の合間に追加されている。（拡張した音声ガイドも参照のこと。）
注記 3:すべての映像の情報がすでに既存の音声で提供されている場合、補足の音声ガイドは不要である。
注記 4: "ビデオ説明" や "説明ナレーション" とも呼ばれる。
- 収録済
ライブではない情報。
- 同期したメディア
情報や時間経過をベースにしたインタラクティブな構成要素を提示するために、他のフォーマットと同期した音声または映像。ただし、そのメディアがテキストの代替メディアではっきりとそのようにラベル付けされているものは除く。
- 映像
連続した写真や画像を動かす技術。
注記： 映像は、アニメあるいは写真の画像、もしくはその両方で構成可能である。
収録済の音声コンテンツの手話通訳:
達成基準 1.2.6 を理解する
この達成基準の意図は、音声が聞こえない、又は音声が聞こえにくい利用者で手話の分かる人が、同期したメディアのプレゼンテーションにおける音声トラックのコンテンツを理解できるようにすることである。例えば、キャプションのように、書かれたテキストというのは、第二言語であることがよくある。手話は、イントネーション、感情、及びキャプションには反映されないが手話通訳には反映されるその他の音声情報を提供するので、手話通訳は同期したメディアの内容に対してキャプションよりも豊富で等価な情報を提供することができる。また、手話で頻繁にコミュニケーションを図っている利用者にとっては、手話で提供された情報のほうがより早く理解できるので、同期したメディアが時間の経過に伴って変化するメディアとなる。
事例 1. ある企業が、従業員すべてに対して重要な発表をしている。総会は本社で行われていて、その模様がウェブへストリーミング配信されている。総会の場には手話通訳者がいて、ライブの映像にはプレゼンテーションをしている人物及び手話通訳者の全身が映し出されている。
事例 2. 事例 1 にあるのと同じ発表が、遠隔地にいる従業員にはウェブキャストで届けられている。画面が一つしかないため、手話通訳者は画面のコーナーに映し出されている。
事例 3. ある大学が、講義をする教授の同期したメディアによるプレゼンテーションを作成して、講義のオンライン版を提供している。そのプレゼンテーションには、化学の実験を解説して実演している教授の映像がある。講義内容の手話通訳を制作して、ウェブ上で同期したメディア版とあわせて提供している。
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
以下に挙げているのは、WCAG ワーキンググループが達成基準 1.2.6 に適合していないとみなした、よくある不適合事例である。
（今のところ、文書化されている不適合事例がない）
- 音声
音声再生の技術。
注記： 音声は、合成的に生成されたものであったり（音声合成を含む）、実世界で録音したものであったり、またその両方もありうる。
- 収録済
ライブではない情報。
- 手話通訳
ある言語、通常は話し言葉を、手話に訳すこと。
注記： 本来の手話は、同じ国や地域の話し言葉とは関係のない独立したものである。
- 同期したメディア
情報や時間経過をベースにしたインタラクティブな構成要素を提示するために、他のフォーマットと同期した音声または映像。ただし、そのメディアがテキストの代替メディアではっきりとそのようにラベル付けされているものは除く。
収録済の映像コンテンツの拡張した音声ガイド:
達成基準 1.2.7 を理解する
この達成基準の意図は、全盲又は視覚障害のある利用者に、同期したメディアのプレゼンテーションについての情報を標準的な音声ガイドよりも多く提供することである。同期したメディアのプレゼンテーションを一時的に停止させて、追加の音声ガイドを再生することで提供できる。その再生が終わった後に、同期したメディアのプレゼンテーションを再開する。
ただし、追加の説明を必要としない利用者にとっては、閲覧の邪魔になってしまうため、その機能のオン / オフを切り替えることのできる方法を提供する。あるいは、その代わりに、拡張した音声ガイドのあるバージョンとないバージョンとを提供してもよい。
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
以下に挙げているのは、WCAG ワーキンググループが達成基準 1.2.7 に適合していないとみなした、よくある不適合事例である。
（今のところ、文書化されている不適合事例がない）
- 音声ガイド
音声トラックに追加されたナレーションで、主音声のトラックだけでは理解できない重要で視覚的な細部を説明するもの。
注記 1： 映像の音声ガイドは、動作やしぐさ、登場人物、場面の変化、画面上の文字、およびその他の視覚的なコンテンツに関する情報を提供する。
注記 2： 標準的な音声ガイドでは、ナレーションが会話の合間に追加されている。（拡張した音声ガイドも参照のこと。）
注記 3: すべての映像の情報がすでに既存の音声で提供されている場合、補足の音声ガイドは不要である。
注記 4: "ビデオ説明" や "説明ナレーション" とも呼ばれる。
- 拡張した音声ガイド
追加の説明を付加する時間を作るために映像を一時停止させて、視聴覚のプレゼンテーションに付加した音声ガイド。
注記： この実装方法は、追加の音声ガイドがないと映像の意味が損なわれてしまい、かつ、会話やナレーションの合間が短すぎるときのみに用いられる。
- 収録済
ライブではない情報。
- 同期したメディア
情報や時間経過をベースにしたインタラクティブな構成要素を提示するために、他のフォーマットと同期した音声または映像。ただし、そのメディアがテキストの代替メディアではっきりとそのようにラベル付けされているものは除く。
- 映像
連続した写真や画像を動かす技術。
注記： 映像は、アニメあるいは写真の画像、もしくはその両方で構成可能である。
収録済のメディアの代替:
達成基準 1.2.8 を理解する
この達成基準の意図
この達成基準の意図は、視力が弱すぎてキャプションを確実に読むことができず、なおかつ聴力も弱すぎて発話や音声ガイドを確実に聞くことができない利用者が、視聴覚的なコンテンツを利用できるようにすることである。時間の経過に伴って変化するメディアの代替を提供することで、それが可能になる。
アプローチは、同期したメディアにある（視覚的及び聴覚的な）情報全てをテキスト形式で提供することである。時間の経過に伴って変化するメディアの代替は、同期したメディアのコンテンツで提供されているすべての情報をそのままに提供するものである。時間の経過に伴って変化するメディアの代替は、本のようなものになる。 音声ガイドとは異なり、映像部分の説明が、既存の発話の合間だけに制限されることはない。 視覚的な状況、登場人物の動きや表情、及びその他のあらゆる視覚的なものを含めて、全ての視覚的な情報について、説明を十分に提供する。さらに、発話ではない音声（笑い声、画面の外から聞こえてくる声など）を説明し、すべての発話のトランスクリプトを含む。そして、そういった説明と発話のトランスクリプトの登場順は、同期したメディア自体での登場順と同じである。そして、そういった説明と発話のトランスクリプトの登場順は、同期したメディア自体での登場順と同じである。結果的に、時間の経過に伴って変化するメディアの代替は、同期したメディアコンテンツについて、音声ガイドだけでの場合よりもずっと多くの完全な説明を提供することが可能である。
同期したメディアのプレゼンテーションの一部分として何らかのインタラクションがある場合（例："質問に今答えてください"）、時間の経過に伴って変化するメディアの代替は、ハイパーリンク又は同じ機能を提供するのに必要なものを提示することになる。
視力が弱すぎてキャプションを確実に読むことができず、なおかつ聴力も弱すぎて発話を確実に聞き取ることのできない利用者は、点字ピンディスプレイを使うことによって、時間の経過に伴って変化するメディアの代替を利用することができる。
注記 1： 達成基準 1.2.3、1.2.5、及び 1.2.7 では、映像トラックにある情報のすべてが音声トラックですでに提供されている場合には、音声ガイドを必要としない。
注記 2： 達成基準 1.2.3、1.2.5、及び 1.2.8 は、お互いに重なり合う部分がある。 これは、最低限の適合レベルではコンテンツ制作者に選択肢を与え、より高い適合レベルでは付加的な要件を提示するためである。 達成基準 1.2.3 のレベル A では、コンテンツ制作者には、音声ガイド又は完全な代替テキストのどちらかを提供するという選択肢がある。 レベル AA で適合したい場合、達成基準 1.2.5 において、コンテンツ制作者は音声ガイドを提供しなければならない。もし達成基準 1.2.3 を満たすための代替コンテンツとして音声ガイドを選択していれば、レベル AA の要件をすでに満たしていることになるが、そうでなければこれは付加的な要件ということになる。 達成基準 1.2.8 のレベル AAA では、コンテンツ制作者は拡張したテキストの説明を提供しなければならない。達成基準 1.2.3 及び 1.2.5 において音声ガイドだけを提供することで要件を満たしていた場合には、達成基準 1.2.8 が付加的な要件ということになる。 しかし、達成基準 1.2.3 をテキストの説明による代替を提供することで満たし、なおかつ達成基準 1.2.5 の音声ガイドの要件を満たしている場合には、達成基準 1.2.8 は新しい要件を付加することにはならない。
達成基準 1.2.8 の事例
事例 1. ある研修ビデオでの、時間の経過に伴って変化するメディアの代替
あるコミュニティ・センターが、その会員向けに研修ビデオを購入し、それをセンターのイントラネットに置いている。そのビデオでは、新しい技術の使い方を説明していて、同時にそれを説明しながら実演する人物が登場している。そのコミュニティ・センターでは、同期したメディアにあるプレゼンテーションを見ることも、説明を聞くこともできない利用者を含めて、すべての会員が提供されている内容をよりよく理解できるように、時間の経過に伴って変化するメディアに代替を提供している。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
（まだ文書化されていない）
達成基準 1.2.8 の実装方法及び不適合事例 － 収録済のメディアの代替
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
達成基準を満たすことのできる実装方法
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の実装方法（又は、実装方法の組合せ）がある。
達成基準 1.2.8 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
達成基準 1.2.8 のよくある不適合事例
以下に挙げているのは、WCAG ワーキンググループが達成基準 1.2.8 に適合していないとみなした、よくある不適合事例である。
重要な用語
- 時間の経過に伴って変化するメディアの代替
時間に伴って変化する視覚的および聴覚的情報のトランスクリプトを含み、時間に伴って変化する情報のやりとりの結果を得る手段を提供する文書。
注記： 同期したメディアのコンテンツを作るために用いられる脚本は、編集後の最終的な同期したメディアを正確に描写したものに訂正されている場合のみ、この定義を満たすことになる。
- 収録済
ライブではない情報。
- 同期したメディア
情報や時間経過をベースにしたインタラクティブな構成要素を提示するために、他のフォーマットと同期した音声または映像。ただし、そのメディアがテキストの代替メディアではっきりとそのようにラベル付けされているものは除く。
- 映像しか含まない
映像しか含まない、時間の経過に伴って変化する表現（音声を含まず、インタラクションも含まない）。
ライブの音声しか含まないコンテンツの代替:
達成基準 1.2.9 を理解する
この達成基準の意図は、例えばテレビ会議のような、ライブの音声、ライブの発話、及びラジオのウェブキャストが伝えている情報を、代替テキストを用いることによってアクセシブルにすることである。ライブのキャプション付加サービスは、耳が聞こえない又は難聴の利用者、あるいは音声を聞くことのできない利用者に対してライブの音声をアクセシブルにすることが可能であろう。そういったサービスでは、訓練された人間のオペレーターが、話の内容を聞きながら、特殊なキーボードを用いてほんの少しの遅延だけでテキストを入力している。オペレーターは、かなり忠実にライブの出来事をテキストで記録することができる。また、内容を理解する上で不可欠な発話以外の音声に関する注記も挿入することができる。ライブの音声が予め用意された現行通りのものであれば、トランスクリプトを事前に準備しておけることもある。しかし、ライブのキャプション付加サービスのほうが好まれる。なぜなら、キャプションが音声自体と同じペースで表示され、台本にはないことが起こったとしてもそれに対処できるからである。
訓練されていないオペレーターを使用したり、実際に起こっていることとは明らかに違うトランスクリプトを提供したりしている場合は、この達成基準を満たしているとはいえない。
ある広告会社が、ウェブベースのキャプションサービスを利用して、ライブのイベントのキャプションを提供している。そのサービスによるキャプションは、ストリーミングの音声制御コントロールのあるウェブペーイのサブフレームに表示されている。
フリンジ劇場のライブのラジオ劇が、ウェブで放送されている。俳優たちが大部分は用意された台本通りに演じていて、番組の予算が限られているため、（脚本家の許諾を得た上で）プロデューサーは劇の台本へのリンクを提供している。
ストリーミングの音声サーバは、例えば Flash や Silverlight のように、テキスト及びグラフィックも使用可能なメディア形式を利用している。速記者が、あるイベントでライブのキャプションを書き起こしていて、それがその場で組み込まれて、メディアプレーヤーで閲覧可能なメディア配信のライブのキャプションとして使われている。
ある CEO が、ニュース速報の報道に反応して、報道メディア向けに電話による記者発表を行っている。その音声を録音して、インターネット上でも配信したが、時間の制約があって、ウェブ・キャプション付加サービスを間に合わせることができなかった。CEO がそこで読み上げる記者発表の内容は予め準備されていたので、その会社は発表内容のトランスクリプトを同時に提供することにした。
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
以下に挙げているのは、WCAG ワーキンググループが達成基準 1.2.9 に適合していないとみなした、よくある不適合事例である。
（今のところ、文書化されている不適合事例がない）
- 時間の経過に伴って変化するメディアの代替
時間に伴って変化する視覚的および聴覚的情報のトランスクリプトを含み、時間に伴って変化する情報のやりとりの結果を得る手段を提供する文書。
注記： 同期したメディアのコンテンツを作るために用いられる脚本は、編集後の最終的な同期したメディアを正確に描写したものに訂正されている場合のみ、この定義を満たすことになる。
- 音声しか含まない
音声のみを含んだ、時間の経過に伴って変化する表現（映像やインタラクションを含まない）。
- ライブ
実世界のイベントから取り込まれ、放送による遅延があるだけで受け手に送信される情報。
注記 1： 放送の遅延は、時間的に短い（通常は自動的な）遅れで、例えば放送局に音声（あるいは映像）を待ち行列に入れる、あるいは検閲する時間を与えるために用いられるものだが、編集できるほどの長さではない。
注記 2： もし情報が完全にコンピュータで生成されたものならば、それはライブではない。
適応可能:
ガイドライン 1.3 を理解する
ガイドライン 1.3： 情報あるいは構造を損なうことなく、さまざまな方法（例えば、よりシンプルなレイアウト）で提供できるように、コンテンツを制作する
ガイドライン 1.3 の意図
このガイドラインの目的は、例えば、音声で読み上げたり、あるいはよりシンプルなレイアウトで提示したりというように、すべての情報をすべての利用者が知覚できるように提供することである。すべての情報が、ソフトウェアによって解釈できるように提供されていれば、情報をさまざまな方法で（視覚的に、聴覚的に、触覚的に）提示することが可能である。もし、支援技術が構造及び情報をプログラムで解釈できないような方法で、情報がある特定の表現形態で提供されていたとしたら、その情報は利用者が必要とするその他の形式ではレンダリングできない。
このガイドラインにある達成基準はすべて、ある表現形態で提供されているさまざまな種類の情報を、その他のモダリティでも提示可能であるように提供しようとするためのものである。
情報及び関係性:
達成基準 1.3.1 を理解する
この達成基準の意図
この達成基準の意図は、視覚的又は聴覚的な体裁によって暗示されている情報及び関係性を、その表現形式が変わったときにも保つようにすることである。例えば、コンテンツがスクリーンリーダーによって読み上げられたり、コンテンツ制作者が提供するスタイルシートが利用者・スタイルシートに置き換えられたりしたときには、表現形式が変わる。
画面を見ている利用者は、さまざまな視覚的な手がかりによって構造を知覚する。例えば、見出しは大きめで太字のフォントになっていることがほとんどで、段落からは空行をはさんで離れている。リスト項目は、その先頭にビュレットがあって、インデントされていることが多い。段落と段落の間には空行がある。共通の特徴を有するアイテムは、表の行と列で整理されている。フォームの複数のテキストフィールドは、テキストのラベルを共有するグループとして配置されていることがある。異なる背景色を用いて、幾つかのアイテムが互いに関係のあることを示していることもある。特別な状態にある語句は、フォントの種類を変えること及び/又は太字、イタリック、下線付きにしたりすることによって示されている、など。
同様に、聴覚的な手がかりを用いることもある。例えば、チャイム音が新しい節の開始位置を示している。声のピッチや発話のスピードを変えて、重要な情報を強調したり、引用符付きのテキストを示したりしている、など。
そういった関係性がある利用者にとって知覚可能であれば、その関係性をすべての利用者が知覚できるようにすることが可能である。情報をすべての利用者にきちんと提供できたかどうかを判断する方法の一つは、その情報にさまざまなモダリティで連続してアクセスしてみることである。
用語集にある用語へのリンクを a 要素（又は、使用している技術特有のリンク要素）を用いて実装して、異なるフォントで示していれば、スクリーンリーダーの利用者は、たとえフォントの違いに関する情報は受け取れなかったとしても、用語集にある用語のところではそれがリンクであることが音声読み上げを聞いていて分かるだろう。
ウェブコンテンツ技術の中には、ある種の情報及び関係性をプログラムで解釈する手段を提供していないものがある。そういった場合には、その情報及び関係性を説明するテキストを提供すべきである。<<!--例えば、"アスタリスク（*）のある項目はすべて必須項目です。"-->> テキストによる説明は、例えばその親要素又はすぐ近くにある要素内などのように、（そのページをリニアライズした際に）テキストが説明している情報の近くに置くべきである。
また、場合によっては、どんな情報をテキストで示すべきで、何を直接関連付ける必要があるのかについては各自の判断に委ねるしかないこともあれば、ある情報を繰り返して提供することが最も適切なこともありえる（例えば、HTML のテーブルでは、そのテーブルの要約を、テーブルの前にある段落とテーブルの summary属性の両方で提供すること）。しかし、可能なかぎり、テーブルがある前のところでテキストによる説明を提供するのではなく、その情報をプログラムで解釈できるようにしなければならない。
注記： 色の値がプログラムで解釈可能であることは要求していない。色によって伝えられる情報は、その値を明らかにするだけでは、十分に提示することができないからである。そのため、色に特有の問題については、達成基準 1.3.1 ではなく、達成基準 1.4.1 で対処している。
達成基準 1.3.1 の具体的なメリット
この達成基準は、ユーザエージェントが個々の利用者のニーズに応じてコンテンツに適応できるようにすることによって、さまざまな障害のある利用者の役に立つ。
- <<!--削除？--
全盲の（スクリーンリーダーを使用している）利用者が、色を用いて伝えられている情報をテキストでも得られるようになる（色を用いて情報を伝えている画像の代替テキストを含む）。
点字ピンディスプレイを使用している盲ろうの利用者は、色に依存した情報を利用できないことがある。-->>
達成基準 1.3.1 の事例
必須項目のある入力フォーム
入力フォームに、いくつかの必須項目がある。必須項目のラベルを、赤で表示している。さらに、各ラベルの最後には、アスタリスクの記号文字 "*" が付いている。フォームへの入力に関する説明文には、フォームへの入力に関する説明文には、"すべての必須項目は赤字で示してあり、アスタリスク (*) が付いています。" と書かれていて、例示が後に続いている。
必須項目を示すために色とテキストを用いている入力フォーム
入力フォームに、必須項目と任意項目の両方がある。入力フォームの先頭にある説明文には、必須項目のラベルが赤字になっていて、"必須" という代替テキストのあるアイコンも付いている。赤字とアイコンの両方が、フォームのテキストフィールドとプログラムで関連付けられているので、支援技術の利用者はどれが必須項目なのかが判断できる。
各セルの見出しがプログラムで解釈可能なバスの時刻表
バスの運行スケジュールが、1行目には縦にバス停の名前が並び、1列目には横に異なるバスが並んでいる表で示されている。各セルには、バスがそのバス停に到着する時刻が書かれている。支援技術が、各セルにある時刻がどのバスとどのバス停とに関連付けられているのかを解釈することができるように、各バス停と各バスのセルは、それぞれの対応する行又は列の見出しとして示されている。
チェックボックスのラベルがプログラムで解釈可能な入力フォーム
あるフォームでは、各チェックボックスに対するラベルが、支援技術によってプログラムで解釈可能になっている。
テキスト文書
構造がプログラムで解釈できるように、シンプルなテキスト文書は、タイトルの前に2行の空行があり、アスタリスクを使ってリスト項目を示し、その他の標準的な書式の決まりに従ってフォーマットされている。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準 1.3.1 の実装方法及び不適合事例 － 情報及び関係性
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
達成基準を満たすことのできる実装方法
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の実装方法（又は、実装方法の組合せ）がある。
達成基準 1.3.1 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
達成基準 1.3.1 のよくある不適合事例
以下に挙げているのは、WCAG ワーキンググループが達成基準 1.3.1 に適合していないとみなした、よくある不適合事例である。
重要な用語
- 表現
利用者が知覚できる形でのコンテンツのレンダリング。
- プログラムで解釈（プログラムで解釈可能）
コンテンツ制作者が提供したデータからソフトウェアが解釈できること。また、その際に、支援技術を含むさまざまなユーザエージェントが、この情報を抽出して利用者にさまざまなモダリティで提示できること。
事例 1： マークアップ言語では、一般に入手可能な支援技術が、要素および属性に直接アクセスすることにより解釈できる。
事例 2： 非マークアップ言語では、技術特有のデータ構造から、一般に入手可能な支援技術がサポートするアクセシビリティ API を通じて支援技術に提供される。
- 関係性
コンテンツの異なる部分間における意味のある関係。
- 構造
-
ウェブページの構成要素が相互に関係して系統的に整理されている状態で、かつ
ウェブページの集合が整理されている状態。
意味のある順序:
達成基準 1.3.2 を理解する
この達成基準の意図
この達成基準の意図は、コンテンツの意味を理解するのに必要な音声読み上げ順序を保ちながら、ユーザエージェントがコンテンツの代替表現を提供できるようにすることである。意味が通じるコンテンツの順序を、プログラムで少なくとも一つは解釈できることが重要である。この達成基準を満たしていないコンテンツは、支援技術がそのコンテンツを正しくない順序で読み上げたり、代替スタイルシート又はその他の書式変更が適用されたりしたときに、利用者を困惑あるいは混乱させてしまう恐れがある。
コンテンツの並び順を変更すると、コンテンツの意味に影響を及ぼす場合、その順序には意味がある。例えば、あるページに2つの独立した記事があり、それらの順序が決まっているかぎり、その記事の相対的な順序がそれぞれの意味に影響を及ぼす可能性はない。そのような状況においては、それらの記事自体には意味のある順序があるかもしれないが、それらの記事が入っているコンテナには意味のある順序はないかもしれない。
ある要素のセマンティクスが、そのコンテンツに意味のある順序があるかどうかを定義している。例えば、HTMLでは、テキストには常に意味のある順序がある。テーブル及び順序付きリストには意味のある順序があるが、順序なしリストにはない。
コンテンツの並び順には、常に意味があるとは限らない。例えば、あるウェブページのメイン部分とナビゲーション部分の相対的な順序は、それぞれの意味には影響を及ぼさない。それらは、プログラムで解釈される音声読み上げ順序で、どちらが先にもなりえる。もう一つの例としては、雑誌の記事には吹き出しの補足記事が幾つかある。記事と補足記事の順序は、それぞれの意味に影響を及ぼすことはない。このような場合においては、この達成基準を満たすことのできるウェブページの異なる音声読み上げ順序が複数あることになる。
達成基準 1.3.2 の実装方法及び不適合事例 － 意味のある順序
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
達成基準 1.3.2 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
Using left-justified text for languages that are written left to right and right-justified text for languages that are written right-to-left（リンク追加予定）
Providing a link to linearized rendering （リンク追加予定）
Providing a style switcher between style sheets that affect presentation order （リンク追加予定）
達成基準 1.3.2 のよくある不適合事例
以下に挙げているのは、WCAG ワーキンググループが達成基準 1.3.2 に適合していないとみなした、よくある不適合事例である。
重要な用語
- 正確な音声読み上げ順序
コンテンツの意味を変更しない順番で単語や段落が提示される、あらゆる順序。
- プログラムで解釈（プログラムで解釈可能）
コンテンツ制作者が提供したデータからソフトウェアが解釈できること。また、その際に、支援技術を含むさまざまなユーザエージェントが、この情報を抽出して利用者にさまざまなモダリティで提示できること。
事例 1： マークアップ言語では、一般に入手可能な支援技術が、要素および属性に直接アクセスすることにより解釈できる。
事例 2： 非マークアップ言語では、技術特有のデータ構造から、一般に入手可能な支援技術がサポートするアクセシビリティ API を通じて支援技術に提供される。
感覚的な特徴:
達成基準 1.3.3 を理解する
1.3.3 感覚的な特徴： コンテンツを理解し操作するための説明を、形、大きさ、視覚的な位置、方向、または音のような、構成要素が人間の感覚に示す特徴だけで提供しない。 （レベル A）
この達成基準の意図
この達成基準の意図は、すべての利用者が形又はサイズを知覚できない、あるいは空間的な位置又は方向に関する情報を利用できない場合でも、すべての利用者がコンテンツを利用するための説明を理解できるようにすることである。コンテンツが、コンテンツの構造からは入手できないオブジェクトの形又は配置が分かることに依存していることがある（例えば、"円いボタン" あるいは "右のボタン"）。障害のある利用者は、使用している支援技術の性質のために、形又は配置を知覚できないことがある。この達成基準は、このような情報に依存しているあらゆるものを明確にするために、補足の情報を提供することを要求している。
しかし、形及び/又は位置を用いて情報を提供することは、認知限界のある利用者を含む多くの利用者に対しては効果的な手法である。この達成基準は、その情報が他の形でも提供されているかぎり、その種の手がかりを使わないようにするものではない。
ある言語においては、"以上" はコンテンツのその地点よりも前にあるコンテンツを指し、"以下" はその地点よりも後にあるコンテンツを指すことが共通理解となっている。そういった言語では、そのように示されたコンテンツが、音声読み上げ順序の中で適切な位置にあり、その示し方が曖昧でなければ、"以下にあるリンクの中から一つ選んでください" あるいは "以上のすべて" といった記述は、この達成基準に適合していることになるだろう。
達成基準 1.3.3 の実装方法及び不適合事例 － 感覚的な特徴
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
達成基準 1.3.3 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
達成基準 1.3.3 のよくある不適合事例
以下に挙げているのは、WCAG ワーキンググループが達成基準 1.3.3 に適合していないとみなした、よくある不適合事例である。
識別可能:
ガイドライン 1.4 を理解する
ガイドライン 1.4： 利用者が、コンテンツを見やすくしたり、聞きやすくしたりする。これには、前景と背景を区別することも含む。
ガイドライン 1.4 の意図
情報を代替の形式で提示できるようにすることを焦点にしたガイドラインがあるが、このガイドラインは、デフォルトの表現を障害のある利用者にとってできるかぎり知覚しやすいものにすることに関係したものである。第一に、利用者が前景の情報を背景と区別しやすくすることに重点を置いている。視覚的な情報の場合は、背景の上に提示されている情報とその背景とのコントラストを十分に確保しているかどうかを確認する。そして、音声によるプレゼンテーションの場合は、前景音が背景音よりも十分に大きいかどうかを確認することが含まれている。視覚及び聴覚に障害のある利用者は、前景と背景の情報を区別することがかなり困難なのである。
ガイドライン 1.4 の参考にすべき実装方法（特定の達成基準に特有ではない実装方法）
このガイドラインにある各達成基準を満たすための実装方法は、この後に達成基準ごとに挙げられている。しかし、このガイドラインに対処するための実装方法がどの達成基準にも該当しない場合は、ここで挙げている。そういった実装方法は、どの達成基準を満たす上でも必須ではないし、十分でもないが、ウェブコンテンツの種類によってはより多くの利用者にとってよりアクセシブルにすることができるものである。
Using readable fonts （リンク追加予定）
Making sure any text in images of text is at least 14 points and has good contrast （リンク追加予定）
Providing a highly visible highlighting mechanism for links or controls when they receive keyboard focus （リンク追加予定）
色の使用:
達成基準 1.4.1 を理解する
1.4.1 色の使用： 情報を伝える、何が起こるかあるいは何が起きたかを示す、利用者の反応を促す、あるいは視覚的な要素を区別する唯一の視覚的な手段として、色のみを使用しない。 （レベル A）
注記： この達成基準は、特に色の知覚に関するものである。その他の知覚形態については、色やその他の視覚的な表現のコーディングへのプログラムによるアクセスも含めて、ガイドライン 1.3 で網羅されている。
この達成基準の意図
この達成基準の意図は、色の違いによって伝えられている情報、言い換えれば、それぞれの色に割り当てられた意味があり、その色を使うことによって伝えている情報を、すべての利用者が知覚できるようにすることである。画像（又は、その他の非テキスト形式）で色の違いによって情報を伝えている場合、色弱の利用者はその色が分からないかもしれない。この場合、色で伝えている情報を他の視覚的な手段で提供することで、色の分からない利用者もその情報を知覚することができるようになる。
色は、審美的な訴求力、利用者ビリティ、そしてアクセシビリティを高めるため、ウェブコンテンツのデザインにおいて重要なものである。しかし、色を知覚しづらい利用者もいる。ロービジョンの利用者は、色覚に限界を感じることがよくあり、年配の利用者も多くは色がよく見えない。さらに、テキストしか表示しない、色数が制限されている、又はモノクロのディスプレイ及びブラウザを使用している利用者は、色だけで提示されている情報を知覚することができないであろう。
色の違いで伝えられている情報の例としては、"必須項目は赤字です"、"赤字はエラーです。"、そして "赤がメアリーの売上、青がトムの売上" などが挙げられる。何が起こるか又は何が起きたかを示している例では、リンクが新しいウィンドウで開くことやデータベースの入力内容が無事に更新されたことを示すのに色を使っていることがある。また、利用者の反応を促している例には、必須項目が未入力であることを示すためにフォームの入力フィールドを反転表示していることが挙げられる。
注記：この達成基準は、ページ上での色の使用、あるいは他の視覚的な表示と重複していても色分けすることを阻むものではない。
達成基準 1.4.1 の具体的なメリット
ロービジョンの利用者が、色覚の限界を感じることがよくある。
年配の利用者は、色がよく見えないかもしれない。
色弱の利用者が、色で伝えられている情報をその他の視覚的な手段で知覚できるようになる。
テキストしか表示しない、色数が制限されている、又はモノクロのディスプレイを使用している利用者は、色に依存している情報を知覚することができないことがある。
達成基準 1.4.1 の事例
必須項目を示すために色とテキストを用いている入力フォーム
入力フォームに、必須項目と任意項目の両方がある。 入力フォームの先頭にある説明文には、必須項目のラベルが赤字になっていて、"必須" という代替テキストのあるアイコンも付いている。 赤字とアイコンの両方が、フォームのテキストフィールドとプログラムで関連付けられているので、支援技術の利用者はどれが必須項目なのかが判断できる。
試験
学生が、化合物の SVG イメージを見て、ダイアグラムに用いられている色に基づいてそこにある化学元素を確認している。代替テキストが、各元素の名前と元素の色を関連付けていて、ダイアグラム内での元素の配置を示している。色を知覚できない学生は、その化合物についてクラスメイトと同じ情報を得ている。（この実装方法は、ガイドライン 1.1 のレベル A も満たしている。）
非活性のフォーム要素
マークアップ又はスクリプトによって使用不可の状態になっているフォーム要素は、ユーザエージェントによってグレー表示され、非活性になっている。使用不可の状態では、これらの要素はフォーカスを受け取らない。支援技術は、使用不可の状態になっている要素をプログラムで解釈することが可能で、ページ上でその要素を見つけた際にこの情報を利用者に提供するであろう。色の変化及びフォーカスがあたらないことの重複によって、そのコントロールの状態に関する情報を視覚的に提供している。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準 1.4.1 の実装方法及び不適合事例 － 色の使用
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
達成基準を満たすことのできる実装方法
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の実装方法（又は、実装方法の組合せ）がある。
達成基準 1.4.1 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
達成基準 1.4.1 のよくある不適合事例
以下に挙げているのは、WCAG ワーキンググループが達成基準 1.4.1 に適合していないとみなした、よくある不適合事例である。
音声制御:
達成基準 1.4.2 を理解する
1.4.2 音声制御： ウェブページ上にある音声が3秒より長く自動的に再生される場合、その音声を一時停止あるいは停止するメカニズムを提供する、あるいはシステム全体の音量レベルとは別々に音量を調整するメカニズムを提供する。 （レベル A）
注記： この達成基準を満たさないコンテンツでは、利用者がそのページ全体を使用できない恐れがあるため、Webページ上のすべてのコンテンツは他の達成基準を満たすために用いられているか否かにかかわらず、この達成基準を満たさなければならない。適合要件 5: 非干渉を参照のこと。
この達成基準の意図
スクリーンリーダーを使用している利用者は、同時に他の音声が再生されていると、スクリーンリーダーによる読み上げ音声が聞き取りづらくなる。スクリーンリーダーの読み上げ音声が、ソフトウェアをベースにしたもので（今日ではほとんどがそうであるように）、システム全体と同じ音量コントロールによって制御されていると、この状況はさらに悪化する。そのため、重要なのは、利用者が背景音の再生をオフにできることがである。注記： 音量コントロールには、その音量をゼロまで下げられることを含む。
注記： 利用者があるページへやってきた時に音声が自動再生されると、スクリーンリーダーの利用者はその音声を停止させるメカニズムを探しづらくなることがある。なぜなら、スクリーンリーダーの利用者は、読み上げ音声を聞きながらナビゲートしており、自動的に開始した音声がそのナビゲーションを邪魔してしまうかもしれないからである。そのため、WCAG ワーキンググループでは、音声を自動的に再生しないことを推奨し（特に、3秒よりも長く続く場合）、利用者がそのページにやってきた後、利用者によって音声の再生を停止させるのではなく、利用者の起こしたアクションによって音声が再生を開始することを勧める。
「達成基準 1.4.7 小さい背景音又は背景音なし」を理解するも参照のこと。.
達成基準 1.4.2 の具体的なメリット
スクリーンリーダーを使用している利用者が、他に再生されている音声に邪魔されることなく、スクリーンリーダーの音声を聞くことができるようになる。難聴及びシステム全体の音量を用いているスクリーンリーダーの利用者（システム全体の音量を下げて、スクリーンリーダーの音量を上げるということができないため）にとっては、特に重要である。
また、この達成基準は、音声が再生されていると、視覚的なコンテンツ（テキストを含む）に集中しづらい利用者に対しても役に立つ。
達成基準 1.4.2 の事例
ページを開いたときに、音声ファイルが自動的に再生を開始する。しかし、利用者が、そのページの先頭にある「音を消す」というリンクを選択することで、その音声を停止させることができる。
音声が再生されるFlashのスプラッシュページがあり、3秒以内にその音声が停止する。
音声が自動的に再生されるFlashのスプラッシュページの先頭に、利用者が音声を停止できるコントロールがある。
達成基準 1.4.2 の実装方法及び不適合事例 － 音声制御
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
達成基準 1.4.2 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
達成基準 1.4.2 のよくある不適合事例
以下に挙げているのは、WCAG ワーキンググループが達成基準 1.4.2 に適合していないとみなした、よくある不適合事例である。
重要な用語
- メカニズム
結果を得るためのプロセスあるいはテクニック。
注記 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 ポイント" 及び "太字" は、異なるフォントでは異なる意味合いを持つこともあるが、特別に細い線のフォント又は文字の形が分かりにくくなるような独特の見た目や特徴のあるフォントについては対象外とする。とても多くのさまざまなフォントがあるため、ここでは一般的な基準を用いることとして、用語集にて装飾的なフォント又は細い線のフォントに関する注記を付けている。
また、前述のテキストに対するコントラストの要件は、達成基準 1.4.3 で述べられているように、画像化された文字（画像フォーマットで保存された文字）にも適用される。
この要件は、画像化された文字が情報を伝えることを目的としている状況に対して適用される。例えば、写真の中にたまたま入っていた街頭の標識にあるような付随的なテキストは、対象外である。また、何らかの理由で、すべての利用者が視覚的に確認できないことを意図しているテキストも対象外である。
この達成基準には、「意味のあるその他の視覚的なコンテンツを含む写真の一部分である」という例外がある。この例外は、テキストの写っている写真と特定の見た目にするためにテキストの代わりに画像化された文字とを区別することを意図している。
注記 1： 認知障害のある利用者は、低めのコントラストの色の組合せ又は色相を必要とすることがある。そのため、コンテンツ制作者にコンテンツの前景色と背景色を調節するメカニズムを提供することを認め、それを推奨する。選択可能な組合せの中には、この達成基準にあるコントラスト比よりも低いレベルのコントラストがあってもよい。もし、この達成基準に合わせて設定したデフォルトの値に戻すことのできるメカニズムが提供されていれば、その場合はこの達成基準に反していることにはならない。
注記 2： 画像化された文字は、画素に分解されてしまうので、テキストと同じようにきれいに拡大することができない。また、画像化された文字の前景と背景のコントラスト及び色の組合せを変更できることを必要とする利用者もいるが、テキストよりも困難である。そのため、可能なかぎり、テキストを用いることを勧めるが、それができない場合には、さらに高い解像度の画像を提供することを考慮すること。
この達成基準は、テキスト（文字）だけに適用されるが、図表やグラフで提示されるデータにも似たような問題が起こる。そのようなデータでも、色のコントラストを十分に確保すべきである。
「達成基準 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 のコントラスト比を必要とすることになる。
色相は、色弱の利用者（先天的及び後天的の両方）によって知覚のされ方がさまざまなため、色及び相対的な輝度コントラストが色弱ではない利用者とは異なる。このため、有効なコントラスト及び読みやすさは、色弱の利用者に対しては異なったものになる。しかし、色弱は多様であるため、（コントラストのために）量的なデータに基づいて有効で一般的な色の組合せを規定することは、適切であるとはいえない。十分な輝度コントラストを要求することで、色の知覚に依存しないコントラストを要求し、この問題に対応している。幸いにも、輝度の寄与のほとんどは、分光感度において大部分が重なる中波長及び長波長の受容体からくるものである。その結果は、有効な輝度コントラストが一般的に特定の色弱に関係なく計算できるということである。ただし、赤色を知覚しにくい第一色弱の利用者の場合、暗い色（一般的に黒のようである）に対して主に波長の長い色を用いることは除く（この理由から、WCAG ワーキンググループは、黒の背景に赤の前景を使うことを避けるという参考にすべき実装方法を提供している）。より詳細な情報は、[ARDITI-KNOBLAUCH][ARDITI-KNOBLAUCH-1996][ARDITI] を参照のこと。
レベル AA で 4.5：1 のコントラスト比を選択したのは、20/40 程度まで視力の低下した利用者におけるコントラスト感度の低下を補うためである（20/40 は約 4.5：1 という計算になる）。また、20/40 は、80歳前後の高齢者の標準的な視力として、よく報告される視力である [GITTINGS-FOZARD]。
レベル AAA で 7：1 のコントラスト比を選択したのは、20/80 程度まで視力の低下した利用者におけるコントラスト感度の低下を補うためである。これ以上に視力が低下した利用者は、通常は支援技術を使用して、コンテンツを利用している（その支援技術には、コントラスト増強と画面拡大の機能が搭載されている）。そのため、7：1 というコントラスト比は、一般的に支援技術を使用していない利用者のコントラスト感度の低下を補い、同様に色弱の利用者に対してもコントラストを向上させる。
計算式に関する注記
RGB 値の非線形から線形への変換は、IEC/4WD 61966-2-1 [IEC-4WD] 及び "A Standard Default Color Space for the Internet - sRGB" [sRGB] に基づいている。
コントラストの計算式（L1/L2）は、[ISO-9241-3] および [ANSI-HFES-100-1988] の標準規格に基づいている。
ANSI/HFS 100-1988 は、L1 及び L2 の計算に含めるために、周辺光からの寄与を必要としている。用いている .05 という値は、[IEC-4WD] の Typical Viewing Flare 及び 論文[sRGB]（M. Stokes et al）に基づいている。
この達成基準及びその定義では、ウェブコンテンツが光自体を発するわけではないという事実を反映するために、"輝度（luminance）" ではなく、"コントラスト比（contrast ratio）" 及び "相対輝度（relative luminance）" という用語を用いている。コントラスト比は、コンテンツが表示されたときに生じる相対輝度の評価基準（尺度）を与える（それは、比率なので、無次元である）。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準 1.4.3 の実装方法及び不適合事例 － 最低限のコントラスト
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
達成基準を満たすことのできる実装方法
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の実装方法（又は、実装方法の組合せ）がある。
達成基準 1.4.3 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
G156： テキスト・ブロックの前景及び背景を変更できる、一般に入手可能なユーザエージェントのあるウェブコンテンツ技術を用いる
Using a higher contrast value for text that is over a patterned background （リンク追加予定）
Using Unicode text and style sheets instead of images of text （リンク追加予定）
Using a higher contrast values for lines in diagrams （リンク追加予定）
Using greater contrast level for red-black text/background combinations （リンク追加予定）
Using colors that are composed predominantly of mid spectral components for the light and spectral extremes (blue and red wavelengths) for the dark
Using a light pastel background rather than a white background behind black text to create sufficient but not extreme contrast （リンク追加予定）
Making icons using simple line drawings that meet the contrast provisions for text （リンク追加予定）
Providing sufficient color contrast in graphs and charts （リンク追加予定）
Using a 3:1 contrast ratio or higher as the default presentation （リンク追加予定）
Providing sufficient color contrast for empty text fields （リンク追加予定）
達成基準 1.4.3 のよくある不適合事例
以下に挙げているのは、WCAG ワーキンググループが達成基準 1.4.3 に適合していないとみなした、よくある不適合事例である。
重要な用語
- コントラスト
(L1 + 0.05) / (L2 + 0.05)
注記 1： コントラスト比は、1～21の範囲になりうる（通常は、1：1～21：1と記述される）。
注記 2： コンテンツ制作者は、テキストのレンダリング（例：フォントのスムージングやアンチエイリアス）に関する利用者の設定を制御できないため、テキストのコントラスト比はアンチエイリアスをオフにした状態で評価される。
注記 3: 達成基準 1.4.3 および 1.4.6 の目的上、コントラストは通常の使用においてテキストがレンダリングされる際に指定されている背景色に対して測定される。もし背景色の指定がない場合は、背景色には白を想定することになる。
注記 4: 背景色は、テキストが通常の使用においてレンダリングされる際に背景となるコンテンツの指定された色である。テキストの色が指定されている際に背景色が指定されていない場合は問題がある。なぜなら、利用者のデフォルトの背景色は未知であり、コントラストが十分かどうかを評価することができないからである。同じ理由で、背景色が指定されている際にテキストの色が指定されていない場合も問題ありということになる。
注記 5: 文字の周囲に縁取りがある際、その縁取りがコントラストを強めることもあり、文字とその背景色におけるコントラストの計算に用いられる。ただし、文字の周囲の細い縁取りは文字として扱われる。文字の周囲の太い縁取りが、かさ（暈：ハロー、後光）のようになって、文字の細かい字画を埋めていれば、背景色として考慮されることになる。
注記 6: WCAG への適合は、典型的な表現において隣接すると制作者が想定してコンテンツで指定した色の組み合わせに対して評価されるべきである。制作者は、ユーザエージェントによる色の変更などのように通常とは異なる表現を考慮する必要はない。ただし、それが制作者のソースコードによって起こる場合は除く。
- 画像化された文字
特定の視覚的効果を得るために非テキスト形式（例：画像）でレンダリングされる文字
注記：これには、重要なその他の視覚的なコンテンツを含む画像の一部であるテキストは含まれない。
- サイズの大きな（テキスト）
少なくとも18ポイント、もしくは14ポイントの太字。あるいは、中国語、日本語、そして韓国語のフォントではそれと同等の文字サイズ（訳注： 日本語では、22ポイント、もしくは18ポイントの太字）。
注記 1： 特別に細い線のフォント、あるいは文字の形が分かりにくくなるような独特の見た目や特徴のあるフォントは、コントラストが低いとき特に読みづらい。
注記 2： ここでいう文字サイズは、コンテンツが提供される際のサイズである。利用者によって変更されたサイズは含まれない。
注記 3: 文字の実際のサイズは、コンテンツ制作者が指定したサイズと利用者のディスプレイあるいはユーザエージェントの設定の両方に依存している。 For many mainstream body text fonts, 14 and 18 point is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text (assuming that the body font is 100%),しかし、制作者は、使用する特定のフォントについて、このことをチェックしておく必要がある。フォントが相対単位で定義されている時、実際の文字ポイントのサイズは、表示画面のため、ユーザエージェントによって計算される。この評価基準を評価する時には、文字ポイントのサイズは、ユーザエージェントから取得されるべきであり、またはユーザエージェントが行うフォントの計算基準に基づいて計算するべきである。ロービジョンの利用者に対しては、自分で適切な設定を選択することを想定している。
注記 4: フォントサイズを指定せずにテキストを用いる際は、サイズを指定していないテキストに対して主要ブラウザで用いられる最小のフォントサイズをそのテキストのサイズとみなすのが妥当であろう。もし、レベル1の見出しが、主要なブラウザで14ポイントの太字あるいはそれ以上のサイズでレンダリングされるならば、それは「サイズの大きな」テキストであると考えてよい。相対的な拡大縮小は、同じやり方でそのデフォルトのサイズから算出することが可能である。
注記 5: ローマ字のテキストにおける18ポイントおよび14ポイントのサイズは、拡大印刷の最小サイズ（14ポイント）と標準的な大きい文字サイズ（18ポイント）からきている。例えば、中国語、日本語、韓国語など、その他の文字については、「同等な」サイズはその言語での拡大印刷の最小サイズと拡大印刷でその次に大きな標準のサイズとなる。
- 装飾だけを目的
美的な目的だけを果たしていて、情報は提供せず、機能性も備えていない。
注記： その単語を手直ししたり置き換えたりしてもその目的が変わらないのであれば、テキストは単に装飾だけを目的にしたものといえる。
事例： 辞書の表紙には、その背景にとても淡い文字で単語がランダムに並んでいる。
- テキスト
プログラムで解釈できる文字の連続で、その連続が自然言語で何かを表現しているもの。
- 利用者インターフェース要素
特定の機能を果たすために単一のコントロールとして利用者が知覚する、コンテンツの一部分。
注記 1： 複数の利用者インターフェース要素が単一のプログラム的要素として実装されることがある。ここでいう要素は、プログラミングテクニックではなく、別々のコントロールとして利用者が知覚するものを指す。
注記 2： 利用者インターフェース要素には、スクリプトで生成されるコンポーネントやフォーム要素、リンクが含まれる。
事例： アプレットには、コンテンツ内を行ごと、ページごと、あるいはランダムに移動するために用いられる "コントロール" がある。これらはどれも識別名があり、個別に設定可能なので、それぞれが "利用者インターフェース要素" となる。
テキストのサイズ変更:
達成基準 1.4.4 を理解する
この達成基準の意図
この達成基準の意図は、軽度の視覚障害のある利用者が、例えば画面拡大ソフトのような支援技術を使わずにそのまま読むことができるように、テキストベースのコントロールを含む視覚的にレンダリングされるテキスト（視覚的に見ることができるように表示されたテキストの文字 [vs. text characters that are still in data form such as ASCII]）を問題なく拡大可能にすることである。利用者がメリットを享受できるのは、ウェブページ上のすべてのコンテンツを拡大できることだが、テキストが最も重要な意味を持つ。
コンテンツを拡大することは、第一にユーザエージェントが果たすべき役割である。UAAG 1.0 チェックポイント 4.1 を満たしているユーザエージェントは、利用者がテキストの拡大及び縮小を設定できるようにしている。コンテンツ制作者が果たすべき役割は、ユーザエージェントがコンテンツを効果的に拡大できるように、ウェブコンテンツを制作することである。コンテンツ制作者は、コンテンツがユーザエージェントによるテキストベースのコントロールを含むテキストのサイズ変更を妨げていないことを確認すること、又はテキストのサイズ変更あるいはレイアウトの変更を直接可能にすることによって、この達成基準を満たすことができる。一つの例としては、さまざまなスタイルシートを適用することができるサーバサイドのスクリプトによって、直接可能にすることができるかもしれない。
利用者がユーザエージェントの拡大機能を使用できない場合、コンテンツ制作者は、HTML コンテンツでこの達成基準を満たすのにユーザエージェントに依存することはできない。例えば、利用者が IE 6 又は Firefox を使用する必要のある環境で仕事をしている場合などである。
ユーザエージェントが拡大機能を提供していないウェブコンテンツ技術をコンテンツ制作者が使用している場合、このような機能を直接提供すること、又はユーザエージェントの提供する機能と連携するコンテンツを提供することが、コンテンツ制作者の責任である。ユーザエージェントが、拡大機能を提供していないが、利用者がテキストのサイズを変更できる場合、テキストのサイズを変更してもコンテンツが利用できる状態のままであるようにすることが、コンテンツ制作者の責任となる。
ラベルとしての機能を有し、利用者が起動する必要のあるユーザインタフェース要素の中には、そのラベルのコンテンツに対応するには幅が十分広くないものがある。例えば、ウェブメールのアプリケーションにおいて、考えられうる件名すべてに対応できるほど件名欄の幅が広くないことがある。しかし、件名の見出しを起動することで、利用者は件名見出しとメッセージが全部表示された状態にすることができる。また、ウェブベースのスプレッドシートでは、セルの内容を表示させるには行幅より長すぎる場合は省略されることがあり、そのセルの内容の全部は、そのセルがフォーカスを受け取ったときに利用者に提供される。ユーザインタフェース要素のコンテンツも、利用者が幅を変更できる場合には、幅よりも広くなってしまうことがある。この種のユーザインタフェース要素では、行の折り返しは必須ではない。ユーザインタフェース要素がフォーカスを受け取った時、又は利用者がユーザインタフェース要素を起動した後にコンテンツ全部が入手可能になり、この情報はアクセス可能であるということが何らかの方法で利用者に提示されている場合には、省略は許容される。
コンテンツが200％まで、言い換えれば、幅と高さが2倍になるまで、拡大可能であれば、そのコンテンツはこの達成基準を満たしていることになる。コンテンツ制作者はそれ以上の拡大をサポートしてもよいが、コンテンツをそれ以上拡大していくにつれて、アダプティブ・レイアウトは利用者ビリティの問題を引き起こす可能性がある。例えば、語句の横幅が広くなりすぎると、省略されてしまうことになる。レイアウト上の制約によって、拡大していったときに、テキストが他のコンテンツと重なり合ってしまうこともある。あるいは、文章中の一つの単語だけが各行にある状態になると、その文章が縦に表示されてしまって読みづらくなってしまう。
ワーキンググループは、広範囲に及ぶデザイン及びレイアウトをサポートできるという点と、最小の拡大率が200％という古い画面拡大ソフトを補完するという点から、200％が妥当ではないかと考えている。200％以上になると、拡大（テキスト、画像、及びレイアウト領域のサイズを変更し、横スクロールと縦スクロールを必要とする可能性のある大きなキャンバスを作り出す）のほうが、テキストのサイズ変更よりも効果的かもしれない。200％を超える状況では、拡大機能専用の支援技術が通常は使用されており、コンテンツ制作者が利用者に直接提供する機能よりもより良いアクセシビリティを提供することができる。
注記： 画像化された文字は、画素に分解されてしまうので、テキストと同じように拡大できない。そのため、可能なかぎり、テキストを用いることを勧める。また、画像化された文字の前景と背景のコントラスト及び色の組合せを変更することを必要とする利用者もいるが、テキストよりも困難である。
「達成基準 1.4.8 視覚的な表現」を理解するも参照のこと。
達成基準 1.4.4 の事例
視覚障害のある利用者が、ウェブページのテキストのサイズをブラウザで 1 em から 1.2 em に変更している。利用者は小さいサイズではテキストを読むことができないが、大きいサイズのテキストは読むことができる。ページ上のすべての情報は、テキストのサイズが大きくなってもまだ表示されている。
ページを拡大するためのコントロールがウェブページにある。さまざまな設定を選択すると、そのサイズで最適なデザインとなるようにページのレイアウトが変更される。
利用者が、ユーザエージェントの拡大機能を使って、コンテンツのサイズを変更している。すべてのコンテンツは滑らかに拡大し、ユーザエージェントが必要に応じてスクロールバーを提供している。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準 1.4.4 の実装方法及び不適合事例 － テキストのサイズ変更
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
達成基準 1.4.4 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
Providing large fonts by default （リンク追加予定）
Using page-percent for container sizes （リンク追加予定）
Avoiding scaling font sizes smaller than the user-agent default （リンク追加予定）
注記：The author won't actually know the font size, but should avoid percentage scaling that results in less than 100%
Avoiding justified text （リンク追加予定）
Providing sufficient inter-line and inter-column spacing （リンク追加予定）
Providing different sizes for non-text content when it cannot have an equivalent accessible alternative （リンク追加予定）
Avoiding the use of text in raster images （リンク追加予定）
Using server-side scripts to resize images of text （リンク追加予定）
C17: Scaling form elements which contain text (CSS)
Ensuring that text in raster images is at least 18pt （リンク追加予定）
Scaling text down to 50% （リンク追加予定）
C20： ブラウザのウィンドウサイズを変更した際に、行幅が80文字以下になるように、カラム幅を相対サイズで指定する (CSS)
C22： CSS を用いて、テキストの視覚的な表現を制御する (CSS)
Providing a mechanism to allow captions to be enlarged （リンク追加予定）
達成基準 1.4.4 のよくある不適合事例
以下に挙げているのは、WCAG ワーキンググループが達成基準 1.4.4 に適合していないとみなした、よくある不適合事例である。
重要な用語
- （この文書で用いられている）支援技術
ユーザエージェントとして機能する、あるいは主流のユーザエージェントと一緒に機能するハードウェアおよび/あるいはソフトウェアで、主流のユーザエージェントで提供されている機能以上である障害者利用者の要求を満たすために機能を提供するもの。
注記 1： 代替のプレゼンテーション（例：合成音声や拡大表示したコンテンツ）、代替入力手法（例：音声認識）、付加的なナビゲーションあるいは位置確認のメカニズム、およびコンテンツ変換（例：テーブルをよりアクセシブルにするもの）を含めて支援技術により提供される機能。
注記 2： 支援技術は、API を用いて監視することで、主流のユーザエージェントとデータやメッセージのやりとりをすることが多い。
注記 3: 主流のユーザエージェントと支援技術とを区別するのに、絶対的な基準などはない。多くの主流のユーザエージェントは、障害者を支援する機能を提供している。基本的な差異は、主流のユーザエージェントが障害のある人もない人も含めて、広く多様な利用者をターゲットにしているのに対し、支援技術は、特定の障害のある利用者という狭義の限られた人たちをターゲットにしているということだ。支援技術により提供される支援は、そのターゲット利用者のニーズにより特化しており適切なものである。主流のユーザエージェントは、プログラムのオブジェクトからウェブコンテンツを取り出したり、マークアップを識別可能な構造に解釈したりするようにして、重要な機能を支援技術に提供することができる。
事例：この文書の文脈において重要な支援技術としては、以下のものが挙げられる：
画面拡大ソフトおよびその他の視覚的な表示に関する支援技術。視覚障害、知覚障害、および読書困難などの障害のある人が、レンダリング後のテキストおよび画像の視覚的な読みやすさを改善するために、テキストのフォント、サイズ、間隔、色、音声との同期などを変更するのに使用している。
スクリーンリーダー。全盲の人がテキスト情報を合成音声あるいは点字で読み取るために使用している。
音声変換ソフトウェア。認知障害、言語障害、および学習障害のある人が、テキストを合成音声に変換するために使用している。
音声認識ソフトウェア。何らかの身体障害のある利用者が使用することがある。
代替キーボード。特定の身体障害のある人がキーボードを擬似操作するのに使用している（ヘッドポインタ、シングルスイッチ、呼気・吸気スイッチ、およびその他の特別な入力デバイスを使った代替キーボードを含む）。
代替ポインティングデバイス。特定の身体障害のある人がマウスポインタとボタンを擬似操作するのに使用している。
- キャプション
そのメディアのコンテンツを理解するのに必要な、発話および発話ではない音声情報の両方に対する、同期した視覚的表現あるいは代替テキスト。
注記 1： キャプションは、発話のみの字幕と似ているが、次の点において異なる。キャプションは、発話コンテンツだけでなく、その番組コンテンツを理解するのに必要な、発話ではない音声情報と等価な内容も伝える。つまり、効果音、音楽、笑い声、話者の特定、そして位置なども含まれるのである。
注記 2：クローズド・キャプションは、プレーヤーによっては ON/OFF を切り替えることのできる等価物である。
注記 3: オープン・キャプションは、OFFにすることのできないキャプションである。例えば、キャプションが映像に埋め込まれた、視覚的に等価な画像化された文字である場合がある。
注記 4: キャプションは、映像の関連情報を分かりにくくしたり遮ったりすべきではない。
注記 5: 国によっては、キャプションはサブタイトル（字幕）と呼ばれている。
注記 6:音声ガイドは既に視覚的に提示されている情報の説明なので、キャプションにしてもよいが、そうする必要があるわけではない。
- 画像化された文字
特定の視覚的効果を得るために非テキスト形式（例：画像）でレンダリングされる文字
注記：これには、重要なその他の視覚的なコンテンツを含む画像の一部であるテキストは含まれない。
- テキスト
プログラムで解釈できる文字の連続で、その連続が自然言語で何かを表現しているもの。
画像化された文字:
達成基準 1.4.5 を理解する
1.4.5 画像化された文字： 使用している技術で意図した視覚的な表現が可能である場合は、画像化された文字ではなくテキストを用いて情報を伝える。ただし、以下に挙げる場合は除く （レベル AA）：
注記： ロゴタイプ（ロゴあるいはブランド名の一部である文字）は必要不可欠なものであるとみなす。
この達成基準の意図
この達成基準の意図は、特定の視覚的な表現が可能なウェブコンテンツ技術を用いるコンテンツ制作者に、テキストの特定の視覚的な表現を必要とする利用者が、必要に応じてテキストの表現を整えられるようにすることを推奨することである。テキストに、特定のフォントサイズ、前景色及び背景色、書体、行間、又は配置を求める利用者がいる。
もし、テキストを用いて同じ視覚的な効果が得られるのであれば、コンテンツ制作者は、情報を提示するのに画像を用いるのではなく、テキストを用いるべきである。もしも何らかの理由により、コンテンツ制作者がテキストの書式を整えても同じ効果が得られない、その効果が一般に入手可能なユーザエージェントでは確実に提示できない、又は、この達成基準を満たすウェブコンテンツ技術を用いることが達成基準 1.4.4 などの他の達成基準を満たすことの妨げになる場合には、画像化された文字を使ってもよい。例としては、書体のサンプル、ロゴタイプ、ブランディングなどのように、伝える情報にとってそのテキストの特定の表現が必要不可欠な場合が該当する。また、画像化された文字は、広く普及していない又はコンテンツ制作者が再配布する権利を持っていない、特定の書体を用いる目的で使われることがある。あるいは、そのテキストがすべてのユーザエージェントでアンチエイリアスをかけた状態になるようにする目的で使われることもある。
利用者が画像化された文字を自分の好みに合わせてカスタマイズできる場合にも、画像化された文字を用いてもよい。
この達成基準を満たすための実装方法は、達成基準 1.4.9 と同じである。ただし、その視覚的な表現がコンテンツ制作者の用いるウェブコンテンツ技術で実現可能な場合だけ適用されるという点だけが異なる。達成基準 1.4.9 については、利用者がカスタマイズできるときのみ、達成基準を満たすことのできる実装方法を適用することになる。
「達成基準 1.4.9 画像化された文字（例外なし）」を理解するも参照のこと。
達成基準 1.4.5 の事例
スタイルを指定した見出し
特定のフォント及びサイズで見出しを提示するために、ビットマップ画像を用いるのではなく、コンテンツ制作者はCSSを用いて同じ見栄えにしている。
動的に生成された画像
あるウェブページでは、サーバサイドのスクリプトを用いてテキストを画像として提示している。そのページには、利用者が生成される画像のフォントサイズ及び前景色と背景色を調節することのできるコントロールがある。
引用
あるウェブページに引用がある。その引用部分自体は、イタリックのテキストで、左側をインデントした状態で提示されている。その引用した部分の人名が、引用の下に1.5倍の行間を空けて、左側からさらにインデントした状態になっている。そのテキストの配置、行間スペースの指定、そしてテキストの書体・サイズ・色及び装飾には、CSS を用いている。
ナビゲーション
ウェブページに、ナビゲーション・リンクのメニューがあり、アイコンとテキストの両方でリンク先を示している。CSSを用いて、テキストの書体、サイズ、前景色及び背景色、そしてナビゲーション・リンク間の間隔を指定している。
文字を含んだロゴ
あるウェブサイトには、各ウェブページの左上のコーナーに組織のロゴがある。そのロゴには、ロゴタイプ（ロゴの一部又は全部に文字）がある。 文字の視覚的な表現は、そのロゴのアイデンティティに不可欠であり、その文字の特徴を変更することができないGIF画像としてそこにある。そして、その画像には、代替テキストがある。
書体のサンプル
ウェブページに、特定の書体に関する情報がある。その書体を他の書体に置き換えると、サンプルとしての目的が損なわれてしまう。そのサンプルは、その文字の特徴を変更することができない JPEG 画像としてそこにある。そして、その画像には、代替テキストがある。
手紙の原本
ウェブページに、手紙の原本を描写したものがある。オリジナルの体裁でその手紙見せることが、その手紙の書かれた時代に関する情報を伝える上で不可欠である。その手紙は、その文字の特徴を変更することができない GIF 画像としてそこにある。そして、その画像には、代替テキストがある。
記号的な文字
利用者がテキストのブロックを入力できるフォームがある。そのフォームは、テキストのスタイル指定やスペルチェックなどの機能のボタンをたくさん提供している。ボタンの中には、文字を用いたものがあり、その文字に自然言語で何かを表現する並び順はない。例えば、フォントを太字にする機能には "B"、テキストをイタリックにする機能には "I"、そしてスペルチェックの機能には "ABC" が使われている。その記号的な文字は、その文字の特徴を変更することができない GIF 画像としてボタンになっている。そして、そのボタンには、代替テキストがある。
画像化された文字のカスタマイズ可能なフォント設定
あるウェブサイトでは、利用者がフォントを設定できるようになっており、このウェブサイトのすべての画像化された文字は、その設定に基づいて提供される。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準 1.4.5 の実装方法及び不適合事例 － 画像化された文字
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
達成基準 1.4.5 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
非テキストコンテンツ向けの一般的な実装方法
Identifying informative non-text content （リンク追加予定）
達成基準 1.4.5 のよくある不適合事例
以下に挙げているのは、WCAG ワーキンググループが達成基準 1.4.5 に適合していないとみなした、よくある不適合事例である。
（今のところ、文書化されている不適合事例がない）
重要な用語
- 必要不可欠
もし取り除いてしまうと、コンテンツの情報あるいは機能を根本的に変えてしまい、かつ、情報および機能が WCAG に適合する他の方法では提供することができない。
- 画像化された文字
特定の視覚的効果を得るために非テキスト形式（例：画像）でレンダリングされる文字
注記：これには、重要なその他の視覚的なコンテンツを含む画像の一部であるテキストは含まれない。
- テキスト
プログラムで解釈できる文字の連続で、その連続が自然言語で何かを表現しているもの。
- 視覚的にカスタマイズ
フォント、サイズ、色、および背景を設定可能。
より十分なコントラスト:
達成基準 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.4.5 で述べられているように、画像化された文字（画像フォーマットで保存された文字）にも適用される。
この要件は、画像化された文字が情報を伝えることを目的としている状況に対して適用される。例えば、写真の中にたまたま入っていた街頭の標識にあるような付随的なテキストは、対象外である。また、何らかの理由で、すべての利用者が視覚的に確認できないことを意図しているテキストも対象外である。
この達成基準には、「意味のあるその他の視覚的なコンテンツを含む写真の一部分である」という例外がある。この例外は、テキストの写っている写真と特定の見た目にするためにテキストの代わりに画像化された文字とを区別することを意図している。
この達成基準は、テキスト（文字）だけに適用されるが、図表やグラフで提示されるデータにも似たような問題が起こる。そのようなデータでも、色のコントラストを十分に確保すべきである。
コントラスト比を定めた論理的根拠
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 のコントラスト比を必要とすることになる。
色相は、色弱の利用者（先天的及び後天的の両方）によって知覚のされ方がさまざまなため、色及び相対的な輝度コントラストが色弱ではない利用者とは異なる。このため、有効なコントラスト及び読みやすさは、色弱の利用者に対しては異なったものになる。しかし、色弱は多様であるため、（コントラストのために）量的なデータに基づいて有効で一般的な色の組合せを規定することは、適切であるとはいえない。十分な輝度コントラストを要求することで、色の知覚に依存しないコントラストを要求し、この問題に対応している。幸いにも、輝度の寄与のほとんどは、分光感度において大部分が重なる中波長及び長波長の受容体からくるものである。その結果は、有効な輝度コントラストが一般的に特定の色弱に関係なく計算できるということである。ただし、赤色を知覚しにくい第一色弱の利用者の場合、暗い色（一般的に黒のようである）に対して主に波長の長い色を用いることは除く（この理由から、WCAG ワーキンググループは、黒の背景に赤の前景を使うことを避けるという参考にすべき実装方法を提供している）。より詳細な情報は、[ARDITI-KNOBLAUCH][ARDITI-KNOBLAUCH-1996][ARDITI] を参照のこと。
レベル AA で 4.5：1 のコントラスト比を選択したのは、20/40 程度まで視力の低下した利用者におけるコントラスト感度の低下を補うためである（20/40 は約 4.5：1 という計算になる）。また、20/40 は、80歳前後の高齢者の標準的な視力として、よく報告される視力である [GITTINGS-FOZARD]。
レベル AAA で 7：1 のコントラスト比を選択したのは、20/80 程度まで視力の低下した利用者におけるコントラスト感度の低下を補うためである。これ以上に視力が低下した利用者は、通常は支援技術を使用して、コンテンツを利用している（その支援技術には、コントラスト増強と画面拡大の機能が搭載されている）。そのため、7：1 というコントラスト比は、一般的に支援技術を使用していない利用者のコントラスト感度の低下を補い、同様に色弱の利用者に対してもコントラストを向上させる。
計算式に関する注記
RGB 値の非線形から線形への変換は、IEC/4WD 61966-2-1 [IEC-4WD] 及び "A Standard Default Color Space for the Internet - sRGB" [sRGB] に基づいている。
コントラストの計算式（L1/L2）は、[ISO-9241-3] および [ANSI-HFES-100-1988] の標準規格に基づいている。
ANSI/HFS 100-1988 は、L1 及び L2 の計算に含めるために、周辺光からの寄与を必要としている。用いている .05 という値は、[IEC-4WD] の Typical Viewing Flare 及び 論文[sRGB]（M. Stokes et al）に基づいている。
この達成基準及びその定義では、ウェブコンテンツが光自体を発するわけではないという事実を反映するために、"輝度（luminance）" ではなく、"コントラスト比（contrast ratio）" 及び "相対輝度（relative luminance）" という用語を用いている。コントラスト比は、コンテンツが表示されたときに生じる相対輝度の評価基準（尺度）を与える（それは、比率なので、無次元である）。
達成基準 1.4.6 の事例
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準 1.4.6 の実装方法及び不適合事例 － より十分なコントラスト
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
達成基準を満たすことのできる実装方法
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の実装方法（又は、実装方法の組合せ）がある。
達成基準 1.4.6 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
G156： テキスト・ブロックの前景及び背景を変更できる、一般に入手可能なユーザエージェントのあるウェブコンテンツ技術を用いる
Using a higher contrast value for text that is over a patterned background （リンク追加予定）
Using Unicode text and style sheets instead of images of text （リンク追加予定）
Using a higher contrast values for lines in diagrams （リンク追加予定）
Using greater contrast level for red-black text/background combinations
Using colors that are composed predominantly of mid spectral components for the light and spectral extremes (blue and red wavelengths) for the dark
Using a light pastel background rather than a white background behind black text to create sufficient but not extreme contrast （リンク追加予定）
Making icons using simple line drawings that meet the contrast provisions for text （リンク追加予定）
Providing sufficient color contrast in graphs and charts （リンク追加予定）
Using a 3:1 contrast ratio or higher as the default presentation （リンク追加予定）
Providing sufficient color contrast for empty text fields （リンク追加予定）
達成基準 1.4.6 のよくある不適合事例
以下に挙げているのは、WCAG ワーキンググループが達成基準 1.4.6 に適合していないとみなした、よくある不適合事例である。
重要な用語
- コントラスト
(L1 + 0.05) / (L2 + 0.05)
注記 1： コントラスト比は、1～21の範囲になりうる（通常は、1：1～21：1と記述される）。
注記 2： コンテンツ制作者は、テキストのレンダリング（例：フォントのスムージングやアンチエイリアス）に関する利用者の設定を制御できないため、テキストのコントラスト比はアンチエイリアスをオフにした状態で評価される。
注記 3: 達成基準 1.4.3 および 1.4.6 の目的上、コントラストは通常の使用においてテキストがレンダリングされる際に指定されている背景色に対して測定される。もし背景色の指定がない場合は、背景色には白を想定することになる。
注記 4: 背景色は、テキストが通常の使用においてレンダリングされる際に背景となるコンテンツの指定された色である。テキストの色が指定されている際に背景色が指定されていない場合は問題がある。なぜなら、利用者のデフォルトの背景色は未知であり、コントラストが十分かどうかを評価することができないからである。同じ理由で、背景色が指定されている際にテキストの色が指定されていない場合も問題ありということになる。
注記 5: 文字の周囲に縁取りがある際、その縁取りがコントラストを強めることもあり、文字とその背景色におけるコントラストの計算に用いられる。ただし、文字の周囲の細い縁取りは文字として扱われる。文字の周囲の太い縁取りが、かさ（暈：ハロー、後光）のようになって、文字の細かい字画を埋めていれば、背景色として考慮されることになる。
注記 6: WCAG への適合は、典型的な表現において隣接すると制作者が想定してコンテンツで指定した色の組み合わせに対して評価されるべきである。制作者は、ユーザエージェントによる色の変更などのように通常とは異なる表現を考慮する必要はない。ただし、それが制作者のソースコードによって起こる場合は除く。
- 画像化された文字
特定の視覚的効果を得るために非テキスト形式（例：画像）でレンダリングされる文字
注記：これには、重要なその他の視覚的なコンテンツを含む画像の一部であるテキストは含まれない。
- サイズの大きな（テキスト）
少なくとも18ポイント、もしくは14ポイントの太字。あるいは、中国語、日本語、そして韓国語のフォントではそれと同等の文字サイズ（訳注： 日本語では、22ポイント、もしくは18ポイントの太字）。
注記 1： 特別に細い線のフォント、あるいは文字の形が分かりにくくなるような独特の見た目や特徴のあるフォントは、コントラストが低いとき特に読みづらい。
注記 2： ここでいう文字サイズは、コンテンツが提供される際のサイズである。利用者によって変更されたサイズは含まれない。
注記 3: 文字の実際のサイズは、コンテンツ制作者が指定したサイズと利用者のディスプレイあるいはユーザエージェントの設定の両方に依存している。多くの主流となっている本文フォントにおいて、本文テキストのデフォルトのサイズは、14ポイントと18ポイントは、1.2emと1.5em、または、（本文フォントが100％であると仮定して）デフォルトサイズの120%と150%に、おおよそ同等である。しかし、制作者は、使用する特定のフォントについて、このことをチェックしておく必要がある。フォントが相対単位で定義されている時、実際の文字ポイントのサイズは、表示画面のため、ユーザエージェントによって計算される。この評価基準を評価する時には、文字ポイントのサイズは、ユーザエージェントから取得されるべきであり、またはユーザエージェントが行うフォントの計算基準に基づいて計算するべきである。ロービジョンの利用者に対しては、自分で適切な設定を選択することを想定している。
注記 4: フォントサイズを指定せずにテキストを用いる際は、サイズを指定していないテキストに対して主要ブラウザで用いられる最小のフォントサイズをそのテキストのサイズとみなすのが妥当であろう。もし、レベル1の見出しが、主要なブラウザで14ポイントの太字あるいはそれ以上のサイズでレンダリングされるならば、それは「サイズの大きな」テキストであると考えてよい。相対的な拡大縮小は、同じやり方でそのデフォルトのサイズから算出することが可能である。
注記 5: ローマ字のテキストにおける18ポイントおよび14ポイントのサイズは、拡大印刷の最小サイズ（14ポイント）と標準的な大きい文字サイズ（18ポイント）からきている。例えば、中国語、日本語、韓国語など、その他の文字については、「同等な」サイズはその言語での拡大印刷の最小サイズと拡大印刷でその次に大きな標準のサイズとなる。（訳注：日本語では、22ポイント、18ポイントの太字を目安とする。）
- 装飾だけを目的
美的な目的だけを果たしていて、情報は提供せず、機能性も備えていない。
注記： その単語を手直ししたり置き換えたりしてもその目的が変わらないのであれば、テキストは単に装飾だけを目的にしたものといえる。
事例： 辞書の表紙には、その背景にとても淡い文字で単語がランダムに並んでいる。
- テキスト
プログラムで解釈できる文字の連続で、その連続が自然言語で何かを表現しているもの。
- 利用者インターフェース要素
特定の機能を果たすために単一のコントロールとして利用者が知覚する、コンテンツの一部分。
注記 1： 複数の利用者インターフェース要素が単一のプログラム的要素として実装されることがある。ここでいう要素は、プログラミングテクニックではなく、別々のコントロールとして利用者が知覚するものを指す。
注記 2： 利用者インターフェース要素には、スクリプトで生成されるコンポーネントやフォーム要素、リンクが含まれる。
事例： アプレットには、コンテンツ内を行ごと、ページごと、あるいはランダムに移動するために用いられる "コントロール" がある。これらはどれも識別名があり、個別に設定可能なので、それぞれが "利用者インターフェース要素" となる。
小さい背景音又は背景音なし:
達成基準 1.4.7 を理解する
1.4.7 小さい背景音又は背景音なし： 収録済の音声しか含まないコンテンツで、(1) 前景に主として話し言葉を含み、(2) 音声 CAPTCHA あるいは音声ロゴではなく、かつ(3) 例えば、歌やラップなどのように、主として音楽表現を意図した発声ではないものについては、以下に挙げるうちの少なくとも1つがあてはまる。 （レベル AAA）：
この達成基準の意図
この達成基準の意図は、発話ではないあらゆる音が、難聴の利用者が発話を背景音又は前景にある不要な他の発話コンテンツと区別することができるようにすることである。
20 dB（デシベル）という値は、 Large area assistive listening systems (ALS): Review and recommendations [LAALS] and In-the-ear measurements of interference in hearing aids from digital wireless telephones [HEARING-AID-INT] に基づいている。
達成基準 1.4.7 の事例
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準 1.4.7 の実装方法及び不適合事例 － 小さい背景音又は背景音なし
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
達成基準 1.4.7 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
達成基準 1.4.7 のよくある不適合事例
以下に挙げているのは、WCAG ワーキンググループが達成基準 1.4.7 に適合していないとみなした、よくある不適合事例である。
（今のところ、文書化されている不適合事例がない）
重要な用語
- 音声しか含まない
音声のみを含んだ、時間の経過に伴って変化する表現（映像やインタラクションを含まない）。
- CAPTCHA
"Completely Automated Public Turing test to tell Computers and Humans Apart"（コンピュータと人間とを判別する完全自動化されたチューリングテスト）の頭文字語。
注記 1：CAPTCHA テストは、不明瞭な画像あるいは音声ファイルで提示される文字を利用者に入力するよう求めることが多い。
注記 2：チューリングテストは、人間とコンピュータを判別するために設計されたテストの仕組みである。その名は、これを考案した有名なコンピュータ科学者のアラン・チューリングにちなんで名付けられた。この用語は、カーネギーメロン大学の研究者たちによる造語であった。 [CAPTCHA]
- 収録済
ライブではない情報。
視覚的な表現:
達成基準 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行あるということである）。
いくらかの認知障害のある利用者は、均等割り付けされているテキストを読むのに問題を抱えている。左右両端を揃えた状態で行ごとに単語間（日本語では文字間）がまちまちの場合、空白が "白い川" のようにページの下のほうへ流れていると、テキストが読みづらくなり、全く読めなくなることもありうる。また、テキストの均等割り付けは、単語間が近くなりすぎて、単語と単語の分かれ目が分かりづらくなってしまうこともある。
テキストのサイズ変更は、視覚的にレンダリングされるテキスト（視覚的に見ることができるように表示されたテキストの文字 [vs. text characters that are still in data form such as ASCII]）を、利用者がすべてのコンテンツを見るのに左右にスクロールすることのないように、問題なく拡大可能にすることである。それが可能なようにコンテンツが制作されていると、コンテンツは折り返しになる。これにより、ロービジョンの利用者及び認知障害のある利用者は、混乱することなく、テキストのサイズを拡大することができるようになる。
コンテンツを拡大することは、第一にユーザエージェントが果たすべき役割である。UAAG 1.0 チェックポイント 4.1 を満たしているユーザエージェントは、利用者がテキストの拡大及び縮小を設定できるようにしている。コンテンツ制作者が果たすべき役割は、ユーザエージェントがコンテンツを効果的に拡大できるように、そして表示されているビューポートの横幅の中でコンテンツが折り返すように、ウェブコンテンツを制作することである。テキストのサイズ拡大に関するその他の情報は、「達成基準 1.4.4 テキストのサイズ変更」を理解するを参照のこと。
横スクロールする必要がないという要件は、長い語句を1行に表示すると利用者が横にスクロールする必要があるような、小さい画面の端末に適用することを意図していない。この要件の目的のためには、コンテンツ制作者は、標準的なデスクトップ/ラップトップの画面でブラウザのウィンドウを最大化した状態で、コンテンツがこの要件を満たすようにしなければならない。利用者は一般的に何年も自分のコンピュータを使い続けるので、この基準をテストする際には、最新のデスクトップ/ラップトップの画面解像度ではなく、数年間にわたって普及しているデスクトップ/ラップトップの画面解像度を考慮すべきである。
一つの単語が全画面の幅の半分以上になるほど長くないかぎり、折り返して全体を表示することが可能である。とても長い URI は、拡大された画面からはみ出してしまうかもしれないが、URI は "読む" ためのテキストではないとみなされるので、この基準に反することはない。
この基準は、利用者が横スクロールをする必要が絶対にないということを意味するわけではない。単に、1行のテキストを読むために、利用者が横スクロールを繰り返す必要がないということを意味しているだけである。例えば、テキストが同じ幅の二段組になっているページは、この基準を自動的に満たしていることになるだろう。ページを拡大するというのは、一つめの段が画面上に全部見えていて、利用者がページを縦にスクロールするだけで読むことができるということを意味する。2つめの段を読むには、利用者は右へ横スクロール移動して、右側の段が画面の幅の中に完全に見える状態にして、それ以上は横にスクロールすることなく、その段を読むであろう。
達成基準 1.4.8 の具体的なメリット
この達成基準は、コンテンツの表現はそのままでテキストを読めるようにすることにより、ロービジョンの利用者の役に立つ。テキストの色及びサイズを調節できるようにすることにより、ロービジョンの利用者は、自分が見やすくなるようにテキストを調節することができるようになる。
この達成基準は、認知障害、言語障害、及び学習障害のある利用者がテキストを知覚して、テキストのブロック内での位置を把握できるようにする。
認知障害のある利用者は、自分に最適な前景色と背景色の組合せを選ぶことができると、テキストをより読むことができるようになる。
認知障害のある利用者は、テキストのブロックの幅が狭くて、行送り幅及び段落の間隔を調整できると、自分の読んでいる位置を把握しやすくなる。
認知障害のある利用者は、単語と単語の間隔が均一になっていると、テキストをより容易に読むことができるようになる。
達成基準 1.4.8 の事例
次の画像は、段落内でシングルスペース（1行送り）、1.5文字分の行送り幅（1.5行送り）、及びダブルスペース（2行送り）になっているテキストの例を示している。
図形記号（グリフ）の例としては、"A"、"→" （矢印の記号）、そして "さ" （日本語の文字）などが挙げられる。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
CSS 2 Box Model
CSS 2 Visual formatting Model
CSS 2 Visual formatting Model Details
CssLayouts
About fluid and fixed width layouts
Accessible CSS
Ideal line length for content
Developing sites for users with Cognitive disabilities and learning difficulties
RDFA Primer
MULTIFUNK: Bringing computer-supported reading one step further, Date: April 2002, ISBN: 82-539-0491-6, Author: Gjertrud W. Kamstrup, Eva Mjøvik, Anne-Lise Rygvold og Bjørn Gunnar Saltnes
ERIC Web portal
"Cognitive difficulties and access to information systems - an interaction design perspective", Peter Gregor and Anna Dickinson, Applied Computing, University of Dundee
"Case Study of a Dyslexic Person's Visual Perceptual Problems: A Fizz Effect", Nigel Beauchamp, IMPACT Research Group, Computer Science, Loughborough University
"A Dyslexic Perspective on e-Content Accessibility" Peter Rainger, Date of Publication: 20/01/03
Legge, G.E., Pelli, D.G., Rubin, G.S., & Schleske, M.M.:Psychophysics of reading. I. Normal Vision,Vision Research, 25, 239-252, 1985.
Legge, G.E., Rubin, G.S., Pelli, D.G., & Schleske, M.M.:Psychophysics of reading. II. Low Vision,Vision Research, 25, 253-266, 1985.
Osaka,N. and Oda, K. (1991). Effective visual field size necessary for vertical reading during Japanese text processing. Bulletin of Psychonomic Society,29(4),345-347.
Beckmann, P.J. & Legge, G.E. (1996). Psychophysics of reading. XIV. The page-navigation problem in using magnifiers. Vision Research, 36, 3723-3733.
川嶋英嗣・小田浩一(2003).読書におけるスクロール方向とウィンドウ幅の影響 日本心理学会第67回大会, 502.
小田浩一・今橋真理子(1995). 文字認知の閾値と読みの閾値. VISION, 7, 165-168.
Osaka,N. (1994). Size of saccade and fixation duration of eye movements during reading: psychophysics of Japanese text processing. Journal of Optical Society of America A, 9(1), 5-13.
山中今日子・小田浩一 (2007). 漢字の画数と書体のウェイトが視認性に及ぼす影響. 視覚学会2007年夏季大会ポスター 1p1 Vision, P.167.
Line Length, Volume, and Density
The Forgotten People: Designing for Cognitive Disability
The Disability Discrimination Act, Developing an Accessible Information Policy (PDF)
Cognitive Disabilities and the Web: Where Accessibility and Usability Meet?
Guidance on accessible publishing
An Accessibility Frontier: Cognitive disabilities and learning difficulties
Cognitive/Perceptual Difference And Good Web Design
達成基準 1.4.8 の実装方法及び不適合事例 － 視覚的な表現
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
達成基準を満たすことのできる実装方法
使用法： これは複数の要件から成る達成基準なので、次の要件それぞれについて、番号付きの項目の中から1つを満たさなければならない。
達成基準 1.4.8 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
Using a hover effect to highlight a paragraph, list items, or table cells (HTML, CSS) （リンク追加予定）
Presenting text in sans serif font or providing a mechanism to achieve this (CSS) （リンク追加予定）
Using vertical (bulleted or numbered) lists rather than inline lists （リンク追加予定）
Using upper and lower case according to the spelling conventions of the text language （リンク追加予定）
Providing large fonts by default （リンク追加予定）
Avoiding the use of text in raster images （リンク追加予定）
Avoiding scaling font sizes smaller than the user-agent default （リンク追加予定）
Providing sufficient inter-column spacing （リンク追加予定）
Avoiding centrally aligned text （リンク追加予定）
Avoiding chunks of italic text （リンク追加予定）
Avoiding overuse of different styles on individual pages and in sites （リンク追加予定）
Making links visually distinct （リンク追加予定）
Providing expandable bullets （リンク追加予定）
Show/hide bullet points （リンク追加予定）
Putting an em-space or two spaces after sentences （リンク追加予定）
達成基準 1.4.8 のよくある不適合事例
以下に挙げているのは、WCAG ワーキンググループが達成基準 1.4.8 に適合していないとみなした、よくある不適合事例である。
重要な用語
- テキスト・ブロック
テキストの一文よりも長いもの。
- メカニズム
結果を得るためのプロセスあるいはテクニック。
注記 1：メカニズムは、コンテンツ内で明白に提供されることもあれば、あるいは、プラットフォームまたは支援技術を含むユーザエージェントのどちらかで提供されるものに依存することもある。
注記 2： メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。
- 全画面表示のウィンドウで
最も一般的なデスクトップ/ラップトップのディスプレイで、ビューポート（情報の表示域）を最大化した状態。
注記： 利用者は一般的にコンピュータを数年間使い続けるので、最新のデスクトップやラップトップの画面解像度を基準にするのではなく、数年間にわたって一般的なデスクトップやラップトップの画面解像度を考慮するのが最もよい。
画像化された文字（例外なし）:
達成基準 1.4.9 を理解する
この達成基準の意図
この達成基準の意図は、テキストの特定の視覚的な表現を必要とする利用者が、必要に応じてテキストの表現を整えられるようにすることである。テキストに、特定のフォントサイズ、前景色及び背景色、書体、行間、又は配置を求める利用者がいる。
これは、テキストをその表現が変更できるように実装すること、又は利用者が代替の表現を選択できるメカニズムを提供することを意味する。画像化された文字を使用することは、すべての利用者がテキストの表現を変えることができない実装の一例である。
ある状況においては、文字の特定の視覚的な表現がその情報を伝える上で不可欠である。その特定の視覚的な表現でないと、その情報が損なわれてしまうことになる。そのような場合は、テキストを変更できるような方法で実装する必要はない。例えば、ある書体を紹介する際のようにテキストの特定の視覚的な様相を示す場合や、企業ロゴにある文字のようにアイデンティティを伝える文字などが挙げられる。
装飾を目的にした文字は、その表現を変更できるように実装する必要はない。
達成基準 1.4.9 の事例
引用
あるウェブページに引用がある。その引用部分自体は、イタリックのテキストで、左側をインデントした状態で提示されている。その引用した部分の人名が、引用の下に1.5倍の行間を空けて、左側からさらにインデントした状態になっている。そのテキストの配置、行間スペースの指定、そしてテキストの書体・サイズ・色及び装飾には、CSS を用いている。
ナビゲーション
ウェブページに、ナビゲーション・リンクのメニューがあり、アイコンとテキストの両方でリンク先を示している。CSSを用いて、テキストの書体、サイズ、前景色及び背景色、そしてナビゲーション・リンク間の間隔を指定している。
文字を含んだロゴ
あるウェブサイトには、各ウェブページの左上のコーナーに組織のロゴがある。 そのロゴには、ロゴタイプ（ロゴの一部又は全部に文字）がある。 文字の視覚的な表現は、そのロゴのアイデンティティに不可欠であり、その文字の特徴を変更することができないGIF画像の中にある。そして、その画像には、代替テキストがある。
書体のサンプル
ウェブページに、特定の書体に関する情報がある。その書体を他の書体に置き換えると、サンプルとしての目的が損なわれてしまう。そのサンプルは、その文字の特徴を変更することができない JPEG 画像の中にある。そして、その画像には、代替テキストがある。
手紙の原本
ウェブページに、手紙の原本を描写したものがある。オリジナルの体裁でその手紙見せることが、その手紙の書かれた時代に関する情報を伝える上で不可欠である。その手紙は、その文字の特徴を変更することができない GIF 画像の中にある。そして、その画像には、代替テキストがある。
記号的な文字
利用者がテキストのブロックを入力できるフォームがある。そのフォームは、テキストのスタイル指定やスペルチェックなどの機能のボタンをたくさん提供している。ボタンの中には、文字を用いたものがあり、その文字に自然言語で何かを表現する並び順はない。例えば、フォントを太字にする機能には "B"、テキストをイタリックにする機能には "I"、そしてスペルチェックの機能には "ABC" が使われている。その記号的な文字は、その文字の特徴を変更することができない GIF 画像としてボタンになっている。そして、そのボタンには、代替テキストがある。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
達成基準 1.4.9 の実装方法及び不適合事例 － 画像化された文字（例外なし）
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
達成基準 1.4.9 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
General Techniques for Non-Decorative Content
達成基準 1.4.9 のよくある不適合事例
以下に挙げているのは、WCAG ワーキンググループが達成基準 1.4.9 に適合していないとみなした、よくある不適合事例である。
重要な用語
- 必要不可欠
もし取り除いてしまうと、コンテンツの情報あるいは機能を根本的に変えてしまい、かつ、情報および機能が WCAG に適合する他の方法では提供することができない。
- 画像化された文字
特定の視覚的効果を得るために非テキスト形式（例：画像）でレンダリングされる文字
注記： これには、重要なその他の視覚的なコンテンツを含む画像の一部であるテキストは含まれない。
- 装飾だけを目的
美的な目的だけを果たしていて、情報は提供せず、機能性も備えていない。
注記： その単語を手直ししたり置き換えたりしてもその目的が変わらないのであれば、テキストは単に装飾だけを目的にしたものといえる。
事例： 辞書の表紙には、その背景にとても淡い文字で単語がランダムに並んでいる。
- テキスト
プログラムで解釈できる文字の連続で、その連続が自然言語で何かを表現しているもの。
キーボード操作可能:
ガイドライン 2.1 を理解する
ガイドライン 2.1： 全ての機能をキーボードから利用できるようにする。
ガイドライン 2.1 の意図
すべての機能がキーボードを用いて利用可能であれば、キーボードの利用者、音声入力（キーボード入力を生成する）、マウス（オンスクリーン・キーボードを使用する）、及び出力として疑似的なキーストロークを生成する広範囲に及ぶ支援技術が、その機能を利用することができることになる。この柔軟性は他の入力形態にはないもので、キーボード入力が時間に依存していないかぎり、広く一般にサポートされていて、さまざまな障害のある利用者が操作可能な入力形態は他にはない。
普遍的なキーボード入力を提供することが、他の種類の入力をサポートをサポートすべきではないという意味ではないことに注意してほしい。最適化された音声入力、最適化されたマウス/ポインタなども、有用である。重要なのは、それらと同様にキーボード入力及び制御も提供することである。
中には、もともとキーボードを持たないものもある。例えば、PDA 又は携帯電話がそうである。しかし、こういったデバイスにウェブ閲覧機能がある場合には、テキスト又は "キーストローク" を生成する何らかの手段があるはずである。このガイドラインでは、キーボード、キーボード・エミュレータ、又はキーボードあるいはテキスト入力を生成するその他のハードウェアあるいはソフトウェアにより生まれるキーストロークにより、ウェブコンテンツが制御可能であるべきだということを認識するために、"キーボード・インタフェース" という用語を用いている。
ガイドライン 2.1 の参考にすべき実装方法（特定の達成基準に特有ではない実装方法）
このガイドラインにある各達成基準を満たすための実装方法は、この後に達成基準ごとに挙げられている。 しかし、このガイドラインに対処するための実装方法がどの達成基準にも該当しない場合は、ここで挙げている。そういった実装方法は、どの達成基準を満たす上でも必須ではないし、十分でもないが、ウェブコンテンツの種類によってはより多くの利用者にとってよりアクセシブルにすることができるものである。
- このガイドラインの参考にすべき実装方法はすべて、特定の達成基準に関係している。
キーボード操作:
達成基準 2.1.1 を理解する
2.1.1 キーボード操作： コンテンツのすべての機能は、個々のキーストロークに特定のタイミングを要することなく、キーボード・インタフェースを通じて操作可能である。ただし、その根本的な機能が単に利用者の動作の終点に依存しておらず、利用者の動作による軌跡に依存して実現されている場合は除く。 （レベル A）
注記 1： 前述の例外は、コンテンツの根本的な機能に関するものであり、入力手法に関するものではない。例えば、テキスト入力に手書き入力を用いるのであれば、その入力手法（手書き）は利用者の動作による軌跡（たとえば手書き入力に用いるマウスの動き）に依存した入力を必要とするが、その根本的な機能（テキスト入力）は利用者の動作による軌跡に依存した入力を必要とするものではない。
注記 2： これは、キーボード操作に加えて、マウス入力あるいはその他の入力手段を提供することを禁ずるものでも妨げるものでもない。
この達成基準の意図
この達成基準の意図は、可能なかぎり、コンテンツをキーボード又はキーボード・インタフェースで操作できるようにすることである（代替キーボードでも使用可能になる）。コンテンツがキーボード又は代替キーボードで操作可能であれば、全盲の（目と手を一緒に使うマウスのようなデバイスを使用できない）利用者、及び代替キーボード又はキーボード・エミュレータのような入力デバイスを使わなければならない利用者が、操作できることになる。キーボード・エミュレータには、音声入力ソフトウェア、呼気/吸気操作ソフトウェア、オンスクリーン・キーボード、スキャニングソフトウェア、そして多種多様な支援技術及び代替キーボードがある。また、ロービジョンの利用者は、ポインタを目で追うのが困難なことがあり、キーボードでソフトウェアを操作できれば、そのソフトウェアがとても使いやすくなる（又は、単に使えるようになる）。
"特定のタイミング" の事例としては、利用者が短時間のうちに複数のキーストロークを繰り返す又は実行する必要がある状況、あるいはキーストロークが登録されるまでは長い間キーを押下していなければならないような状況などが挙げられる。
"ただし、その根本的な機能が単に利用者の動作の終点に依存しておらず、利用者の動作による軌跡に依存して実現されている場合は除く。" というフレーズがあるのは、キーボードから合理的に制御できないものを区別するためである。
ポインティング・デバイスにより実行されるアクションのほとんどは、キーボードでも実行可能である（例えば、クリックする、選択する、動かす、拡大・縮小する）。しかし、ポインティング・デバイスでは可能だが、ものすごい数のキーストロークでないとキーボードでは不可能な入力がある。手書き描画、水彩画、及び障害物コースでのヘリコプター操縦などは、どれも軌跡（たとえば手書き入力に用いるマウスの動き）に依存した入力を要する機能の例である。直線や正の幾何学的図形を描くこと、ウィンドウのサイズを変更すること、及びある場所へオブジェクトをドラッグして移動させること（その位置への軌跡に意味がない際）は、軌跡に依存した入力を必要としない。
マウスキーを使用することでは、この達成基準を満たしたことにはならないだろう。なぜなら、アプリケーションに対しては、キーボードと等価なのではなく、マウスと等価だからである（つまり、アプリケーションからはマウスのように見えてしまうためである）。
利用者の入力機能を設計する際に、利用者がそのOSのキーボード・アクセシビリティ機能を使用する可能性があることを考慮するのは当然のことである。例えば、修飾キーがロックされているかもしれない。しかし、修飾キーのロックと衝突するイベントを送って予期しない結果が生じることのないように、コンテンツはそのような環境においても機能し続ける必要がある。
達成基準 2.1.1 の具体的なメリット
全盲の利用者（目と手を一緒に使うマウスのようなデバイスを使用できない）
ロービジョンの利用者（画面上のポインタを見つけたり目で追ったりするのが困難なことがある）
手に震えのある利用者は、マウスを使うのがとても困難なため、通常はキーボードを使用している。
達成基準 2.1.1 の事例
事例 1： 描画プログラム
ある描画プログラムは、利用者がキーボード操作でオブジェクトの作成、サイズ設定、配置及び回転をすることが可能である。
事例 2： ドラッグ&ドロップ機能
ドラッグ&ドロップを用いているアプリケーションが、オブジェクトを移動させるための "カット&ペースト" 又はフォーム・コントロールをサポートしている。
事例 3： 離れている点の間を移動および接続
点つなぎプログラムは、利用者が画面上の点を移動し、スペースキーで現在の点と直前の点を結ぶことができる。
事例 4： 例外 － お絵描きプログラム
水彩画を描くプログラムは、ひと筆がその動きの速さや持続にかなり依存して変化するため、例外の一つとして認められる。
事例 5： 例外 － ヘリコプター操縦訓練シミュレータ
ヘリコプター操縦訓練シミュレータは、シミュレータの性質上、リアルタイムなヘリコプターの動作を教えるものであるため、例外の一つとして認められる。
事例 6： オプションのキーボード付き PDA
通常はスタイラス・ペンで操作する PDA に、オプションで接続可能なキーボードがある。そのキーボードは、標準的な方法でウェブ閲覧を可能にする。ウェブコンテンツがキーボードのみでも利用できるように設計されているので、そのキーボードでも操作可能である。
達成基準 2.1.1 の実装方法及び不適合事例 － キーボード操作
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
達成基準 2.1.1 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
Using XHTML role, state, and value attributes if repurposing static elements as interactive user interface components （リンク追加予定） AND SCR29: Adding keyboard-accessible actions to static HTML elements (Scripting)
Providing keyboard shortcuts to important links and form controls （リンク追加予定）
Using unique letter combinations to begin each item of a list （リンク追加予定）
Choosing the most abstract event handler （リンク追加予定） (Scripting)
Using the onactivate event （リンク追加予定） (Scripting)
Avoiding use of common user-agent keyboard commands for other purposes （リンク追加予定）
達成基準 2.1.1 のよくある不適合事例
以下に挙げているのは、WCAG ワーキンググループが達成基準 2.1.1 に適合していないとみなした、よくある不適合事例である。
重要な用語
- 機能性
利用者のアクションにより実現可能なプロセスおよび結果。
- キーボード・インターフェース
キーストローク入力を取得するためにソフトウェアが用いるインターフェース。
注記 1： キーボードをもともと含んでいない技術であっても、キーボードインターフェースによって利用者がキーストローク入力をプログラムに提供できるようにする。
事例：タッチスクリーンPDAには、外部キーボードへのコネクタとあわせて、そのOSに組み込まれたキーボード・インターフェースがある。PDA上のアプリケーションはそのインターフェースを用いて、外部キーボード、あるいは手書き解釈プログラムや「キーボード・エミュレーション」機能付きの音声テキスト変換アプリケーションのような擬似キーボード出力を提供する他のアプリケーションのいずれかからキーボード入力を取得することができる。
注記 2：マウスキーのようなキーボード操作によるマウス・エミュレータによるアプリケーション（あるいは、そのアプリケーションの一部）の操作は、キーボード・インターフェースからの操作として見なされていない。それはプログラムの操作がキーボード・インターフェースからではなく、そのポインティング・デバイスからの操作だからである。
フォーカス移動:
達成基準 2.1.2 を理解する
2.1.2 フォーカス移動： キーボード・インタフェースを用いてキーボード・フォーカスをそのページのある構成要素に移動できる場合、キーボード・インタフェースだけを用いてその構成要素からフォーカスを外すことが可能である。また、もしその操作が矢印キー、あるいはTabキー以外の操作を必要とするならば、キーボード・フォーカスをその構成要素から外す方法を利用者に知らせる。 （レベル A）
注記： この達成基準を満たさないコンテンツでは、利用者がそのページ全体を使用できない恐れがあるため、Webページ上のすべてのコンテンツは他の達成基準を満たすために用いられているか否かにかかわらず、この達成基準を満たさなければならない。適合要件 5: 非干渉を参照のこと。.
この達成基準の意図
この達成基準の意図は、コンテンツがウェブページ上の一部分にキーボード・フォーカスを "閉じ込める" ことのないようにすることである。これは、一つのページの中に複数のフォーマットを組み合わせていて、プラグインを用いてレンダリングする又はアプリケーションを埋め込んでいる際によく起こる問題である。
ただし、その状態を抜け出してフォーカスを "閉じ込められない" ようにする方法を利用者が分かっているのであれば、ウェブページの機能がフォーカスの移動をコンテンツの一部分に限定してもよい。
達成基準 2.1.2 の事例
カレンダーのウィジェット
カレンダーのウィジェットは、利用者がキーボードを用いてそのカレンダーにアイテムを追加、削除又は更新することができるようになっている。ウィジェットにあるコントロールは、そのウェブページの Tab キーによるフォーカス移動順序の一部に入っていて、利用者がウィジェットのコントロールもその他のリンク又はコントロールをTabキーで移動できる。
利用者が Tab キーでフォーカスをアプレットの中に入れると、そこから先のフォーカス移動及びその他のキーストロークはそのアプレットが処理することになる。そして、そのアプレットから外へ出るのに用いるキーストロークに関する説明文が、そのアプレットに入る前及びそのアプレットの中にある。
モーダル・ダイアログボックス
ウェブアプリケーションで、ダイアログボックスが出てくる。そのダイアログボックスの下部には、"キャンセル" と "OK" の2つのボタンがある。ダイアログボックスが開くと、フォーカスはそのダイアログボックスから外へ抜け出せなくなる。ダイアログボックスの最後のコントロールで Tab キーを押すと、フォーカスはダイアログボックスの最初のコントロールへ移動してしまうのである。"キャンセル" ボタン又は "OK" ボタンを押下すると、そのダイアログボックスは閉じられる。
達成基準 2.1.2 の実装方法及び不適合事例 － フォーカス移動
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
達成基準 2.1.2 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
（まだ文書化されていない）
達成基準 2.1.2 のよくある不適合事例
以下に挙げているのは、WCAG ワーキンググループが達成基準 2.1.2 に適合していないとみなした、よくある不適合事例である。
重要な用語
- キーボード・インターフェース
キーストローク入力を取得するためにソフトウェアが用いるインターフェース。
注記 1： キーボードをもともと含んでいない技術であっても、キーボードインターフェースによって利用者がキーストローク入力をプログラムに提供できるようにする。
事例：タッチスクリーンPDAには、外部キーボードへのコネクタとあわせて、そのOSに組み込まれたキーボード・インターフェースがある。PDA上のアプリケーションはそのインターフェースを用いて、外部キーボード、あるいは手書き解釈プログラムや「キーボード・エミュレーション」機能付きの音声テキスト変換アプリケーションのような擬似キーボード出力を提供する他のアプリケーションのいずれかからキーボード入力を取得することができる。
注記 2：マウスキーのようなキーボード操作によるマウス・エミュレータによるアプリケーション（あるいは、そのアプリケーションの一部）の操作は、キーボード・インターフェースからの操作として見なされていない。それはプログラムの操作がキーボード・インターフェースからではなく、そのポインティング・デバイスからの操作だからである。
キーボード操作（例外なし）:
達成基準 2.1.3 を理解する
この達成基準の意図
この達成基準の意図は、すべてのコンテンツをキーボードで操作可能にすることである。例外が認められないということを除いては、達成基準 2.1.1 と同じである。ただし、その根本的な機能が単に利用者の動作の終点に依存しておらず、利用者の動作による軌跡に依存した入力を必要とするコンテンツ（つまり、達成基準 2.1.1 では例外とされていたコンテンツ）をキーボードで操作可能にするということではない。正しくは、そういったアナログで時間の経過に依存した入力を用いるコンテンツは、この達成基準に適合することができないため、ガイドライン 2.1 にレベル AAA で適合することはできないということである。
達成基準 2.1.3 の実装方法及び不適合事例 － キーボード操作（例外なし）
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
達成基準を満たすことのできる実装方法
この達成基準には、特に実装方法があるわけではない。達成基準 2.1.1 の実装方法を参照のこと。アナログで時間の経過に依存した入力があるためにその実装方法が不可能な場合は、このレベル AAA の達成基準に適合することはできない。
重要な用語
- 機能性
利用者のアクションにより実現可能なプロセスおよび結果。
- キーボード・インターフェース
キーストローク入力を取得するためにソフトウェアが用いるインターフェース。
注記 1： キーボードをもともと含んでいない技術であっても、キーボードインターフェースによって利用者がキーストローク入力をプログラムに提供できるようにする。
事例： タッチスクリーンPDAには、外部キーボードへのコネクタとあわせて、そのOSに組み込まれたキーボード・インターフェースがある。PDA上のアプリケーションはそのインターフェースを用いて、外部キーボード、あるいは手書き解釈プログラムや「キーボード・エミュレーション」機能付きの音声テキスト変換アプリケーションのような擬似キーボード出力を提供する他のアプリケーションのいずれかからキーボード入力を取得することができる。
注記 2： マウスキーのようなキーボード操作によるマウス・エミュレータによるアプリケーション（あるいは、そのアプリケーションの一部）の操作は、キーボード・インターフェースからの操作として見なされていない。それはプログラムの操作がキーボード・インターフェースからではなく、そのポインティング・デバイスからの操作だからである。
十分な時間:
ガイドライン 2.2 を理解する
ガイドライン 2.2： 利用者がコンテンツを読んだり使用したりするのに十分な時間を提供する。
ガイドライン 2.2 の意図
障害のある利用者の多くは、そうでない利用者と比べると、タスクを完了するのにより長い時間を必要とする。それは、身体的に反応するのに時間がかかることがある、何かを読むのに時間がかかることがある、ロービジョンのために何かを見つけたり読んだりするのに時間がかかることがある、あるいはより時間を要する支援技術を使用してコンテンツを利用していることがあるからである。このガイドラインは、利用者がコンテンツに要求されるタスクを自分の必要とする時間をかけて完了できるようにすることに焦点を当てている。主なアプローチとして、制限時間を取り除くこと、又はタスクを完了するために十分な時間を利用者が追加できるようにすることを挙げている。ただし、それが不可能な場合に対する例外が認められている。
ガイドライン 2.2 の参考にすべき実装方法（特定の達成基準に特有ではない実装方法）
このガイドラインにある各達成基準を満たすための実装方法は、この後に達成基準ごとに挙げられている。 しかし、このガイドラインに対処するための実装方法がどの達成基準にも該当しない場合は、ここで挙げている。そういった実装方法は、どの達成基準を満たす上でも必須ではないし、十分でもないが、ウェブコンテンツの種類によってはより多くの利用者にとってよりアクセシブルにすることができるものである。
- このガイドラインの参考にすべき実装方法はすべて、特定の達成基準に関係している。
調整可能な制限時間:
達成基準 2.2.1 を理解する
2.2.1 調整可能な制限時間： コンテンツに制限時間を設定する場合は、次のうちの少なくとも1つが当てはまる。 （レベル A）：
解除： 制限時間内に、利用者がその制限時間を解除することができる。または、
調整： 制限時間内に、利用者が制限時間をデフォルトの設定の少なくとも10倍の長さまでの範囲で調整できる。または、
延長： 時間切れになる前に利用者に警告し、利用者が少なくとも20秒間の猶予をもって、例えば "スペースキーを押す" などの簡単な操作で延長でき、そして利用者が制限時間を少なくとも10倍以上延長することができる。または、
リアルタイムの例外： 制限時間がリアルタイムのイベント（例えば、オークション）に必須の要素で、その制限時間に代わる手段が存在しない。または、
必要不可欠な例外： 制限時間が必要不可欠なもので、制限時間を延長することがコンテンツの動作を無効にすることになる。または、
20時間の例外： 制限時間が20時間よりも長い。
注記： この達成基準は、制限時間の結果として、コンテンツあるいは状況の変化が予期せず起こることなく、利用者がタスクを完了できるようにするためのものである。この達成基準は、利用者のアクションの結果としてのコンテンツあるいは状況の変化を制限する達成基準 3.2.1と併せて考慮されるべきである。
この達成基準の意図
この達成基準の意図は、可能なかぎり、障害のある利用者がウェブコンテンツを操作するのに十分な時間を提供するようにすることである。例えば、全盲、ロービジョン、巧緻性障害、及び認知限界のある利用者は、コンテンツを読む又はオンラインフォームに記入するというような機能を実行するのに、より長い時間を必要とする。そのため、ウェブコンテンツの機能が時間の経過に依存している場合、制限時間内に必要な操作を実行することが困難な利用者もいるだろう。このことは、そのサービスをそういった利用者に対してアクセシブルではないものにしてしまう。そこで、機能を時間の経過に依存しないように設計することで、障害のある利用者がその操作を完了させやすくなる。制限時間を解除する、制限時間の長さを調整する、又は時間切れになる前に制限時間を延長することのできるオプションを提供することが、タスクを無事に終えるのに時間がかかってしまう利用者の手助けになる。この達成基準では、これらのオプションを利用者にとって最も手助けになるものから順に挙げている。つまり、時間切れになる前に制限時間を延長できるようにすることよりも、制限時間の長さを調整できるようにすることのほうが望ましく、さらにそれよりも制限時間を解除できるようにすることのほうが望ましい、といった具合である。
利用者による開始がなく、設定時間後又は定期的に発生する処理は、どれも制限時間である。コンテンツの一部又は全部の更新（例えば、ページのリフレッシュ）、コンテンツの変更、利用者が入力の要求に応じるウィンドウの期限切れなどが含まれる。
また、利用者が読む及び/又は理解することのできない速度で進んだり更新したりするコンテンツも含まれる。言い換えれば、アニメや動画のコンテンツ、動きのあるコンテンツ、又はスクロールするコンテンツは、利用者がコンテンツを読むのに制限時間を課することになる。
サーバの制限時間に関する注記
サーバによる制限時間のあるリダイレクトは、以下にあるよくある不適合事例で参照可能である。
ログインの時間切れのようなサーバによる制限時間には、達成基準 2.2.5が対応している。
サーバによる制限時間のないリダイレクト（例： 3xx のレスポンスコード）は、制限時間はなく、瞬時に働くので、この達成基準には適用されない。
この達成基準は、コンテンツ自体が設定する制限時間だけに適用される。例えば、ユーザエージェント又はインターネット固有の要因などにより、コンテンツ以外のものが設定する制限時間は、コンテンツ制作者が制御できるものではなく、WCAG への適合要件の対象とはならない。ウェブサーバにより設定される制限時間は、コンテンツ制作者が制御できるものであり、他の達成基準が対応している。
デフォルトの10倍を基準に選んだのは、臨床的経験及び他のガイドラインに基づいている。例えば、利用者が反応してスイッチを押すのに15秒間与えられていたとしたら、たとえ苦労したとしても、150秒がほとんどすべての利用者がスイッチを押すのに十分な時間となる。
また、20秒間というのも、臨床的経験及び他のガイドラインに基づいている。'あらゆるスイッチ' を押すのに、20秒あれば、痙性（麻痺している筋肉が自分の意思に関わらず勝手に緊張して収縮する症状）のある利用者も含むほとんどすべての利用者にとっては十分である。中にはそれでも足りない利用者もいるかもしれないし、時間をどれだけ延ばしても足りないという利用者もいるだろう。任意の長い時間にしてしまうと、障害のある利用者を含むすべてのアプリケーション利用者に対して、セキュリティのリスクを引き起こす恐れがあるため、時間の延長を要求するのに妥当な時間を定める必要がある。例えば、金銭的な取引を行うのに用いられるキオスク端末又はターミナル端末では、利用者がサインオフせずにその場を離れてしまうことが非常によくある。そのままでは、端末を次の人に不正利用されやすい状態にしておくことになってしまう。利用者の確認をせずに休止状態を長時間与えて、長時間にわたって利用者がその場にいるという状態にしておくことは、端末を不正利用の危険にさらすことになる。何も動きがなければ、システムはそこに利用者がいるかどうかを確認しなければならない。そのため、システムは、利用者がそこにいることを確認するように求め（'どれかキーを押してください'）、そして誰もが応じることができるだけの長さで利用者の反応を待つべきである。"どれかキーを押してください" や20秒間というのは、この条件を満たすであろう。もし利用者が自分はまだそこにいるということを示せば、その端末は利用者に確認する前と同じ状況を利用者に再び提示しなくてはならない。
上限として20時間を基準に選んだのは、一般に人が一日で起きている時間よりも長いからである。
制限時間が本質的な要件ではないが、利用者に制限時間のあるイベントを制御できるようにすることが、その結果を無効にしてしまうような場合には、第三者がその利用者のために制限時間を調整することができる（例えば、試験に2倍の時間を与える）。
「達成基準 2.2.3 時間制限なし」を理解するも参照のこと。
達成基準 2.2.1 の具体的なメリット
身体に障害のある利用者は、反応する、入力する、及びタスクを完了するのに、より長い時間を要することが多い。ロービジョンの利用者は、画面上で何かを探したり、読んだりするのに時間がかかる。全盲でスクリーンリーダーを使用している利用者は、画面のレイアウトを理解する、情報を見つける、そしてコントロールを操作するのに時間がかかることがある。認知限界又は言語障害のある利用者は、読んで理解するのに時間がかかることがある。音声が聞こえなくて手話でコミュニケーションしている利用者は、テキストで書かれた情報（彼らにとっては第二言語のようなものである可能性がある）を読むのに時間がかかるかもしれない。
手話通訳者が音声が聞こえない利用者に音声コンテンツを通訳しているような状況では、制限時間を調整できることも重要である。.
読字障害、認知障害及び学習障害のある利用者は、情報を読んで理解するのに時間がかかることがあり、コンテンツを一時停止させることによって、その情報を読む時間を延長させることができるようになる。
達成基準 2.2.1 の事例
あるウェブサイトは、クライアントサイドの制限時間を用いて、コンピュータから離れてしまう可能性のある利用者を保護している。何も活動がないと、ウェブページは利用者がまだ時間が必要かどうかを確認する。もし利用者からの反応がなければ、そこでタイムアウトになる。
ウェブページに、最新のニュース見出しを回転させて自動的に更新する部分がある。インタラクティブなコントロールがあり、利用者は更新する間隔の時間をデフォルトの10倍の長さに延ばすことができる。そのコントロールは、マウス又はキーボードのどちらかで操作可能である。
ウェブページにアニメーションがあり、至るところに現れては消えるテキストがある。テキストがスクロールして画面を横切るものもあれば、表示されると短時間で背景にフェードしていくものもある。テキストを読むのが困難な利用者がテキストが消えてしまう前に読むことができるように、そのページには一時停止ボタンがある。
オークションにおいて、利用者が入札しなければならない時間に制限時間がある。その制限時間は、特定にアイテムに入札したい利用者すべてに適用されるので、特定の利用者だけに時間の延長を認めると公平ではなくなってしまう。そのため、制限時間はこの種のコンテンツには必須であり、この達成基準によって、制限時間の延長、調整、又は解除を要求されることはない。
オンラインチケット購入サイトでは、利用者が席を確保して購入内容を確認するのに2分間の制限時間が与えられている。そのようなサイトのチケットはすぐに売り切れてしまうため、それ以上チケットを確保しておくと、そのサイトの機能を発揮できない可能性がある。そのため、これは制限時間が必要不可欠で、コンテンツを有効なまま延長することができない事例の一つである。しかし、そのサイトは、制限時間の始まる前に、例えば氏名、支払方法などの必要な情報を利用者が提供できるようにするなどして、できるかぎり多くのプロセスを制限時間外で行えるようにしている。
チケット購入サイトは、利用者が選択した席の購入を確認するために2分間の制限時間を与えているが、時間切れが近づくと利用者に警告を出し、例えば、"時間を延長する" ボタンを押すなどの簡単な操作で、利用者がこの制限時間を何分間か延長できるようにしている。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
（まだ文書化されていない）
達成基準 2.2.1 の実装方法及び不適合事例 － 調整可能な時間制限
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
達成基準を満たすことのできる実装方法
使用法： そのコンテンツに合致する状況を以下から選択すること。それぞれの状況には、WCAG ワーキンググループがその状況において十分であると判断する、番号付の実装方法（又は、実装方法の組合せ）がある。
達成基準 2.2.1 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
達成基準 2.2.1 のよくある不適合事例
以下に挙げているのは、WCAG ワーキンググループが達成基準 2.2.1 に適合していないとみなした、よくある不適合事例である。
重要な用語
- 必要不可欠
もし取り除いてしまうと、コンテンツの情報あるいは機能を根本的に変えてしまい、かつ、情報および機能が WCAG に適合する他の方法では提供することができない。
一時停止、停止、非表示:
達成基準 2.2.2 を理解する
2.2.2 一時停止、停止、非表示： 動きのある、点滅している、スクロールする、あるいは自動更新する情報に対しては、それぞれ次のすべてがあてはまる。 （レベル A）：
動き、点滅、スクロール： 動きのある、点滅している、あるいはスクロールしている情報が、(1) 自動的に開始し、(2) 5秒よりも長く継続し、そして (3) その他のコンテンツと並行して提示される場合、利用者がそれらを一時停止、停止、あるいは非表示にすることのできるメカニズムがある。ただし、その動き、点滅、またはスクロールが必要不可欠な動作の一部である場合は除く。
自動更新： 自動更新する情報が、(1) 自動的に開始し、そして (2) その他のコンテンツと並行して提示される場合、利用者がそれを一時停止、停止、あるいは非表示にする、もしくはその更新頻度を調整することのできるメカニズムがある。ただし、その自動更新が必要不可欠な動作の一部である場合は除く。
注記 1： 明滅する、あるいは閃光を放つコンテンツに関する要件は、ガイドライン 2.3を参照のこと。
注記 2： この達成基準を満たさないコンテンツでは、利用者がそのページ全体を使用できない恐れがあるため、Webページ上のすべてのコンテンツは他の達成基準を満たすために用いられているか否かにかかわらず、この達成基準を満たさなければならない。適合要件 5: 非干渉を参照のこと。
注記 3: 周期的にソフトウェアによって自動的に更新されるコンテンツ、またはユーザエージェントにストリーム配信されるコンテンツは、コンテンツ再生の一時停止と再開の操作の間に生成あるいは受信される情報を保持したり、提示したりする必要はない。これは技術的に不可能であることが考えられ、多くの状況において利用者の混乱を招くことにつながる可能性があるためである。
注記 4: コンテンツの読み込み中やそれに類似した状況の一部として表示されるアニメーションについては、この段階ですべての利用者に対していかなる対話も発生する可能性がなく、かつコンテンツ読み込みの進行状況を表示しないことが利用者の混乱を招いたり、コンテンツが動作を停止した、あるいはコンテンツが破損しているという誤解を生じたりする可能性がある場合には、必要不可欠なものと考えることができる。
この達成基準の意図
この達成基準の意図は、利用者がウェブページとやりとりしている間、他の事に気をとられないようにすることである。
"動き、点滅、スクロール" は、視覚的に認識できるコンテンツが何らかの動きをしているコンテンツのことを指している。よくある例としては、動画、同期したメディアのプレゼンテーション、アニメーション、リアルタイムのゲーム、スクロールする株価表示などが挙げられる。そして、"自動更新" は、あらかじめ設定された間隔で更新されたり消えたりするコンテンツのことを指している。時間の経過に伴って変化するコンテンツのよくある例としては、音声、自動的に更新される天気情報、ニュース、株価更新、及び自動進行するプレゼンテーションやメッセージなどがある。動き、点滅、スクロールと自動更新に対する要件は、次のものを除いて同じである：
動きのある又は自動更新するコンテンツは、動かないテキストを素早く読むのが困難な利用者及び動きのあるオブジェクトを目で追うのが困難な利用者にとっての障壁となる可能性がある。また、スクリーンリーダーの利用者にも問題を引き起こす。
動きのあるコンテンツは、ある利用者にとっては深刻な妨害になる可能性もある。特に注意力欠如障害のある利用者などは、点滅しているコンテンツに気を取られてしまい、ウェブページのそれ以外の部分に集中するのが困難になってしまう。5秒を基準として選んだのは、利用者の注意を引くには十分であり、なおかつ、それがページを利用するのに必要なものであれば、利用者が最後まで待たされるとしても、さほど長くはないという理由からである。
一時停止したコンテンツは、リアルタイムで再開するか、利用者が一時停止したところから再生を続けるかのどちらかである。
一時停止した後、利用者が一時停止したところから再開することが、コンテンツを読むために一時停止したい利用者にとっては最適であり、コンテンツがリアルタイムのイベント又は状態に関係のないときには最も良い方法である。
情報の意味がリアルタイム又は "状態" にある場合には、一時停止した後にそれを再開した時点（一時停止を止めた時点）での表示へジャンプするほうがよい。例えば、気象レーダー、株価表示、交通情報カメラ、又はオークションのタイマーなどは、もし一時停止したことによって再開時に古い情報が表示されると、誤った情報を提供してしまうことになるだろう。
注記： コンテンツを非表示にすることは、一時停止した後にそれを再開した時点（一時停止を止めた時点）での表示へジャンプするのと同じ効果が得られる。
注記： "点滅" と "閃光" は、同じコンテンツを指すことがありえる。
"点滅" は、利用者を注意散漫にさせる問題を引き起こすコンテンツを指している。点滅が停止する（又は停止させることが可能である）かぎり、短い間であれば許容することができる。
"閃光" は、（3秒よりも長く、大きさと明るさが十分な場合に）光過敏性発作を誘発する恐れのあるコンテンツを指している。これは、光過敏性発作を誘発する恐れがあるため、たとえ1秒間だけであったとしても許容されない。そして、閃光をオフにすることも選択肢にはならない。なぜなら、光過敏性発作は利用者がオフにする前に誘発される恐れがあるからである。
通常、点滅は1秒間に3回以上の速度にはならないが、そうなる可能性もある。点滅が1秒間に3回以上の速度の場合には、それも閃光であるとみなされるであろう。
達成基準 2.2.2 の具体的なメリット
5秒後に点滅を停止するコンテンツを提供すること、又は利用者が点滅するコンテンツを停止できるメカニズムを提供することで、特定の障害のある利用者がウェブページとやりとりできるようになる。
点滅するコンテンツを使用する一つの方法は、そのコンテンツへ利用者の注意を引くことである。これは画面を見ている利用者すべてに対して効果的な方法ではあるが、点滅が持続するとある利用者に対しては問題を引き起こす恐れがある。読み書き能力の低い利用者、読字障害及び知的障害のある利用者、及び注意力欠如障害のある利用者などにとっては、点滅するコンテンツはウェブページの残りのコンテンツとのやりとりを困難にするか、又は不可能にさえしてしまうことがある。
達成基準 2.2.2 の事例
利用者の行動に影響を与えずに一時停止できる不可欠なアニメーション
あるウェブサイトは、プロセスを紹介するアニメーションによって、利用者が 'どのように機能するか' を理解するのを手助けしている。アニメーションには "一時停止" ボタンと "再開" ボタンがある。
株価表示
株価表示のティッカーには、 "一時停止" ボタンと "再開" ボタンがある。ティッカーを一時停止すると、現在表示している株価のところで一時停止する。再開すると、ティッカーは停止したところから再開するが、画面が遅れていることを示す注意書きが出る。株価表示のティッカーの意図は、通常リアルタイムの情報を提供することなので、ティッカーを最新の取引株価に進めるボタンもあるかもしれない。
利用者がリアルタイムで完了するのではなく、交代するように設計されたゲーム
1つのグループが、ゲームの競争的な形勢を無効にすることなく、ゲームを一時停止することができる。
ウェブ広告
ある広告は、閲覧者の注意を引くために点滅するが、5秒後に停止する。
フォームのプロンプト
フォームは、利用者がフォームへの記入を終えても送信ボタンを押下しないと、送信ボタンの近くにある矢印を点滅させる。その点滅は5秒後に停止する。
アニメーション
アニメーションがページの上部で再生されるが、アニメーションの下部には "アニメーションを一時停止する" ボタンがある。
"読み込み中" のアニメーション
再生を開始するまでに大きなファイルを一定のパーセンテージまでダウンロードする必要のあるページ上に、読み込み中であることを示すアニメーションが表示されている。ページ上のコンテンツはそのアニメーションだけで、映像を読み込んでいる間、利用者にしばらく待つ必要があることを知らせている。その動きのあるコンテンツは、他のコンテンツと並行して提示されているわけではないので、アニメーションを一時停止、停止、又は非表示にするメカニズムを提供する必要はない。接続回線の遅い利用者に対して、たとえそのアニメーションが5秒以上再生されていたとしてもである。
全ページ広告
あるサイトは、利用者が無償のコンテンツを利用する前に、すべての利用者が15秒の広告を閲覧することを要求している。その広告を閲覧することがすべての利用者に対する要件であり、他のコンテンツと並行して提示されていないので、広告を一時停止、停止、又は非表示にするメカニズムを提供する必要はない。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
（まだ文書化されていない）
達成基準 2.2.2 の実装方法及び不適合事例 － 一時停止、停止、非表示
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
達成基準 2.2.2 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
達成基準 2.2.2 のよくある不適合事例
以下に挙げているのは、WCAG ワーキンググループが達成基準 2.2.2 に適合していないとみなした、よくある不適合事例である。 by the WCAG Working Group.
重要な用語
- 点滅
注意を引くように、2つの視覚的な状態を交互に切り替えること。
注記： 閃光も参照のこと。（ある頻度で、ある程度以上に大きく、明るく点滅することによって、閃光として分類されることもありうる。）
- 必要不可欠
もし取り除いてしまうと、コンテンツの情報あるいは機能を根本的に変えてしまい、かつ、情報および機能が WCAG に適合する他の方法では提供することができない。
- 一時停止
利用者の要求により停止し、利用者の要求があるまで再開しない。
制限時間なし:
達成基準 2.2.3 を理解する
この達成基準の意図
この達成基準の意図は、制限時間のあるインタラクションを要求するコンテンツの提供を最少限にすることである。それにより、全盲、ロービジョン、認知限界、又は運動障害のある利用者が、コンテンツとやりとりできるようになる。この達成基準は、唯一の例外がリアルタイムのイベントであるという点で、レベル A の達成基準とは異なる。
達成基準 2.2.3 の具体的なメリット
身体に障害のある利用者は、反応する、入力する、及びタスクを完了するのに、より長い時間を要することが多い。ロービジョンの利用者は、画面上で何かを探したり、読んだりするのに時間がかかる。全盲でスクリーンリーダーを使用している利用者は、画面のレイアウトを理解する、情報を見つける、そしてコントロールを操作するのに時間がかかることがある。認知限界又は言語障害のある利用者は、読んで理解するのに時間がかかることがある。音声が聞こえなくて手話でコミュニケーションしている利用者は、テキストで書かれた情報（彼らにとっては第二言語のようなものである可能性がある）を読むのに時間がかかるかもしれない。
手話通訳者が音声が聞こえない利用者に音声コンテンツを通訳しているような状況では、制限時間を調整できることも重要である。
達成基準 2.2.3 の事例
試験を完了する時間が点数に影響しないように考案されている試験
制限時間を用いてオンライン試験の結果を評価するのではなく、制限時間がないときの点数をもとに試験の結果を評価している。
利用者がリアルタイムで完了するのではなく、交代するように設計されたゲーム
1つのグループが、ゲームの競争的な形勢を無効にすることなく、ゲームを一時停止することができる。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
（まだ文書化されていない）
達成基準 2.2.3 の実装方法及び不適合事例 － 時間制限なし
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
達成基準 2.2.3 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
（まだ文書化されていない）
達成基準 2.2.3 のよくある不適合事例
以下に挙げているのは、WCAG ワーキンググループが達成基準 2.2.3 に適合していないとみなした、よくある不適合事例である。
（今のところ、文書化されている不適合事例がない）
重要な用語
- 必要不可欠
もし取り除いてしまうと、コンテンツの情報あるいは機能を根本的に変えてしまい、かつ、情報および機能が WCAG に適合する他の方法では提供することができない。
- リアルタイムのイベント
a) 閲覧しているのと同時に発生するイベントで、b) コンテンツによって完全に生成されるものではないイベント。
事例 1： ライブパフォーマンスのウェブ放送（閲覧と同時に発生していて、収録済ではない）。
事例 2： 利用者が入札するオンラインのオークション（閲覧と同時に発生している）。
事例 3： アバターを用いたバーチャルな世界での互いのやりとり（コンテンツによって完全に生成されるものではなく、閲覧と同時に発生する）。
- 同期したメディア
情報や時間経過をベースにしたインタラクティブな構成要素を提示するために、他のフォーマットと同期した音声または映像。ただし、そのメディアがテキストの代替メディアではっきりとそのようにラベル付けされているものは除く。
中断:
達成基準 2.2.4 を理解する
2.2.4 中断： 利用者が中断を延期あるいは抑制することができる。ただし、緊急を要する中断は除く。 （レベル AAA）
この達成基準の意図
この達成基準の意図は、緊急を要する場合を除いて、利用者がコンテンツ制作者/サーバからの更新を抑制できるようにすることである。緊急には、市民向け緊急警報メッセージ、又は健康、安全、又は財産の危険を警告するその他のメッセージがある。また、データの損失、通信の喪失などが含まれる。
これにより、認知限界又は注意力欠如のある利用者が、コンテンツに集中することができるようになる。全盲又はロービジョンの利用者が、現在読んでいるコンテンツに神経を集中し続けられるようにもなる。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
（まだ文書化されていない）
達成基準 2.2.4 の実装方法及び不適合事例 － 中断
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
達成基準 2.2.4 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
（まだ文書化されていない）
達成基準 2.2.4 のよくある不適合事例
以下に挙げているのは、WCAG ワーキンググループが達成基準 2.2.4 に適合していないとみなした、よくある不適合事例である。
重要な用語
- 緊急
健康、安全や財産を守るために直ちに行動をとる必要のある、突然で予期されなかった状況あるいは出来事。
再認証:
達成基準 2.2.5 を理解する
2.2.5 再認証： 認証済のセッションが切れたときは、再認証後でもデータを失うことなく利用者が操作を継続できる。 （レベル AAA）
この達成基準の意図
この達成基準の意図は、非活動の制限時間がある又はトランザクションを完了させる途中で利用者をログアウトさせてしまうその他の状況がある、認証済のトランザクションを、すべての利用者が完了できるようにすることである。
セキュリティ上の理由により、多くのサイトが、利用者の認証に対して、何も活動せずに一定の時間が経過した後に制限時間を設けている。障害のある利用者はタスクを完了させるのにより長く時間がかかるので、制限時間は問題を引き起こす恐れがある。
その他のサイトでは、利用者が他のコンピュータからそのウェブサイトにログインしてきた場合、又はその利用者がもともとログインした利用者と本当に同じかどうかに疑問を抱くようなその他の行為があった場合には、利用者を認証済のセッションからログアウトさせてしまうだろう。利用者がトランザクションの最中であったとしてもログアウトさせられる際には、利用者が再認証を受けることができて、すでに入力済のデータを失うことなくそのトランザクションを継続できるようにすることが重要である。
達成基準 2.2.5 の具体的なメリット
この達成基準は、タスクを完了するのに時間の追加を必要とする利用者の役に立つ。認知限界のある利用者は、ゆっくり読むので、質問を読んで回答するのに追加の時間を必要とすることがある。スクリーンリーダーを使用している利用者は、複雑なフォームをナビゲートして完了させるのに追加の時間を必要とするかもしれない。運動障害のある利用者又は代替入力デバイスでナビゲートする利用者は、フォーム内をナビゲートして入力を完了させるのに、やはり追加の時間を必要とすることがある。
手話通訳者が音声が聞こえない利用者に音声コンテンツを通訳しているような状況では、制限時間を調整できることも重要である。
達成基準 2.2.5 の事例
ショッピングサイトの支払手続
手をほとんど使うことのできない利用者が、ショッピングサイトにログインしている。アプリケーションでクレジットカード情報を入力するのに時間がとてもかかり、利用者が支払手続をしている間に制限時間が切れてしまう。利用者がその支払手続に戻ってきてフォームを送信しようとすると、そのサイトは再認証するためのログイン画面を表示する。利用者がログインした後、支払手続のプロセスは同じ段階で同じ情報の状態に戻してくれる。セッションはタイムアウトになったものの、サーバが一時的に送信を受け付けて保存していて、再認証が完了した後に利用者を同じ状態に戻したため、利用者はデータを失わずに済んだのである。
電子メールプログラムでの認証
ある電子メールプログラムは、30分後に認証がタイムアウトする。そのプログラムは、タイムアウトの数分前に利用者にプロンプトを出し、再認証するために新しいウィンドウを開くリンクを提供している。作成中のメールがあった元のウィンドウはそのままで、再認証後に、利用者はそのデータを送信することができる。
制限時間のあるアンケート
単一のウェブペーイで提供されている長いアンケートの最初に、セッションが15分経過後にタイムアウトすることを知らせる情報がある。また、アンケートはどの時点でも保存することが可能で、後から完了させることも可能であることが、利用者には知らされている。そのウェブページには、部分的に完了したフォームを保存するためのボタンが幾つかある。さらに、依存しているアクセシビリティ・サポーテッドなウェブコンテンツ技術の一覧にあるJavaScriptによって、セッションがタイムアウトに近づいたらポップアップで知らせてもらうことを利用者が選択できるようになっている。
関連リソース
リソースは、情報提供のみを目的としており、推奨を意味するものではない。
（まだ文書化されていない）
達成基準 2.2.5 の実装方法及び不適合事例 － 再認証
この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。
達成基準を満たすことのできる実装方法
Providing options to continue without loss of data using one of the following techniques:
達成基準 2.2.5 でさらに対応が望まれる実装方法（参考）
適合するためには必須ではないが、コンテンツをよりアクセシブルにするためには、次の付加的な実装方法もあわせて検討するとよい。ただし、すべての状況において、すべての実装方法が使用可能であったり、効果的であるとは限らない。
（まだ文書化されていない）
達成基準 2.2.5 のよくある不適合事例
以下に挙げているのは、WCAG ワーキンググループが達成基準 2.2.5 に適合していないとみなした、よくある不適合事例である。
