【注意】 この文書は、2008年12月11日付の W3C 勧告「WCAG 2.0」(原文は英語)を、財団法人日本規格協会情報技術標準化研究センター情報アクセシビリティ国際標準化に関する調査研究開発委員会ウェブアクセシビリティ国際規格調査研究部会が日本語に翻訳したものです。このワーキングドラフトの正式な文書は、あくまで W3C のサイト内にある英語版であり、この文書には翻訳上の間違い、あるいは不適切な表現が含まれている可能性がありますのでご注意ください。また、リンク先が英語の場合、あるいはダミーのページである場合もあります。ご了承ください。
なお、文中にある関連文書の "Understanding WCAG 2.0" へのリンクは、すべて原文の英語版へリンクしていますが、 "Understanding WCAG 2.0" の日本語訳もあります。あわせてご覧ください。
[contents]
この文書の正誤表を参照してください。規定の訂正があるかもしれません。
翻訳版もご覧ください。
この文書には、規定ではないフォーマットもあり、WCAG 2.0 の代替バージョン(英語)で入手可能です。
Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
ウェブコンテンツ・アクセシビリティ・ガイドライン 2.0(以下、WCAG 2.0)は、ウェブコンテンツをよりアクセシブルにするための広範囲に及ぶ推奨事項を網羅している。このガイドラインに従うことで、全盲又はロービジョン、ろう又は難聴、学習障害、認知障害、運動制限、発話困難、光過敏性発作およびこれらの組合せ等を含んだ、さまざまな障害のある人に対して、コンテンツをアクセシブルにすることになるだろう。また、このガイドラインに従うと、すべてのユーザに対してウェブコンテンツをより使いやすいものにすることにもなるだろう。
WCAG 2.0 の達成基準は、技術に依存しない検証可能なものとして記述されている。特定の技術において達成基準を満たすためのガイドについては、達成基準を理解するための一般的な情報とあわせて、別の文書群として提供している。イントロダウションおよび WCAG のテクニックや教育に関する資料については、ウェブコンテンツ・アクセシビリティ・ガイドライン (WCAG) 概要(英語)を参照のこと。
WCAG 2.0 は、1999年5月に W3C 勧告として公開された ウェブコンテンツ・アクセシビリティ・ガイドライン 1.0(英語)[WCAG10] の後を継ぐものである。WCAG 1.0 または WCAG 2.0 のいずれか(あるいは、その両方)に適合することは可能だが、W3C は新規で更新されるコンテンツは WCAG 2.0(あるいは、両方)を用いることを推奨する。また、W3C は、ウェブアクセシビリティのポリシーも WCAG 2.0 を参照することを推奨する。
この節では、この文書の発行された時点でのステータスを説明する。他の文書が、この文書にとって代わっている場合もある。現行のW3Cの発行文書およびこの技術レポートの改訂版は、http://www.w3.org/TR/ にある W3C テクニカルレポート・インデックス(英語)で参照可能である。
これは、WCAG ワーキンググループ(英語) が作成した W3C 勧告(英語) の WCAG 2.0 である。
この文書は、W3C 会員、ソフトウェア開発者、そしてその他の W3C グループや関係者によってレビューされており、W3C のディレクターにより W3C 勧告として承認されたものである。安定した文書であり、参考資料として用いたり、他の文書で引用したりしてもよい。勧告文書の作成における W3C の役割は、その仕様への関心を引いて、広く普及させていくことにある。これにより、ウェブの機能および相互運用性の向上につながる。
WCAG 2.0 には、規定ではない関連文書の Understanding WCAG 2.0 及び Techniques for WCAG 2.0 がある。それらの文書には、WCAG 2.0 自体が有する正式なステータスはないものの、WCAG の理解及び実装に関する重要な情報を提供している。
ワーキンググループへのコメントは、オンライン・コメントフォーム(英語)を使って送っていただきたい。もしそれができない場合は、public-comments-wcag20@w3.org 宛に電子メールで送信することも可能である。公開メーリングリストのアーカイブ(英語)は誰も利用可能である。WCAG 2.0 の勧告文書に関して寄せられたコメントにより、このバージョンのガイドラインを変更することはできないが、正誤表あるいは WCAG の将来のバージョンに反映されることはある。また、コメントに対して、ワーキンググループが正式な返答をする予定はない。WCAG ワーキンググループのメーリングリストでの議論のアーカイブは一般に公開されており、この文書に関して寄せられたコメントについては、ワーキンググループが将来的に対処することがあるかもしれない。
この文書は、W3Cの ウェブアクセシビリティ・イニシアティブ(WAI)(英語)(WAI)の活動の一環として作成されたものである。WCAG ワーキンググループの目的については、 ワーキンググループ趣意書(英語)に記載されている。WCAG ワーキンググループは、WAI テクニカル・アクティビティ(英語)の一つである。
この文書は、2004年2月5日付の W3C 特許ポリシー(英語)に則って運営するワーキンググループによって作成された。W3C では、ワーキンググループの成果物に関係する 全開示特許の公開リストを管理しており、そのページには、特許を開示するにあたっての指示も記載されている。エッセンシャル・クレームを含んでいると思われる特許について知識のある人は、W3C 特許ポリシー 第6節に従ってその情報を開示しなければならない。
この節は、参考情報である。
WCAG 2.0 は、ウェブコンテンツを障害者にとってよりアクセシブルにする方法を定義している。アクセシビリティは、視覚、聴覚、身体、発話、認知、言語、学習、そして神経の障害を含む、さまざまな障害と関係がある。このガイドラインは、広範囲に及ぶ事項を網羅しているが、障害のすべての種類、程度、そして組合せからくるニーズを満たすことはできない。また、このガイドラインは、加齢によりさまざまな能力が変化している高齢者にとってもウェブコンテンツをより使いやすくするものであり、しばしばユーザ全般のユーザビリティを向上させる。
WCAG 2.0 は、ウェブコンテンツのアクセシビリティに関する、さまざまな国の個人、組織、そして政府のニーズを満たすような基準を提供すべく、世界中の個人および組織と協力して、W3Cプロセスを通じて作成されている。WCAG 2.0 は WCAG 1.0 [WCAG10] をふまえ、現在および将来のさまざまなウェブ技術に広く適用できるように設計されている。また、自動テストおよび人間による評価の組合せによって検証可能であるように作られている。WCAG のイントロダクションとしては、ウェブ・コンテンツ・アクセシビリティ・ガイドライン (WCAG) 概要(英語) を参照のこと。
ウェブアクセシビリティは、アクセシブルなコンテンツだけではなく、アクセシブルなウェブブラウザやその他のユーザエージェントにも依存している。そして、オーサリングツールもまたウェブアクセシビリティにおいて重要な役割を担っている。こういったウェブ開発やインタラクションが相互にどのように関係しているかの概要については、以下を参照のこと:
WCAG を用いる個人や組織は、ウェブデザイナーや開発者、ポリシー策定者、調達担当者、そして講師および学生など実に広汎である。これらの人たちのさまざまなニーズに応えるために WCAG 2.0 では、原則、一般的なガイドライン、検証可能な達成基準、そして事例や参考となるリンク、ソースコードとともに十分なテクニック、参考テクニックおよびよくある失敗例を紹介した豊富な文書群を含む様々なレイヤーのガイダンスが提供されている。
原則 - 最上位には、ウェブアクセシビリティの土台となる4つの原則がある:知覚可能、操作可能、理解可能、そして互換性。あわせて、アクセシビリティの4原則を理解する(英語)も参照のこと。
ガイドライン - 原則の下にあるのがガイドラインである。12のガイドラインは、さまざまな障害者ユーザに対してコンテンツをよりアクセシブルにするために取り組むべき基本的な目標を提供している。これらのガイドラインは検証可能ではないが、コンテンツ制作者が達成基準を理解し、より適したテクニックを用いることができるように、そのフレームワークおよび全般的な目的を提供するものである。
達成基準 - 各ガイドラインには、検証可能な達成基準が設けられており、デザイン仕様検討、調達、基準策定、および契約上の合意などにあたりその要件や適合性検査が必要となる際に WCAG 2.0 を用いることが可能である。さまざまなユーザ層や状況からくるニーズを満たすために、3つの適合レベルが定義されている:A (最低レベル)、AA、AAA (最高レベル)。( WCAG のレベルに関する補足情報は、適合レベルを理解する(英語)を参照のこと。
十分なテクニックおよび参考テクニック - WCAG 2.0 文書自体にあるガイドラインおよび達成基準それぞれに対して、ワーキンググループはテクニックについても広範囲にわたって文書化している。テクニックは参考情報であり、2つのカテゴリに分類される:達成基準を満たすのに十分なテクニックと参考テクニックである。参考テクニックは、個々の達成基準の要件を上回るもので、コンテンツ制作者はガイドラインに対してより良い対処ができる。参考テクニックの中には、検証可能な達成基準によってカバーされていないアクセシビリティの問題に対処するものもある。よくある失敗例がある場合は、それも文書化されている。「WCAG 2.0 解説書」における十分なテクニックおよび参考テクニック(英語)も参照のこと。
このガイダンスのレイヤー(原則、ガイドライン、達成基準、十分なテクニックおよび参考テクニック)はすべて、コンテンツをよりアクセシブルにする方法に関するガイダンスを提供するために連携している。コンテンツ制作者は可能な範囲で最も広いユーザのニーズに最大限対処できるように、参考テクニックを含めたすべてのレイヤーを確認して適用することが推奨される。
注意すべきなのは、最高レベル(AAA)で適合しているコンテンツでさえも、すべての種類、程度あるいは組合せの障害者にとってアクセシブルではないということである。特に、認知、言語および学習の面においてはそうである。コンテンツ制作者は、参考テクニックを含むすべてのテクニックを考慮するとともに、 ウェブコンテンツが彼らに対しても可能な限りアクセシブルであることを確実にするためにも、最新のベストプラクティスに関するアドバイスを探し求めることが推奨される。メタデータ(英語)は、そういったユーザのニーズに最適なコンテンツを探し出す上で、ユーザを支援できるかもしれない。
WCAG 2.0 の文書は、安定した参照可能な技術標準を必要とする人たちのニーズを満たすように作成されている。関連文書と呼ばれるその他の文書群は、WCAG 2.0文書に基づいて、WCAG が新しい技術にどのように適用されるかを説明するために更新できるようにすることも含めてその他の重要な役割を果たすものである。関連文書には以下に挙げるものがある:
WCAG 2.0 を満たす方法 - WCAG 2.0 のカスタマイズ可能なクイックリファレンス。コンテンツ制作者がウェブコンテンツを制作したり評価したりする際に用いるガイドライン、達成基準、そしてテクニックのすべてを参照できる。
WCAG 2.0 解説書 - WCAG 2.0を理解して実践するための解説書。重要なトピックスとあわせて、WCAG 2.0の各ガイドラインおよび達成基準を「理解する」ための簡潔な文書がある。
WCAG 2.0 テクニック集 - テクニック集および既知の失敗事例集。個々に別々の文書になっており、解説、事例、ソースコード例、そして検証方法が記述されている。
WCAG 2.0 文書群 - 技術文書群がどのように関係していてリンクされているのかを示したダイアグラムと解説。
WCAG 2.0に関する教育資料を含む関連資料の説明は、ウェブコンテンツ・アクセシビリティ・ガイドライン (WCAG) 概要(英語)を参照のこと。例えば、ウェブアクセシビリティのビジネスにおける効果、ウェブサイトのアクセシビリティを改善するための実装プラン作成、そしてアクセシビリティ・ポリシーといったトピックに関する補足資料は、WAI リソース集(英語)に挙げられている。
WCAG 2.0 では、WCAG 1.0 とは異なる3つの重要な用語が用いられている。それぞれを以下で簡潔に紹介し、その詳細を用語集で定義している。
重要なのは、ウェブページという用語が、このガイドラインにおいては、静的な HTML ページよりも多くのものを指すということに注意することである。完全にバーチャルでインタラクティブなコミュニティを提供できる、ウェブ上に登場してきているますます動的なウェブページも含んでいる。例えば、ウェブページには、単一の URL で提供される、あたかも実体験であるかのようにインタラクティブで映画のようなエクスペリエンス(経験)も含まれる。より詳細な情報は、「ウェブページ」を理解する(英語)を参照のこと。
いくつかの達成基準では、コンテンツ(あるいは、コンテンツのある一部)をプログラムで解釈できるようにすることを要求している。これは、そのコンテンツが支援技術を含むユーザエージェントによってその情報を抽出され、さまざまなモダリティでユーザに提供することが可能であることを指す。より詳細な情報は、「プログラムで解釈」を理解する(英語)を参照のこと。
技術をアクセシビリティ・サポーテッドな方法で用いるというのは、支援技術(AT)および OS、ブラウザ、その他のユーザエージェントのアクセシビリティ機能と連携するということを意味する。技術は、アクセシビリティ・サポーテッドな方法で用いられている場合のみ、WCAG 2.0 の達成基準を満たすために依存することが可能である。ただし、何らかの達成基準を満たすために用いられていない(つまり、同じ情報あるいは機能が、アクセシビリティ・サポーテッドな他の方法でも利用可能である)かぎり、その技術をアクセシビリティ・サポーテッドではない(支援技術などと連携しない)方法で用いることができる。
アクセシビリティ・サポーテッドの用語定義は、このガイドラインの附録 A: 用語集で提供されている。より詳細な情報は、「アクセシビリティ・サポーテッド」を理解するを参照のこと。
この節は、規定である。
1.1.1 非テキストコンテンツ: ユーザに提示されるすべての非テキストコンテンツには、同等の目的を果たす代替テキストがある。ただし、以下に挙げる場合は除く (レベル A):
コントロール、入力: 非テキストコンテンツが、コントロールまたはユーザの入力を受け入れるものである場合、代替テキストは、その目的を説明する識別名を提供している。(コントロールおよびユーザの入力を受け入れるコンテンツに関するその他の要件は、ガイドライン 4.1を参照のこと。)
時間の経過に伴って変化するメディア: 非テキストコンテンツが、時間の経過に伴って変化するメディアであるとき、代替テキストは、少なくとも、その非テキストコンテンツを識別できる説明を提供している。(メディアに関するその他の要件は、ガイドライン 1.2を参照のこと。)
試験: 非テキストコンテンツが、テキストで提示されると無効になる試験あるいは演習のとき、代替テキストは、少なくともその非テキストコンテンツを識別できる説明を提供している。
感覚的: 非テキストコンテンツが、特定の感覚的体験を創り出すことを主に意図しているとき、代替テキストは、少なくともその非テキストコンテンツを識別できる説明を提供している。
CAPTCHA: 非テキストコンテンツが、コンピュータではなく人間がコンテンツにアクセスしていることを確認する目的で用いられているとき、代替テキストは、その非テキストコンテンツの目的を特定し、説明している。なおかつ、他の感覚による知覚に対応して出力するCAPTCHAの代替形式を提供することで、様々な障害に対応している。
装飾、整形、非表示: 非テキストコンテンツが、装飾だけを目的にしている、あるいは見た目の整形のためだけに用いられている、またはユーザに提供されるものではないとき、支援技術が無視できるように実装されている。
1.2.1 収録済の音声しか含まないメディア及び収録済の映像しか含まないメディア: 収録済の音声しか含まないメディア及び収録済の映像しか含まないメディアは、次の事項が当てはまる。ただし、その音声あるいは映像がテキストの代替メディアであって、そのことがはっきりとラベル付けされている場合は除く。 (レベル A):
収録済の音声しか含まないコンテンツ: 時間の経過に伴って変化するメディアの代替が、収録済の音声しか含まないコンテンツと等価な情報を提供している。
収録済の映像しか含まないコンテンツ: 時間に伴って変化するメディアの代替あるいは音声トラックが、収録済の映像しか含まないコンテンツと等価な情報を提供している。
1.2.2 収録済の音声コンテンツのキャプション: 同期したメディアに含まれている収録済の音声コンテンツすべてにキャプションを提供する。ただし、そのメディアがテキストの代替メディアで、はっきりとそのようにラベル付けされている場合は除く。(レベル A)
1.2.3 収録済の映像コンテンツの音声ガイドまたは代替: 同期したメディアには、時間の経過に伴って変化するメディアの代替あるいは収録済の映像コンテンツの音声ガイドを提供する。ただし、そのメディアがテキストの代替メディアで、はっきりとそのようにラベル付けされている場合は除く。 (レベル A)
1.2.8 収録済のメディアの代替: 収録済の同期したメディアすべて及び収録済の映像しか含まないメディアすべてに、時間の経過に伴って変化するメディアの代替を提供する。 (レベル AAA)
1.2.9 ライブの音声しか含まないコンテンツの代替: ライブの音声しか含まないコンテンツと等価な情報を提示する時間の経過に伴って変化するメディアの代替を提供する。 (レベル AAA)
1.3.3 感覚的な特徴: コンテンツを理解し操作するための説明を、形、大きさ、視覚的な位置、方向、または音のような、構成要素が人間の感覚に示す特徴だけで提供しない。 (レベル A)
注記: 色に関する要件は、ガイドライン 1.4を参照のこと。
1.4.1 色の使用: 情報を伝える、何が起こるかあるいは何が起きたかを示す、ユーザの反応を促す、あるいは視覚的な要素を区別する唯一の視覚的な手段として、色のみを使用しない。 (レベル A)
注記: この達成基準は、特に色の知覚に関するものである。その他の知覚形態については、色やその他の視覚的な表現のコーディングへのプログラムによるアクセスも含めて、ガイドライン 1.3で網羅されている。
1.4.2 音声制御: ウェブページ上にある音声が3秒より長く自動的に再生される場合、その音声を一時停止あるいは停止するメカニズムを提供する、あるいはシステム全体の音量レベルとは別々に音量を調整するメカニズムを提供する。 (レベル A)
注記: この達成基準を満たさないコンテンツでは、ユーザがそのページ全体を使用できない恐れがあるため、Webページ上のすべてのコンテンツは他の達成基準を満たすために用いられているか否かにかかわらず、この達成基準を満たさなければならない。適合要件 5: 非干渉を参照のこと。
1.4.3 最低限のコントラスト:テキストおよび画像化された文字の視覚的な表現には、少なくとも 4.5:1 のコントラスト比をもたせる。ただし、次に挙げる場合は除く (レベル AA):
大きな文字: サイズの大きなテキストおよびサイズの大きな画像化された文字には、少なくとも3:1のコントラスト比がある。
付随的: テキストあるいは画像化された文字において、以下の場合はコントラストの要件は該当しない: アクティブではないユーザインタフェース要素の一部分である、装飾だけを目的にしている、視覚的に確認できない、あるいは重要な他の視覚的なコンテンツを含む写真の一部分である。
ロゴタイプ: ロゴあるいはブランド名の一部である文字には、コントラストの要件はない。
1.4.5 画像化された文字: 使用している技術で意図した視覚的な表現が可能である場合は、画像化された文字ではなくテキストを用いて情報を伝える。ただし、以下に挙げる場合は除く (レベル AA):
カスタマイズ可能: 画像化された文字がユーザの要求に応じて視覚的にカスタマイズできる。
必要不可欠: 文字の特定の表現が、伝えようとする情報にとって必要不可欠である。
注記:ロゴタイプ(ロゴあるいはブランド名の一部である文字)は必要不可欠なものであるとみなす。
1.4.6 より十分なコントラスト:テキストおよび画像化された文字の視覚的な表現には、少なくとも 7:1 のコントラスト比がある。ただし、以下に挙げる場合は除く (レベル AAA):
大きな文字: サイズの大きなテキストおよびサイズの大きな画像化された文字には、少なくとも 4.5:1 のコントラスト比がある。
付随的: テキストあるいは画像化された文字において、以下の場合はコントラストの要件は該当しない: アクティブではないユーザインタフェース要素の一部分である、装飾だけを目的にしている、視覚的に確認できない、あるいは重要な他の視覚的なコンテンツを含む写真の一部分である。
ロゴタイプ: ロゴあるいはブランド名の一部である文字には、コントラストの要件はない。
1.4.7 小さい背景音または背景音なし: 収録済の音声しか含まないコンテンツで、(1) 前景に主として話し言葉を含み、(2) 音声CAPTCHA あるいは音声ロゴではなく、かつ(3) 例えば、歌やラップなどのように、主として音楽表現を意図した発声ではないものについては、以下に挙げるうちの少なくとも1つがあてはまる。 (レベル AAA):
背景音なし: 音声は背景音を含まない。
消音: 背景音を消すことができる。
20 dB: 背景音は、前景にある話し言葉のコンテンツより少なくとも20デシベルは低い。ただし、時折1~2秒間だけ続く音は除く。
注記: "デシベル" の定義によれば、この要件を満たす背景音は、前景にある話し言葉のコンテンツよりも約4分の1の大きさになる。
1.4.8 視覚的な表現: テキスト・ブロックの視覚的な表現には、以下を実現するメカニズムが利用できる (レベル AAA):
ユーザが、前景色と背景色を選択できる。
幅が、80文字(図形記号を含む)以下(中国語、日本語、韓国語の場合は、40文字以下)である。
テキストが、均等割り付けされていない (両端揃えではない)。
段落中の行送り幅(行間隔)は、少なくとも1.5文字分ある。そして、段落の間隔は、その行送り幅の少なくとも1.5倍以上ある。
テキストが、支援技術を用いなくてもサイズを200%まで変更できて、ユーザが全画面表示にしたウィンドウで1行のテキストを読む際に横スクロールする必要がない。
2.1.1 キーボード操作: コンテンツのすべての機能は、個々のキーストロークに特定のタイミングを要することなく、キーボードインタフェースを通じて操作可能である。ただし、その根本的な機能が単にユーザの動作の終点に依存しておらず、ユーザの動作による軌跡に依存して実現されている場合は除く。 (レベル A)
注記 1: 前述の例外は、コンテンツの根本的な機能に関するものであり、入力手法に関するものではない。例えば、テキスト入力に手書き入力を用いるのであれば、その入力手法(手書き)はユーザの動作による軌跡(たとえば手書き入力に用いるマウスの動き)に依存した入力を必要とするが、その根本的な機能(テキスト入力)はユーザの動作による軌跡に依存した入力を必要とするものではない。
注記 2: これは、キーボード操作に加えて、マウス入力あるいはその他の入力手段を提供することを禁ずるものでも妨げるものでもない。
2.1.2 フォーカス移動: キーボード・インタフェースを用いてキーボード・フォーカスをそのページのある構成要素に移動できる場合、キーボード・インタフェースだけを用いてその構成要素からフォーカスを外すことが可能である。また、もしその操作が矢印キー、あるいはTabキー以外の操作を必要とするならば、キーボード・フォーカスをその構成要素から外す方法をユーザに知らせる。 (レベル A)
注記: この達成基準を満たさないコンテンツでは、ユーザがそのページ全体を使用できない恐れがあるため、Webページ上のすべてのコンテンツは他の達成基準を満たすために用いられているか否かにかかわらず、この達成基準を満たさなければならない。適合要件 5: 非干渉を参照のこと。
2.1.3 キーボード操作(例外なし): コンテンツのすべての機能は、個々のキーストロークに特定のタイミングを要することなく、キーボード・インタフェースを通じて操作可能である。 (レベル AAA)
2.2.1 調整可能な制限時間: コンテンツに制限時間を設定する場合は、次のうちの少なくとも1つが当てはまる。 (レベル A):
解除: 制限時間内に、ユーザがその制限時間を解除することができる。または、
調整: 制限時間内に、ユーザが制限時間をデフォルトの設定の少なくとも10倍の長さまでの範囲で調整できる。または、
延長: 時間切れになる前にユーザに警告し、ユーザが少なくとも20秒間の猶予をもって、例えば "スペースキーを押す" などの簡単な操作で延長でき、そしてユーザが制限時間を少なくとも10倍以上延長することができる。または、
リアルタイムの例外: 制限時間がリアルタイムのイベント(例えば、オークション)に必須の要素で、その制限時間に代わる手段が存在しない。または、
必要不可欠な例外: 制限時間が必要不可欠なもので、制限時間を延長することがコンテンツの動作を無効にすることになる。または、
20時間の例外: 制限時間が20時間よりも長い。
注記: この達成基準は、制限時間の結果として、コンテンツあるいは状況の変化が予期せず起こることなく、ユーザがタスクを完了できるようにするためのものである。この達成基準は、ユーザのアクションの結果としてのコンテンツあるいは状況の変化を制限する達成基準 3.2.1と併せて考慮されるべきである。
2.2.2 一時停止、停止、非表示: 動きのある、点滅している、スクロールする、あるいは自動更新する情報に対しては、それぞれ次のすべてがあてはまる。 (レベル A):
動き、点滅、スクロール: 動きのある、点滅している、あるいはスクロールしている情報が、(1) 自動的に開始し、(2) 5秒よりも長く継続し、そして (3) その他のコンテンツと並行して提示される場合、ユーザがそれらを一時停止、停止、あるいは非表示にすることのできるメカニズムがある。ただし、その動き、点滅、またはスクロールが必要不可欠な動作の一部である場合は除く。
自動更新: 自動更新する情報が、(1) 自動的に開始し、そして (2) その他のコンテンツと並行して提示される場合、ユーザがそれを一時停止、停止、あるいは非表示にする、もしくはその更新頻度を調整することのできるメカニズムがある。ただし、その自動更新が必要不可欠な動作の一部である場合は除く。
注記 1: 明滅する、あるいは閃光を放つコンテンツに関する要件は、ガイドライン 2.3を参照のこと。
注記 2: この達成基準を満たさないコンテンツでは、ユーザがそのページ全体を使用できない恐れがあるため、ウェブページ上のすべてのコンテンツは他の達成基準を満たすために用いられているか否かにかかわらず、この達成基準を満たさなければならない。適合要件 5: 非干渉を参照のこと。
注記 3: 周期的にソフトウェアによって自動的に更新されるコンテンツ、またはユーザエージェントにストリーム配信されるコンテンツは、コンテンツ再生の一時停止と再開の操作の間に生成あるいは受信される情報を保持したり、提示したりする必要はない。これは技術的に不可能であることが考えられ、多くの状況においてユーザの混乱を招くことにつながる可能性があるためである。
注記 4: コンテンツの読み込み中やそれに類似した状況の一部として表示されるアニメーションについては、この段階ですべてのユーザに対していかなる対話も発生する可能性がなく、かつコンテンツ読み込みの進行状況を表示しないことがユーザの混乱を招いたり、コンテンツが動作を停止した、あるいはコンテンツが破損しているという誤解を生じたりする可能性がある場合には、必要不可欠なものと考えることができる。
2.3.1 3回の閃光または閾値以下: ウェブページには、どの1秒間においても3回を超える閃光を放つものがない。あるいは、閃光は一般閃光閾値および赤色閃光閾値を下回っている。 (レベル A)
注記: この達成基準を満たさないコンテンツでは、ユーザがそのページ全体を使用できない恐れがあるため、Webページ上のすべてのコンテンツは他の達成基準を満たすために用いられているか否かにかかわらず、この達成基準を満たさなければならない。適合要件 5: 非干渉を参照のこと。
3.1.3 一般的ではない用語: 慣用句および専門用語を含めて、一般的には使われることのない、または限定された用法で使われている単語あるいは語句の特定の定義を示すメカニズムが利用可能である。 (レベル AAA)
3.1.6 発音(読み仮名): 文脈において、発音が分からないと単語の意味が不明瞭になる場合、その単語の特定の発音(読み仮名)を示すメカニズムが利用可能である。 (レベル AAA)
3.2.1 オン・フォーカスによる状況の変化: あらゆる要素がフォーカスを受け取る際、状況の変化を引き起こさない。 (レベル A)
3.2.2 ユーザインタフェース要素による状況の変化: ユーザが使用する前にその挙動を知らせてある場合を除いて、ユーザインタフェース要素の設定を変更することで状況の変化を引き起こさない。 (レベル A)
3.3.1 入力エラー箇所の特定: 入力エラーを自動的に発見した場合は、エラーとなっているアイテムを特定し、そのエラーをユーザにテキストで説明する。 (レベル A)
3.3.2 ラベルまたは説明文: コンテンツがユーザの入力を要求する際は、入力箇所のラベルまたは入力方法の説明文を提供する。 (レベル A)
3.3.3 入力エラー修正方法の提示: 入力エラーを自動的に発見した場合は、その修正方法が明らかであれば、その方法をユーザに提示する。ただし、セキュリティあるいはコンテンツの目的を損なう場合は除く。 (レベル AA)
3.3.4 法的義務・金銭的取引・データ変更・回答送信のエラー回避: ユーザにとって法的な義務または金銭的な取引が生じる、データのストレージシステムにあるユーザが自分で管理可能なデータを変更または削除する、あるいはユーザが試験の回答を送信するウェブページでは、次の少なくとも1つが当てはまる (レベル AA):
4.1.1 構文解析: マークアップ言語を用いて実装されているコンテンツにおいては、仕様で認められているものを除いて、要素には完全な開始タグおよび終了タグがあり、要素は仕様に準じて入れ子になっていて、要素には重複した属性がなく、どのIDも固有である。 (レベル A)
注記: 閉じる山括弧(">")や不一致な属性値の引用符のように、その記述において重要な文字のない開始および終了タグは完全ではない。
4.1.2 プログラムで解釈可能な識別名・役割及び設定可能な値: すべてのユーザインタフェース要素(フォーム要素、リンク、そしてスクリプトが生成するコンポーネントなどを含む)では、識別名および役割がプログラムで解釈可能である。また、ユーザが設定可能なステータス、プロパティ、そして値はプログラムで設定できる。そして、支援技術を含むユーザエージェントがこれらの項目が変更された通知を受け取ることができる。 (レベル A)
注記: この達成基準は、主に独自のユーザインタフェース要素を開発したりスクリプトを書いたりするコンテンツ制作者に向けたものである。例えば、標準的なHTMLのコントロールは、仕様に準じていればそれで既にこの達成基準を満たしていることになる。
この節は、規定である。
この節では、WCAG 2.0への適合性に関する要件を列挙している。また、任意である適合宣言の方法についての情報も提供している。最後に、アクセシビリティ・サポーテッドとは何かを説明する。なぜならば、適合においては技術のアクセシビリティ・サポーテッドな使用法だけに依存することができるからである。適合性を理解するには、アクセシビリティ・サポーテッドという概念についてさらに詳しい説明がある。
ウェブページが WCAG 2.0 に適合するためには、以下に挙げる適合要件のすべてが満たされていなければならない:
1. 適合レベル: 以下に挙げる適合レベルの1つが完全に満たされていること。
レベル A: レベル A(適合の最低レベル)で適合するには、ウェブページがすべてのレベル A 達成基準を満たすか、あるいは適合した代替バージョンを提供する。
レベル AA: レベル AA で適合するには、ウェブページはすべてのレベル A およびレベル AA 達成基準を満たすか、あるいはレベル AA に適合した代替バージョンを提供する。
レベル AAA: レベル AAA で適合するには、ウェブページがすべてのレベル A、レベル AA、およびレベル AAA 達成基準を満たすか、あるいはレベル AAA に適合した代替バージョンを提供する。
注記 1: 適合には宣言したレベルのみを達成すればよいが、コンテンツ制作者は、達成した適合レベルよりも上のレベルの達成基準にも適合していれば、その達成基準すべてを(その適合宣言の中で)報告することを推奨する。
注記 2: レベル AAA 適合をサイト全体の基本的なポリシーとして要求することは推奨しない。なぜなら、コンテンツによっては、レベル AAA の達成基準をすべて満たすことができないからである。
2. ページ全体: 適合性(および適合レベル)はウェブページ全体のみに対するものであり、ウェブページの一部が除外されている場合には認められない。
注記 1: 適合性を判断する際に、代替がそのページから直接得られる場合は、ページの一部のコンテンツに対する代替をそのページの一部であるとみなす。例えば、長い説明文や映像の代替表現など。
注記 2: コンテンツ制作者が制御できないコンテンツがあるために適合できないウェブページのコンテンツ制作者は、部分適合の説明を考慮するとよい。
3. 一連のプロセス: ウェブページがプロセスを提示する一連の流れのページ群(つまり、ユーザがある目的を達するために完了させる必要のある一連の手順)に含まれる場合、そのプロセス中のすべてのウェブページが指定したレベルまたはそれ以上のレベルで適合している(もし、プロセス中のページがそのレベルまたはそれ以上のレベルに適合していなければ、特定のレベルに適合できない)。
事例: オンラインストアに、製品を選択して購入するために用いられている一連のページがあるとする。この場合、すべてのページが適合すべきプロセスの一部なので、最初から最後(支払い)まで一連のすべてのページが、適合していること。
4. 技術のアクセシビリティ・サポーテッドな使用法のみ: 達成基準を満たすためには、用いる技術のアクセシビリティ・サポーテッドな使用法だけに依存することができる。アクセシビリティ・サポーテッドではない技術で提供されている情報あるいは機能は、アクセシビリティ・サポーテッドな方法でも利用可能である(「アクセシビリティ・サポーテッド」を理解するを参照のこと)。
5. 非干渉: もし技術がアクセシビリティ・サポーテッドではない方法で用いられている、あるいは技術が WCAG 2.0 に適合していない状態で用いられている場合、ユーザがページの残りの部分へアクセスすることを妨げていない。加えて、全体としてウェブページは、以下のそれぞれの条件の下で適合要件を満たしている:
依存していないあらゆる技術が、ユーザエージェントでオンになっているとき
依存していないあらゆる技術が、ユーザエージェントでオフになっているとき、および
依存していないあらゆる技術が、ユーザエージェントでサポートされていないとき
さらに、適合性を満たすのに依存していないコンテンツも含めて、以下の達成基準はページ上の全てのコンテンツに適用される。なぜなら、これらを満たさないことはページの利用を妨げる可能性があるからである:
1.4.2 - Audio Control、
2.1.2 - No Keyboard Trap、
2.3.1 - Three Flashes or Below Threshold、および
2.2.2 - Pause, Stop, Hide
注記: もし、あるページが適合できないならば(例えば、適合しない悪い事例を紹介するためのページも含む)、そのページを適合あるいは適合宣言の範囲に含めることはできない。
事例も含む、より詳細な情報は、「適合要件」を理解する(英語)を参照のこと。
適合性は、ウェブページに対してのみ定義されている。しかし、適合宣言は1ページ、一連のページ群、または複数の関連するウェブページに対して行ってもよい。
適合宣言は、必須ではない。コンテンツ制作者は、適合宣言をしなくても、WCAG 2.0 に適合することができる。しかし、もし適合宣言をする場合には、その適合宣言には以下に挙げる情報が含まれていなければならない:
宣言の日付
ガイドライン名、バージョン、および URI :例えば、「ウェブコンテンツ・アクセシビリティ・ガイドライン 2.0(http://www.w3.org/TR/2008/REC-WCAG20-20081211/)」
満たしている適合レベル:(レベル A、AA、あるいは AAA)
ウェブページの簡潔な説明: 例えば、宣言している URI のリスト。サブドメインがその宣言に含まれているかどうかの説明も含む。
注記 1: ウェブページは、リストを用いて説明してもよいし、あるいは宣言に含まれる URI のすべてを説明する表現によって説明してもよい。
注記 2: 顧客がウェブサイト上でインストールするまでは URI のないウェブベースの製品は、その製品はインストールされると適合した状態になる、というような説明文を用いてもよい。
依存している ウェブコンテンツ技術のリスト
注記: 適合性のロゴを使用する場合、それで適合を宣言していることとなり、上記の適合宣言の必須要素を明示しなければならない。
前述の適合宣言の必須要素に加えて、ユーザのために追加で情報を提供することを検討するとよい。追加する情報として推奨するものを以下に挙げる:
適合宣言したレベル以上で満たしている達成基準のリスト。この情報は、ユーザが使用できる形式で提供すべきで、機械的に読み取れるメタデータが好ましい。
"使用しているが依存していない" 特定の技術のリスト。
コンテンツを検証するのに用いた、支援技術を含むユーザエージェントのリスト。
アクセシビリティを向上するために達成基準以上に追加で施した措置に関する情報。
依存している特定の技術を示したリストの機械的に読み取れるメタデータ版。
適合宣言の機械的に読み取れるメタデータ版。
注記 1: より多くの情報や適合宣言の事例は、「適合宣言」を理解する(英語)を参照のこと。
注記 2: 適合宣言内でのメタデータの使用に関する詳細な情報は、「メタデータ」を理解する(英語)を参照のこと。
公開後にコンテンツが追加されるウェブページを制作することもある。例えば、電子メールのプログラム、ブログ、ユーザがコメントを追加できる記事、あるいはユーザがコンテンツを提供できるようなアプリケーションである。その他の例としては、複数の提供者から集めたコンテンツで構成されるポータルやニュースサイト、あるいは動的に挿入される広告のように他の情報源から何度もコンテンツが自動的に挿入されるサイトが挙げられる。
これらの場合、最初に掲載した時点では、そのページの制御していないコンテンツがどのようになっていくか分からない。制御していないコンテンツが、制御しているコンテンツのアクセシビリティにも影響を及ぼす可能性があることに注意することが重要である。そこで、2つの選択肢がある:
適合性の判断は、分かる範囲で下すことができる。もしこの種のページが監視されていて、2営業日以内に修正される(適合していないコンテンツを削除するか、適合させる)ならば、そのページは適合しているとみなすことができ、発見したときに修正されたり削除されたりする外部から提供されたコンテンツにおける不具合は除いて、適合性の判断あるいは宣言を行うことができる。ただし、適合していないコンテンツを監視したり修正したりできないのであれば、適合宣言を行うことはできない。
もしくは、
そのページ全体としては適合していないが、特定の部分を除けば適合していることになる、という意味の "部分適合の説明" をしてもよい。そのような場合の記述は、「このページ全体としては適合していないが、制御していないソースによる以下の部分を除けば、WCAG 2.0 のレベル X で適合していることになる。」というような形式になる。加えて、次に挙げるものも、部分適合の説明に記述される、制御していないコンテンツに当てはまる:
コンテンツ制作者の制御できるコンテンツではない。
ユーザが識別できるように説明されている(該当箇所が明確に示されていなければ、"私たちが制御できない部分すべて" という説明だけでは不十分である)。
そのページは適合していないが、もしアクセシビリティ・サポートがページ上で用いられている言語(のすべて)に存在していれば適合している場合には、"言語による部分適合の説明" をしてもよい。その記述の形式は、「このページは適合していないが、もし以下の言語にアクセシビリティ・サポートがあれば、WCAG 2.0 にレベル X で適合していることになる:」というようになる。
この節は、規定である。
単語、語句、あるいは名称の短縮形で、その略語が言語の一部になっていないもの。
注記 1:これには、以下のような頭文字語および頭字語を含む:
頭文字語は、その名称あるいは語句に含まれる単語や音節の頭文字による、名称あるいは語句の短縮形である。
注記 1:すべての言語で定義されているわけではない。
事例 1: SNCFは、フランス語の頭文字語で、フランス国有鉄道の "Société Nationale des Chemins de Fer" の頭文字を含んでいる。
事例 2: ESPは、"extrasensory perception"(超感覚的知覚)の頭文字語である。
頭字語は、(名称や語句にある)頭文字あるいは他の単語の一部で一つの単語のように発音されるような省略形である。
事例: NOAAは、米国の "National Oceanic and Atmospheric Administration" の頭文字による頭字語である。
注記 2: 会社名の頭字語だったものをそのまま会社名とする会社がある。そのような場合、その会社の新しい名前は単語(例:Ecma)であり、その単語はもはや頭字語ではない。
ブラウザおよびその他のユーザエージェントにあるアクセシビリティ機能と同様に、ユーザの支援技術でもサポートされている。
ウェブコンテンツ技術(あるいは、技術の機能)のアクセシビリティ・サポーテッドな使用であると見なすには、次の 1. と 2. の両方がそのウェブコンテンツ技術(あるいは、機能)で満たされなければならない:
ウェブコンテンツ技術の使用法が、ユーザの支援技術(AT)によりサポートされていなければならない。これは、その技術の使用法がコンテンツの自然言語においてユーザの支援技術との相互運用性を検証されていることを意味する。
かつ
そのウェブコンテンツ技術には、ユーザが利用可能で、アクセシビリティ・サポーテッドでもあるユーザエージェントがなければならない。これは、少なくとも次の1つが当てはまることを意味する:
その技術が、アクセシビリティ・サポーテッドな広く配布されているユーザエージェントで自然にサポートされている(例えば、HTML や CSS など)。Thetechnology is supported natively in widely-distributed user agents that are also accessibility supported (such as HTML and CSS);
もしくは、
その技術が、アクセシビリティ・サポーテッドな広く配布されているプラグインでサポートされている。
もしくは、
そのコンテンツが、例えば大学あるいは企業内ネットワークのような閉じた環境で利用可能であって、その技術が必要とし、その組織で使用されているユーザエージェントもアクセシビリティ・サポーテッドである。
もしくは、
その技術をサポートするユーザエージェントが、アクセシビリティ・サポーテッドであって、次のようにダウンロードあるいは購入可能である:
障害のない人よりも障害のある人に時間や労力がかかるようなことはなく、かつ、
障害のない人と同じくらい容易に障害のある人も探して入手することができる。
注記 1: WCAG ワーキンググループならびに W3C は、ウェブ技術のある特定の使用法がアクセシビリティ・サポーテッドであると分類するために、そのウェブ技術の特定の使用法に対して、どの支援技術のサポートあるいは支援技術によるどれだけのサポートがなければならないのかを指定しない(「アクセシビリティ・サポート」に必要な支援技術サポートのレベルを参照のこと)。
注記 2: そのウェブ技術に依存していなくて、適合要件 4:技術のアクセシビリティ・サポーテッドな使用法のみおよび適合要件 5: 非干渉を含む適合要件をページ全体が満たしているかぎり、そのウェブ技術をアクセシビリティ・サポーテッドではない方法で用いることができる。
注記 3: ウェブ技術がアクセシビリティ・サポーテッドな方法で用いられている際、その技術全体あるいはその技術の使用すべてがサポートされているということを暗に示すわけではない。ほとんどの技術は、HTML を含めて、少なくとも 1つの機能あるいは使用に対するサポートを欠いている。技術のアクセシビリティ・サポーテッドな使用法が、WCAG の要件を満たすために依存しうる場合のみ、ページは WCAG に適合する。
注記 4: 複数のバージョンを有するウェブコンテンツ技術を挙げる際は、アクセシビリティ・サポーテッドなバージョンを特定すべきである。
注記 5: コンテンツ制作者が技術のアクセシビリティ・サポーテッドな使用法を見つける方法の一つに、アクセシビリティ・サポーテッドであることが文書化されている使用法の資料を参考にすることである(ウェブ技術のアクセシビリティ・サポーテッドな使用法を理解するを参照のこと)。コンテンツ制作者、企業、技術ベンダー、あるいはその他の者が、ウェブコンテンツ技術のアクセシビリティ・サポーテッドな使用法を文書化してもよい。しかし、文書中の技術の使用法すべては、前述のアクセシビリティ・サポーテッドなウェブコンテンツ技術の定義を満たしていなければならない。
時間に伴って変化する視覚的および聴覚的情報のトランスクリプトを含み、時間に伴って変化する情報のやりとりの結果を得る手段を提供する文書。
注記:同期したメディアのコンテンツを作るために用いられる脚本は、編集後の最終的な同期したメディアを正確に描写したものに訂正されている場合のみ、この定義を満たすことになる。
リンクおよびリンクと同時にユーザに提供されているウェブページのすべての情報からその目的が断定できない(すなわち、障害のないユーザでも、そのリンクがどうなるかがはそれを選択するまでは分からない)。
事例:「注目すべき輸出品はグァバです。」という文中にある "グァバ" という単語がリンクだとする。そのリンクは、グァバの定義、輸出されているグァバの量を挙げる図表、あるいはグァバを収穫している人々の写真へリンクされているかもしれない。そのリンクを選択するまでは、すべてのユーザが分からず、障害のあるユーザだけが不利な立場になるわけではない。
文字あるいは記号文字(通常は、ASCIIで定義されている95の印字)の空間的配置による図画
ユーザエージェントとして機能する、あるいは主流のユーザエージェントと一緒に機能するハードウェアおよび/あるいはソフトウェアで、主流のユーザエージェントで提供されている機能以上である障害者ユーザの要求を満たすために機能を提供するもの。
注記 1: 代替のプレゼンテーション(例:合成音声や拡大表示したコンテンツ)、代替入力手法(例:音声認識)、付加的なナビゲーションあるいは位置確認のメカニズム、およびコンテンツ変換(例:テーブルをよりアクセシブルにするもの)を含めて支援技術により提供される機能。
注記 2: 支援技術は、API を用いて監視することで、主流のユーザエージェントとデータやメッセージのやりとりをすることが多い。
注記 3: 主流のユーザエージェントと支援技術とを区別するのに、絶対的な基準などはない。多くの主流のユーザエージェントは、障害者を支援する機能を提供している。基本的な差異は、主流のユーザエージェントが障害のある人もない人も含めて、広く多様なユーザをターゲットにしているのに対し、支援技術は、特定の障害のあるユーザという狭義の限られた人たちをターゲットにしているということだ。支援技術により提供される支援は、そのターゲットユーザのニーズにより特化しており適切なものである。主流のユーザエージェントは、プログラムのオブジェクトからウェブコンテンツを取り出したり、マークアップを識別可能な構造に解釈したりするようにして、重要な機能を支援技術に提供することができる。
事例: この文書の文脈において重要な支援技術としては、以下のものが挙げられる:
画面拡大ソフトおよびその他の視覚的な表示に関する支援技術。視覚障害、知覚障害、および読書困難などの障害のある人が、レンダリング後のテキストおよび画像の視覚的な読みやすさを改善するために、テキストのフォント、サイズ、間隔、色、音声との同期などを変更するのに使用している。
スクリーンリーダー。全盲の人がテキスト情報を合成音声あるいは点字で読み取るために使用している。
音声変換ソフトウェア。認知障害、言語障害、および学習障害のある人が、テキストを合成音声に変換するために使用している。
音声認識ソフトウェア。何らかの身体障害のあるユーザが使用することがある。
代替キーボード。特定の身体障害のある人がキーボードを擬似操作するのに使用している(ヘッドポインタ、シングルスイッチ、呼気・吸気スイッチ、およびその他の特別な入力デバイスを使った代替キーボードを含む)。
代替ポインティングデバイス。特定の身体障害のある人がマウスポインタとボタンを擬似操作するのに使用している。
音声再生の技術。
注記: 音声は、合成的に生成されたものであったり(音声合成を含む)、実世界で録音したものであったり、またその両方もありうる。
音声トラックに追加されたナレーションで、主音声のトラックだけでは理解できない重要で視覚的な細部を説明するもの。
注意を引くように、2つの視覚的な状態を交互に切り替えること。
注記: 閃光も参照のこと。(ある頻度で、ある程度以上に大きく、明るく点滅することによって、閃光として分類されることもありうる。)
テキストの一文よりも長いもの。
"Completely Automated Public Turing test to tell Computers and Humans Apart"(コンピュータと人間とを判別する完全自動化されたチューリングテスト)の頭文字語。
注記 1: CAPTCHA テストは、不明瞭な画像あるいは音声ファイルで提示される文字をユーザに入力するよう求めることが多い。
注記 2: チューリングテストは、人間とコンピュータを判別するために設計されたテストの仕組みである。その名は、これを考案した有名なコンピュータ科学者のアラン・チューリングにちなんで名付けられた。この用語は、カーネギーメロン大学の研究者たちによる造語であった。[CAPTCHA]
そのメディアのコンテンツを理解するのに必要な、発話および発話ではない音声情報の両方に対する、同期した視覚的表現あるいは代替テキスト。
注記 1: キャプションは、発話のみの字幕と似ているが、次の点において異なる。キャプションは、発話コンテンツだけでなく、その番組コンテンツを理解するのに必要な、発話ではない音声情報と等価な内容も伝える。つまり、効果音、音楽、笑い声、話者の特定、そして位置なども含まれるのである。
注記 2: クローズド・キャプションは、プレーヤーによっては ON/OFF を切り替えることのできる等価物である。
注記 3: オープン・キャプションは、OFFにすることのできないキャプションである。例えば、キャプションが映像に埋め込まれた、視覚的に等価な画像化された文字である場合がある。
注記 4: キャプションは、映像の関連情報を分かりにくくしたり遮ったりすべきではない。
注記 5: 国によっては、キャプションはサブタイトル(字幕)と呼ばれている。
注記 6: 音声ガイドは既に視覚的に提示されている情報の説明なので、キャプションにしてもよいが、そうする必要があるわけではない。
ウェブページのコンテンツにおける大きな変化で、ユーザが気づかないと、同時にページ全体を見ることのできないユーザを混乱させてしまう恐れのあるもの。
状況における変化には以下に挙げるものの変化が含まれる:
注記: コンテンツの変化が、常に状況の変化であるとはかぎらない。外枠を広げること、動的なメニュー、あるいはタブコントロールのように、コンテンツにおける小さな変化は、それが上記のいずれか(例:フォーカス)を変更しないかぎり、状況を変化させるものではない。
事例: 新しいウィンドウを開くこと、フォーカスを異なる要素へ移動させること、新しいページへ行くこと(新しいページへ行ったかのように思わせてしまうことも含む)、あるいはページの内容を大きく再配置することなどは、状況の変化の事例である。
定められた標準、ガイドライン、あるいは仕様のすべての要件を満たすこと。
以下のようなバージョンのことを指す:
指定されたレベルで適合しており、かつ
適合していないコンテンツと同時に更新されていて、かつ
以下に挙げるうち少なくとも一つが当てはまること:
アクセシビリティ・サポーテッドなメカニズムを用いて、適合していないページから適合しているバージョンへ移動できる。もしくは、
適合しているバージョンからのみ適合していないバージョンへ移動できる。もしくは、
適合しているバージョンへ移動するメカニズムも提供している適合したページからのみ、適合していないバージョンへ移動できる。
注記 1: この定義においては、"・・・からのみ・・・へ移動できる" とは、条件付きのリダイレクトのような何らかのメカニズムがあり、ユーザが特定のページから来ないかぎり、ユーザが適合していないページに "たどり着く"(適合していないページを読み込む)ことがない、ということを意味する。
注記 2: 代替バージョンは、オリジナルのページと全く同じページである必要はない(例:適合した代替バージョンは複数のページであってもよい)。
注記 3: 複数の言語版がある場合は、適合した代替バージョンは提供されている各言語のものが必要となる。
注記 4: さまざまな技術環境あるいはユーザ層に対応するために代替バージョンを提供してもよい。適合要件 1を満たすためには、1つのバージョンが完全に適合したものでなければならない。
注記 5: 適合していないバージョンと同じように自由に利用可能であるかぎり、適合した代替バージョンは、適合範囲内あるいは同じウェブサイト上にさえもある必要はない。
注記 6: 代替バージョンは、元のページを補助して理解を高める補足的なコンテンツと混同されないようにすべきである。
注記 7: 適合したバージョンを作り出すためにコンテンツ内でユーザ選択の設定を行うことは、その選択を設定するのに用いられている手法がアクセシビリティ・サポーテッドであるかぎり、代わりのバージョンへの移動メカニズムとして条件を満たしているといえる。
適合した代替バージョンを理解するを参照のこと。
ユーザエージェントによってユーザに伝達される情報および感覚的な体験で、コンテンツの構造、表現、およびインタラクションを定義するソースコードやマークアップを含む。
そのとき実行されている機能に関する情報を提供するヘルプのテキスト。
注記: 明解なラベルは、状況に応じたヘルプとして機能しうる。
(L1 + 0.05) / (L2 + 0.05)
注記 1: コントラスト比は、1~21の範囲になりうる(通常は、1:1~21:1と記述される)。
注記 2: コンテンツ制作者は、テキストのレンダリング(例:フォントのスムージングやアンチエイリアス)に関するユーザの設定を制御できないため、テキストのコントラスト比はアンチエイリアスをオフにした状態で評価される。
注記 3: 達成基準 1.4.3 および 1.4.6 の目的上、コントラストは通常の使用においてテキストがレンダリングされる際に指定されている背景色に対して測定される。もし背景色の指定がない場合は、背景色には白を想定することになる。
注記 4: 背景色は、テキストが通常の使用においてレンダリングされる際に背景となるコンテンツの指定された色である。テキストの色が指定されている際に背景色が指定されていない場合は問題がある。なぜなら、ユーザのデフォルトの背景色は未知であり、コントラストが十分かどうかを評価することができないからである。同じ理由で、背景色が指定されている際にテキストの色が指定されていない場合も問題ありということになる。
注記 5: 文字の周囲に縁取りがある際、その縁取りがコントラストを強めることもあり、文字とその背景色におけるコントラストの計算に用いられる。ただし、文字の周囲の細い縁取りは文字として扱われる。文字の周囲の太い縁取りが、かさ(暈:ハロー、後光)のようになって、文字の細かい字画を埋めていれば、背景色として考慮されることになる。
注記 6: WCAG への適合は、典型的な表現において隣接すると制作者が想定してコンテンツで指定した色の組み合わせに対して評価されるべきである。制作者は、ユーザエージェントによる色の変更などのように通常とは異なる表現を考慮する必要はない。ただし、それが制作者のソースコードによって起こる場合は除く。
コンテンツの意味を変更しない順番で単語や段落が提示される、あらゆる順序。
健康、安全や財産を守るために直ちに行動をとる必要のある、突然で予期されなかった状況あるいは出来事。
もし取り除いてしまうと、コンテンツの情報あるいは機能を根本的に変えてしまい、かつ、情報および機能が WCAG に適合する他の方法では提供することができない。
追加の説明を付加する時間を作るために映像を一時停止させて、視聴覚のプレゼンテーションに付加した音声ガイド。
十分な大きさがあり、ある周波数において発作を誘発する恐れのある、相対輝度の相反する変化の組合せ。
注記 1: 許容されない閃光のタイプに関する情報は、一般閃光閾値および赤色閃光閾値を参照のこと。
注記 2: 点滅も参照のこと。
ユーザのアクションにより実現可能なプロセスおよび結果。
以下に挙げるうちのいずれかに該当していれば、閃光あるいは急速に変化する画像の連続は、閾値を下回っていることになる(すなわち、コンテンツは基準を満たしている)ことになる:
あらゆる1秒間の間隔において、3つより多くの一般閃光がある。および/または、3つより多くの赤色閃光がある。もしくは、
一般的な画面との距離で、閃光のある領域が、画面上の視野角10度以内で合計0.006ステラジアン(画面上の視野角10度の25%)よりも多くを占めていない。
ただし:
一般閃光とは、暗いほうの相対輝度が0.80未満で、最大相対輝度の10%以上の相対輝度における相反する変化の組合せのことである。および、"相反する変化の組合せ" とは、増加した後に減少する、あるいは減少した後に増加するものを指す。そして、
赤色閃光とは、彩度の高い赤色を含む相反する遷移のあらゆる組合せのことである。
例外: ホワイトノイズあるいは1辺が(典型的な閲覧距離における視野の)0.1度未満の格子縞模様のように、細かくて整っている模様の閃光は、閾値を破ることにはならない。
注記 1: 一般的なソフトウェアやウェブコンテンツでは、コンテンツを 1024 × 768 ピクセルの解像度で閲覧している際の画面上での 341 × 256 ピクセルの矩形が、標準的な画面サイズおよび画面からの距離(例:15~17インチの画面で22~26インチ)における視野角10度に該当する(同じコンテンツでも高解像度のディスプレイでは小さく安全になるので、閾値を定めるには低解像度が用いられている)。
注記 2: 遷移とは、時間に対する相対輝度(赤色閃光の相対輝度/色)測定結果の一部にある隣接した山と谷(上がりと下がり)の間における相対輝度(赤色閃光の相対輝度/色)の変化である。閃光は、2つの相反する遷移から成る。
注記 3: "彩度の高い赤色を含む相反する遷移の組合せ" のその分野における現時点での定義は、各遷移に含まれる状態の一方あるいは双方とも、R / (R+G+B) >= 0.8で、(R-G-B) × 320 の値の変化が双方の遷移において > 20 ((R-G-B) × 320 が負の値になるときはゼロとする)である。R、G、Bの値は、"相対輝度" の定義で定められているように 0~1 の範囲である。[HARDING-BINNIE]
注記 4: ビデオの画面キャプチャから分析を行うツールが入手可能である。しかし、閃光があらゆる1秒間の間隔において3つ以下であれば、ツールでこの条件を満たしているかどうかを確認する必要はない。コンテンツは自動的に条件を満たしたことになるからである(上記 1. および 2. を参照のこと)。
人間とコミュニケーションをとるための言語で、話したり、書いたり、あるいは(視覚的あるいは触覚的な手段で)手話にするもの。
注記: 手話も参照のこと。
個々の単語の意味からはその意味を推測できず、そこにある単語を変えると意味が通じなくなる言い回し。
注記: 慣用句は、単語単位で直接翻訳すると、その(文化的あるいは言語特有の)意味が通じなくなる。
事例 1: 英語では、"spilling the beans"(豆をこぼす) は "revealing a secret"(秘密を漏らす)という意味である。しかし、"knocking over the beans"(豆をひっくり返す)や "spilling the vegetables"(野菜をこぼす)は同じ意味にはならない。
事例 2: 日本語では、「さじを投げる」という言い回しは、逐語訳では "he throws a spoon" となるが、「どうすることもできずに諦める」という意味である。
事例 3: オランダ語では、"Hij ging met de kippen op stok" は、逐語訳すれば "He went to roost with the chickens"(彼はニワトリとねぐらについた)となるが、「彼は早く寝た」という意味である。
特定の視覚的効果を得るために非テキスト形式(例:画像)でレンダリングされる文字
Note: これには、重要なその他の視覚的なコンテンツを含む画像の一部であるテキストは含まれない。
事例: 写真に写っている人の名札にある人名
情報提供を目的にしたものであり、適合するために必須のものではない。
ユーザが提供した情報で、受け付けられないもの。
注記: 以下のものが含まれる:
ウェブページでは必須とされているが、ユーザが入力し忘れた情報
ユーザが入力したが、要求されたデータ形式あるいは値ではない情報
特定の分野の人々が特定の用法で用いる単語
事例: "StickyKeys"(固定キー)という用語は、支援技術 / アクセシビリティの分野における専門用語である。
キーストローク入力を取得するためにソフトウェアが用いるインターフェース。
注記 1: キーボードをもともと含んでいない技術であっても、キーボードインターフェースによってユーザがキーストローク入力をプログラムに提供できるようにする。
事例: タッチスクリーンPDAには、外部キーボードへのコネクタとあわせて、そのOSに組み込まれたキーボード・インターフェースがある。PDA上のアプリケーションはそのインターフェースを用いて、外部キーボード、あるいは手書き解釈プログラムや「キーボード・エミュレーション」機能付きの音声テキスト変換アプリケーションのような擬似キーボード出力を提供する他のアプリケーションのいずれかからキーボード入力を取得することができる。
注記 2: マウスキーのようなキーボード操作によるマウス・エミュレータによるアプリケーション(あるいは、そのアプリケーションの一部)の操作は、キーボード・インターフェースからの操作として見なされていない。それはプログラムの操作がキーボード・インターフェースからではなく、そのポインティング・デバイスからの操作だからである。
ウェブコンテンツにある構成要素を識別するために、ユーザに提示されているテキスト、あるいは代替テキストのある構成要素。
注記 1: ラベルはすべてのユーザに提示されるが、識別名は隠されていて支援技術に対してのみ明らかにされる。多くの場合(すべてではないが)、識別名とラベルは同じである。
注記 2: ラベルという用語は、HTML における label 要素だけに限定されない。
少なくとも18ポイント、もしくは14ポイントの太字。あるいは、中国語、日本語、そして韓国語のフォントではそれと同等の文字サイズ。
注記 1: 特別に細い線のフォント、あるいは文字の形が分かりにくくなるような独特の見た目や特徴のあるフォントは、コントラストが低いとき特に読みづらい。
注記 2: ここでいう文字サイズは、コンテンツが提供される際のサイズである。ユーザによって変更されたサイズは含まれない。
注記 3: 文字の実際のサイズは、コンテンツ制作者が指定したサイズとユーザのディスプレイあるいはユーザエージェントの設定の両方に依存している。多くの主流となっている本文フォントにおいて、本文テキストのデフォルトのサイズは、14ポイントと18ポイントは、1.2emと1.5em、または、(本文フォントが100%であると仮定して)デフォルトサイズの120%と150%に、おおよそ同等である。しかし、制作者は、使用する特定のフォントについて、このことをチェックしておく必要がある。フォントが相対単位で定義されている時、実際の文字ポイントのサイズは、表示画面のため、ユーザエージェントによって計算される。この評価基準を評価する時には、文字ポイントのサイズは、ユーザエージェントから取得されるべきであり、またはユーザエージェントが行うフォントの計算基準に基づいて計算するべきである。ロービジョンのユーザに対しては、自分で適切な設定を選択することを想定している。
注記 4: フォントサイズを指定せずにテキストを用いる際は、サイズを指定していないテキストに対して主要ブラウザで用いられる最小のフォントサイズをそのテキストのサイズとみなすのが妥当であろう。もし、レベル1の見出しが、主要なブラウザで14ポイントの太字あるいはそれ以上のサイズでレンダリングされるならば、それは「サイズの大きな」テキストであると考えてよい。相対的な拡大縮小は、同じやり方でそのデフォルトのサイズから算出することが可能である。
注記 5: ローマ字のテキストにおける18ポイントおよび14ポイントのサイズは、拡大印刷の最小サイズ(14ポイント)と標準的な大きい文字サイズ(18ポイント)からきている。例えば、中国語、日本語、韓国語など、その他の文字については、「同等な」サイズはその言語での拡大印刷の最小サイズと拡大印刷でその次に大きな標準のサイズとなる。
法的に拘束力のある義務あるいは利益が発生する取引。
事例: 結婚許可証、株取引(金銭上および法的)、遺言、ローン、採用、軍隊への入隊登録、あらゆる契約、など
ハイパーリンクを起動することで得られる結果の本質。
実世界のイベントから取り込まれ、放送による遅延があるだけで受け手に送信される情報。
注記 1: 放送の遅延は、時間的に短い(通常は自動的な)遅れで、例えば放送局に音声(あるいは映像)を待ち行列に入れる、あるいは検閲する時間を与えるために用いられるものだが、編集できるほどの長さではない。
注記 2: もし情報が完全にコンピュータで生成されたものならば、それはライブではない。
6年間の学校教育後に始まり、初等教育の開始から9年後に終わる、2年間あるいは3年間の教育。
注記: この定義は、教育の国際標準分類(International Standard Classification of Education)[UNESCO]をもとにしている。
結果を得るためのプロセスあるいはテクニック。
テキストで(直接あるいは代替テキストによって)既に提示されている情報以上のものは提示していないメディア。
注記: テキストの代替メディアは、テキストの代替プレゼンテーションの恩恵を受ける人たちのために提供される。テキストの代替メディアになるのは、音声しか含まないメディア、映像しか含まないメディア(手話の映像を含む)、あるいは音声付映像メディアである。
ソフトウェアがウェブコンテンツ内の構成要素をユーザに識別させることのできるテキスト
注記 1: 識別名は隠されていて、支援技術に対してのみ明らかにされるが、ラベルはすべてのユーザに提示される。多くの場合(すべてではないが)、ラベルと識別名は同じである。
注記 2: これは、HTML の name 属性とは関係がない。
キーボードインターフェースを用いてフォーカスを前進させるために指定された順序でナビゲート。
プログラムで解釈できる文字の並びではないコンテンツ、あるいはその文字の並びが自然言語で何も表現していないコンテンツ。
注記: これには、(文字で作る模様である)ASCII アート、顔文字、(当て字を用いる)リート語、そして文字を表現している画像が含まれる。
適合に必須とされるもの
注記 1: このガイドラインには、さまざまな明確な方法で適合することができる。
注記 2: "参考情報" あるいは "非規定" となっている部分は、適合のためには必須ではない。
最も一般的なデスクトップ/ラップトップのディスプレイで、ビューポート(情報の表示域)を最大化した状態。
注記: ユーザは一般的にコンピュータを数年間使い続けるので、最新のデスクトップやラップトップの画面解像度を基準にするのではなく、数年間にわたって一般的なデスクトップやラップトップの画面解像度を考慮するのが最もよい。
ユーザの要求により停止し、ユーザの要求があるまで再開しない。
ライブではない情報。
ユーザが知覚できる形でのコンテンツのレンダリング。
5~7歳の間に始まる6年間で、その前には教育を受けた期間がないとされる。
注記: この定義は、教育の国際標準分類(International Standard Classification of Education)[UNESCO]をもとにしている。
ある目的を達するために必須の各アクションから成るユーザのアクションの連続。
事例 1: ショッピングサイト上の一連のウェブページで目的を果たすためには、ユーザが選択肢となりうる製品、価格および内容を閲覧し、製品を選択して、注文を送信し、配送先情報および支払情報を提供する必要がある。
事例 2: アカウント登録ページでは、登録フォームにアクセスする前にチューリングテスト(訳注:CAPTCHAなど)を完了させる必要がある。
コンテンツ制作者が提供したデータからソフトウェアが解釈できること。また、その際に、支援技術を含むさまざまなユーザエージェントが、この情報を抽出してユーザにさまざまなモダリティで提示できること。
事例 1: マークアップ言語では、一般に入手可能な支援技術が、要素および属性に直接アクセスすることにより解釈できる。
事例 2: 非マークアップ言語では、技術特有のデータ構造から、一般に入手可能な支援技術がサポートするアクセシビリティ API を通じて支援技術に提供される。
リンクとの関係性からプログラムで解釈したり、リンクテキストと併用したり、異なるモダリティでユーザに提示したりすることが可能な補足情報。
事例: HTMLでは、英語でリンクからプログラムで解釈可能な情報には、そのリンクと同じ段落、リスト、あるいはテーブルのセルにあるテキスト、あるいはリンクのあるテーブルのセルと関連付けられたテーブルの見出しセルにあるテキストなどがある。
注記: スクリーンリーダーは句読点を解釈するので、フォーカスが文中のリンクにあるときには、その文から文脈を提供することも可能である。
支援技術を含むユーザエージェントがサポートしている手法を用いてソフトウェアが設定する。
美的な目的だけを果たしていて、情報は提供せず、機能性も備えていない。
注記: その単語を手直ししたり置き換えたりしてもその目的が変わらないのであれば、テキストは単に装飾だけを目的にしたものといえる。
事例: 辞書の表紙には、その背景にとても淡い文字で単語がランダムに並んでいる。
a) 閲覧しているのと同時に発生するイベントで、b) コンテンツによって完全に生成されるものではないイベント。
事例 1: ライブパフォーマンスのウェブ放送(閲覧と同時に発生していて、収録済ではない)。
事例 2: ユーザが入札するオンラインのオークション(閲覧と同時に発生している)。
事例 3: アバターを用いたバーチャルな世界での互いのやりとり(コンテンツによって完全に生成されるものではなく、閲覧と同時に発生する)。
コンテンツの異なる部分間における意味のある関係。
色空間内のすべての点の相対輝度。もっとも暗い黒を0とし、もっとも明るい白を1とする。
注記 1: sRGB色空間においては、色の相対輝度は、L = 0.2126 * R + 0.7152 * G + 0.0722 * B と定義されており、R, G および B は以下のように定義される:
if RsRGB <= 0.03928 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4
if GsRGB <= 0.03928 then G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ^ 2.4
if BsRGB <= 0.03928 then B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ^ 2.4
そして、RsRGB、GsRGB、および BsRGB は、次のように定義される:
RsRGB = R8bit/255
GsRGB = G8bit/255
BsRGB = B8bit/255
注記 2: ウェブコンテンツを閲覧するのに今日用いられているほとんどすべてのシステムは、sRGBエンコーディングを前提としている。コンテンツを処理して表示するのに他の色空間が用いられているのでなければ、コンテンツ制作者はsRGB色空間を用いて検証すべきである。もしその他の色空間を用いるのであれば、達成基準 1.4.3 を理解する(英語)を参照のこと。
注記 3: ディザリングが発生する場合は、元の色の値が用いられる。発生源でディザリングしている色については、用いられている色の平均値を用いるべきである(Rの平均値、Gの平均値、およびBの平均値)。
注記 4: コントラストおよび閃光を検証する際には、自動的に検証してくれるツールがある。
注記 5: 相対輝度定義のMathMLバージョン(英語:XMLファイル)も参照可能である。
ソフトウェアがウェブコンテンツにある構成要素の機能を識別できるためのテキストあるいは数字。
事例: 画像が、ハイパーリンク、コマンドボタン、あるいはチェックボックスのどれなのかを示している数字。
使うと同じ結果が得られる。
事例: あるウェブページ上にある "検索" ボタンと他のウェブページ上にある "さがす" ボタンは、どちらもキーワードを入力するテキストフィールドがあり、そのウェブサイトにある入力されたキーワードに関係のあるコンテンツをリスト表示する。この場合、同じ機能性を有しながらも、ラベルは一貫していないことになる。
他のアイテムと相対的に同じ位置。
注記: たとえ、他のアイテムが元の順序から挿入されていたり削除されていたりしたとしても、アイテムは相対的に同じ順序になっていると考えられる。例えば、展開するナビゲーションメニューは詳細を示すレベルを追加して挿入することがあり、派生したナビゲーション部分が音声読み上げ順序の中に挿入される。
ページに適用した際、その達成基準が "不合格" と判定されない
1つ以上の関連するトピックあるいは考えを扱う自己完結的なコンテンツの一部。
注記: セクションは1つ以上の段落から成り、グラフィック、表、リスト、およびサブセクションを含む。
共通の目的を共有し、同じコンテンツ制作者、グループ、あるいは組織により制作されたウェブページの集合。
注記: 異なる言語のバージョンは、違うウェブページ一式と見なされるであろう。
手と腕、顔の表情、あるいは身体の位置などの動きを組み合わせて意味を伝える言語。
ある言語、通常は話し言葉を、手話に訳すこと。
注記: 本来の手話は、同じ国や地域の話し言葉とは関係のない独立したものである。
単に装飾だけを目的にしたものではなく、また第一に重要な情報を伝えたり機能を提供したりするものではない感覚的な体験。
事例: フルートのソロ演奏、視覚芸術の作品などが例として挙げられる。
元のコンテンツを説明したり、より明確にしたりするために付加されたコンテンツ。
情報や時間経過をベースにしたインタラクティブな構成要素を提示するために、他のフォーマットと同期した音声または映像。ただし、そのメディアがテキストの代替メディアではっきりとそのようにラベル付けされているものは除く。
ユーザエージェントによりレンダリング、再生、または実行される符号化手順のメカニズム。
注記 1: このガイドラインで用いられている "ウェブ技術" および(単独で用いられている)"技術" という用語は、どちらもウェブコンテンツ技術を指す。
注記 2: ウェブコンテンツ技術には、マークアップ言語、データ形式、あるいはプログラム言語が含まれる。静的なウェブページから、同期したメディアによるプレゼンテーション、動的なウェブアプリケーションに至るまでのエンドユーザの体験を創り出すために、コンテンツ制作者はウェブコンテンツ技術を単独あるいは複数の組み合わせで用いる。
事例: ウェブコンテンツ技術のよくある事例としては、HTML、CSS、SVG、PNG、PDF、Flash、そして JavaScript が挙げられる。
非テキストコンテンツとプログラムで関連付けられている、あるいは非テキストコンテンツとプログラムで関連付けられているテキストから参照されるテキスト。プログラムで関連付けられたテキストとは、その場所が非テキストコンテンツからプログラムで定めることのできるテキストである。
事例: チャートの画像は、チャートの直後にある段落でテキストで説明されている。チャートの簡潔な代替テキストは、説明が後に続くことを示している。
注記: より詳細な情報は、代替テキストを理解する(英語)を参照のこと。
そのコンテンツを正しく理解するために、そこではどの定義が適用されるのかをユーザが知っていることを要求するように用いられる用語。
事例: "gig" という用語は、音楽コンサートの話の中で使われている場合は、コンピュータのハードディスクドライブの容量に関する記事で使われている場合とは違うことを意味するが、適切な定義は文脈により決まってくる。それに対して、"text" という用語は、WCAG 2.0では非常に特殊な使われ方をしているので、その定義が用語集で提供されている。
ウェブコンテンツを抽出してユーザに提示するあらゆるソフトウェア。
事例: ウェブコンテンツの抽出、レンダリング、そしてインタラクションを支援する、ウェブブラウザ、メディアプレーヤー、プラグイン、およびその他のプログラムで、支援技術も含まれる。
ユーザがアクセスすることを目的にしたデータ。
注記: これは、インターネットのログや検索エンジンの監視データのようなものは指していない。
事例: ユーザアカウントのための氏名と住所のフィールド。
特定の機能を果たすために単一のコントロールとしてユーザが知覚する、コンテンツの一部分。
注記 1: 複数のユーザインターフェース要素が単一のプログラム的要素として実装されることがある。ここでいう要素は、プログラミングテクニックではなく、別々のコントロールとしてユーザが知覚するものを指す。
注記 2: ユーザインターフェース要素には、スクリプトで生成されるコンポーネントやフォーム要素、リンクが含まれる。
事例: アプレットには、コンテンツ内を行ごと、ページごと、あるいはランダムに移動するために用いられる "コントロール" がある。これらはどれも識別名があり、個別に設定可能なので、それぞれが "ユーザインターフェース要素" となる。
連続した写真や画像を動かす技術。
注記: 映像は、アニメあるいは写真の画像、もしくはその両方で構成可能である。
ユーザエージェントがコンテンツを提示するオブジェクト。
注記 1: ユーザエージェントは、 1つ以上のビューポートでコンテンツを提示する。ビューポートには、ウィンドウ、フレーム、スピーカー、そして拡大鏡ソフトなどがある。ビューポートは、他のビューポートを含んでいることがある(例:入れ子のフレーム)。プロンプト、メニュー、アラートボックスのようなユーザエージェントのユーザインターフェースのコントロールは、ビューポートではない。
注記 2: この定義は、ユーザエージェント・アクセシビリティ・ガイドライン 1.0 用語集(英語)をもとにしている。
フォント、サイズ、色、および背景を設定可能。
HTTP によって単一の URI から得られる埋め込みではないリソースと、レンダリングに用いられたり、ユーザエージェントで一緒にレンダリングされる目的で用いられたりしているその他のリソース。
注記 1: どのような "その他のリソース" も第一のリソースと一緒にレンダリングされるであろうが、必ずしもお互いが同時にレンダリングされる必要があるわけではない。
注記 2: このガイドラインに適合する目的において、ウェブページと見なされる適合範囲内ではリソースは『埋め込みではない』ものでなければならない。
事例 1: すべての埋め込まれた画像とメディアを含んだウェブリソース。
事例 2: Ajaxを用いたウェブメールのプログラム。そのプログラムは http://example.com/mail に存在しているが、受信箱、アドレス帳、そしてカレンダーがある。受信箱、アドレス帳やカレンダーを起動するリンクあるいはボタンがあるが、ページ全体の URI は変わらない。
事例 3: カスタマイズ可能なポータルサイトで、ユーザがさまざまなコンテンツのモジュール一式の中から表示させるコンテンツを選択できる。
事例 4: ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、 ウェブサイトの中のほんの1ページなのかもしれない。
この節は、参考情報である。
この文書の発行にあたっては、契約番号 ED05CO0039 の下、米国教育省、米国障害者リハビリテーション研究所(NIDRR)からのフェデラル・ファンドによる部分的な資金援助を受けている。この文書の内容は、必ずしも米国教育省の見解又はポリシーを反映したものでもなければ、商標、商品、あるいは組織は、米国政府による公認を意味するものでもない。
WCAG ワーキンググループへの参加に関する詳細な情報は、WCAG ワーキンググループのウェブページを参照のこと。
Bruce Bailey (U.S. Access Board)
Frederick Boland (NIST)
Ben Caldwell (Trace R&D Center, University of Wisconsin)
Sofia Celic (W3C Invited Expert)
Michael Cooper (W3C)
Roberto Ellero (International Webmasters Association / HTML Writers Guild)
Bengt Farre (Rigab)
Loretta Guarino Reid (Google)
Katie Haritos-Shea
Andrew Kirkpatrick (Adobe)
Drew LaHart (IBM)
Alex Li (SAP AG)
David MacDonald (E-Ramp Inc.)
Roberto Scano (International Webmasters Association / HTML Writers Guild)
Cynthia Shelly (Microsoft)
Andi Snow-Weaver (IBM)
Christophe Strobbe (DocArch, K.U.Leuven)
Gregg Vanderheiden (Trace R&D Center, University of Wisconsin)
Shadi Abou-Zahra, Jim Allan, Jenae Andershonis, Avi Arditti, Aries Arditi, Mike Barta, Sandy Bartell, Kynn Bartlett, Marco Bertoni, Harvey Bingham, Chris Blouch, Paul Bohman, Patrice Bourlon, Judy Brewer, Andy Brown, Dick Brown, Doyle Burnett, Raven Calais, Tomas Caspers, Roberto Castaldo, Sambhavi Chandrashekar, Mike Cherim, Jonathan Chetwynd, Wendy Chisholm, Alan Chuter, David M Clark, Joe Clark, James Coltham, James Craig, Tom Croucher, Nir Dagan, Daniel Dardailler, Geoff Deering, Pete DeVasto, Don Evans, Neal Ewers, Steve Faulkner, Lainey Feingold, Alan J. Flavell, Nikolaos Floratos, 福田健太郎(日本IBM), Miguel Garcia, P.J. Gardner, Greg Gay, Becky Gibson, Al Gilman, Kerstin Goldsmith, Michael Grade, Jon Gunderson, Emmanuelle Gutiérrez y Restrepo, Brian Hardy, Eric Hansen, Sean Hayes, Shawn Henry, Hans Hillen, Donovan Hipke, Bjoern Hoehrmann, Chris Hofstader, Yvette Hoitink, Carlos Iglesias, Ian Jacobs, Phill Jenkins, Jyotsna Kaki, Leonard R. Kasday, 木達一仁(ミツエーリンクス), Ken Kipness, Marja-Riitta Koivunen, Preety Kumar, Gez Lemon, Chuck Letourneau, Scott Luebking, Tim Lacy, Jim Ley, William Loughborough, Greg Lowney, Luca Mascaro, Liam McGee, Jens Meiert, Niqui Merret, Alessandro Miele, Mathew J Mirabella, Charles McCathieNevile , Matt May, Marti McCuller, Sorcha Moore, Charles F. Munat, Robert Neff, Bruno von Niman, Tim Noonan, Sebastiano Nutarelli, Graham Oliver, Sean B. Palmer, Sailesh Panchang, Nigel Peck, Anne Pemberton, David Poehlman, Adam Victor Reed, Chris Ridpath, Lee Roberts, Gregory J. Rosmaita, Matthew Ross, Sharron Rush, Gian Sampson-Wild, Joel Sanda, Gordon Schantz, Lisa Seeman, John Slatin, Becky Smith, Jared Smith, Neil Soiffer, Jeanne Spellman, Mike Squillace, Michael Stenitzer, Jim Thatcher, Terry Thompson, Justin Thorp, 植木 真(インフォアクシア), Eric Velleman, Dena Wainwright, Paul Walsch, 渡辺隆行(ITRC UAI分科会), Jason White.
この節は、参考情報である。