【注意】 この文書は、W3Cが公開している2005年11月23日付の「Understanding WCAG 2.0 ワーキングドラフト（草稿）」（原文は英語）を、財団法人日本規格協会情報技術標準化研究センター 情報アクセシビリティ国際標準化に関する調査研究開発委員会ウェブアクセシビリティ国際規格調査研究部会が日本語に翻訳したものです。このワーキングドラフトの正式な文書は、あくまでW3Cのサイト内にある英語版であり、この文書には翻訳上の間違い、あるいは不適切な表現が含まれている可能性がありますのでご注意ください。また、リンク先が英語の場合、あるいはダミーのページである場合もあります。ご了承ください。
Copyright © 2005 W3C ® ( MIT , ERCIM , Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
このドキュメント、"Understanding WCAG 2.0" は、"Web Content Accessibility Guidelines 2.0" [WCAG20]を理解して利用するために必要なガイド文書である。そして、WCAG 2.0 をサポートする一連の文書の一つでもある。
WCAG 2.0 は、WCAG 2.0 のガイドラインへの準拠を定義する "達成基準" を定めている。達成基準は、特定のWebコンテンツに適用されるときに、クリアしているか否かを検証できるような内容になっている。"Understanding WCAG 2.0" は、各達成基準について、その意図、達成基準で用いられている重要な用語、様々なWeb技術（例えば、HTML、CSS、XMLなど）を用いて達成基準を満たしている事例、達成基準を満たしていないよくある事例、などを含んだ詳細な情報を提供する。さらに、この文書は WCAG 2.0 の達成基準がどのように様々なタイプの障害を持つ人のためになるのかということも説明している。
このセクションでは、この文書の発行時におけるステータスについて説明します。他の文書がこの文書にとって代わるかもしれません。最新のW3C発行文書およびこの技術文書の最新バージョンは、http://www.w3.org/TR/ にある W3C technical reports index でご覧いただけます。
このドラフトは、"Understanding WCAG 2.0" の最初の公開ワーキングドラフトである。Web Content Accessibility Guidelines Working Group(WCAG WG) は、この文書を Web Content Accessibility Guidelines 2.0 (WCAG 2.0) の達成基準を理解するのに不可欠なものと考えており、このドラフトに対するフィードバックを求める。この文書のコンテンツは参考となる情報（ガイダンスを提供するもの）であり、要件（WCAG 2.0 への準拠するための要件を定義するもの）ではない。
ワーキンググループは、特に以下の質問に対するフィードバックを歓迎する。
加えて、ワーキンググループは、まだ WCAG 2.0 に準拠するための全てのテクニックをリストアップする時間がとれていないが、できるかぎり広範囲に及ぶテクニックを網羅する考えでいる。そのため、ワーキンググループは、この文書に含めるべきテクニックを追加していただくことを歓迎する。以下に書かれているように、他のコメントと同様にご意見をお送りいただきたい。
この文書のフォーマットはまだ最終形ではない。ワーキンググループは、各達成基準ごとに別々のファイルに分ける予定である。そして、サンプルコードを提供する関連テクニックへのリンクも追加していく。また、ワーキンググループは WCAG 2.0 をサポートする各種文書間を参照しやすいようなナビゲーション構造も開発中である。
コメントを2005年12月21日までに、public-comments-wcag20@w3.orgまで送っていただきたい。コメントのアーカイブリスト（英語）は公開されている。また、WCAG WG メーリングリスト（英語）も公開されている。
ワーキングドラフトとしての発行は、W3C会員による承認を意味するものではない。これはドラフト文書であり、いつでも更新されたり、他の文書に置き換えられたり、旧バージョンになったりすることがある。この文書はあくまで作成作業中の文書でしかない。この文書は、WCAG 2.0 がW3C勧告になった時点で W3C ワーキンググループ・ノートとして公開されるだろう。
この文書は、W3C Web Accessibility Initiative (WAI)の活動の一部として作成されている。WCAG WG のゴールは、Working Group charterで議論されている。WCAG WG は、WAI Technical Activityの一部である。
1.1.1 情報を伝達する非テキストコンテンツについて、その非テキストコンテンツを特定する代替テキストを提供し、同じ情報を伝達すること。マルチメディアについては、そのマルチメディアを特定する代替テキストを提供すること。ライブの音声のみおよびライブのビデオのみについては、達成基準 1.1.5に準拠すること。（Level 1）
For non-text content that is used to convey information, text alternatives identify the non-text content and convey the same information. For multimedia, provide a text-alternative that identifies the multimedia. For live audio-only and live video-only, conform to success criterion 1.1.5. (Level 1)
注： マルチメディアに同期した代替コンテンツに関する要件は、マルチメディアには同期化した代替コンテンツを提供するを参照してください。
考え、データ、事実、情報を伝える非テキストコンテンツで、テキストではないコンテンツ。
非テキストコンテンツの代わりに用いられるプログラム的に決められたテキスト、あるいは非テキストコンテンツに加えて用いられていてプログラム的に決められているテキストと関連しているテキスト。
コンテンツタイプの正式な仕様に準じてユーザーエージェントにレンダリングされたときに、Unicodeの文字あるいはUnicodeの文字の連続ではないコンテンツ。文字のパターンであるASCII Artもこれに含まれる。
このガイドラインの目的においては、マルチメディアとは音声とビデオの組合せによるプレゼンテーションのことである。インタラクションを含んだ音声のみおよびビデオのみのプレゼンテーションも含まれる。
この達成基準の意図は、チャート、ダイアグラム、音声、写真、およびアニメーションのような非テキストコンテンツで伝達されている情報をあらゆる感覚（例えば、視覚、聴覚、あるいは触覚）を通じて解釈できるような形式で入手可能にすることである。代替テキストを提供することで、情報は様々なユーザーエージェントにより様々なかたちで解釈されるようになる。例えば、写真を見ることのできない人は、その代替テキストを合成音声を用いて読み上げさせることができるようになる。音声ファイルを聞くことのできない人は、その代替テキストを画面に表示させて読むことができるようになる。
マルチメディアのプレゼンテーションにラベルを付けることで、ユーザーはそれを再生したいかどうかを決めることができるようになる（準拠しているマルチメディアにはビルトインの音声ガイドとキャプションがあるので、全ての代替テキストは必要ではない）。
WCAG ワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 1.1.1 を満たすのに十分であると考える。
説明： まず、あなたのコンテンツに合致する状況を選択する。そのすぐ下にあるのは、その状況に十分であると考えて示されているオプションである。技術特有のテクニックについては、以下に挙げられたあなたの使用している技術に関するオプションを参照のこと。
以下にリストされている技術特有のテクニックを用いて代替テキストを提供すること
以下にリストされている技術特有のテクニックを用いて簡潔な代替テキストを提供し、かつ以下のテクニックのうち1つを用いて長い説明を提供すること
以下にリストされている技術特有のテクニックを用いて長い説明を提供すること
別の場所で長い説明を、簡潔な記述の中にリンクへのリファレンスのある非テキストコンテンツのすぐそばにあるそこへのリンクとともに提供する
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
全盲の人、弱視の人、認知障害がある人などは、支援技術によって代替テキストを読み上げさせることができる。
テキストを読むことに問題がある人は、読み上げている単語を反転させながらテキストを読み上げるツールを使うことがある。場合によっては、視覚的な情報を認知するのが困難なことがあり、代替テキストは非テキストコンテンツの目的を理解する手助けになる。
耳の聞こえない人、耳の聞こえにくい人、あるいは何らかの理由で音声情報を理解するのが困難な人は、支援技術によってテキストとして読めるほか、テキストを手話に翻訳することができるようになる。
全盲で耳が聞こえない人は、テキストを点字で読めるようになる。
さらに、代替テキストは、非テキストコンテンツを検索したり、様々な方法でコンテンツを異なる目的に再利用する際に、助けとなる。
以下の事例において、非テキストコンテンツは異なる代替テキストを必要とする様々な状況にて用いられている。
データを示すチャート図
6月、7月、8月の部品売上数量が、棒グラフで比較されている。簡潔なラベルは、「図1：6～8月の売り上げ」となっているが、長い記述では、チャートのタイプを特定し、グラフから得られるのと同等のデータを高いレベルでまとめたサマリーとして提供し、さらにデータを表として提供している。
スピーチを録音した音声ファイル（動画なし）
音声クリップへのリンクには、「全体会議での会長のスピーチ」と書かれている。そして、このリンクの直後に、テキスト・トランスクリプト（訳注：音声情報を書き起こしたテキスト）へのリンクが提供されている。
車のエンジンがどう機能するかを説明するアニメーション
車のエンジンがどう機能するかが、アニメーションで説明されている。音声はなく、アニメーションは、エンジンの機能を説明したチュートリアルの一部である。ここで必要とされるのは、画像の説明だけである。「車のエンジンの機能：筒内噴射」より。
道路交通情報を示すWebカメラ
Webサイトのエンドユーザーが、ある大都市の至る所に設置された様々なWebカメラからどれか1つを選ぶと、画像が2分ごとに更新される。Webカメラには短い代替テキストが付けられ、「道路交通情報Webカメラ」と説明されている。このサイトでは、Webカメラが撮影している道路を使った場合のそれぞれの所要時間の表も提供しており、その表も2分ごとに更新されている。
ニュースにおける歴史的な出来事の写真
2人の世界を代表する首脳が握手している写真が、国際サミット会議のニュースに添えられており、その代替テキストには、「X国のX大統領がY国のY首相と握手している」と記述されている。
外交関係を議論するコンテンツにおける歴史的な出来事の写真
同じ写真が、外交関係のニュアンスを説明する意図で異なる文脈で使われている。首相と握手する大統領の画像は、もつれた外交関係を議論するWebサイトに登場している。最初の代替テキストは、「2009年1月2日、X国のX大統領は、Y国のY首相と握手している」と記述されている。補足的な代替テキストは、2人の首脳が立っている部屋の様子、2人の顔の表情、そしてその部屋にいる他の人物を説明している。その補足的な代替テキストは、写真と同じページ、あるいはその画像からリンクされた別のファイルや標準に準拠したプログラム的な他のメカニズムで提供されることもある。
録音した音声
前述の例にあるWebページに、2人の首脳の記者会見を録音した音声へのリンクがあり、記者会見のテキスト・トランスクリプトへのリンクもある。トランスクリプトには、話者が発言した全ての内容を一言一句記録している。そして、喝采、笑い声、聴衆からの質問などのような録音の中にある重要な音声に加えて、誰が話しているのかも記している。
NBAテープ録音マニュアル 第3版からの抜粋 全盲の人に複雑な画像を説明することに関する情報
1.1.2
機能を持った非テキストコンテンツについて、その機能と同じ目的を果たす代替テキストを提供すること。代替テキストが非テキストコンテンツと同じ目的を果たせない場合は、その非テキストコンテンツの役割を特定する代替テキストを提供すること(レベル 1)
For non-text content that is functional, text alternatives
serve the same purpose as the non-text content. If text alternatives
can not serve the same purpose as the functional non-text content, text
alternatives identify the purpose of the functional non-text content (Level 1)
ユーザーの入力に反応して1つあるいはそれ以上のアクションを起こすことができて、かつテキストではない非テキストコンテンツ
注：これには、以下に限定されないが、画像ベースの送信ボタン、アプレット、そして埋め込まれたプログラム・オブジェクトなどが挙げられる。
非テキストコンテンツの代わりに用いられるプログラム的に決められたテキスト、あるいは非テキストコンテンツに加えて用いられていてプログラム的に決められているテキストと関連しているテキスト。
この達成基準の意図は、送信ボタンとして用いられている画像のように、非テキストコンテンツの機能が可能であればテキスト形式で入手可能にすることである。もしその機能をテキストで入手可能にできない場合は、その機能をテキストで明示する。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 1.1.2 を満たすのに十分であると考える。
説明： まず、あなたのコンテンツに合致する状況を選択する。そのすぐ下にあるのは、その状況に十分であると考えて示されているオプションである。技術特有のテクニックについては、以下に挙げられたあなたの使用している技術に関するオプションを参照のこと。
以下に挙げる技術特有のテクニックのうち1つを用いて、非テキストコンテンツと同じ目的を果たす代替テキストを提供する。
以下に挙げる技術特有のテクニックのうち1つを用いて、機能を持った非テキストコンテンツの目的を特定する代替テキストを提供する。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
スクリーンリーダーや点字ディスプレイを使用している全盲あるいは全盲で耳の聞こえない人は、常に機能的な非テキストコンテンツにアクセスできるとは限らない。代替テキストにより、そのコンテンツの機能にアクセスすることが可能となる。
以下の事例において、非テキストコンテンツは異なる代替テキストを必要とする様々な状況にて用いられている。
ボタンとして用いられている画像
ウェブサイトの検索ページへのリンクとして、虫眼鏡のアイコンが使われている。スクリーンリーダーは、このボタンをリンクと認識して、代替テキストである「検索」を読み上げる。
NBAテープ録音マニュアル 第3版からの抜粋 全盲の人に複雑な画像を説明することに関する情報
1.1.3
特定の感覚体験を作り出す目的で使われている非テキストコンテンツについて、少なくともその非テキストコンテンツを説明的なラベルで特定する代替テキストを提供すること。(レベル 1)
For non-text content that is intended to create a specific sensory experience, text alternatives at least identify the non-text content with a descriptive label. (Level 1)
主として情報を伝達したり、機能を実行したりせずに、感覚的な体験をもたらす非テキストコンテンツ。
非テキストコンテンツの代わりに用いられるプログラム的に決められたテキスト、あるいは非テキストコンテンツに加えて用いられていてプログラム的に決められているテキストと関連しているテキスト。
主として感覚的な経験を作り出すことを目的にしたコンテンツをまったく知覚できない人は、その名前あるいは簡潔な説明が提供されていない場合、そのコンテンツの目的について困惑してしまうことがある。彼らはそのコンテンツを知覚して経験することができないかもしれないが、その名前（あるいは、簡潔な説明）を提供することで、そういった人々は自分が出くわしたコンテンツが何であるのかを理解することができるだろう。
WCAG ワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 1.1.3 を満たすのに十分であると考える。
以下にリストしている簡潔な代替テキストを提供するための技術特有のテクニックを用いて、非テキストコンテンツに説明的な名前あるいは作者（あるいは誰か）がつけた名前を提供する
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
もし非テキストコンテンツにラベルがなかったとしたら、スクリーンリーダーや点字ディスプレイはそれを識別しようがないだろう。代替テキストがなければ、スクリーンリーダーや点字ディスプレイを使用している、全盲や全盲で耳の聞こえない人は、自分が出くわしたものが何なのか分からないだろう。たとえ、例えば絵画を見ることができなかったとしても、その名前（あるいは、簡潔な説明）を聞くことができれば、コンテンツの中で出くわしたものが何であるかを理解する手助けになるだろう。
交響曲の録音
マーズ交響楽団の「次回公演」ページに、楽団がベートーベン交響曲第5番を演奏した3分間の音声ファイルへのリンクがある。その目的は、ユーザーに生演奏のチケット購入を勧めることである。その音声ファイルへのリンクには、「ベートーベン交響曲第5番、マーズ交響楽団による演奏」と書かれている。同じページに、ベートーベンと交響曲第5番に関する情報がある。両方のページは、この達成基準を満たしている。
1.1.4
機能を持たず、情報を伝達せず、また特定の感覚体験を作り出す目的で使われているのでもない非テキストコンテンツは、支援技術が無視できるような方法で実装されていること。(Level 1)
Non-text content that is not functional, is not used to convey information, and does not create a specific sensory experience is implemented such that it can be ignored by assistive technology. (Level 1)
コンテンツタイプの正式な仕様に準じてユーザーエージェントにレンダリングされたときに、Unicodeの文字あるいはUnicodeの文字の連続ではないコンテンツ。文字のパターンであるASCII Artもこれに含まれる。
ユーザーの入力に反応して、1つあるいはそれ以上のアクションを実行すること、あるいは実行できること。
主として情報を伝達したり、機能を実行したりせずに、感覚的な体験をもたらす非テキストコンテンツ。
ユーザーに対して特定の目的（情報を伝達する、機能を提供する、あるいは、特定の感覚的な経験を作り出す）を持っていない非テキストコンテンツは、テキストの状態でそのコンテンツにアクセスしているユーザーの妨げになるので、テキストで説明すべきではない。しかしながら、もし代替テキストがなかったならば、ユーザーはそのコンテンツが何だったのかを考えてしまう。この達成基準の意図は、そのようなコンテンツを、スキップされるべきコンテンツとして、支援技術によって認識不可能にすることである。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 1.1.4.を満たすのに十分であると考える。
以下に挙げる技術特有のテクニックのうち1つを用いて非テキストコンテンツをマークする
Editorial Note: Not all mechanisms for including non-text content have a convention similar to empty alt for img elements (object and embed are two examples). Are there additional strategies/techniques for addressing this criterion that should be included here to address this?
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
スクリーンリーダーあるいは点字出力デバイスのユーザーは、彼らにとって意味のないデータに時間をとられることがなくなる。
視覚効果を作り出すために用いられている1対の画像
「タブ」のインターフェイスの曲線状になった端を作るために、2つの画像が使われている。この画像は、情報や機能を持ったものではなく、感覚体験を作り出すためのものでもない。そして、支援技術が無視できるようにマークアップされている（例：alt="")。
'background-image' - CSS 2.1 勧告候補文書 - 背景画像を指定するCSSの使い方
1.1.5
ライブ音声のみまたはライブ動画のみのコンテンツについて、少なくともそのコンテンツを説明的なラベルで特定する代替テキストを提供すること(レベル 1)
For live audio-only or video-only content, text alternatives at least identify the purpose of the content with a descriptive label. (Level 1)
注： 音声とビデオを組み合わせたコンテンツについては、マルチメディアには同期化した代替コンテンツを提供するを参照のこと。
音声だけ（ビデオおよびインタラクションはない）が入っていて、時間をベースにしたライブのプレゼンテーション
動画だけ（音声およびインタラクションはない）が入っていて、時間をベースにしたライブのプレゼンテーション
非テキストコンテンツの代わりに用いられるプログラム的に決められたテキスト、あるいは非テキストコンテンツに加えて用いられていてプログラム的に決められているテキストと関連しているテキスト。
この達成基準の意図は、ライブ音声あるいはライブ映像を知覚できない人々が、少なくともそのコンテンツが何についてのものであるかを知ることができるようにすることである。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 1.1.5.
以下に挙げる技術特有のテクニックを用いて、ライブ音声のみおよびライブ動画のみコンテンツの目的を説明するラベルを提供する
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
視覚障害および/あるいは認知障害のある人は、そのコンテンツの目的や用途を把握するために、支援技術を用いて説明を読み上げさせることができて。
聴覚障害のある人は、そのコンテンツの目的や用途を把握するために、説明を読むことができる。
全盲で耳の聞こえない人は、点字でそのコンテンツの目的や用途を把握できる。
ストリーミングのスピーチ音声
ストリーミングによるライブのスピーチ音声に、「フィニー・ジョーンズの集会でのスピーチ」というラベルがついている。
ライブ映像（音声なし）
新しい定理に関する質問に回答する教授のライブ映像（音声なし）へのリンクに、「ヴァンダーハイム教授の解説と質疑応答 - 生中継」
ラジオの生放送
あるラジオ局がインターネット上で番組を流している。ラジオ局のWebサイトでは、流れている音楽のジャンルや番組表が紹介されており、"現在放送中の歌"はDJが新しい音楽を流し始めるたびに更新される。
オンライン授業
ストリーミングによる化学の授業のプレゼンテーションは、トピックについて説明するだけでなく、講義ノートや関連書物へのリンクも提供している。
1.1.6 あらかじめ記録されたマルチメディアのコンテンツについて、動画のキャプションと音声ガイドのトランスクリプトの両方が提供されていること。(Level 3) For prerecorded multimedia content, a combined document containing both captions and transcripts of audio descriptions of video is available. (Level 3)
会話および重要な効果音の同期させたトランスクリプト。キャプションは、聴覚障害のある人や音声の聞こえづらい人にマルチメディアへのアクセスを提供する。
メインの音声トラックだけでは理解できない重要な細部を説明するために、音声トラックに追加される音声ナレーション。会話部分の合間に、ビデオの音声ガイドは、アクション、登場人物、シーンの変化、画面上の文字などを全盲の人や視覚障害のある人に提供する。
この達成基準は、音声付のビジュアル素材を、視覚が弱くてキャプションを確実に読むことのできない人や聴覚が弱くて会話や音声ガイドを確実に聞きとることのできない人にも入手可能にするためのものである。これは、キャプション（達成基準 1.2.1 を参照）と音声ガイド (達成基準 1.2.2 を参照）のテキスト・トランスクリプトの組合せで構成される1つのテキスト文書を提供することで可能である。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 1.1.6を満たすのに十分であると考える。
キャプションおよび音声ガイドの照合するスクリプトおよび以下に挙げるうちの1つを提供する:
以下にリストされている技術特有のテクニックを用いて、照合するスクリプトにリンクする
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
全盲あるいは弱視の人、および耳の聞こえない人あるいは聞こえにくい人が音声と映像によるプレゼンテーションにアクセスできるようになる。
映画のテキストによる説明
制作者は映画の録画に説明を付け、テキストと音声ガイドの両方を書き起こす。そして、音や話者などのキャプションに含めるべき補足情報を拾いながら映画を見て、トランスクリプトに追加する。Webページでは、その映画へのリンクのすぐ横にそのトランスクリプトへのリンクを提供する。
1.2.1
あらかじめ録音されたマルチメディアには、キャプションが提供されていること (レベル 1)
Captions are provided for prerecorded multimedia. (Level 1)
Editorial Note: The working group is seeking comment on the following proposal:
Change 1.2.1 to " Provide captions OR provide a text transcript of all audio intermixed with a text description of what is happening visually."
so authors have an option of providing captions OR a text script. Then, at Level 2, require captions.
会話および重要な効果音の同期させたトランスクリプト。キャプションは、聴覚障害のある人や音声の聞こえづらい人にマルチメディアへのアクセスを提供する。
このガイドラインの目的においては、マルチメディアとは音声とビデオの組合せによるプレゼンテーションのことである。インタラクションを含んだ音声のみおよびビデオのみのプレゼンテーションも含まれる。
この達成基準の意図は、耳の聞こえない人あるいは難聴の人がマルチメディアのプレゼンテーションを見ることができるようにすることである。キャプションは、音声トラックにより入手可能なコンテンツの部分を提供する。キャプションは、会話部分だけでなく、誰が話しているのかを明示し、そして効果音およびその他の重要な音声も記号で表す。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 1.2.1 を満たすのに十分であると考える。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
キャプションが、キャプションの定義を満たしていない (すなわち、会話も重要な効果音も含んでいない)
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
SMIL 1.0 の追加テクニック（助言）
音声トラックのある全ての言語にキャプションを提供する
SMIL 2.0 の追加テクニック (助言)
音声トラックのある全ての言語にSMIL 2.0のキャプションを提供する
耳の聞こえない人あるいは聞こえにくい人が、キャプションによって、マルチメディア・コンテンツの音声情報にアクセスすることができるようになる。
キャプションの付いたチュートリアル
ビデオクリップが、結び目の作り方を示している。キャプションは、次のように書かれている。
「(音楽)
ロープを使って結び目を作ることは、船乗りや兵士、木こりにとって重要なスキルです。」
ウィット・アンダーソン氏がフォーマット化したサンプル・トランスクリプト（音声情報を書き起こしたテキスト）より。
1.2.2
あらかじめ録音されたマルチメディアには、動画の音声ガイドが提供されていること。 (レベル 1)
Audio descriptions of video are provided for prerecorded multimedia
(Level 1)
Editorial Note: The working group is seeking comment on the following proposal:
Change 1.2.2 to " Provide audio descriptions OR provide a text transcript of all audio intermixed with a text description of what is happening visually."
so authors have an option of providing audio descriptions OR a text script. Then, at Level 2, require audio descriptions.
メインの音声トラックだけでは理解できない重要な細部を説明するために、音声トラックに追加される音声ナレーション。会話部分の合間に、ビデオの音声ガイドは、アクション、登場人物、シーンの変化、画面上の文字などを全盲の人や視覚障害のある人に提供する。
このガイドラインの目的においては、マルチメディアとは音声とビデオの組合せによるプレゼンテーションのことである。インタラクションを含んだ音声のみおよびビデオのみのプレゼンテーションも含まれる。
この達成基準の意図は、全盲の人あるいは視覚障害のある人にマルチメディアのプレゼンテーションを提供することである。音声ガイドは、ビデオ部分の視覚的な情報が入手可能でないユーザーが必要とする情報をプレゼンテーションの音声部分に付加するものである。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 1.2.2を満たすのに十分であると考える。
マルチメディア・コンテンツに音声ガイドを作成して組み込む、あるいはプログラム的に関連付けるために、技術特有のテクニックを用いる
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
(現在、作成中)
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
(現在、作成中)
何が起こっているのか視覚的に解釈するのが困難な認知障害のある人だけでなく、全盲や弱視の人も、視覚的な情報を音声ガイドで得ることができるようになる。
音声ガイドのある映画
説明者: タイトル「Teaching Evolution Case Studies. Bonnie Chen」。先生が写真を見せています。
ボニー・チェン: "これはすべて、エバーグレードで撮影されました。"
説明者: 彼女は全員に平たくて薄い木製のスティックを2本ずつ渡します。
ボニー・チェン: "今日はみんなで、こんなくちばしを持った鳥になることにしましょう。"
説明者: 先生は2本のスティックを自分の口に当てて、くちばしのような形を作ります。
「Teaching Evolution Case Studies, Bonnie Chen」（教授法革命のケーススタディ、ボニー・チェン）の最初の数分の音声を書き起こしたトランスクリプト（著作権はWGBHおよびClear Blue Sky Productions, Inc.に帰属）
1.2.3
ライブのマルチメディアには、リアルタイムのキャプションが提供されていること (レベル 2)
Real-time captions are provided for live
multimedia. (Level 2)
会話および重要な効果音の同期させたトランスクリプト。キャプションは、聴覚障害のある人や音声の聞こえづらい人にマルチメディアへのアクセスを提供する。
このガイドラインの目的においては、マルチメディアとは音声とビデオの組合せによるプレゼンテーションのことである。インタラクションを含んだ音声のみおよびビデオのみのプレゼンテーションも含まれる。
この達成基準の意図は、耳の聞こえない人や難聴の人がリアルタイムのプレゼンテーションを見ることができるようにすることである。キャプションは、音声トラックにより入手可能なコンテンツの部分を提供する。キャプションは、会話部分だけでなく、誰が話しているのかを明示し、そして効果音およびその他の重要な音声も記号で表す。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 1.2.3を満たすのに十分であると考える。
注： キャプションは、リアルタイムのテキスト翻訳サービスで生成できるかもしれない（速記、あるいは訂正された音声テキスト変換）
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
耳の聞こえない人あるいは聞こえにくい人は、キャプションによって、マルチメディア・コンテンツの音声情報にアクセスできるようになる。
Web放送 A webcast
ある報道機関は、ライブのキャプション付きWeb放送を提供している。
達成基準 1.2.1 を満たす方法を参照のこと。
1.2.4
マルチメディアには、手話の通訳が提供されていること。 (レベル 3)
Sign language interpretation is provided for multimedia
(Level 3)
話し言葉の翻訳および意味を、特定のジェスチャ、手のポジションや動きで提供する。
このガイドラインの目的においては、マルチメディアとは音声とビデオの組合せによるプレゼンテーションのことである。インタラクションを含んだ音声のみおよびビデオのみのプレゼンテーションも含まれる。
この達成基準の意図は、耳の聞こえない人あるいは難聴の人で手話の分かる人がマルチメディアのプレゼンテーションを見ることができるようにすることである。多くの人にとってキャプションはしばしば第2言語であるため、キャプションのテキストを読むよりも手話を解釈することのほうが容易である。
注：各国の手話は、話し言葉とは別の言語である。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 1.2.4を満たすのに十分であると考える。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
(現在、作成中)
手話でコミュニケーションできるが、文字を読むのが苦手な人たちがいる。こういった人たちはキャプションを読んで理解することができず、マルチメディア・コンテンツにアクセスするのに手話通訳を必要とすることがある。
手話を用いてコミュニケーションして、文字を読むのにも熟練している人の中には、画面上のキャプションを読むのが困難な視覚障害を持っている人もいる。手話通訳のほうが見やすいことがある。
事例 1. ある会社が全ての従業員に対して重要な告知を行っている。会議は本社で行われ、Webで放送される。手話通訳者が会議場にいる。ライブのビデオには、出席者だけでなく、手話通訳者の姿も全部映っている。
事例 2.事例 1 と同じ告知が遠く離れた所にいる従業員にもWeb放送される。1つのディスプレイしかないため、ディスプレイの隅に手話通訳者が映っている。
事例 3.ある大学が講義をする教授のマルチメディア・プレゼンテーションを制作して、特定の講義のオンライン版を提供している。そのプレゼンテーションには、科学実験について話して実演する教授のビデオが含まれている。講義の手話通訳が作成され、マルチメディア版としてWeb状で提供されている。
NCAM Rich Media Accessibility, Accessible SMIL Templates（英語）
National Institute on Deafness and other Communication Disorders: Information on American Sign Language（英語）
1.2.5
あらかじめ録音されたマルチメディアには、動画の詳細な音声ガイドが提供されていること。 (レベル 3)
Extended audio descriptions of video are provided for prerecorded multimedia. (Level 3)
追加説明の時間を確保するためにビデオの再生を一時停止して、音声/ビデオのプレゼンテーションに追加した音声ガイド。このテクニックは、追加の音声ガイドがなければビデオの意味が通じなくなるような場合のみ用いられる。
このガイドラインの目的においては、マルチメディアとは音声とビデオの組合せによるプレゼンテーションのことである。インタラクションを含んだ音声のみおよびビデオのみのプレゼンテーションも含まれる。
この達成基準の意図は、全盲あるいは視覚障害のある人に、標準的な音声ガイドが提供できる以上のアクセスを提供することである。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 1.2.5を満たすのに十分であると考える。
以下に挙げる技術特有のテクニックを用いて、マルチメディア・コンテンツの詳細な音声ガイドを作成する。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
(現在作成中)
視覚的に解釈するのが困難な認知障害のある人だけでなく、全盲や弱視の人も、視覚的な情報の音声ガイドをよく利用する。しかしながら、もし会話があまりにも多くあると、音声ガイドは不十分である。詳細な音声ガイドは、本当にそのビデオを理解するのに必要な補足情報を提供することができる。
(現在、作成中)
1.3.1
コンテンツ内の知覚できる構造が、プログラム的に決められていること (Level 1)
Perceivable structures within the content can be programmatically determined. (Level 1)
オーサード・ユニットのパーツがそれぞれと関連して構成されている状態
デリバリーユニットの一群が、あるデリバリーユニットと関連して構成されている状態
デリバリーユニットの一群が構成されている状態
選択されたベースラインにある技術をサポートしている、支援技術を含むユーザーエージェントによって認識可能であること。
この達成基準の意図は、そのコンテンツ内の重要な構造的な関係を保持したまま、支援技術がWebコンテンツを合成音声、より大きいフォント、あるいは異なる色のような代替のプレゼンテーションによって表現（レンダリング）できるようにすることである。
Webコンテンツ制作者は、情報を理解しやすいかたちで構成するために、情報に構造を付加する。画面を見ることのできるユーザーは、様々な視覚的な手がかりによってその構造を知覚する。 - 見出しは、段落との間に空の1行があり、しばしば大きめで太字である。リスト項目は、行頭にビュレットがあり、おそらくインデントされている。段落は、空の1行で区切られている。共通の特徴を有するアイテムは、テーブルの行と列に並んでいる。フォームのフィールドは、テキストのラベルを共有するグループとして配置されている。
この達成基準の目的は、ある特定のユーザーが知覚可能なあらゆる構造を全てのユーザーにとって知覚可能にすることである。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 1.3.1を満たすのに十分であると考える。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
(現在作成中)
構造をプログラム的に決めることで、Webコンテンツを視覚障害、聴覚障害、そして認知障害のある人のニーズや制約に応じて異なる形で提示できるようになる。情報を異なる形で提供できるようにするためには、支援技術がその情報のタイプを理解できるようにする必要がある。例えば、テーブルの情報がプログラム的にテーブルとして決められていれば、スクリーンリーダーはテーブルの各セルのコンテンツを曖昧なところなく把握することができる。もしテーブルがコンテンツを縦の列に並べているだけだとしたら、スクリーンリーダーは各行のテキストを読むことしかできないだろう。もし、"目に見えるセル" に複数行の情報があったとしたら、各セルの各行は他のセルのそれぞれ同じ行と混同されてしまい、ユーザーはそれを理解することはできないだろう。つまり、スクリーンリーダーは、各セルの1行目をまず読み上げ、次に各セルの2行目を読み上げる、といった具合だ。
色とアスタリスクで必須項目を示しているフォーム
フォームに必須項目と任意項目とがある。フォームの先頭にある説明に、必須項目は赤字でアスタリスクが付いていると書かれている。赤字のテキストとアスタリスクの両方は、しかるべきフォームのフィールドにプログラム的に関連付けられており、支援技術ユーザーは必須項目を把握することができる。
ヘッダーがセルとプログラム的に関連付けられているバスの時刻表
バスの運行スケジュールが表として表示され、縦の1列目にバス停の名前、横の1行目に異なるバスがリストアップされている。それぞれのセルは、それぞれのバスがそのバス停に到着する時刻を示している。バス停とバスのセルは、対応する各行と各列に対する見出しとして識別されているので、支援技術はどのバスとどのバス停が各セルにある時刻と関連付けられているかをプログラム的に把握することができる。
チェックボックスのためのラベルがプログラム的に関連付けられているフォーム
フォームで、支援技術が各チェックボックスに対するラベルをプログラム的に把握できるようになっている。
テキスト文書
シンプルなテキスト文書には、タイトルの前に空の行が2行あり、ビュレットにアスタリスクが用いられ、他にも標準的なフォーマットの仕様を用いているので、その構造をプログラム的に決めることができる。
1.3.2
情報が色によって伝達される場合は、その色がプログラム的に決められていること。また、同じ情報が、利用者の色覚能力に頼らない別の手段でも伝達されていること (レベル 1)
When information is conveyed by color, the color can be programmatically determined or the information is also conveyed through another means that does not depend on the user's ability to differentiate colors. (Level 1)
その色の特性を知覚することがコンテンツを理解するのに必要不可欠であること。
選択されたベースラインにある技術をサポートしている、支援技術を含むユーザーエージェントによって認識可能であること。
この達成基準の意図は、全てのユーザーが色で伝達されている情報にアクセスできるようにすることである。もし情報が画像（あるいは、他の非テキストフォーマット）内で色によって伝達されていたら、支援技術はその色をプログラム的に認識できない。このようなケースでは、色で伝達している情報を他の手段でも提供して、色を見ることのできない支援技術のユーザーでもその情報を知覚できるようにする。
色は、美的な訴求、ユーザビリティ、そしてアクセシビリティを向上させるので、Webコンテンツのデザインにおいて重要な価値のあるものである。しかしながら、色を知覚するのが困難なユーザーもいる。弱視の人はしばしば限られた色しか見れなかったり、多くの高齢者ユーザーは色がよく見えなかったりする。加えて、テキストのみで色が限定された、あるいはモノクロの画面やブラウザを使用している人は、色だけで提供されている情報にアクセスすることはできないだろう。
色がコンテンツを理解するのに必要不可欠なときには、その色をプログラム的に認識可能にして、支援技術がユーザーにその色について知らせることができるようにすれば、ユーザーが色で伝達されている情報にアクセスできるようになる。あるいは、色以外の手段でも伝達することでも、色で伝達されている情報をアクセシブルにすることができる。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 1.3.2 を満たすのに十分であると考える。
色とパターンを用いる (例えば、棒グラフ/円グラフの色に線あるいは模様を併用する)
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
視覚障害のあるユーザー
弱視のユーザーはよく限られた色しか見えないことがある
（スクリーンリーダーを使用している）全盲で色による情報を把握する必要のあるユーザー
高齢者は色がよく見えない場合がある
色覚に特性のあるユーザー
視覚と聴覚に障害のあるユーザー
点字ディスプレイを使用している全盲で耳の聞こえない人が色で伝達されている情報にアクセスできるようになる
テキストブラウザ、色が限定されたディスプレイ、あるいはモノクロのディスプレイを使用している人は、色だけで伝達されている情報にアクセスできない
色を表示できないハンドヘルド端末を使用しているユーザー
必須項目を示すのに色とアスタリスクを用いているフォーム
フォームに必須項目と任意項目の両方がある。フォームの先頭で、必須項目は赤字でアスタリスクも付いていることが説明されている。赤字のテキストとアスタリスクの両方が該当するフォームのフィールドとプログラム的に関連付けられているので、支援技術ユーザーは必須項目を把握することができる。
試験
学生たちが化合物のSVG画像を見ていて、ダイアグラムに用いられている色に基づいて化学元素を確認している。各元素の代替テキストが元素の色とダイアグラムでの位置を示している。色を知覚できない学生もクラスメイトと同じように化合物に関する情報を得ている。（このテクニックは、達成基準1.1のレベル1も満たす）
1.3.3
テキストのプレゼンテーションの変化によって伝達されている情報が、テキストでも伝達されていること。あるいは、テキストのプレゼンテーションの変化が、プログラム的に決められていること。(レベル 2)
Information that is conveyed by variations in presentation of text is also conveyed in text or the variations in presentation of text can be programmatically determined. (Level 2)
プレゼンテーションとは、ユーザーが知覚できるかたちでコンテンツおよび構造が表示されること。
選択されたベースラインにある技術をサポートしている、支援技術を含むユーザーエージェントによって認識可能であること。
この達成基準の意図は、テキストのプレゼンテーションを変えることで伝達している情報を、たとえその情報が代替形式で提供されていたとしても、あるいはユーザーがそのテキストの見た目の差異を知覚できなかったとしても、入手可能にすることです。
見た目の手段において、テキストのプレゼンテーションにおける差異の例としては以下のようなものがある。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 1.3.3を満たすのに十分であると考える。
強調された、あるいは特別なテキストをマークする、特定の技術の標準的なテクニックを用いる
同じ情報をテキストでも補足して提供する
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
(現在作成中)
スクリーンリーダーあるいは点字ディスプレイのユーザーは、テキストの見た目の変化により伝達されている情報にアクセスできない
高齢者を含めて、視覚の衰えている人は、テキストの見た目の変化をよく見れないことがある
(現在作成中)
1.3.4
色で伝達されている情報はすべて、色が使えない時でも視覚的に明らかに見えること。 （レベル 2)
Any information that is conveyed by color is visually evident when color is not available. (Level 2)
その色の特性を知覚することがコンテンツを理解するのに必要不可欠であること。
この達成基準の意図は、全てのユーザーが色で伝達されている情報にアクセスできるようにすることである。
この達成基準は、1.3.2に似ている。1.3.2は、色の情報を直接的に、あるいは支援技術によってアクセシブルにすることを指しているが、この達成基準（1.3.4）は、支援技術を使用しない色覚特性のある人にフォーカスしている。したがって、この達成基準は、色により伝達されている情報を、その色なしでもユーザーに支援技術を使用することを要求せずに入手可能にすることに焦点を合わせている。
色は、美的な訴求、ユーザビリティ、そしてアクセシビリティを向上させるので、Webコンテンツのデザインにおいて重要な価値のあるものである。しかしながら、色を知覚するのが困難なユーザーもいる。弱視の人はしばしば限られた色しか見れなかったり、多くの高齢者ユーザーは色がよく見えなかったりする。加えて、テキストのみで色が限定された、あるいはモノクロの画面やブラウザを使用している人は、色だけで提供されている情報にアクセスすることはできないだろう。
それゆえ、色がコンテンツを理解するのに必要不可欠なときには、色で伝達されている情報を色以外の手段でも伝達することが重要である。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 1.3.4を満たすのに十分であると考える。
説明： まず、あなたのコンテンツに合致する状況を選択する。そのすぐ下にあるのは、その状況に十分であると考えて示されているオプションである。技術特有のテクニックについては、以下に挙げられたあなたの使用している技術に関するオプションを参照のこと。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
(現在作成中)
色は、ユーザビリティおよび美観の訴求を向上させる、Webデザインにおける重要な要素の一つである。しかしながら、中には色を知覚するのが困難なユーザーもいる。弱視のユーザーは限られた色しか見えなかったり、多くの高齢者ユーザーは色がよく見えなかったりする。加えて、テキストのみでモノクロのディスプレイを使用しているユーザーは、色だけで提供されている情報にアクセスすることができないだろう。
必須項目を示すのに色とアスタリスクを用いているフォーム
フォームに必須項目と任意項目の両方がある。フォームの先頭で、必須項目は赤字でアスタリスクも付いていることが説明されている。赤字のテキストとアスタリスクの両方が該当するフォームのフィールドとプログラム的に関連付けられているので、支援技術ユーザーは必須項目を把握することができる。
試験
学生たちが化合物のSVG画像を見ていて、ダイアグラムに用いられている色に基づいて化学元素を確認している。各元素の代替テキストが元素の色とダイアグラムでの位置を示している。色を知覚できない学生もクラスメイトと同じように化合物に関する情報を得ている。（このテクニックは、達成基準1.1のレベル1も満たす）
1.3.5
コンテンツが意味に影響する順番で並べられている場合は、その並び順がプログラム的に決められていること(レベル 3)
When content is arranged in a sequence that affects its meaning, that sequence can be programmatically determined. (Level 3)
選択されたベースラインにある技術をサポートしている、支援技術を含むユーザーエージェントによって認識可能であること。
この達成基準の意図は、支援技術が意味を知覚するのに必要な読み上げ順序を保持したまま、コンテンツの代替プレゼンテーションを提供できるようにすることである。例えば、文章中の単語および段落中の文章の順序は、常にその意味の決め手となる重要なものである。しかしながら、もしページに2つの独立した記事がある場合には、それらが交互に重なっていないかぎりは、記事の順序はそれぞれの意味には影響を及ぼさないかもしれない。意味の通じるコンテンツの順序が、少なくとも一つはプログラム的に認識可能でなければならない。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 1.3.5を満たすのに十分であると考える。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
この達成基準は、コンテンツのリニアライズされた代替プレゼンテーションに依存している視覚、聴覚、および認知障害のあるユーザーの役に立つ。リニアライズされたプレゼンテーションでの情報にアクセスしたとき、デフォルトのプレゼンテーションでの情報の順序による意味と同じになる。この達成基準が満たされないときには、ユーザーは情報が意味を成さない順序で提供されるので困惑するか頭が混乱してしまうだろう。
事例 1: 複数の段組のある文書で、コンテンツをリニアライズすると、ある段の先頭から最後までいって、その後、次の段の先頭へいく。
事例 2: CSSを用いて、ナビゲーションバー、メインコンテンツ、関連コンテンツを配置している。各セクションの見た目のプレゼンテーションはプログラム的に決められた順序通りではないが、そのページの意味は各セクションの順序に依存していない。
1.3.6
コンテンツを理解して操作するのに必要な情報は、コンポーネントの形、大きさ、視覚的な位置、あるいは方向に依存しないこと (Level 3)
Information required to understand and operate content does
not rely on shape, size, visual location, or orientation of components.
(Level 3)
この達成基準の意図は、たとえユーザーが形あるいはサイズを知覚できなかったり、空間上の位置や方向を認識できなかったりしたとしても、全てのユーザーがそのコンテンツを利用するための説明にアクセスできるようにすることである。中には、コンテンツの構造からは入手不可能なオブジェクトの形や位置に依存しているコンテンツがある（例えば、"丸いボタン" あるいは "右にあるボタン"）。障害のあるユーザーの中には、使用している支援技術の特性からそういった形や位置を知覚できない人もいる。この達成基準は、このような形や位置に依存したあらゆるものを明確にする情報を付加することを要件としている。
しかしながら、形および/あるいは位置を用いて情報を提供することは、認知障害のある人を含む多くのユーザーに対して効果的な手法である。この達成基準は、情報が他の手段でも提供されているかぎり、そういった見た目の手がかりを使わないようにするものではない。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 1.3.6を満たすのに十分であると考える。
形や位置で示されている情報を、プログラム的に決められる特徴によっても示す（例えば、プログラム的に決められるテキストあるいはマークアップで情報を伝える）
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
全盲や弱視のユーザーは、情報が形あるいは位置だけで伝達されていると理解できないことがある。形あるいは位置以外の情報も追加することで、形あるいは位置で伝達されている情報を理解できるようになる。
1.4.1
テキストあるいはダイアグラムとそれらの背景は、少なくとも5:1の輝度コントラスト比を保つこと (レベル 2)
Text or diagrams, and their background, must have a luminosity contrast ratio of at least 5:1. (Level 2)
(L1+.05) / (L2+.05) L は輝度で、リニアライズした R、G、そして B の値を用いて、.2126*R + .7152*G + .0722B のように規定される。リニアライズした R (例) = (R/FS)^2.2 FS は、フルスケール（全範囲）の値 (8 ビットのカラーチャンネルでの255）。L1 は、高いほうの値（テキストあるいは背景のどちらか）で、L2 は低いほうの値。
(L1+.05) / (L2+.05) where L is luminosity and is defined as .2126*R + .7152*G + .0722B using linearized R, G, and B values. Linearized R (for example) = (R/FS)^2.2 where FS is full scale value (255 for 8 bit color channels). L1 is the higher value (of text or background) and L2 is the lower value.
この達成基準の目的は、ロービジョンのユーザーにも読みやすいように、テキストとその背景のコントラストを十分に確保することである。コントラストは、色覚に特性のある人にとってもテキストと背景のコントラストが十分であるような方法で計算される。
.05 のオフセットは、ある値がゼロあるいはゼロに近いときに起こるコントラスト比の影響と周辺光の影響を調整するために含まれている。
ガンマ補正(^2.2)とRGB定数値は、sRGB definitionによるものです。
この達成基準は、Webコンテンツはそれ自体が光を放つわけではないという事実を反映させるため、輝度ではなく、輝度コントラスト比の用語を用いている。輝度コントラスト比は、表示されたときの相対的な輝度の基準を提供する。（なぜなら、それは比率であり、それは寸法ではないから。）
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 1.4.1を満たすのに十分であると考える。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
(現在作成中)
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
弱視のユーザーは、背景とのコントラストが十分ではないテキストを読むのが困難なことが多い。もしユーザーが、さらにコントラストを低下させるような色覚特性を持っていると悪化する可能性もある。テキストと背景に最低限の輝度コントラスト比を与えることで、たとえユーザーが全ての色を見ることができなくても、テキストをより読みやすくすることが可能だ。また色を見ることのできない人にも有用である。
1.4.2
自動的に流れる背景音がある場合は、再生を停止するメカニズムが提供されていること (Level 2)
A mechanism is available to turn off background audio that plays automatically. (Level 2)
画面を読み上げるソフトウェアを使用している人は、もし他の音声が同時に再生されていたら、読み上げの音声出力を理解しづらいことがある。この状況は、スクリーンリーダーの音声出力がソフトウェアベースで（今日ではほとんどがそうである）、他の音声と同じ音量コントロールで制御されているときに、より悪化する。この達成基準の目的は、その音声を停止できる手段を提供することである。スクリーンリーダーのユーザーは、画面上のあらゆるコントロールにアクセスするためにはスクリーンリーダーを用いなくてはならないので、音声を停止する手段は操作しやすくすべきで、音量の大きい音楽でスクリーンリーダーの読み上げを完全にかき消してはならない。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 1.4.2を満たすのに十分であると考える。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
音声読み上げ技術を使用している人は、他の音が再生されていないことでスクリーンリーダーの音声を聞くことができる。これは、耳の聞こえにくい人やシステム音量を用いるスクリーンリーダーを使用している人（つまり、音声の音量を下げて、スクリーンリーダーの音量を上げることができない人）にとっては、特に重要である。
また、音声を無視してWebコンテンツに集中することのできない注意力欠如障害のある人にとっても役に立つ。
ページが開くと自動的に再生が開始する音声ファイルがあるが、ユーザーがページの先頭にある「音を消す」リンクを選択することで停止させることができる。
1.4.3
テキストあるいはダイアグラムとそれらの背景は、少なくとも10:1の輝度コントラスト比を保つこと (レベル 3)
Text or diagrams, and their background, must have a luminosity contrast ratio of at least 10:1. (Level 3)
(L1+.05) / (L2+.05) L は輝度で、リニアライズした R、G、そして B の値を用いて、.2126*R + .7152*G + .0722B のように規定される。リニアライズした R (例) = (R/FS)^2.2 FS は、フルスケール（全範囲）の値 (8 ビットのカラーチャンネルでの255）。L1 は、高いほうの値（テキストあるいは背景のどちらか）で、L2 は低いほうの値。
この達成基準の目的は、ロービジョンのユーザーにも読みやすいように、テキストとその背景のコントラストを十分に確保することである。コントラストは、色覚に特性のある人にとってもテキストと背景のコントラストが十分であるような方法で計算される。この達成基準は、1.4.1とは異なり、レベル2の達成基準であり、より高いレベルでのコントラストを要求する。
.05 のオフセットは、ある値がゼロあるいはゼロに近いときに起こるコントラスト比の影響と周辺光の影響を調整するために含まれている。
ガンマ補正(^2.2)とRGB定数値は、sRGB definitionによるものです。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 1.4.3を満たすのに十分であると考える。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
(現在作成中)
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
弱視のユーザーは、背景とのコントラストが十分ではないテキストを読むのが困難なことが多い。もしユーザーが、さらにコントラストを低下させるような色覚特性を持っていると悪化する可能性もある。テキストと背景に最低限の輝度コントラスト比を与えることで、たとえユーザーが全ての色を見ることができなくても、テキストをより読みやすくすることが可能だ。また色を見ることのできない人にも有用である。
1.4.4
音声コンテンツは、背景音を含んでいないこと。あるいは、背景音がある場合は、前景の音声コンテンツよりも少なくとも20デシベルは音量が小さいこと。ただし、時折の効果音は例外とする。(レベル 3)
Audio content does not contain background sounds or the
background sounds are at least 20 decibels lower than the foreground
audio content, with the exception of occasional sound effects. (Level 3)
注： 音声レベルでの20デシベルの差というのは、おおよそ4倍の静かさ（あるいは、騒がしさ）です。この要件を満たす背景音は、前景の音声よりもだいたい4倍静かである。
耳の聞こえにくい人は、背景音あるいはその他の雑音と話し言葉を聞き分けるのが困難である。この達成基準の目的は、話し言葉ではない音声をユーザーが話し言葉を理解できるくらい十分に低くすることである。音のレベルで20デシベルの差は、だいたい4倍の静かさ（あるいは、騒がしさ）に相当する。この要件を満たす話し言葉ではない音声は、話し言葉よりもおおよそ4倍静かだといえる。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 1.4.4を満たすのに十分であると考える。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
(現在作成中)
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
(現在作成中)
耳の聞こえにくい人は、話し言葉の音声と背景音を区別するのがとても困難なことがよくある。
以下の音声トラックは、背景音のあるスピーチの例である。
最初の例では、声（前景音）は -17.52デシベルで録音されており、音楽（背景音）は -37.52デシベルで、前景音を背景音より20デシベル大きくしている。
2つ目の例は、声（前景音）は -18デシベルで、音楽（背景音）が約 -16デシベルで、前景音は背景音より2デシベルしか大きくない。
About Decibels by Gregg Vanderheiden（英語）
2.1.1
コンテンツの全ての機能は、アナログで時間に依存した入力を必要とするタスクを除いて、キーボード・インターフェースにより時間に依存しない方法で操作可能であること (レベル 1)
All functionality of the content is operable in a non time-dependent manner through a keyboard interface, except where the task requires analog, time-dependent input. (Level 1)
注： これは、キーボード操作に加えて他の入力手段（マウスなど）でもサポートすることを排除するわけではなく、妨げるべきものでもない。
注： マウスキーはこの達成基準を満たさない。
ユーザーの入力に反応して、1つあるいはそれ以上のアクションを実行すること、あるいは実行できること。
ビルトインあるいは付属のキーボードのないデバイスに、テキストを入力する目的でキーボードを接続する代替手法。あるいは、デバイスの内部にあるテキストを入力する仕組み。"キーボード・インターフェイス"を介した制御を可能にするということは、コンテンツがキーボードやキーボードのようにテキスト生成が可能な代替手段によって発せられたコマンドを介して制御できる、ということを意味する。
この達成基準の目的は、可能なかぎり、コンテンツをキーボードあるいはキーボード・インターフェースで操作できるようにすることである。コンテンツがキーボードあるいは代替キーボードで操作可能であれば、代替キーボードあるいはキーボード・エミュレータのようにふるまう入力デバイスを使用しなければならない人や全盲の人（目と手を一緒に動かす必要のあるマウスなどのデバイスを使えない人）がそのコンテンツを利用できる。キーボード・エミュレータには、音声入力ソフトウェア、呼吸操作ソフトウェア、恩スクリーン・キーボード、スキャニング・ソフトウェアおよび様々な支援技術と代替キーボードなどがある。ロービジョンの人は、ポインタを目で追うのが困難なことがあり、キーボードで操作可能なソフトウェアを使ったほうがより簡単（あるいは、そうするしかない）な場合もある。
しかしながら、Webコンテンツの中にはキーボードでは操作できないタイプのものがある。例えば、動きおよび動きのスピードやその強弱などで筆使いが決まる彩画アプリケーションなどはその一例である。"タスクがアナログかつ時間に依存した入力を必要とする場合は除いて"というフレーズがあるのは、当然ながらキーボードでは操作しようのないそういったものを区別するためである。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 2.1.1を満たすのに十分であると考える。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
全盲の人（目と手での操作を必要とするマウスのようなデバイスを使用できない）
ドラッグ・アンド・ドロップを用いるアプリケーションが、"カット"と"ペースト"あるいはオブジェクトを動かすフォームのコントロールをサポートする
弱視の人（画面上のマウスポインタを見つけるのが困難なことがある）
事例 1: 描画プログラム
描画プログラムは、ユーザーがキーボードでオブジェクトを作成したり、サイズを変えたり、位置を決めたり、回転させたりすることができる。
事例 2: ドラッグ・アンド・ドロップ機能
ドラッグ・アンド・ドロップを用いるアプリケーションが、"カット"と"ペースト"あるいはオブジェクトを動かすフォームのコントロールをサポートしている。
事例 3: Association or discreet line
点と点を線で結ぶプログラムは、ユーザーが画面上で点の間を移動できて、スペースキーでその点と前の点とをつなげるようになっている。
事例 4: 例外 - 水彩画プログラム
筆のストロークは動きのスピードや持続時間によって変わるので、水彩画プログラムは例外として認められる。
事例 5: 例外 - ヘリコプターのフライト・トレーニング・シミュレーター
シミュレーターはヘリコプターのリアルタイムのふるまいを教える性質のものなので、ヘリコプターのフライト・トレーニング・シミュレーターは例外として認められる。
2.1.2
コンテンツの全ての機能はすべて、キーボード・インターフェイスを通して操作できるように設計されていること。 (レベル 3)
All functionality of the content is designed to be operated through a keyboard interface. (Level 3)
ユーザーの入力に反応して、1つあるいはそれ以上のアクションを実行すること、あるいは実行できること。
ビルトインあるいは付属のキーボードのないデバイスに、テキストを入力する目的でキーボードを接続する代替手法。あるいは、デバイスの内部にあるテキストを入力する仕組み。"キーボード・インターフェイス"を介した制御を可能にするということは、コンテンツがキーボードやキーボードのようにテキスト生成が可能な代替手段によって発せられたコマンドを介して制御できる、ということを意味する。
この達成基準は、達成基準 2.1.1と同じだが、例外が一切認められない：全てのコンテンツは、キーボードで操作可能である。
2.2.1
コンテンツの機能であるタイムアウトのそれぞれについて、以下の項目の少なくとも1つが当てはまること(レベル 1)
For each time-out that is a function of the content, at least one of the following is true: (Level 1)
ユーザーが、タイムアウトの機能を無効にできる。あるいは、
ユーザーが、タイムアウトの間隔を大幅に調整でき、少なくとも初期設定の10倍の長さに変えられる。あるいは、
タイムアウトする前に警告が表示され、ユーザーが簡単な操作（例えば、どれかキーを押すなど）でタイムアウトを延長するのに少なくとも20秒の猶予が与えられる。かつ、ユーザーはタイムアウトまでの時間を少なくとも10倍に延長できる。あるいは、
タイムアウトが、リアルタイム・イベント（例えば、オークションなど）の重要な一部となっていて、タイムアウトを何かで代替することが不可能である。あるいは、
タイムアウトが、不可欠な時間要素（例えば、競争するゲームや時間制限のあるテストなど）の一部となっていて、その有効性を損なわずに時間制限を延長するのが不可能である。
Editorial Note: The Working Group is considering adding techniques and/or modifying the success criterion to ensure additional accessibility features are employed for events where no alternative to a timeout is possible or where timing is essential.
タイミングがそのコンテンツの企画設計の一部で、その時間的要素を取り除くとコンテンツの機能が変わってしまう要素。
この達成基準の目的は、想定しうる障害のある人がWebコンテンツを操作するのに十分な時間を与えるようにすることである。全盲の人や手の不自由な人、認知障害のある人などは、オンラインフォームの入力のような操作をするのに時間がかかるかもしれない。もしWebの機能が時間に依存しているならば、タイムアウトが発生するまでに要求されている操作を終えることが困難なユーザーもいるだろう。これはそのサービスがそういったユーザーに対してアクセシブルでないことを意味する。時間に依存しないように機能を設計することは、障害のある人が必要な操作を完了できることにつながる。タイムアウトを無効にする、制限時間をカスタマイズする、あるいはタイムアウトが発生する前に時間延長を要求する、といったオプションを提供することは、フォームの入力を完了するのに時間のかかるそういったユーザーの助けとなる。
しかしながら、場合によっては、タイムアウトを変更できないことがある（例えば、オークション、あるいはその他のリアルタイム性のあるイベント）。そのため、そういった場合に対しては例外としている。
サーバ側のタイムアウトに関する注記
サーバで時間設定したリダイレクトに関しては、以下にある"よくある悪い例"を参照。
ログイン有効時間のようなサーバでのタイムアウトは、達成基準 2.2.6で述べている。
サーバでの自動リダイレクト（例： "3xx response codes"）は、タイムアウトがないので対象外である。：すぐにリダイレクトするため。
Editorial Note: The sufficient techniques currently do not cover server timeouts, which some members of the working group think is a problem that can sometimes, but not always, be addressed. Further thoughts and comments on this are solicited.
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 2.2.1を満たすのに十分であると考える。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
スクリプトを用いて、サーバを調べてユーザーにタイムアウトがあるかどうかを知らせる
注： サイト運営者やコンテンツ制作者がサーバを制御できない場合は、タイムアウトを用いるべきではない。
身体に障害のある人は、反応したり、入力したり、タスクを完了するのに時間がかかることがよくある。弱視の人は画面上の要素を確認して読むのに時間がかかる。全盲でスクリーンリーダーを使用している人は、画面レイアウトを理解したり、情報を見つけたり、コントロールを操作したりするのに時間がかかる。認知あるいは言語に問題のある人は、文章を読んで理解するのに時間がかかる。聴覚障害で手話を使う人は、紙に印刷されたテキストの情報を読むのに時間がかかることがある。
2.2.2
コンテンツが3秒を超えて点滅しないこと。あるいは、コンテンツの点滅を止める方法が、デリバリー・ユニットの中で提供されていること。(レベル 2)
Content does not blink for more than 3 seconds, or a method is available to stop any blinking content in the delivery unit. (Level 2)
注： 光源性による発作を誘発する恐れのあるコンテンツの制作を避けることの要件については、 光源性のてんかん発作を誘発する恐れのあるコンテンツを使用しないを参照のこと。
Editorial Note: Is there a widespread problem with individuals who are so transfixed, that they are unable to turn blinking content off (so that the second option in the above success criterion would not be possible)?
1秒間に0.5～3回点いたり消えたりすること。
2つの連携するWebプログラムの間で、1つのHTTPリクエストに対する反応として転送される素材のセット。この転送には、例えば、元のサーバとユーザーエージェントの間の転送などがある。
注： この用語は、Glossary of Terms for Device Independence（英語）からそのまま引用した。
この達成基準の意図は、デリバリー・ユニットとのインタラクションにおいて、ユーザーの注意を散漫にしないようにすることです。特に注意欠陥障害のある人などの特定のユーザー層は、点滅しているコンテンツがあると注意力が散漫になり、デリバリーユニットの他の部分に集中することが困難になります。ユーザーの注意をひくために十分な時間だが、ユーザーがページを利用するために待てないほど長くもない、という理由で3秒間としている。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 2.2.2を満たすのに十分であると考える。
(何もする必要なし)
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
デリバリーユニット内で点滅する全てのコンテンツを停止させる仕組みを提供する
3秒以内に自動的に停止する場合でも、ユーザーがコンテンツを停止できる手段を提供する
注： サイト運営者やコンテンツ制作者がサーバを制御できない場合は、タイムアウトを用いるべきではない。
ユーザーの注意を引くために、コンテンツを点滅させることがある。これは画面を見ている全てのユーザーに対して効果的な手法ではあるが、点滅が続くとあるユーザーにとっては問題となりうる。読み書き能力の低い人、ディスレクシアの人、注意力欠如障害のある人などにとっては、点滅するコンテンツによって、デリバリーユニットの他の部分を操作することに気を向けることができない場合がある。3秒後に点滅を停止するコンテンツを提供するか、あるいはユーザーが点滅を停止できる仕組みを提供することで、これらの人たちはデリバリーユニットを操作できるようになる。
事例 1: Web広告が、ユーザーの注意を引くために点滅しているが、3秒後に停止する
事例 2: フォームが、もしユーザーが入力を終えたのに送信ボタンを押さなかったら、送信ボタンの近くにある矢印を点滅させる。その点滅は3秒後に停止する。
事例 3: アニメーションがページの上部にあるが、アニメーションの下に"アニメーションを停止する"ボタンがある。
2.2.3
そのタイミングあるいは動きが不可欠な時間あるいは動きの要素の一部でないかぎり、ユーザーがコンテンツを一時停止できること (Level 2)
Content can be paused by the user unless the timing or movement is part of an activity where timing or movement is essential. (Level 2)
タイミングがそのコンテンツの企画設計の一部で、その時間的要素を取り除くとコンテンツの機能が変わってしまう要素。
この達成基準の意図は、コンテンツがユーザーの読解力や理解力を超えた速度で先に進んだり更新したりするのを、一時的に停止できるオプションを提供することである。
"動き"は、目に見えるコンテンツが動きを伝えているものを指す。よくある例としては、映画、マルチメディア・プレゼンテーション、アニメーション、リアルタイムのゲームやスクロールする株価表示などが挙げられる。
"時間に依存した"は、あらかじめ設定した時間の間隔でコンテンツが更新されたり、消えたりするものを指す。よくある時間に依存したコンテンツとしては、音声、自動更新される天気情報、ニュース、株価更新、そして自動進行のプレゼンテーションやメッセージなどが挙げられる。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 2.2.3を満たすのに十分であると考える。
以下に挙げるテクニックのいずれかが用いられる。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
(現在作成中)
情報を読んだり理解したりするのに時間のかかる、読字障害、認知障害および学習障害のある人は、コンテンツを停止させることで情報を読む時間を確保できる。
必要不可欠なアニメーションが、タスクに影響を及ぼすことなく、停止させることが可能である。
Webサイトは、プロセスを紹介するアニメーションによって、読者が"どのように機能するか"を理解しやすくしている。そのアニメーションには、"一時停止"と"再開"のボタンがある。
株価表示
株価表示に"一時停止"と"再開"のボタンがある。表示を一時停止させると、その時点での株価で一時停止する。再開させると、その時点での最新の株価を表示する - 一時停止していた間の株価は表示されない。その代わりに、一時停止した時点から再開できるとしても、ユーザーがリアルタイムの表示までジャンプするためにコンテンツをリロードしないかぎり、あるいは株価表示がリアルタイムの株価に追いつくまで"早送り"しないかぎり、その株価表示は遅れたままである。
ユーザーがリアルタイムで競争しないで交代できるように設計されたゲーム
参加者がその競争を無効にされることなくゲームを一時停止できる。
オークション
オークションの性質上、ユーザーはタイミングを一時停止することができない。代わりに、ユーザーは1つのキー操作で送信できるように、入札価格を用意して保持しておくことができる。
2.2.4
リアルタイム・イベントを除いて、タイミングがコンテンツによって提示されているイベントや活動の不可欠な一部となっていないこと。 (レベル 3)
Except for real-time events, timing is not an essential part of the event or activity presented by the content. (Level 3)
ライブであり、コンテンツ制作者がコントロールできないイベント。
この達成基準の目的は、タイミングを要求するコンテンツの発生を最小限に抑えることである。これは全盲、ロービジョン、認知障害、あるいは運動障害などの人がコンテンツを操作できるようにする。この達成基準は、唯一の例外がリアルタイム性のあるイベントであるという点においてレベル1の達成基準とは異なる。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 2.2.4を満たすのに十分であると考える。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
(現在作成中)
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
(現在作成中)
身体に障害のある人は、反応したり、入力したり、タスクを完了するのに時間がかかることがよくある。弱視の人は画面上の要素を確認して読むのに時間がかかる。全盲でスクリーンリーダーを使用している人は、画面レイアウトを理解したり、情報を見つけたり、コントロールを操作したりするのに時間がかかる。認知あるいは言語に問題のある人は、文章を読んで理解するのに時間がかかる。聴覚障害で手話を使う人は、紙に印刷されたテキストの情報を読むのに時間がかかることがある。
テストを完了するのに要する時間が点数に影響しないテスト
（事例作成中）
ユーザーがリアルタイムで競争しないで交代できるように設計されたゲーム
参加者がその競争を無効にされることなくゲームを一時停止できる。
2.2.5
緊急性のあるものを除いて、更新コンテンツの通知のような中断表示は、ユーザーが延期または抑制できること。 (レベル 3)
Interruptions, such as updated content, can be postponed or suppressed by the user, except those involving an emergency. (Level 3)
唐突で予期しなかった状況あるいは出来事で、健康、安全あるいは財産を保護するために迅速な対応を要求されるもの。
この達成基準の意図は、緊急事態を除いて、ユーザーがサイト運営者/サーバからの更新を停止できるようにすることです。緊急事態には、市民向け緊急事態の警報メッセージあるいはデータ消失、接続の失敗などの警告が挙げられる。
この達成基準により、認知障害のある人あるいは注意力に問題のある人がコンテンツに集中できるようになる。また、全盲の人やロービジョンの人も"閲覧"の神経を現在読んでいるコンテンツに集中できるようになる。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 2.2.5を満たすのに十分であると考える。
アップデートが入手可能であることをユーザーに知らせて、今すぐアップデートを行うか、それとも後で行うかを選択できるようにするあるいは
「今後このメッセージを表示しない」または時間を設定できるようにして「～まではこのメッセージを表示しない」というチェックボックスのあるリマインダーを用いる
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
(現在作成中)
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
(現在作成中)
注意力欠如障害のある人が、注意散漫にならずにコンテンツに集中できる。
弱視の人あるいはスクリーンリーダーを使用している人は、閲覧中はコンテンツをアップデートしない (もし読み始めたときのトピックが読んでいる途中で別のトピックに変わっていたら、内容が途切れて誤解してしまう恐れがある）。
(現在作成中)
2.2.6
認証されたセッションが一定時間にわたって操作がないことでタイムアウトとなる場合、ユーザーが再認証後に前のセッションのデータを失わずに活動が続けられるようになっていること。(レベル 3)
When an authenticated session has an inactivity timeout, the
user can continue the activity without loss of data after
re-authenticating. (Level 3)
意図は、一定時間経過後にタイムアウトする認証されたトランザクションを全てのユーザーが完了できるようにすることである。セキュリティ上の理由で、多くのサイトは何もしない時間がある程度経過すると認証をタイムアウトする仕組みを実装している。こういったタイムアウトは、障害のある人の場合、タスクを完了するのにより長い時間を要するので問題を引き起こすことがある。このようなユーザーが再認証されたら、既に入力したデータが損なわれることなく、そのトランザクションを継続できるようにしなければならない。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 2.2.6を満たすのに十分であると考える。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
(現在作成中)
この達成基準は、タスクを完了するのに追加の時間を必要とする人の役に立つ。認知障害のある人はゆっくり読むことがあるので、読んで質問に答えるのに追加の時間を必要とする。スクリーンリーダーを使って操作しているユーザーは、複雑なフォームを操作して完了させるのに余分な時間を必要とすることがある。運動障害のある人あるいは代替入力デバイスを使用している人は、フォームの操作あるいは入力完了に追加の時間を必要とすることがある。
ショッピングサイトのチェックアウト
ユーザーがあるショッピングサイトにログインしている。チェックアウト手続きを進めている間、ユーザーは長時間にわたり気が散っていて、セッションがタイムアウトになる。ユーザーがチェックアウト手続きに戻ってフォームを送信すると、サイトは再認証のためのログイン画面を出す。ユーザーがログインした後、チェックアウト手続きは同じ段階での同じ情報の状態に戻る。サーバが一時的に送信を受け付けて保存していたので、ユーザーはデータを失うことなく、再認証が完了した後に同じ状態に戻った。
Eメール・プログラムの認証
あるEメール・プログラムは30分後に認証をタイムアウトする。そのプログラムは、タイムアウトになる数分前にユーザーに警告を出し、再認証するために新しいウィンドウを開くリンクを提供する。作成中だったEメールのある元のウィンドウは損なわれることなく、再認証後に、ユーザーはそのデータを送信できる。
タイムアウトのあるアンケート
1つのデリバリーユニットで提供されている長いアンケートの冒頭に、15分後にセッションがタイムアウトすることを示す情報がある。ユーザーは、どの時点でもデータは一時保存され、後で完了させることができることも知らされる。そのデリバリーユニットには、部分的に完了したフォームを保存するために提供されたボタンが幾つかある。加えて、ベースラインにあるJavaScriptで、ユーザーは、セッションがタイムアウト間近になると、ポップアップウィンドウでアラートが出るように選ぶことができる。
2.3.1
コンテンツが一般閃光閾値、または赤色閃光閾値に違反している場合、その表示を回避できるようにユーザーに警告していること (レベル 1)
When content violates either the general flash threshold or thered flash threshold, users are warned in a way that they can avoid it. (Level 1)
明滅または急速に変化する画像の連続は、次の2点の両方が当てはまる場合は、使用してはならない。
同時に起こっている（ただし必ずしも隣接はしていない）明滅のエリアの合計サイズが、そのコンテンツを1024×768ピクセルで見た場合の表示画面上で、335×268ピクセルの長方形の4分の1を超えるエリアを占めている。
1秒間に3回を超える明滅がある。
注： 一般閃光の閾値について、明滅とは、フルスケールの白色度の10％以上の明度における1組の相対する変化のことで、明度はリニアライズした R、G、そして B の値を用いて、.2126*R + .7152*G + .0722B で計算される。Linearized-X = (X/FS)^2.2 FSはフルスケール（今日では通常255）である。"相対する変化"とは、明度が増加した後に減少する、あるいは明度が減少した後に増加することを指す。
彩度の高い赤色閃光への移行、あるいは彩度の高い赤色閃光からの移行は、次の2点の両方が当てはまる場合は、使用してはならない。
同時に起こっている明滅のエリアの合計サイズが、そのコンテンツを1024×768ピクセルで見た場合の表示画面上で、335×268ピクセルの長方形の4分の1を超えるエリアを占めている。
1秒間に3回を超える明滅がある。
この達成基準の目的は、ユーザーに光源性による発作を誘発する恐れのあるコンテンツに知らず知らず出くわすことを避ける手段を提供することである。
光源性の発作による障害のある人は、特定の頻度で閃光を繰り返し発するコンテンツにより発作を引き起こされる可能性がある。一般的に、他の色よりも赤色の閃光にさらに敏感なので、彩度の高い赤色の閃光による特別なテストを提供している。これらのガイドラインは、コンピュータの画面にも適用できる放送業界のガイドラインを基準にしており、コンピュータの画面ではコンテンツがより近距離（より広い視角）で閲覧される。
この達成基準は、広い範囲内の頻度（3～50ヘルツ）でのあらゆる閃光（1ピクセルの閃光でさえ）許容していなかったWCAG 1.0におけるより限定されていた基準にとってかわるものである。この達成基準は、英国や他国でテレビ放送に用いられ、コンピュータのディスプレイ視聴にも適用されてきている既存の規格に基づいている。評価には1024ピクセル x 768ピクセルの画面を用いている。そして、335ピクセル x 268ピクセルの四角形を、典型的な画面までの距離における10度の視野角での画面上の表示領域としている。（10度という視野角は、参照した元の規格にもとづいており、眼の中心視力部分をあらわす - 感光刺激に最も敏感な部分である）
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 2.3.1を満たすのに十分であると考える。
メタデータを用いて、一般閃光閾値あるいは赤色閃光閾値を超えるコンテンツを特定する
ページタイトルで情報を提供する（検索結果ページで示すことが可能）
一般閃光閾値あるいは赤色閃光閾値を超えるコンテンツを表示する前に、デリバリーユニットで警告を出す
ユーザーが一般閃光閾値あるいは赤色閃光閾値を超えるコンテンツに出くわす前に、表示させない、あるいは停止させる手段を提供する
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
閃光を停止させるボタンをその閃光と同じ画面上に置く
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
一般閃光閾値及び赤色閃光閾値を超える素材を使用しない
光源性の閾値を超える素材を使用しない
ユーザーが光源性の閾値を超える素材に出くわす前に警告を与える
ユーザーが光源性の閾値を超える素材に出くわす前に、それを表示させなくするか、オフにできる手段を提供する
閃光を放つコンテンツを見ると発作を起こしてしまう人は、そういうコンテンツがいつ現れるかを知り、それを避けることができる。光源性のけいれん疾患のある人と同様に、光源性てんかんの人もこれに含まれる。
閾値を超える閃光を含むアニメのあるサイトは、大きくて目立つ警告のあるページからしかそのページにアクセスできない。さらに、そのコンテンツ自体は検索も不可能であるか、その警告ページからしかアクセスできないようになっている。
Trace Center Photosensitive Epilepsy Analysis Tool
2.3.2
コンテンツが、一般閃光閾値あるいは赤色閃光閾値に違反していないこと (Level 2)
Content does not violate general flash threshold or red flash threshold. (Level 2)
明滅または急速に変化する画像の連続は、次の2点の両方が当てはまる場合は、使用してはならない。
同時に起こっている（ただし必ずしも隣接はしていない）明滅のエリアの合計サイズが、そのコンテンツを1024×768ピクセルで見た場合の表示画面上で、335×268ピクセルの長方形の4分の1を超えるエリアを占めている。
1秒間に3回を超える明滅がある。
注： 一般閃光の閾値について、明滅とは、フルスケールの白色度の10％以上の明度における1組の相対する変化のことで、明度はリニアライズした R、G、そして B の値を用いて、.2126*R + .7152*G + .0722B で計算される。Linearized-X = (X/FS)^2.2 FSはフルスケール（今日では通常255）である。"相対する変化"とは、明度が増加した後に減少する、あるいは明度が減少した後に増加することを指す。
彩度の高い赤色閃光への移行、あるいは彩度の高い赤色閃光からの移行は、次の2点の両方が当てはまる場合は、使用してはならない。
同時に起こっている明滅のエリアの合計サイズが、そのコンテンツを1024×768ピクセルで見た場合の表示画面上で、335×268ピクセルの長方形の4分の1を超えるエリアを占めている。
1秒間に3回を超える明滅がある。
この達成基準の目的は、ユーザーが光源性による発作を引き起こすことなく、サイトの全てのコンテンツにアクセスできるようにすることである。
光源性の発作による障害のある人は、特定の頻度で閃光を繰り返し発するコンテンツにより発作を引き起こされる可能性がある。一般的に、他の色よりも赤色の閃光にさらに敏感なので、彩度の高い赤色の閃光による特別なテストを提供している。これらのガイドラインは、コンピュータの画面にも適用できる放送業界のガイドラインを基準にしており、コンピュータの画面ではコンテンツがより近距離（より広い視角）で閲覧される。
この達成基準は、広い範囲内の頻度（3～50ヘルツ）でのあらゆる閃光（1ピクセルの閃光でさえ）許容していなかったWCAG 1.0におけるより限定されていた基準にとってかわるものである。この達成基準は、英国や他国でテレビ放送に用いられ、コンピュータのディスプレイ視聴にも適用されてきている既存の規格に基づいている。評価には1024ピクセル x 768ピクセルの画面を用いている。そして、335ピクセル x 268ピクセルの四角形を、典型的な画面までの距離における10度の視野角での画面上の表示領域としている。（10度という視野角は、参照した元の規格にもとづいており、眼の中心視力部分をあらわす - 感光刺激に最も敏感な部分である）
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 2.3.2を満たすのに十分であると考える。
コンテンツが一般閃光閾値あるいは赤色閃光閾値を超えていないことを検証により確認する(関連リソースにあるツールを参照)
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
(現在作成中)
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
閃光を放つコンテンツのコントラストを下げる
サイドの高い赤色を使用しない
閃光の数を減らす
光源性の閾値を超える素材を使用しない
ユーザーが光源性の閾値を超える素材に出くわす前に警告を与える
ユーザーが光源性の閾値を超える素材に出くわす前に、それを表示させなくするか、オフにできる手段を提供する
閃光を放つコンテンツを見ると発作を起こしてしまう人は、発作を起こすことなく、かつ代替テキストを利用することでコンテンツの持つエクスペリエンスを逃すことなく、サイト上の全てのコンテンツを見ることができる。光源性のけいれん疾患のある人と同様に、光源性てんかんの人もこれに含まれる。
とても明るい閃光を放つシーンのある映画は、閃光が2回しか放たれないようになっている。
Trace Center Photosensitive Epilepsy Analysis Tool
2.4.1
ナビゲーション機能がプログラム的に決められていること。(レベル 1)
Navigational features within the content can be programmatically determined. (Level 1)
ユーザーがコンテンツの様々な部分の位置を確認したり様々な部分へ移動したりできるメカニズム
選択されたベースラインにある技術をサポートしている、支援技術を含むユーザーエージェントによって認識可能であること。
ユーザーは、コンテンツのナビゲーション機能を識別し、コンテンツ内を行き来する。サイト制作者が定義したナビゲーション機能（例えば、リンク）、インタラクティブな要素（例えば、フォームのフィールド）、そしてコンテンツ内をナビゲートするのに役に立つ構造のコンポーネントを見つけて識別できることは特に有用である。構造は、例えば、リストあるいはテーブルのような部分の開始位置や終了位置を見つけること、あるいはそれぞれの見出しによりコンテンツの区切りを見つけることにより、ユーザーがナビゲーションのために用いることができる。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 2.4.1を満たすのに十分であると考える。
達成基準 1.3.1 のテクニックを用いて、共通のナビゲーション機能をプログラム的に明確にするために、技術特有のテクニックを用いる.
注： ナビゲーションに最もよく用いられる構造には、ユーザーが文章中を素早く移動してコンテンツの各部分を確認できるグループ化された構造と同様に、章、節、見出しなどもある。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
自分の探しているコンテンツをより簡単に探し出せる方法があると、運動障害あるいは視覚障害のある人のように、コンテンツに順次アクセスしなければならない人のためになる。情報に辿り着くまでのキーストロークの回数を減らすことは、運動障害のある人に対して重要です。コンテンツに順次アクセスしている人は、興味のないコンテンツをスキップできれば時間の節約になる。
事例 1. スクリーンリーダーのユーザーは、テキストの次の見出しにスキップできる。
事例 2.スクリーンリーダーのユーザーは、目次のような階層構造を持つリストを読んでいる。リストの入れ子状態がマークされているので、目次の中で入れ子になった小見出しをスキップすることが可能で、また今のリストの最後までスキップすることもできる。
事例 3.ユーザーは、支援技術がフォームの次のフィールドを認識できるので、タブ移動順序の途中にあるリンクをスキップしながら、フォームの次のフィールドに"タブ"移動するのに支援技術を使うことができる。
2.4.2
コンテンツが一連のプロセスあるいはタスクの結果または途中段階ではない場合、コンテンツを探し出す方法が、1組のデリバリー・ユニット内で複数提供されていること。(レベル 2)
More than one way is available to locate content within a set of delivery units where content is not the result of, or a step in, a process or task.. (Level 2)
2つの連携するWebプログラムの間で、1つのHTTPリクエストに対する反応として転送される素材のセット。この転送には、例えば、元のサーバとユーザーエージェントの間の転送などがある。
注： この用語は、Glossary of Terms for Device Independenceからそのまま引用した。
この達成基準の目的は、ユーザーのニーズに最も合うかたちで、ユーザーがコンテンツを探し出せるようにすることである。ユーザーは、他よりもある一つのテクニックのほうがより容易あるいはより分かりやすく使えると考えるかもしれない。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 2.4.2を満たすのに十分であると考える。
以下のうち2つを選択すること:
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
複数の手段でサイトをナビゲートできるようにすることは、人が情報をより早く探し出せるのに役立つ。視覚障害のある人は、スクリーンリーダーあるいは画面拡大ソフトを使いながらナビゲーションバーをスクロールするよりも、検索機能を使ってサイト内のコンテンツを収集していくほうが簡単だと思うだろう。認知障害のある人は、幾つかのデリバリーユニットを読んで行き来するよりも、サイトの概観を提供する目次やサイトマップを好むことがある。中には、コンセプトとレイアウトを最もよく理解するために、デリバリーユニットからデリバリーユニットへと移動しながら、サイト内を順序良く回るのを好むユーザーもいるかもしれない。
検索メカニズム
ある大手食品加工メーカーが、その製品を用いて作られたレシピのあるサイトを提供している。そのサイトには、特定の材料を使ったレシピを検索するメカニズムが提供されている。加えて、様々なカテゴリの食品を一覧にしたリストボックスも提供している。ユーザーは、そのメーカーのスープ製品で作られたレシピのリストのあるページへ行くのに、検索キーワードに "スープ" と入力するかもしれないし、あるいはリストボックスから "スープ" を選択するかもしれない。
デリバリーユニット間のリンク
ある地方のヘアーサロンがそのサービスを紹介するWebサイトを作った。そのサイトには、たったの5つのデリバリーユニットしかない。各デリバリーユニットには、デリバリーユニット間を順番に行き来するための「次へ進む」、「前に戻る」というリンクがある。加えて、各デリバリーユニットには、その他のデリバリーユニットへ移動するためのリンクが一覧になっている。
コンテンツが一連のプロセスやタスクの結果である場合 - 電子振替の確認画面:
あるオンラインバンキングのサイトでは、Webで口座間の電子振替が可能である。口座の持ち主が振替を完了するまで、電子振替の確認画面が出てくることはない。
コンテンツが一連のプロセスやタスクの結果である場合 - 検索結果ページ:
ある検索エンジンは、ユーザーの入力に応じた検索結果を提供している。検索行為自体を行わないかぎり、その検索結果ページが出てくることはない。
National Center for Accessible CurriculumのGraphic Organizers（英語）ページは、様々なGraphic organizerの役立つ概要に加えて、学習障害のある学生にとってのGraphic organizerの効果に関連した調査の要約も提供している。
2.4.3
複数の知覚可能なユニットで繰り返されているコンテンツのブロックは、無視できるように実装されていること。(レベル 2)
Blocks of content that are repeated on multiple perceivable units are implemented so that they can be bypassed. (Level 2)
ユーザーエージェントが、デリバリー・ユニットのコンテンツをレンダリングした結果。ユーザーエージェントは、デリバリーユニットの中にある情報をすべてレンダリングすることもあれば、しないこともある。場合によっては、1つのデリバリー・ユニットが、複数の知覚可能なユニットとして提示されることもある。例えば、1セットのプレゼンテーション用スライドとしてレンダリングされる1つのHTMLファイルが該当する。ほとんどの知覚可能なユニットには、プレゼンテーションとインタラクションのための手段が含まれている。しかし、プリンターなどの機器では、知覚可能なユニットはプレゼンテーションしか含んでいない。
この達成基準の意図は、コンテンツを順番にナビゲートしているユーザーがデリバリーユニットの主要なコンテンツによりダイレクトにアクセスできるようにすることである。Webページやアプリケーションは、他のページあるいは画面にも表示されるコンテンツを有することがよくある。コンテンツの繰り返されるブロックの例としては、これらに限られないが、ナビゲーションリンク、ヘッダー部分の画像、そして広告用のフレームなどが挙げられる。
画面を見ているユーザーが画面の中央（通常、メインコンテンツが表示される部分）に意識を集中したり、マウスを使用しているユーザーが目的のアイテムの前にあるリンクやフォームのコントロールに煩わされずに1回のマウスクリックであるリンクを選択したりできるのとは大違いである。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 2.4.3を満たすのに十分であると考える。
技術特有のテクニックを用いて、ブロックをスキップするリンクを提供し、以下に挙げるテクニックのうち1つを用いて、繰り返される部分をスキップする
注： (注意：これらのリンクは目に見えるのが望ましい)
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
技術特有のテクニックを用いて、メインコンテンツの後に繰り返される情報のブロックを提供するようにコンテンツを配置する（これは、ユーザーにナビゲーション部分に素早く移動できる手段を提供する必要があるかもしれない）
この達成基準が満たされないと、障害のある人がWebページのメインコンテンツに素早く簡単に辿り着くことが困難になることがある。
同じサイトで幾つかのページを訪れるスクリーンリーダーのユーザーは、メインコンテンツが読み上げられる前に、各ページで全てのヘッダーのグラフィックやナビゲーションのリンクを沢山聞かなければならなくなる。
キーボードあるいはキーボード・インターフェースだけを使用している人は、メインコンテンツ部分のリンクに辿り着くまでに沢山のキーストロークをしなければならない。
People who use screen magnifiers can do not have to search through the same headers or other blocks of information to find the other side where the content begins each time then enter a new page.
ある報道機関のWebサイトには、たくさんの広告や検索、その他のサービスなどのサブメニューに囲まれたページの真ん中にメインコンテンツがある。ページの先頭には、メインコンテンツへジャンプするリンクがある。このリンクを使わないと、キーボードユーザーはメインコンテンツに辿り着くのに40くらいのリンクをタブ移動する必要があり、スクリーンリーダーのユーザーは200語を聞かなければならず、 画面拡大ソフトユーザーはメインコンテンツ部分の場所を探し回らなくてはならなくなる。
2.4.4
デリバリーユニットにタイトルが付けられていること。 (レベル 2)
Delivery units have titles (Level 2)
2つの連携するWebプログラムの間で、1つのHTTPリクエストに対する反応として転送される素材のセット。この転送には、例えば、元のサーバとユーザーエージェントの間の転送などがある。
注： この用語は、Glossary of Terms for Device Independenceからそのまま引用した。
タイトルは、ユーザーがコンテンツを探し出し、コンテンツ内で自分の現在位置を確認するのに役立つ。タイトルは、ユーザーがページのコンテンツを読んだり解釈したりしなくても、現在位置を特定する。タイトルがサイトマップあるいは検索結果の一覧に表示されたとき、ユーザーは自分が探しているコンテンツをより素早く特定することができる。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 2.4.4を満たすのに十分であると考える
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
これらのテクニックは、全てのユーザーの役に立つ。文章を読むのが遅くなる障害のある人や短期記憶が限られている人には特に役に立つ。両手を使うのが困難な人あるいは両手を使うのに痛みを伴う人は、自分の求めているコンテンツに辿り着くのに必要なキーストロークの回数を減らすテクニックの恩恵を受ける。
事例 1: Webページにタイトルが付けられている：「スモールビル高校Webサイト」
事例 2: アプリケーションの各フレームにタイトルがある：「ナビゲーションバー」、「イベント情報」、「スポーツの最新結果」
Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen Readers（英語）. Theofanos, M.F., and Redish, J. (2003). Interactions, Volume X, Issue 6, November-December 2003, pages 38-51, http://portal.acm.org/citation.cfm?doid=947226.947227
2.4.5
他のデリバリーユニットあるいは同一のデリバリーユニット内で他の位置へのプログラム的な参照は、それぞれの参照先を説明するテキストと関連付けられていること (レベル 2)
Each programmatic reference to another delivery unit or to another location in the same delivery unit, is associated with text describing the destination. (Level 2)
2つの連携するWebプログラムの間で、1つのHTTPリクエストに対する反応として転送される素材のセット。この転送には、例えば、元のサーバとユーザーエージェントの間の転送などがある。
注： この用語は、Glossary of Terms for Device Independenceからそのまま引用した。
Editorial Note: The working group is not sure how close the "association" between the text and the destination should be. On one hand, if you have a page with a list of book titles with links saying WORD, PDF, HTML, and TEXT following each title, it seems logical that having the title next to the row of links would be better than repeating the title in each of the links. It would be better for people who look at the page and better for someone reading down the page with a screen reader looking for a book title and then selecting the type. On the other hand, allowing "text next to a link" to suffice for 'associated' would allow one to say "for more information" next to a link labeled "click here". This can lead to a page of 'click here' links and that is not seen as desirable.
Is there a rule or wording for the success criterion that allows one but not the other?
How big is the problem?
Would requiring that all links contain full information about their destination (without reading any surrounding text) be overly restrictive or not?
Should links be required to make sense when read out of context? (Or is this requiring that pieces of content need to make sense when removed from the rest of the content?)
注： Jumping between links or listing the links on a page is a common navigation technique.
Comments invited.
この達成基準の意図は、ユーザーにリンク先を知らせることで、それによりユーザーはそのリンク先へ移動するかどうかを判断できるようになる。リンクの良い説明は、ユーザーがリンク先のページを解釈するのを助けることで、サイト内でのユーザーの誘導を改善する。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 2.4.5.
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
この達成基準は、自分が興味のないデリバリーユニットをスキップして、関連コンテンツを閲覧して戻ってくるのに必要なキーストロークを避けることができるので、運動障害のある人の役に立つ。
認知障害のある人は、興味のないコンテンツへの余分なナビゲーションで混乱することもないだろう。
視覚障害のある人は、元のページに戻ってきたときに自分の現在位置を見失うことがなくなる。リンク先が説明されているので、スクリーンリーダーのリンク一覧機能は、情報を探し出すのにより使えるものになる。
リンクの前にそのURLにある情報の説明テキストがある
"投票に行こう！"のリンクの前に、"アイルランドの電子投票委員会についての詳細"
リンクにプログラム的に関連付けられているメタデータがリンク先に関する補足情報を提供している
リンクのラベルには、"電子投票に関する委員会" とある。加えて、"アイルランド政府の電子投票に関する委員会のWebサイト" という説明がリンクと関連付けられている。
アイコンとテキストの両方が同じリンクに含まれている
投票機のアイコンと"アイルランド政府の電子投票に関する委員会" というテキストがセットで一つのリンクになっている。
書籍名のリスト
書籍名のリストが3つのフォーマットで提供されている：HTML、PDF、そしてMP3（書籍を読んでいる人の録音）。各書籍名を3回繰り返して聞くのを避けるために（各フォーマットごとに1回）、各書籍の最初のリンクは書籍名で、2つ目は「PDF」、3つ目は「MP3」となっている。
2.4.6
タイトルおよび見出しが説明的であること (レベル 3)
Titles and headings are descriptive. (Level 3)
この達成基準の意図は、デリバリーユニットにどんな情報があるのか、そしてその情報がどのように構成されているのか、をユーザーが理解するのを助けることである。タイトルおよび見出しが明確で説明的であれば、ユーザーは自分の探している情報を見つけやすくなり、そしてユーザーはコンテンツの各部分の関係性をより容易に理解できるようになる。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 2.4.6を満たすのに十分であると考える。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
説明的なタイトルは、文章を読むのが遅くなる障害のある人や短期記憶が限られている人に特に役に立つ。セクションのタイトルで各セクションに何があるのかを予見できると、これらの人のためになる。
両手を使うのが困難な人あるいは両手を使うのに痛みを伴う人は、自分の求めているコンテンツに辿り着くのに必要なキーストロークの回数を減らすテクニックの恩恵を受ける。
この達成基準は、タイトルと見出しが前後関係に関係なく意味のある記述であれば、スクリーンリーダーのユーザーのためになる。例えば、目次あるいはページ内で見出しから見出しへジャンプするときなどである。
また、この達成基準は、一度に数語しか見ることのできない弱視のユーザーのためにもなる。
ニュースサイト
ニュースサイトのHOMEページに、その時点でのトップニュースの見出しが一覧になっている。各見出しの下には、記事の冒頭部分35語と全文へのリンクがある。各見出しは記事の主題を明確に伝えている。
文章の書き方ガイド
ライティングに関するガイドには、以下のようなセクションタイトルがある：上手な文章の書き方、無駄な言葉を省く、不要な言葉を探す、など。セクションの見出しは、明快で簡潔であり、見出しの構造は情報の構造を反映している。
事例 3: 異なる記事での一貫性ある見出し
Webページの集合体によくあるスタイルで記事がある。記事は各セクションには同じ見出しを用いているが、Webページのタイトルはセクションのトピックをわかりやすくしている。
例えば、Webサイトにはカンファレンスの論文がある。カンファレンスに論文を提出するには、以下の構造担っている必要がある：要約、はじめに、...この論文特有のセクション...、結論、作者略歴、用語説明、そして参考文献。
Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen Readers（英語）. Theofanos, M.F., and Redish, J. (2003). Interactions, Volume X, Issue 6, November-December 2003, pages 38-51, http://doi.acm.org/10.1145/947226.947227
Writing Better Web Page Titles How to write titles for web pages that will be more effective for use with search engines.
Methods for Designing Usable Web Sites Methods for collecting, writing, and revising web content to make it easy to use.
How Users Read on the Web A study showing that most users scan web pages rather than reading them word by word.
Applying Writing Guidelines to Web Pages A report on the effects of making web sites concise, easy to scan, and objective.
2.4.7
ページやその他のデリバリーユニットが順番にナビゲートされる場合は、コンテンツの関係や順序に従った順番で、各要素にフォーカスが当たるようになっていること。(レベル 3)
When a page or other delivery unit is navigated sequentially, elements receive focus in an order that follows relationships and sequences in the content. (Level 3)
2つの連携するWebプログラムの間で、1つのHTTPリクエストに対する反応として転送される素材のセット。この転送には、例えば、元のサーバとユーザーエージェントの間の転送などがある。
注： この用語は、Glossary of Terms for Device Independenceからそのまま引用した。
この達成基準の意図は、ユーザーがコンテンツ内を連続的にナビゲートしているとき、コンテンツ内の論理的関係を反映した順序で情報を提供することである。ユーザーに一貫したコンテンツのメンタルモデルを形成させることで、混乱を軽減することになる。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 2.4.7を満たすのに十分であると考える。
Webコンテンツは連続したナビゲーションをサポートしなければならないことがある。例えば、キーボードあるいはキーボード・インターフェースを用いてオンラインフォームを入力するユーザーは、フォーム上のある入力項目から次の項目へ移動するのにTabキーをよく使っている。ユーザーがTabキーを押すたびに、他の要素がフォーカスを受け取る（つまり、ユーザーの次のアクションがフォーカスのあたるアイテムに影響を及ぼす）。場合によっては、デフォルトの順序が論理的でないために、どのアイテムがフォーカスを受け取るかという順序を特定する必要のあることがある。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
これらのテクニックは、ドキュメントを順番にナビゲートして、タブ順序が音声読み上げ順序と一致していると予想しているユーザーのためになる。視覚障害のある人、あるいは文字を読むのが困難な人は、タブ順序で予想しないところにフォーカスがあたると混乱してしまう恐れがある。
達成基準を満たせなかった結果: オンライン申込フォーム
ある企業のWebサイトにマーケティング・データを収集するフォームがあり、ユーザーがその企業の発行する幾つかのニュースレターの購読申込ができるようになっている。フォームには、名前、住所、市区町村、県、郵便番号など、よくある入力項目がある。また、ユーザーが購読したいニュースレターを選択するためのチェックボックスもある。画面拡大ソフトを使用している人は、名前と住所を入力して、次は市区町村を入力すると予想してTabキーを押す。しかし、実際には、ニュースレター名の横にあるチェックボックスにフォーカスが移動する。画面を拡大しているため、ニュースレターのタイトルの一部しか見えず、ユーザーは何が起こったのか理解できない。アドレスを入力してフォームを送信すると、複数の必須項目が入力されていないというエラーメッセージが出て、ユーザーは驚いた。
2.4.8
1組のデリバリーユニット内で、ユーザーの現在位置を示す情報が提供されていること(レベル 3)
Information about the user's location within a set of delivery units is available. (Level 3)
2つの連携するWebプログラムの間で、1つのHTTPリクエストに対する反応として転送される素材のセット。この転送には、例えば、元のサーバとユーザーエージェントの間の転送などがある。
注： この用語は、Glossary of Terms for Device Independenceからそのまま引用した。
この達成基準は、ユーザーにWebサイトあるいはWebアプリケーション内での現在位置を確認するとともに関連する情報を見つける手段を提供することである。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 2.4.8を満たすのに十分であると考える。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
この達成基準は、延々と続くナビゲーションのステップを追っていくと混乱してしまうことのある、短時間しか集中できない人のためになる。また、ユーザーがWebサイト内の階層の深いページへの直接のリンクを辿ってそのサイトをナビゲートする必要のあるときには、そのページのコンテンツを理解するか、関連する情報をより多く見つけることが役に立つ。
ユーザーがサイト内での現在位置を把握するのを手助けするリンク
その研究グループは、ある大学の教育学部に属している。そのグループのWebサイトは、学部と大学のWebサイトにそれぞれリンクしている。
パンくずリスト
あるポータルサイトが、話題をカテゴリで分類している。ユーザーがカテゴリとサブカテゴリをナビゲートしていると、パンくずリストがカテゴリの階層構造での現在位置を示す。また、各ページにはカテゴリのトップページへのリンクもある。
2.5.1
入力エラーが見つかった時は、エラーが指摘され、ユーザーにテキストで示されること。(レベル 1)
If an input error is detected, the error is identified and described to the user in text. (Level 1)
ユーザーが提供したが受け取られないあらゆる情報。以下のようなものが挙げられる。
デリバリーユニットにより要求されたが、ユーザーが省略した情報
ユーザーにより提供されたが、そのデータのフォーマットあるいは値が要求に沿っていない情報
この達成基準は、ユーザーがエラーが発生したことに気づき、何が問題なのかを判断できるようにすることである。フォームの入力に失敗したようなケースでは、フォームを再び表示してエラー箇所を示すだけでは、ユーザーがエラーが起きたことを認識するには不十分なことがある。例えば、スクリーンリーダーのユーザーはエラー箇所にたどりつくまでエラーが発生したことに気づかないだろう。ユーザーは、単にそのページが機能していないと考えて、そのエラー箇所に気づく前にフォームの入力完了を完全にあきらめてしまうかもしれない。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 2.5.1を満たすのに十分であると考える。
Instructions: Select the situation(s) below that match your content. Beneath it are the option(s) that are known and documented to be sufficient for that situation. For the technology-specific techniques, see the options for the technology you are using listed immediately below.
必須であることを示す情報がないときには、テキストのメッセージを提供する。テキストのメッセージは、必須項目を特定する、あるいは必須項目を示すために用いられている手法を説明する。
ユーザーが要求されたデータ形式あるいは値ではない情報を提供したときに、テキストのメッセージを提供する。そのテキストのメッセージは以下のどれか1つに該当する:
エラーのフィールドを示して、適切なデータ形式あるいは値を説明する
エラーのフィールドを示している手法、および適切なデータ形式あるいは値を記述している手法について説明する
フォームのフィールドで提供されているデータのデータ形式を評価する
フォームのフィールドで提供されているデータを評価する
フォーム上の必須項目を示す
クライアントサイドでチェックしてアラートを出す
クライアントサイドでチェックして、DOMによってエラーテキストを提供する
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
ユーザーが情報を入力したときにエラーメッセージを提供する
各エラー箇所へのリンクを提供して、ユーザーが訂正するのをアシストする
エラーが発生した箇所を反転表示するか、視覚的に強調する
入力エラーの情報をテキストで提供することで、全盲、色弱、あるいは学習障害のあるユーザーがエラーが発生したという事実を認識できるようになる。
フォーム送信でのエラー
航空会社のWebサイトは、ディスカウントチケットの特別なプロモーションを展開している。ユーザーは、名前、住所、電話番号、座席指定、Eメールアドレスなどの個人情報を簡単なフォームに入力する必要がある。フォームの項目のいずれかが入力されなかったり、誤って入力されたりすると、ユーザーに受け付けられなかった入力情報があることを知らせるテキストのメッセージが表示される。また、そのメッセージは、フォームが再度表示されて、2つのアスタリスクで正しくない項目が示されることを伝えている。ユーザーは、前と同じで正しく入力した情報も全て含めて、同じフォームを目にする。ユーザーは2つのアスタリスクの付いたフォームの入力項目を訂正する必要がある。
注： この達成基準は、色あるいはテキストのスタイルでエラーを示してはいけないということを意味しない。単にエラーをテキストを用いて示すように求めている。この例では、2つのアスタリスクが色に加えて用いられている。
2.5.2
入力エラーが見つかり、修正のための提案が分かっているうえ、セキュリティやコンテンツの目的を阻害せずに提案を示すことができる場合は、エラーが指摘され、ユーザーに提案が提供されること。(レベル 2)
If an input error
is detected and suggestions for correction are known and can be
provided without jeopardizing the security or purpose of the content,
the suggestions are provided to the user. (Level 2)
ユーザーが提供したが受け取られないあらゆる情報。以下のようなものが挙げられる。
デリバリーユニットにより要求されたが、ユーザーが省略した情報
ユーザーにより提供されたが、そのデータのフォーマットあるいは値が要求に沿っていない情報
この達成基準の意図は、可能であれば、ユーザーが入力エラーの訂正方法に関する適切な説明を得られるようにすることである。
達成基準 2.5.1は、エラーの通知に関してである。しかしながら、認知障害のある人はそのエラーをどのように修正すればよいのかが分からないかもしれない。視覚障害のある人は、エラーの修正方法を正確に把握することができないかもしれない。フォーム入力に失敗したようなケースでは、ユーザーはエラーが発生したことには気づいていてもそのエラーを修正する方法が分からないために、そのフォームの入力完了をあきらめてしまうことがある。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 2.5.2を満たすのに十分であると考える。
Instructions: Select the situation(s) below that match the input error for a field. Beneath it are the option(s) that are known and documented to be sufficient for suggestions for that error.
その項目が必須であることを示すテキストのメッセージを提供する
データ形式の例を含むテキストのメッセージを提供する、あるいは
データ形式を説明するテキストのメッセージを提供する、あるいは
ユーザーの入力した値と"似た" 値を所定のデータ形式で表すテキストのメッセージを提供する
所定の値のリストを含むテキストのメッセージを提供し、ユーザーの入力した値と"似た"値を反転表示する、あるいは
ユーザーが選択できるように、所定の値のリストをダイアログで示す、あるいは
所定の値を一通り説明するテキストのメッセージを提供する、あるいは
所定の値を一通り説明するテキストのメッセージを提供して、ユーザーの入力した値と"似た"値をそのリストから示す
入力エラーの数、各項目の修正方法、そして先に進むための指示を含むテキストのメッセージを提供する
最初の項目を修正する方法を含むテキストのメッセージを提供する、あるいはコンテンツの中でこの情報を強調する
元のフォームの文脈の中でエラーと修正方法を表示する（例えば、フォームを再表示して、元のフォームの文脈の中で、入力エラーと修正方法をハイライト表示して示す）
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
必須であることを示す情報が提供されていないとき、必須である項目を特定するのに加えて、情報を修正する説明と事例を含める
そのフォーム項目の文脈の中で、各入力エラーの修正方法を繰り返して強調する
ユーザーが修正リストにある各項目からフォーム上の対応する項目へスキップできる手段を提供する
変更が必要なフォーム項目に補足のヘルプを提供する
入力エラーを訂正する方法に関する情報を提供することで、学習障害のあるユーザーがフォームに正しく入力できるようになる。全盲の人あるいは視覚障害のある人は、入力エラーの内容とその守勢方法をより理解しやすくなる。運動障害のある人は、入力した値を変更する必要のある回数を減らすことが出来る。
入力エラー修正のヘルプ
送信がうまくいかなかったoutput from an HTML form（英語）の例。"正しい"入力の中にある入力エラーを説明し、入力エラーを起こした項目のヘルプを提供している。
限定された値からの提案
入力フィールドが、月の名前を入力するように要求している。もしユーザーが "12" を入れると、修正方法が示される。
受け付けられる値のリスト、例えば"次から1つを選択してください: January, February, March, April, May, June, July, August, September, October, November, December"
値に関する説明、例えば、月の名前を入れてください
異なるフォーマットでの入力データの変換: "December" ですか？
2.5.3
法的または金銭的な取引を行うためのフォームで、リモートにあるデータストレージシステムのデータを変更または削除したり、テスト回答を送信したりするフォームの場合は、以下の項目の少なくとも1つが当てはまること。 (レベル 2)
For forms that cause legal or financial transactions to occur, that modify or
delete data in remote data storage systems, or that submit test responses, at
least one of the following is true: (Level 2)
操作を取り消すことができる。
プロセスの次のステップに進む前に、入力エラーのチェックが行われる。
情報を送信する前に、ユーザーが送信内容を確認して修正できる。
ユーザーが提供したが受け取られないあらゆる情報。以下のようなものが挙げられる。
デリバリーユニットにより要求されたが、ユーザーが省略した情報
ユーザーにより提供されたが、そのデータのフォーマットあるいは値が要求に沿っていない情報
この達成基準の意図は、障害のあるユーザーが、失敗した結果としての重大な被害を避けることができるようにすることである。例えば、払い戻し不能の航空券チケットの購入あるいは証券取引口座での株購入注文などは、深刻な結果を伴うトランザクションである。もしユーザーが飛行機旅行の日付を間違えてしまったら、交換することのできない間違った日付の航空券を購入したことになる。もしユーザーが購入する株式数を間違えてしまったら、購入する予定以上の株式を購入したことになる。こういった失敗はどちらもとても高くついてしまう。
障害のあるユーザーは、より失敗しやすいといえるかもしれない。学習障害のある人は数と文字を入れ替えてしまうかもしれないし、運動障害のある人はキーを誤って押してしまうかもしれない。アクションを元の状態に戻すことができるようにすることで、ユーザーは深刻な結果につながる失敗を修正することができるようになる。情報を確認および修正できる手段を提供すれば、ユーザーは深刻な結果につながるアクションをとる前にエラーを発見できる機会を与えることになる。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 2.5.3を満たすのに十分であると考える。
Instructions: Select the situation(s) below that match your content. Beneath it are the option(s) that are known and documented to be sufficient for that situation. For the technology-specific techniques, see the options for the technology you are using listed immediately below.
ユーザーが注文をアップデートしたりキャンセルしたりする可能性があるとき、フォームの送信後に一定の時間を提供する、あるいは
送信する前に、全てのトランザクションを確認して修正できるようにする
消去した情報をリカバリできるようにする、あるいは
本当にその情報を消去したいかどうかを確認するメッセージをユーザーに提供する
ユーザーが送信する前に回答を確認して修正できるようにする、あるいは
最後の送信前に最終確認するよう要求する
「このまま実行しますか？」というメッセージと「OK」ボタン、「キャンセル」ボタンのあるアラートあるいはポップアップを出す
ユーザーが後からログインしなおして、過去のトランザクションを確認してキャンセルできるようにする
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
ユーザーに取り消せないアクションであることを知らせる
ミスによる深刻な結果を回避するための予防手段を提供することで、ミスを起こしやすい障害のあるユーザーのためになる。
注文の確認
ある小売店がオンラインショッピングを提供している。注文が送信されると、注文された商品、各商品の数量、送付先、支払方法を含む注文情報が表示され、ユーザーは注文内容が正しいかどうかを確認することができる。ユーザーは注文を確定させることも変更することもできる。
2.5.4
テキスト入力に対して、文脈に応じたヘルプが提供されていること。(レベル 3)
Context-sensitive help is available for text input. (Level 3)
この達成基準の意図は、ユーザーが失敗するのを避けられるようにすることである。障害あるいは加齢のために、そういったユーザーは障害のないユーザーよりもミスしやすい傾向にあるといえるかもしれない。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 2.5.4を満たすのに十分であると考える。
Instructions: Select the situation(s) below that match your content. Beneath it are the option(s) that are known and documented to be sufficient for that situation. For the technology-specific techniques, see the options for the technology you are using listed immediately below.
各デリバリーユニット上にヘルプへのリンクを提供する、あるいは
ヘルプのバブルを提供する、あるいは
デリバリーユニットでアシスタントによるヘルプを提供する、あるいは
その言語で可能であれば、テキスト入力のスペルチェック機能と修正方法を提供する
所定のデータ形式及び例を提供する
可能であれば、入力されたテキストのバイト数をチェックして、所定のバイト数に自動変換
例えば、日本語の文字には半角と全角の両方がある。もしユーザーが半角文字の代わりに全角文字を入力した場合、サーバサイドのプログラムが全角文字を検知して半角文字に変換する。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
テキスト入力をアシストすることは、フォームやテキスト入力を必要とするところでテキストを入力するのが困難である、文字を書くのに障害のある人とディスレクシアの人のためになる。
加えて、このようなアシストは、加齢によりテキスト入力やマウス操作が同じように困難な人のためにもなる。
オンライン求職アプリケーション
質問の中には、初めての求職者には理解しづらい質問があるかもしれない。各質問の横にあるヘルプへのリンクが、それぞれの説明を提供している。
3.1.1
基本となる自然言語またはデリバリーユニットの言語が、プログラム的に決められていること (レベル 1)
The primary natural language or languages of the delivery unit can be programmatically determined. (Level 1)
言語とは、話し言葉、書き言葉、そして手話など、人が意思伝達をするのに用いるもの。
選択されたベースラインにある技術をサポートしている、支援技術を含むユーザーエージェントによって認識可能であること。
この達成基準の意図は、ユーザーエージェントがテキストおよびその他の言語に関するコンテンツを正確に提供するために必要とする情報を、コンテンツ制作者がデリバリーユニット内に提供することである。支援技術と従来のユーザーエージェントのどちらも、デリバリーユニットの言語が特定できれば、より正確にテキストをレンダリングできる。スクリーンリーダーは正しい発音規則で読み上げることができる。視覚形ブラウザは文字やスクリプトを正確に表示できる。メディアプレーヤーはキャプションを正しく表示できる。結果として、障害のあるユーザーはコンテンツをより理解できるようになるだろう。
"HTML および XHTMLにおける言語の宣言は、文字コードやテキストの方向とは全く関係がない。(…) 言語とスクリプトの間には常に1対1のマッピングがあるわけではなく、そのため方向性も同様である。例えば、アゼルバイジャン語は右から左、そして左から右のどちらでも書くことができる。" （Relationships with character encoding and directionalityより）それゆえ、言語とテキストの方向性を宣言するメカニズムは別々になっている。デフォルトのテキストの方向が左から右であれば、右から左の場合だけその方向を指定する必要がある。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 3.1.1を満たすのに十分であると考える。
説明： まず、あなたのコンテンツに合致する状況を選択する。そのすぐ下にあるのは、その状況に十分であると考えて示されているオプションである。技術特有のテクニックについては、以下に挙げられたあなたの使用している技術に関するオプションを参照のこと。
以下に挙げる技術特有のテクニックを用いて、基本となる自然言語を特定する
以下に挙げる技術特有のテクニックを用いて、テキストの方向を指定して基本となる自然言語を特定する
lang 属性を html 要素に用いる;
lang 属性 および xml:lang 属性を html 要素に用いる (text/htmlとしてのXHTML );
xml:lang 属性を html 要素に用いる (application/xhtml+xmlとしてのXHTML)
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
この達成基準は以下のような人の役に立つ:
スクリーンリーダーあるいはテキストを合成音声に変換するその他の支援技術のユーザー
個々の単語や文章を理解しづらい、学習障害や認知的限界のある人
マルチメディアのキャプションに依存している人
3.1.2
コンテンツに含まれる外国語の文章やフレーズのそれぞれの自然言語が、プログラム的に決められていること (レベル 2)
The natural language of each foreign passage or phrase in the content can be programmatically determined. (Level 2)
注： この要件は、1つの単語あるいはコンテンツの基本となる言語の一部となっているフレーズには適用されない。
外国語の文章やフレーズとは、周囲にあるテキストの言語とは異なる言語で書かれた文章やフレーズのこと。
選択されたベースラインにある技術をサポートしている、支援技術を含むユーザーエージェントによって認識可能であること。
この達成基準の意図は、ユーザーエージェントがデリバリーユニットの第一言語と異なる言語で書かれているコンテンツを正しく提供できるようにすることである。このことは、スクリーンリーダー、点字ディスプレイ、およびその他の音声ブラウザと同様にグラフィカルなブラウザにもあてはまる。
支援技術と従来のユーザーエージェントのどちらも、もしデリバリーユニット内での言語の変化が示されていれば、テキストをより正確にレンダリングできる。スクリーンリーダーは、外国語のテキストの言語にあわせて発音規則を切り替えて、それからその外国語のフレーズや文章が終わったところで第一言語の発音規則に戻すことが可能である。視覚系ブラウザは、文字とスクリプトを適切に表示することができる。ある言語は左から右へ読み、そして他の言語は右から左へ読むとき、あるいは外国語のフレーズや文章が第一言語と異なるアルファベットを用いているときなどには、これは特に重要なことである。そのデリバリーユニット全体の言語と同様に外国語の文章やフレーズで使われている言語も知っている障害のあるユーザーは、そのコンテンツをよりよく理解できるだろう。
この要件は、単独の単語あるいはコンテンツの第一言語の一部になっているフレーズには適用されない。例えば、"rendezvous"というフランス語の単語は、英語として採用され、英語の辞書にも登場しており、英語版のスクリーンリーダーでも正しく発音される。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 3.1.2を満たすのに十分であると考える。
説明： まず、あなたのコンテンツに合致する状況を選択する。そのすぐ下にあるのは、その状況に十分であると考えて示されているオプションである。技術特有のテクニックについては、以下に挙げられたあなたの使用している技術に関するオプションを参照のこと。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
スクリーンリーダーあるいはテキストを合成音声に変換するその他の支援技術のユーザー
個々の単語や文章を理解しづらい、学習障害や認知的限界のある人
マルチメディアコンテンツの音声トラックでの言語の変化を認識するのにキャプションに依存している人
英語の文章中にあるドイツ語のフレーズ
以下の文章 "He maintained that the DDR (German Democratic Republic) was just a 'Treppenwitz der Weltgeschichte'." で、ドイツ語のフレーズ 'Treppenwitz der Weltgeschichte' は、ドイツ語としてマークされている。マークアップ言語によって、英語は指定箇所以外はドキュメント全体の言語としてマークされているか、段落のレベルでマークされている。スクリーンリーダーがドイツ語のフレーズに出くわすと、その単語を正しく発音するために、発音規則を英語からドイツ語へと変更する。
Language tags in HTML and XML - W3C Internationalization Working Group
HTML 4.0 Block-Level Elements - Liam Quinn (1998)
HTML 4.0 Inline Elements - Liam Quinn (1998)
3.1.3
慣用句や専門用語など、通常ではない、または限られた用法で使われている言葉について、その特定の定義を探すためのメカニズムが提供されていること (レベル 3)
A mechanism is available for identifying specific definitions of words used in an unusual or restricted way, including idioms and jargon. (Level 3)
結果を得るためのプロセスあるいはテクニック
ユーザーがコンテンツを正しく理解するためにどの定義が適用されるかを知っていなければならないような用法で使われている用語。例えば、"representational"という単語は、もしビジュアル・アートの議論で使われるときには、政府に関する論文で使われるときとは全く異なる意味を持つが、文脈から適切な定義は自ずと決まってくる。それに反して、"text"という単語は、WCAG 2.0ではとても限定された用法で使われており、用語集でその定義が提供されている。
地域や言語に特有で、個々の単語の辞書での定義そのままを意味しない語句あるいはフレーズ。例えば、英語の"he blew his stack"は、ある人がとても怒ったことを意味する。
特定分野の人により特有の用法で用いられる語句。例えば、Stickkeys という単語は、支援技術/アクセシビリティの分野の専門用語である。
特定の障害は、文字通りではない単語およびある専門分野に特化した単語あるいは使用法を理解するのを困難にする。特定の障害は、比喩的な言語あるいは専門分野に特化した用法を理解するのを困難にする。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 3.1.3を満たすのに十分であると考える。
以下に挙げるリストから少なくとも1つ、あるいは技術特有のテクニックから1つを用いて、単語の定義を提供する。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
（現在作成中）
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
この達成基準は、理解するのに文脈を用いる能力に影響のあるユーザーのためになる。学習障害および認知障害のある人が含まれる。さらに、弱視の人は、画面拡大ソフトが画面上の小さいエリアを拡大していると、文脈を見失うことがよくある。また、この達成基準は、その文脈に合う定義を見つけるために必要とする辞書登録語彙を限定することで、単語を認識するのが困難な人や単語の意味を記憶するのが困難な人のためにもなる。
一般的でない使われ方の単語の定義を含むテキスト
"カスケード"における他のリソースから定義を表示する代わりに、定義検索で意図した定義を見つけるように、リストあるいは辞書や他のリソースの "カスケード" を構成する。（"カスケード" は、適切な定義が上に来るような順序で辞書と他のリソースを一覧にする。これは、定義を検索するときの順序を制御する）。
用語集に定義を入れる
WCAG 2.0 は、"テキスト" を特別な用法で用いている。WCAG 2.0 で"テキスト" という単語が用いられているときには、同じデリバリーユニット内にある用語集の"テキスト"のi定義にリンクされている。
単語の特別な定義がページの下部で提供されている
単語からそれに対応する定義へのページ内リンクもページ内で提供されている。
注： 以下のリストにある製品名あるいはメーカー名は、WCAG ワーキンググループあるいはW3CのWAIによる推薦を意味するものではない。このリストは、単に便宜上のものであり、ユーザーにどんなリソースが入手可能かを示すためのものである。
数多くの言語の二ヶ国語辞書が無償で Freedict.org Web siteにて提供されている。サイト上で明記されているように、各辞書の質や量はまちまちである（2005年4月9日）。
The WorldStar Free Dictionaries, Translators and Search Engines のサイトは、多くの言語でのオンライン辞書および検索エンジンを無償で提供している（2005年11月18日）。
他にも、 your dictionary, freelang.com (英語、スペイン語、フランス語) などがある。
3.1.4
省略語の省略されていない正式な言葉を探すためのメカニズムが提供されていること (レベル 3)
A mechanism for finding the expanded form of abbreviations is available. (Level 3)
この達成基準の意図は、ユーザーが略語の拡張形（省略する前の元の状態）にアクセスできるようにすることである。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 3.1.4を満たすのに十分であると考える。
以下に挙げたテクニックの1つを用いて、略語の元の状態を提供する:
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
(現在作成中)
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
この達成基準は、文字を読むのが困難あるいは全く出来ない人のためになる。以下の人たちを含む。
読解力を弱める学習障害あるいは認知的限界のある人
弱視の人。画面拡大ソフトは文脈上の手がかりを減少させることがある。
記憶障害のある人
この達成基準は、理解を進めるのに文脈を用いる能力と同様に単語を認識する能力にも影響のあるユーザーの役にも立つ。頭字語や省略語は、これらの読者も異なるかたちで困惑させることがある:
省略語の中には、普通の単語のように見えなくて、その言語の通常の規則では発音できないものがある。例えば、英語の単語 "room" は "rm," と省略され、英語の単語あるいは音素に対応していない。ユーザーは、正しく読むために、"rm" が"room" の省略語であることを知る必要がある。
時々、同じ省略語が異なる文脈において異なるものを意味することがある。例えば、英語の文章 "Dr. Johnson lives on Boswell Dr." では、最初の "Dr." は "Doctor" の省略語であり、2つ目は "Drive" ("street"を意味する)という単語の省略語である。ユーザーは、その省略語が何を意味するのかを知るためには文脈を理解できなくてはならない。
頭字語には、よくある単語と同じスペルだが、異なる用法で用いられるものがある。例えば、"JAWS" は "Job Access with Speech" というフルネームのスクリーンリーダーの頭字語である。また、あごを指す英語の単語でもある。頭字語は、通常の単語とは使われ方が異なる。
頭字語には、よくある単語と同じように発音するがスペルが異なるものがある。例えば、Synchronized Multimedia Integration Language の頭字語 S M I L は英語の単語 "smile" のように発音する。
辞書検索フォーム
Webサイトにオンライン頭字語サービス提供の検索フォームがある。ユーザーが頭字語を入れると、フォームは可能性のある元の言葉のリストを表示する。
医療系Webサイト
医療系のWebサイトが、医者と患者の両方に情報を提供している。そのサイトには、非常に特化した医学辞書が一番目で、一般大衆向けの医学辞書が二番目のカスケード式の辞書がある。そのカスケードには、そのサイト特有の頭事後および省略語のリストがあり、さらに最後にはスタンダードな辞書もある。リストの最後にあるスタンダードな辞書は、テキストにあるほとんどの単語の定義を提供する。特化した医学辞書は、一般的でない医学用語の定義を与える。複数の辞書に出てくる単語の定義が、カスケードの並びで一覧になっている。頭字語および省略語の意味は、頭字語および省略語のリストにより提供されている。
コンテンツでの初出箇所に省略語の元の形が提供されている
"World Wide Web Consortium" という名前は、その組織のWebサイトで最初の見出しとして登場する。その省略語である "W3C" が同じ見出しの中で括弧で括られている。
Acronym finder（英語） - you can search with the exact acronym, the beginning of the acronym, wildcards and reverse lookup
The Opaui Guide to Lists of Acronyms, Abbreviations, and Initialisms on the World Wide Web（英語）
AbbreviationZ - The A to Z of Acronyms & Abbreviations on the Net（英語）
3.1.5
テキストが中等教育レベル以上の読解力を必要とする場合、以下のうち少なくとも1つ以上の補足コンテンツが提供されていること。(レベル 3)
When text requires reading ability more advanced than the
lower secondary education level, one or more of the following types of supplemental content is available: (Level 3)
中等教育レベルを超える読解力を必要としないテキストのサマリー
そのコンテンツを使用するために理解しなければならない概念または手順の図解
そのテキストコンテンツの話し言葉のバージョン
テキストコンテンツを図解にしたり分かりやすく説明する追加のコンテンツで、ユーザーはテキストコンテンツに代えて、またはそれに加えて利用する。例えば、テキスト、グラフィック、そして音声による補足がありえる。
この達成基準の意図は以下の通りである。
この達成基準は、コンテンツ制作者には難解又は複雑なWebコンテンツの公開を可能にしながらも、読字障害のある人の助けとなる。テキストの難しさは、そのテキストを読むのに要求される教育レベルという観点から説明されている。教育レベルに関しては、教育システムの国際間比較を可能にするために作成された"International Standard Classification of Education (UNESCO 1975, 1997)"に従って定義されている。
難解又は複雑なテキストが想定しているユーザー層のほとんど（つまり、そのコンテンツが制作された対象者のほとんど）にとって適切な場合もある。しかし、特定の事柄に関する専門知識を有する高等教育を受けたユーザーの中にも、読字障害を含めて、障害のある人がいる。テキストをより読みやすくすることで、そういったユーザーにも対応することが可能になるだろう。テキストをより読みやすくすることができない場合は、補足説明するコンテンツが必要となる。
補足説明するコンテンツが必要とされるのは、テキストが中等教育レベル以上（つまり、9年以上の学校教育）の読解力を要求するときである。そのようなテキストは、読字障害のある人にとっては重大な障壁となり、また高等学校を卒業した障害のない人にとっても難しいとされる。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 3.1.5を満たすのに十分であると考える。
説明： まず、あなたのコンテンツに合致する状況を選択する。そのすぐ下にあるのは、その状況に十分であると考えて示されているオプションである。技術特有のテクニックについては、以下に挙げられたあなたの使用している技術に関するオプションを参照のこと。
テキスト・コンテンツが状況Aあるいは状況Bのどちらに該当するかを、
テキスト・コンテンツの読みやすさ（Readability）を測定して判断する
補足するコンテンツを含めない
(現在作成中)
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
(現在作成中)
この達成基準は、極めて読みやすいテキスト、あるいは関係とプロセスを描写したグラフィックまたは話し言葉のような他の手段で、複雑な考えやプロセス読字障害のある人のためになる。
ディスレクシアのような読字障害は、個々の単語を認識する能力に影響を及ぼす。人が流暢に読むためには、解読は自動的でなければならない。テキストを単語ごとに解読する行為は、ほとんどの人が読んでいるものを理解するのに費やすことの出来る精神的なエネルギーの多くを消費する。
難解な研究論文の読みやすい要約がある科学雑誌
科学雑誌には、その分野の専門家を対象にした、極めて技術的な用語で書かれた論文がある。その雑誌の目次ページには、各論文の平易な要約がある。要約は初等教育レベルの一般読者向けに書かれている。その雑誌のメタデータは、ダブリンコアの仕様を用いて、論文の対象読者の教育レベルを "上級" と指定している。そして、要約の対象読者の教育レベルは、"中等教育" としている。
公衆向けの医療情報
ある医学学校は、最近の医療および科学的な発見を説明するWebサイトを運営している。そのサイトの記事は、医学の知識のない人向けに書かれている。各記事は、ダブリンコアの仕様を用いて、想定している読者層を "中等教育" として指定しており、記事の読みやすさのスコアも示してある。各ページのリンクは、教育レベルと他のメタデータを表示する。中等教育レベルの人はその記事を読むことが出来るので、補足説明のコンテンツは必要ない。
E-ラーニング・アプリケーション
スペイン文化の歴史に関するオンライン講座に、ムーア建築に関する単元がある。その単元には、様々な読解能力を持つ生徒向けに書かれたテキストがある。建築物の写真と絵が、建築のコンセプトと様式を示している。Graphic organizerが複雑な関係を示すのに用いられ、合成音声を用いた音声バージョンもある。各バージョンのメタデータは、コンテンツの学術レベルを説明し、スペイン語のテキスト用に開発された計算式に基づいたリーダビリティのスコアを含んでいる。アプリケーションはこのメタデータおよび生徒に関するメタデータを用いて、個々の生徒のニーズに合致する説明コンテンツのバージョンを提供している。
A Plain Language Audit Tool provides a checklist for determining whether documents can be edited for clarity and "plain language." The checklist includes a readability assessment. Available from the Northwest Territories (Canada) Literacy Council at http://www.nwt.literacy.ca/plainlng/auditool/cover.htm（英語）.
The Plain Language Network Web site provides many useful resources to help writers produce documents that communicate clearly in a variety of cultural and rhetorical contexts. Refer to: http://www.plainlanguagenetwork.org/（英語）.
The US government's plain language Web site（英語） provides general information about plain language as well as information about use of plain language in US government documents, including legal requirements
The Plain English Campaign Web site（英語） provides useful information and guidance for authors writing in English.
Hall, T.,and Strangman, N. CAST: Graphic organizers（英語）. Retrieved 5 April 2005. This article illustrates several different kinds of graphic organizers, explains how each type may be useful, and summarizes research findings that graphic organizers support learning, especially among students with learning disabilities.
3.1.6
ページやその他のデリバリーユニットが順番にナビゲートされる場合は、コンテンツの関係や順序に従った順番で、各要素にフォーカスが当たるようになっていること。(Level 3)
When a page or other delivery unit is navigated sequentially, elements receive focus in an order that follows relationships and sequences in the content. (Level 3)
2つの連携するWebプログラムの間で、1つのHTTPリクエストに対する反応として転送される素材のセット。この転送には、例えば、元のサーバとユーザーエージェントの間の転送などがある。
注： この用語は、Glossary of Terms for Device Independenceからそのまま引用した。
この達成基準の意図は、ユーザーがコンテンツ内を連続的にナビゲートしているとき、コンテンツ内の関係を反映した順序で情報を提供することである。ユーザーに一貫したコンテンツのメンタルモデルを形成させることで、混乱を軽減することになる。
連続的なナビゲーションをサポートしているWebコンテンツがある。例えば、オンラインフォームの入力を完了させるためにキーボードあるいはキーボード・インターフェースを使用しているユーザーは、フォーム上のある要素から次のアイテムへ移動するためによくTabキーを用いる。ユーザーがTabキーを押すたびに、他の要素がフォーカスを受け取る（つまり、ユーザーの次のアクションがフォーカスのあたっている要素に影響を及ぼす）。場合によっては、デフォルトの順序が論理的でないために、どのアイテムが次にフォーカスを受取るべきかを指定する必要があるかもしれない。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 3.1.6を満たすのに十分であると考える。
技術特有のテクニックを用いて、コンテンツ内の配列と関係に従ったタブ順序を定義する。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
これらのテクニックは、ドキュメントを順番にナビゲートして、タブ順序が音声読み上げ順序と一致していると予想しているユーザーのためになる。視覚障害のある人あるいは文字を読むのが困難な障害のある人は、タブ順序が予想しなかった状態になると混乱してしまう恐れがある。
事例 1. 全盲のユーザーは、スクリーンリーダーを使って、インタラクティブなフィールドのあるページを読んでいる。
ページのコンテンツでの位置を見定めると、インタラクティブなフィールドをタブで移動する。アクティブではないフィールドがあるため、全てのフィールドがタブ順序に現れるわけではない。しかしながら、タブで移動したフィールドの順序は、読み上げたときの順序と一貫性がある。
3.2.1
どのコンポーネントにフォーカスが当てられても、状況の変化が起こらないこと
When any component receives focus, it does not cause a change of context. (Level 1)
注： 全ての機能をキーボード・インターフェースで操作可能にする要件については、 Make all functionality operable via a keyboard interface.: を参照のこと。
ユーザー・エージェント、表示域、あるいはフォーカスの変化。または、デリバリーユニットの意味を変えるコンテンツの完全な変化。
注： コンテンツの変化は、常に状況の変化とはならない。外形の拡大あるいは動的なメニューのようなコンテンツにおける小さな変化は状況を変化させることはない。
この達成基準の意図は、訪問者がドキュメントをナビゲートしている時に、機能が予測可能であるようにすることである。フォーカスを受け取ったときにイベントを始動させるあらゆるコンポーネントは、状況を変化させてはならない。フォーカスを受け取ったときの状況が変化することの例としては、以下に挙げられるが、これらに限らない。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 3.2.1を満たすのに十分であると考える。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
(現在作成中)
支援技術を使っている視覚障害のある人、ポインティングデバイスを使用するのが困難な運動障害のある人、を含めて、キーボードでナビゲートしている人は、適切な選択をする機会もなく、状況の変化を引き起こすことがある。
認知に困難のある人は、明白なアクションが状況の変化を引き起こしたことに気づかないことがある。
3.2.2
入力欄の設定変更が、自動的に状況の変化を引き起こさないこと(レベル 2)
Changing the setting of any input field does not automatically cause a change of context . (Level 2)
ユーザー・エージェント、表示域、あるいはフォーカスの変化。または、デリバリーユニットの意味を変えるコンテンツの完全な変化。
注： コンテンツの変化は、常に状況の変化とはならない。外形の拡大あるいは動的なメニューのようなコンテンツにおける小さな変化は状況を変化させることはない。
この達成基準の意図は、データの入力あるいはコントロールからの選択が予測可能な結果を生むようにすることである。ラジオボタンの値に基づいて入力フィールドを変化させるような状況の変化は、その変化を知覚しづらいユーザーや変化によって気が散りやすいユーザーを困惑させることがある。状況の変化は、フィールドが選択されたりボタンが押されたりしたときにそのような変化が起こるだろうということが明白なときだけにすべきである。
"利点"を参照のこと。
See Benefits.
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 3.2.2を満たすのに十分であると考える。
送信ボタンを用いて、状況の変化を起こす
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
アイテムが選択されたときに何が起こるかを説明する
ユーザーのアクションに対して、一貫性があり予測可能な反応を提供することは、ユーザーへのフィードバックとして重要です。これは、ユーザーにサイトが正しく動作していることを知らせ、コンテンツを操作し続けるよう促します。ユーザーが予測していなかった反応を受け取ると、何かがおかしいか壊れていると結論付けてしまうことがある。サイトを使うことができなくて、混乱してしまう人もいるかもしれない。
状況の変化を検知できない人、あるいは状況が変化したことを理解できない人は、サイトをナビゲートしている間は混乱することはない。これは、以下のような人に当てはまる。
全盲の人あるいは弱視の人は、新しいウィンドウが開くような、視覚的な状況の変化を知るのが困難なことがある。この場合、事前にユーザーに状況の変化を知らせておくことで、ユーザーが戻るボタンが利かなくなったときに起こす混乱を最小限に留められる。
弱視、ディスレクシアそして視覚的な手がかりを解釈するのが困難な人は、状況の変化を察知するために追加の手がかりが手助けになることがある。
以下に挙げる全てのテクニックは、達成基準3.2.2に反する
以下の達成基準3.2.2に反する事例は、すぐ後にその解決法の提案を示す。:
ページを送信するようなアクションを自動的に起こすフォームのコントロール。別の送信ボタンを用いる。
選択されると、コンテンツをがらりと変化させてしまうフォームのコントロール。別のボタンを使って、コンテンツを変化させるべきである。選択した値に基づいて説明を変化させたり、詳細を表示したりするようなコンテンツへの小さな変化は許容範囲である。
複数の入力すべきフィールドのあるフォームがユーザーに提示されている。送信ボタンは、値を受け入れて状況の変化を起こすために用いられている。
3.2.3
1組のデリバリーユニット内の複数のデリバリー・ユニットで繰り返されているコンポーネントが、繰り返されるたびに必ず同じ相対的な順序で提示されていること。(レベル 2)
Components that are repeated on multiple delivery units within a set of delivery units occur in the same relative order each time they are repeated. (Level 2)
2つの連携するWebプログラムの間で、1つのHTTPリクエストに対する反応として転送される素材のセット。この転送には、例えば、元のサーバとユーザーエージェントの間の転送などがある。
注： この用語は、Glossary of Terms for Device Independenceからそのまま引用した。
それぞれのアイテムは、他のアイテムと相対的な位置を保持する。たとえ、他のアイテムが挿入されたり、または元の並びから削除されたりしたとしても、各アイテムは同じ相対的な順序に並んでいると考えられている。例えば、ナビゲーションメニューを拡張するときには詳細を追加で挿入したり、あるいは二次的なナビゲーション部分が読み上げ順序に挿入される。
この達成基準の意図は、デリバリーユニット一式において繰り返されるコンテンツを操作し、特定の情報あるいは機能の位置を何度も見つける必要のあるユーザーのために、一貫したプレゼンテーションとレイアウトを用いるようにすることです。画面内の小さい一部分を表示するために画面拡大ソフトウェアを使用しているロービジョンのユーザーは、繰り返されるコンテンツの位置を見つけるために、見た目の手がかりやページの境界線を頼りにしている。繰り返されるコンテンツを同じ順序で提示することは、空間記憶あるいはデザインにおける見た目の手がかりを頼りにしている視力のあるユーザーが繰り返されるコンテンツの位置を見つけるためにも重要です。
この達成基準において、"同じ順序"という用語を使用することは、サブナビゲーションを使ってはいけないとか、補助的なナビゲーションあるいはページ構造のブロックを使ってはいけない、という意味ではない。むしろ、この基準はデリバリーユニット中で繰り返されるコンテンツを操作するユーザーが探しているコンテンツの位置を予測できたり、再び出くわしたときにより早くそれに気づくことができるようにするためのものである。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 3.2.3を満たすのに十分であると考える。
(現在作成中)
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
(現在作成中)
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
状況の変化をプログラム的に決められるようにすることで、ユーザーエージェントがユーザーに状況の変化が起ころうとしていることを事前に知らせたり、ユーザーがそれを無効にできたりするようになる。
ユーザーは、リンクあるいは送信ボタンを選択したときに、ユーザーエージェントが状況を変化させる（例えば、新しいページを読み込む）ことを予想する。しかしながら、もし単にWebページをナビゲートしていたり、フォームのフィールドの設定を変更したりしているときに状況が変化すると、ユーザーは驚いて困惑する。驚きと困惑は、全盲あるいは弱視で新しいページが読み込まれていることを見ることはできないが、スクリーンリーダーが突然全く新しいページを読み上げ始めるのを聞くだけのユーザーにとっては、より深刻である。この驚きと困惑は学習障害のユーザーにとってもより深刻なものになりうる。こういった予測しない状況の変化を避けることで、ユーザーを驚かせたり困惑させたりすることを軽減できる。
繰り返されるコンポーネントがサイトの各ページで同じ順序で現れるようにすることで、ユーザーは各ページでどこに何があるのかが予測できるので心地よくさせることができる。これは学習障害のある人のためになり、また全盲の人のためにもなる。
一貫性のある配置のコントロール
ユーザーは、検索フィールドが常にサイト内のページの下部の右角にあることを思い起こすことができる。そのサイト内で沢山のページを閲覧して、探しているものが見つからなかったとき、ユーザーは素早く検索機能を見つけられる。
拡張するナビゲーションメニュー
ナビゲーションメニューに、サイトの主要セクションへのリンクになっている7つのアイテムがある。ユーザーがそのうちの1つを選択すると、サブナビゲーションのアイテム一覧がトップレベルのナビゲーションメニューに挿入される。
一貫して配置されたスキップリンク
スキップリンクがサイト内の全ページ上で最初のリンクとして実装されている。このリンクで、ユーザーはヘッダー情報とナビゲーション要素を素早くスキップして、ページのメインコンテンツを操作し始めることができる。
ナビゲーションリンクへのスキップ
ナビゲーションリンクへのスキップが、ページの最後にあるナビゲーションに対して提供されている。このリンクは各ページの先頭に一貫して配置されており、キーボードユーザーは必要なときに利用できる。
Detweiler, M.C. and Omanson, R.C. (1996), Ameritech Web Page User Interface Standards and Design Guidelines.
3.2.4
1組のデリバリーユニット内の複数のデリバリーユニットで同じ機能を果たしているコンポーネントが、一貫性のあるラベルを有していること (レベル 2)
Components that have the same functionality in multiple delivery units within a set of delivery units are identified consistently. (Level 2)
もし使用した結果が同一であれば、それらのアイテムは同じ機能を持っていると見なされる。例えば、あるデリバリーユニットにある"検索"という送信ボタンと他のデリバリーユニットにある"探す"という送信ボタンには、どちらにもキーワードを入力するフィールドがあって、送信されたキーワードに関連するそのWebサイト内のトピックが一覧表示される。この場合、機能は同じでもラベルが一貫していないことになる。
2つの連携するWebプログラムの間で、1つのHTTPリクエストに対する反応として転送される素材のセット。この転送には、例えば、元のサーバとユーザーエージェントの間の転送などがある。
注： この用語は、Glossary of Terms for Device Independenceからそのまま引用した。
この達成基準は、デリバリーユニット一式の中で繰り返して現れる機能的なコンポーネントに一貫性を持たせて同一であるようにすることです。スクリーンリーダーを使用する人がWebサイトを操作するときに用いる方策は、異なるデリバリーユニットで現れる機能に馴染みがあることに大きく依存している。もし全く同じ機能が異なるデリバリーユニットでは異なるラベルになっていたとしたら、そのサイトは相当に使いづらいものになるだろう。認知障害のある人にとっては分かりにくく、認知にかかる負担も増すことになる。それゆえ、一貫したラベリングが役に立つのである。
この一貫性は、代替テキストもその対象となる。もしアイコンあるいは他の非テキストアイテムが同じ機能を持っていたら、それらの代替テキストも同様であるべきである。
"利点"を参照のこと。
See Benefits.
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 3.2.4を満たすのに十分であると考える。
同じ機能を持つコンテンツに対して、一貫したラベル、名前、そして代替テキストを用いる
注記 1:"一貫した" 代替テキストは常に "全く同じ" であるとはかぎらない。例えば、デリバリーユニットの下部に次のデリバリーユニットにリンクするグラフィックの矢印があるとする。代替テキストは "4ページ目へ行く" となることがある。当然ながら、次のデリバリーユニットでは全く同じテキストを繰り返すのは適切ではないだろう。"5ページ目へ行く" というのが適切である。これらの代替テキストは全く同じではないものの、一貫しており、それゆえこの達成基準を満たすことになる。
注記 2:一つの非テキストコンテンツのアイテムが、異なる機能のために用いられることがある。そのような場合は、異なる代替テキストが必要であり、用いられるべきである。よく見られる例としては、チェックマークや×マーク、交通標識などのアイコンの使用である。それらの機能は、デリバリーユニットの文脈によって異なる可能性がある。チェックマークは、状況によって、"承認済み"、"完了"、あるいは"含まれる" といった機能を示す。全てのデリバリーユニットを通じて、"チェックマーク" という代替テキストを用いることは、ユーザーがそのアイコンの機能を理解する手助けにはならない。同じ非テキストコンテンツが複数の機能に用いられるときには、異なる代替テキストが用いられる可能性がある。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
Failure due to 全く同じ機能を持つコンポーネントに対して異なる代替テキストを用いる
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
代替テキストがコンポーネントの機能およびユーザーがそれを選択すると何が起こるのかを伝えるようにする
ガイドライン 1.1 にある意味のある代替テキストの記述法に関するテクニックを参考にする: http://www.w3.org/TR/WCAG20-GENERAL/text-equiv-informative.html
可能なときは常に特定の機能に対しては同じ非テキスト・コンテンツを用いる
あるサイトの1ページ上の機能を把握した人が、もしあれば他のページ上でもその機能を見つけることができる。
テキストを読むのが困難な人あるいは代替テキストを見つけるのが困難な人が、代替テキストに頼らずにWebを操作できる。
代替テキストに依存している人が、より予測可能なエクスペリエンスを持つことができる。また異なるページでも一貫性のあるラベルを持っていれば、そのボタンを見つけることができる。
事例 1: ドキュメントのアイコン
サイトからダウンロードできるドキュメントを示すために用いられているドキュメントのアイコンがある。ダウンロードできるドキュメントは複数あるため、代替テキストがドキュメントを区別するのに役立つ。この場合、ドキュメントのアイコンはドキュメントをダウンロードするという同じ機能を示している。ドキュメント名を特定した異なる代替テキストを用いることで、代替テキストの一貫性のある使用といえる。
事例 2: チェックマーク
チェックマークのアイコンが、あるページでは「承認済」、またあるページでは「あり」、という意味を持っている。これらは異なる機能なので、異なる代替テキストを持っている。
事例 3: 失敗例
ページ保存機能が複数のデリバリーユニットで手供されているサイト内で、よくある「保存する」アイコンが使われている。
事例 4: 失敗例
あるデリバリーユニットにある「検索」ボタンと他のデリバリーユニットにある「見つける」ボタンは、両方ともテキスト入力フィールドがあり、入力された用語に関連するトピックを一覧にする。この場合、両者は同じ機能でありながら、ラベルに一貫性がないということになる。
3.2.5
状況の変化は、ユーザーのリクエスト主導であること (レベル 3)
Changes of context are initiated only by user request. (Level 3)
ユーザー・エージェント、表示域、あるいはフォーカスの変化。または、デリバリーユニットの意味を変えるコンテンツの完全な変化。
注： コンテンツの変化は、常に状況の変化とはならない。外形の拡大あるいは動的なメニューのようなコンテンツにおける小さな変化は状況を変化させることはない。
この達成基準の意図は、状況の変化はユーザーが全てコントロールできるようにWebコンテンツをデザインすることである。この達成基準は、自動的に新しいウィンドウが開いたり、リストからアイテムを選択したとたんに自動的にフォームが送信されたり、というような予期していなかった状況の変化により引き起こされうる混乱を取り除くことを狙いとしている。そういった予期していなかった状況の変化は、運動障害のある人、ロービジョンの人、全盲の人、そして認知障害のある人に困難をもたらす。
この達成基準により誰にどのような利点があるかについては、さらに以下で説明がある。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 3.2.5を満たすのに十分であると考える。
説明： まず、あなたのコンテンツに合致する状況を選択する。そのすぐ下にあるのは、その状況に十分であると考えて示されているオプションである。技術特有のテクニックについては、以下に挙げられたあなたの使用している技術に関するオプションを参照のこと。
自動的なアップデートについて:
自動的なリダイレクトについて:
ポップアップウィンドウについて:
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
もしサーバサイドのリダイレクトを使えない場合は、自動的なリダイレクトを次の方法で実装する。
新しいウィンドウを開くには、
リンクが新しいウィンドウで開くことを示しながら、
スクリプトの代わりにtarget 属性を用いる
、あるいは
多くのユーザーエージェントはユーザーが新しいウィンドウあるいはタブでリンク先を開けるようにしているので、
target 属性を使わずに普通のハイパーリンクを提供する
状況の変化を検知できない人、あるいは状況が変化したことを理解できない人は、サイトをナビゲートしている間は混乱することはない。これは、以下のような人に当てはまる。
全盲の人あるいは弱視の人は、新しいウィンドウが開くような、視覚的な状況の変化を知るのが困難なことがある。この場合、事前にユーザーに状況の変化を知らせておくことで、ユーザーが戻るボタンが利かなくなったときに起こす混乱を最小限に留められる。
弱視、ディスレクシアそして視覚的な手がかりを解釈するのが困難な人は、状況の変化を察知するために追加の手がかりが手助けになることがある。
認知障害のある人は、もし自動的なリダイレクトがブラウザではなくWebサーバで実行されれば、困惑することはない。
「今アップデートする」ボタン
自動的にコンテンツを更新する代わりに、コンテンツの更新をリクエストする"今アップデートする"ボタンを提供する。
自動リダイレクト
リダイレクトされたことに気づかないような方法で、ユーザーは旧いページから新しいページへ自動的にリダイレクトされる。
4.1.1
デリバリーユニットは、曖昧なところなく構文解析されて、その結果得られるデータの構造における関係もはっきりとしていること (Level 1)
Delivery units can be parsed unambiguously and the relationships in the resulting data structure are also unambiguous. (Level 1)
2つの連携するWebプログラムの間で、1つのHTTPリクエストに対する反応として転送される素材のセット。この転送には、例えば、元のサーバとユーザーエージェントの間の転送などがある。
注： この用語は、Glossary of Terms for Device Independenceからそのまま引用した。
構文分析により、マークアップあるいはその他のソースコードはデータ構造化、通常は後の処理に適したツリー構造に変換され、インプットしたデータの暗示された階層を捉える。曖昧なところなく構文解析するというのは、結果として得られるデータ構造は唯一無二であることを意味する。
目的は、ユーザーエージェント（支援技術を含む）が構文分析可能なコンテンツを正確に解釈できるようにすることである。もし曖昧なところなく構文解析可能でなければ、異なるユーザーエージェントは異なった提示をするかもしれないし、構文分析することが全くできないかもしれない。メジャーで主流なユーザーエージェントによって（構文分析に修復テクニックを用いながら）構文分析できたとしても、そのことは障害のあるユーザーが使用する必要のある特定のブラウザ（支援技術を含む）によって構文分析される（正確に構文分析される）とは限らない。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 4.1.1を満たすのに十分であると考える。
以下の技術特有のテクニックを用いて、デリバリーユニットを曖昧なところなく構文解析できるようにする
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
デリバリーユニットが曖昧なところなく構文解析されるようにすることで、支援技術がクラッシュせずに、コンテンツを正確に解析できるようになる。
4.2.1
もしコンテンツがすべてのレベル1達成基準を満たさない場合は、すべてのレベル1達成基準を満たす代替バージョンが同じURIから利用可能であること (レベル 1)
If content does not meet all level 1 success criteria, then an alternate version is available from the same URI that does meet all level 1 success criteria. (Level 1)
ユーザーエージェントが知覚可能なユニットを生成するために使用するデリバリーユニットの中の情報。これには、構造やプレゼンテーション、インタラクションを定義するソースコードやマークアップのほか、エンドユーザーに情報を伝達するテキスト、画像、音声が含まれる。
同じ情報及び機能の全てを提供し、適合していないコンテンツ同様に最新版であるバージョン
この達成基準の意図は、全てのコンテンツのアクセシブルなバージョンを入手可能にすることである。コンテンツ制作者は、アクセシブルでない技術やフォーマットをWebサイトで用いるかもしれない。しかし、それと同時に全ての情報と機能を容易に手に入るアクセシブルな形式で提供しなければならない。万一のときに代用できる選択肢であり、そのコンテンツ自体をアクセシブルにすることより好ましいわけではない。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 4.2.1を満たすのに十分であると考える。
コンテンツ・ネゴシエーションがされていない場合、デフォルトとしてアクセシブルなバージョンを提供するが、準拠していないコンテンツを扱うことのできるユーザーにはそれを提供する
注意: この最後のオプションは、コンテンツ・ネゴシエーションがないため、今日の技術やユーザーエージェントではすぐには可能ではないかもしれない。
（現在作成中）
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
技術要件を定めて文書化することの利点は、ユーザーが（サイト上のドキュメントでも、メタデータにより自動的でも）そのサイトを利用できそうかどうかを見極めることができる点である。検索エンジンあるいはプロキシサーバと連動して、これはユーザーがアクセス不可能なサイトか、あるいは最も使いやすいだろうトップレベルのサイトかを自動的にフィルタリングするために用いられうる。技術要件を文書化することは、サイト運営者/制作者にユーザーエージェントに関する仮説を検証させ、後方互換性に気づいていないという理由で不注意にアクセシブルでないサイトの数を最小化するだろう。ユーザーインターフェースのアクセシビリティを確認して、アクセシブルな代替コンテンツを提供することの利点は、代替のブラウザ技術やデバイスを使わなくてはならない人がコンテンツにアクセスできるようになることである。最新技術を利用できない人も、アップグレード製品や装置を購入する必要がなくなるという点で、後方互換性の恩恵を受けられる。
必要な技術を挙げているオンラインストア
最低限のユーザーエージェント要件を文書化することで、そのストアは特定の技術を使用している人が、ショッピングを始める前に、そのストアやチェックアウト手続きで問題が起きそうかどうかを見極めることを可能にしている。これにより、ユーザーが製品を選択し終えてチェックアウト手続きに入った後で、トランザクションを完了できないことに気づく、というのを回避できる。それゆえ、ユーザーはうまく行くことが保証されている他の手段を選ぶことが可能である。
イントラネットAn intranet site that transforms gracefully.
ある大企業は、異なるテクノロジー基盤を有する多くの様々な拠点の従業員が使えるかどうかに懸念があった。その問題の解決に向けて2つのバージョンを制作し、各バージョンの要件を明文化した。それにより、従業員個々の拠点によってどちらのバージョンがそこで使用しているテクノロジーで最も使えるかを判断することが容易になった。
後方互換性を保証する情報サイト
ある情報サイトは広範囲に及ぶテーマをカバーしており、利用者が素早く探しているトピックを見つけることができるようにしたいと考えていた。そして、2つのポピュラーなユーザー・エージェントの最新バージョンでのみサポートされているインタラクティブなメニュー・システムを導入した。その特定のユーザー・エージェントを使用していない利用者もそのサイトを有効に使用できることを保証するために、そのインタラクティブなメニュー・システムに依存してないナビゲーション・メカニズムを最新のテクノロジーをサポートしていないユーザー・エージェントに提供している。
（現在作成中）
4.2.2
たとえ選択したベースラインにない技術を用いているとしても、コンテンツが、次の基準を満たしていること。(レベル 1)
Content meets the following criteria even if the content uses a technology that is not in the chosen baseline: (Level 1)
コンテンツが一般閃光閾値および赤色閃光閾値に違反している場合、ユーザーがその表示を回避できるよう警告している。
When content violates either the general flash threshold or thered flash threshold, users are warned in a way that they can avoid it.
ユーザーがキーボードを使ってそのコンテンツの中に入れる場合、ユーザーはキーボードを使ってそのコンテンツの外へ出ることができる。
If the user can enter the content using the keyboard, then the user can exit the content using the keyboard.
ユーザーエージェントが知覚可能なユニットを生成するために使用するデリバリーユニットの中の情報。これには、構造やプレゼンテーション、インタラクションを定義するソースコードやマークアップのほか、エンドユーザーに情報を伝達するテキスト、画像、音声が含まれる。
Webコンテンツがこれらのガイドラインに準拠するにあたり、ユーザーエージェントでサポートされていて使用可能であると考えられている技術一式。
注： コンテンツ制作者が従うことになるベースラインを定める当事者としては、コンテンツ制作者、企業、顧客、政府機関などが挙げられる。
明滅または急速に変化する画像の連続は、次の2点の両方が当てはまる場合は、使用してはならない。
同時に起こっている（ただし必ずしも隣接はしていない）明滅のエリアの合計サイズが、そのコンテンツを1024×768ピクセルで見た場合の表示画面上で、335×268ピクセルの長方形の4分の1を超えるエリアを占めている。
1秒間に3回を超える明滅がある。
注： 一般閃光の閾値について、明滅とは、フルスケールの白色度の10％以上の明度における1組の相対する変化のことで、明度はリニアライズした R、G、そして B の値を用いて、.2126*R + .7152*G + .0722B で計算される。Linearized-X = (X/FS)^2.2 FSはフルスケール（今日では通常255）である。"相対する変化"とは、明度が増加した後に減少する、あるいは明度が減少した後に増加することを指す。
彩度の高い赤色閃光への移行、あるいは彩度の高い赤色閃光からの移行は、次の2点の両方が当てはまる場合は、使用してはならない。
同時に起こっている明滅のエリアの合計サイズが、そのコンテンツを1024×768ピクセルで見た場合の表示画面上で、335×268ピクセルの長方形の4分の1を超えるエリアを占めている。
1秒間に3回を超える明滅がある。
この達成基準の意図は、コンテンツが残りのコンテンツのアクセシビリティを著しく妨げるコンポーネントを含まないようにすることである。そういったコンポーネントとしては、以下のようなものが挙げられる。
ベースラインとは、そのWebサイトでサポートされていなくてはならない技術とユーザーが利用可能な機能のセットである。ベースラインにある技術により実現される全てのコンテンツは、そのサイトが有効であり、適合を宣言するためにはWCAGに準拠しなければならない。しかしながら、もしアクセシブルな代替コンテンツがベースラインにある技術を用いて提供されていたり、もしコンテンツがベースラインにある技術だけをサポートしているユーザーエージェントに対してアクセシブルだったりすれば、ベースラインにない技術で実現されているコンテンツもあるかもしれない。著しくアクセシビリティの妨げとなっているコンテンツに何の特徴もないことは極めて重大である。これは、その技術をサポートしているユーザーエージェントが存在することがありえて、たとえその技術がベースラインの一部でなかったとしてもアクセシビリティの問題を作り出すからである。
この達成基準で挙げられている"操作の対象になっていてアクセシブルでない状態"には2つのタイプがある。光源性のてんかん発作を誘発する閃光のあるコンテンツはガイドライン2.3で述べられている問題であり、この達成基準は、たとえベースラインにはなくともそのサイトで用いられている全ての技術にガイドライン2.3のレベル1達成基準が適用されることを明確にしている。キーボード操作により中に入ることのできるコンテンツがキーボードだけでも外に出ることができるという要件は、"キーボード・トラッピング"といって、キーボードだけで操作しているユーザーにアクセシブルなコンテンツに戻る手段を与えずに、キーボードのフォーカスがアクセシブルではないプラグインにの中に閉じ込められるというよくある状況に言及している。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 4.2.2を満たすのに十分であると考える。
Instructions: Select the situation below that matches your content. Beneath it, are the option(s) that are known and documented to be sufficient for that situation. For the technology-specific techniques, see the options for the technology you are using listed immediately below.
達成基準 2.3.1 を満たす方法 にある全てのテクニックを用いる
注記: ガイドライン 2.3 のレベル1 達成基準1 のみが、閃光を放つコンテンツが存在しないようにではなく、それを避けられるようにマークすることを要求している。ガイドライン 4.2 のレベル1 達成基準2を満たすためには、そのコンテンツを避けるための手段が、閃光を放つベースラインにない技術ではなく、ベースラインにある技術においては提供されなければならない。さもなければ、ユーザーは閃光を放つコンテンツを避ける仕組みにアクセスすることができないかもしれない。
以下に挙げる中から1つ以上を実践する:
（現在作成中）
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
異なる技術のコンテンツがフォーカスを受け取ったとき、キーボード・ナビゲーションの独自の状況をしばしば設定し、ユーザーエージェントのグローバルな状況を無効にする。特に、フォーカスがタブの循環の最後に達したとき、そのコンテンツタイプのタブ順序の先頭に戻ってしまい、元のドキュメントには戻らず、そのタブの循環を繰り返してしまう。
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
この達成基準は、ベースラインにあるアクセシブルなコンテンツが、ベースラインにない技術のコンテンツが同時に表示されることで、意図に反してアクセシブルでなくなることのないようにするためのものである。ベースラインやWCAG適合レベルの宣言の範囲外の技術であったとしても、"アクセシブルでない" 場合のことを述べている。
HTML文書に「次のページには閃光を放つコンテンツがあります」という警告があり、閃光のない代替ページへのリンクを提供している。
ベースラインではないコンテンツに、キーボードでベースラインのコンテンツにフォーカスを戻す方法に関する情報へのリンクがある。
ベースラインではないコンテンツから、キーボードでベースラインのコンテンツにフォーカスを戻す方法に関する情報があり、キーボードだけでヘルプ情報にアクセス可能である。
（現在作成中）
4.2.3
利用者からの入力を受け付けるWebコンテンツ、または利用者の入力や外部のイベントに応じてダイナミックに変化するWebコンテンツのユーザー・インターフェイス・コンポーネントすべてについて、その役割、状態、そして値が、プログラム的に決められていること。(レベル 1)
The role, state, and value can be programmatically determined
for every user interface component of the web content that accepts
input from the user or changes dynamically in response to user input or
external events. (Level 1)
選択されたベースラインにある技術をサポートしている、支援技術を含むユーザーエージェントによって認識可能であること。
この達成基準の意図は、支援技術がインタラクティブなユーザーインターフェースのコンポーネントをユーザーに分かりやすく提供するために、それに関するアクセシビリティ情報を引き出すことのできるかたちで情報を提供することである。例えば、スクリーンリーダーはユーザーに今のコントロールはチェックボックスでそれは選択されていないということを知らせるかもしれない。チェックボックスは"役割"であり、"選択されていない"は状態である。そして、ユーザーはチェックボックスで提示されている選択肢が選択されているということを理解できる。音声認識プログラムは、この情報を用いてインタラクションのボキャブラリーを作り上げるかもしれない。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 4.2.3を満たすのに十分であると考える。
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
（現在作成中）
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
（現在作成中）
役割、状態、そして値の情報を全てのユーザーインターフェースコンポーネントに提供することで、障害のある人が使うスクリーンリーダー、画面拡大ソフト、音声認識ソフトウェアのような支援技術との互換性を持たせられる。
アクセシブルな API
Javaアプレットが、その言語により定義されたアクセシビリティAPIを使っている。IBM Guidelines for Writing Accessible Applications Using 100% Pure Java（英語）を参照のこと。
4.2.4
利用者からの入力を受け付けるユーザー・インターフェイス・コントロールのラベルがそれぞれ、プログラム的に決められていて、そのコントロールと明らかに関連付けられていること(レベル 1)
The label of each user interface control that accepts input from the user can be programmatically determined and is explicitly associated with the control. (Level 1)
選択されたベースラインにある技術をサポートしている、支援技術を含むユーザーエージェントによって認識可能であること。
この達成基準に従うことで、支援技術が全てのユーザーインターフェースのコントロールに正しいラベルを提供することができる。
WCAGワーキンググループは、以下に挙げるテクニックを組み合わせることで達成基準 4.2.4を満たすのに十分であると考える。
以下に挙げる技術特有のテクニックを用いて、UIコントロールにラベルを付ける。
Editorial Note: Looking for script techniques, and role of APIs. Comments invited.
以下に挙げるのは、ワーキングループがこの達成基準においてよくある失敗例であると考える事例である。
スクリプトを用いて、 <div> あるいは <span> をHTMLのユーザーインターフェースのコントロールにする
注意: DHTML ロードマップで解決済み
適合のために必須ではないが、コンテンツをよりアクセシブルにするために以下に挙げる追加のテクニックも考慮すべきである。ただし、全てのテクニックが使用可能とはかぎらない。また、あらゆる状況に効果的であるともかぎらない。
（現在作成中）
支援技術のユーザーは、ラベルも含めてコンテンツに出くわすことなく、コントロールからコントロールへとナビゲートして、フォームの入力を終えることがある。また、ページのレイアウトが、どのラベルがどのコントロールと関連があるのかを前後関係の情報だけでは把握するのを困難にしている。コントロールを明示的にラベルと関連付けることで、ユーザーエージェントは要求に応じて、コントロールに対応する正しいラベルを提示できるようになる。
マウス操作が困難なユーザーは、ラベルのテキストをクリックすることでチェックボックス/ラジオボタンを選択できるようになる。
（現在作成中）
（現在作成中）
4.2.5
ユーザー・インターフェイスを通して変更できるコンテンツおよびユーザー･インターフェース要素のプロパティは、プログラム的にも直接的に変更できること (レベル 1)
The content and properties of user interface elements that
can be changed via the user interface can also be directly changed
programmatically. (Level 1)
注： ユーザー･インターフェースにより一般的に変更可能な標準化されたプロパティの例としては、その値、現在選択されているかどうか、そして現在フォーカスがあたっているかどうか、などが挙げられる。
Editorial Note: The working group is still considering whether this criterion should be included and, if so, at what level.
この達成基準により、ユーザーは支援技術を使って、ユーザーインターフェースにより変更可能な全てのコンテンツの値と状態を変更することができる。
注記：達成基準3は値が読み上げ可能であることを指し、この達成基準は操作可能であることを指している。
WCAGワーキ