【注意】 この文書は、2008年12月11日付の W3C ワーキンググループノート「Understanding WCAG 2.0」(原文は英語)を、財団法人日本規格協会情報技術標準化研究センター情報アクセシビリティ国際標準化に関する調査研究開発委員会ウェブアクセシビリティ国際規格調査研究部会が日本語に翻訳している作業中のものです。この文書の正式版は、あくまで W3C のサイト内にある英語版であり、この文書には翻訳上の間違い、あるいは不適切な表現が含まれている可能性がありますのでご注意ください。また、リンク先が英語の場合、あるいはダミーのページである場合もあります。ご了承ください。

【重要】 なお、原文の "Understanding WCAG 2.0" 自体がまだ未完成であり、この文書の内容は、WCAG ワーキンググループによって今後修正されていくものと思われます。あくまでも参考程度にご覧ください。


[contents]

W3C

WCAG 2.0 解説書 [原題:Understanding WCAG 2.0]

WCAG 2.0 を理解して実装するためのガイド

W3C ワーキンググループ・ノート 2008年12月11日

このバージョン:
http://www.w3.org/TR/2008/NOTE-UNDERSTANDING-WCAG20-20081211/
最新バージョン:
http://www.w3.org/TR/UNDERSTANDING-WCAG20/
前のバージョン:
http://www.w3.org/TR/2008/WD-UNDERSTANDING-WCAG20-20081103/
編集者:
Ben Caldwell, Trace R&D Center, University of Wisconsin-Madison
Michael Cooper, W3C
Loretta Guarino Reid, Google, Inc.
Gregg Vanderheiden, Trace R&D Center, University of Wisconsin-Madison
Previous Editors:
Wendy Chisholm (until July 2006 while at W3C)
John Slatin (until June 2006 while at Accessibility Institute, University of Texas at Austin)

This document is also available in these non-normative formats:


要約

この文書「WCAG 2.0 解説書」は、WCAG 2.0 [英語] [WCAG20]WCAG 2.0 [日本語訳])を理解して実践するために不可欠なガイドである。WCAG 2.0 の関連文書群の中の一つだが、この文書のコンテンツはガイダンスを提供する参考情報であり、WCAG 2.0 に適合するための要件を定める規定文書ではない。WCAG やその関連技術文書、教育用素材などへのイントロダクションは、ウェブコンテンツ・アクセシビリティ・ガイドライン (WCAG) 概要を参照のこと。

WCAG 2.0 には、WCAG 2.0 に適合するための達成基準がある。個々の達成基準は、テスト可能な記述内容になっており、特定のウェブコンテンツに適用した際に適合もしくは不適合であると判断できるようになっている。「WCAG 2.0 解説書」が提供するのは、それぞれの達成基準に関する詳細な情報で、達成基準の意図、用いられている重要な用語や、どのようにさまざまな種類の障害のある利用者の役に立つのかが記されている。また、この文書は、さまざまなウェブ技術(例えば、HTML、CSS、XML)を用いて達成基準を満たしているウェブコンテンツの事例、そして達成基準を満たしていないウェブコンテンツのよくある例も提供している。

この文書では、それぞれの達成基準を満たすための特定の実装方法も示している。それぞれの実装方法は、Techniques for WCAG 2.0 [英語]で提供されているが、この「WCAG 2.0 解説書」では各実装方法と個々の達成基準との関係性に関する情報を提供している。実装方法は、達成基準への対応レベルによって分類されている。(それ単体もしくは他の実装方法との併用により、)ある達成基準を満たすのに十分であると考えられる実装方法が "達成基準を満たすことのできる実装方法" で、それ以外は参考にすべき実装方法で用いるかどうかは任意である。幾つかの実装方法は、ある特定のウェブコンテンツ技術を用いる場合にはそれが唯一の既知の手法であるかもしれないが、どの実装方法も WCAG 2.0 に適合する上で必須というわけではない。"参考にすべき実装方法" は、(テスト可能ではない、あるいは完全なものではないので、)それ自体では達成基準を満たすのに十分ではないが、アクセシビリティをさらに向上させるためにもコンテンツ制作者は可能であればそれらを用いることを推奨する。もう一つの分類は "よくある不適合事例" で、WCAG 2.0 に適合していないウェブコンテンツの事例として知られているものを説明している。"よくある不適合事例" は、特定のコンテンツ制作事例に関する参考情報を提供しているが、コンテンツ制作者は WCAG 2.0 の達成基準を満たすためにはそれらを避けなければならない。

この文書は、W3C WAI が提供する WCAG 2.0 関連文書群の一つであり、WCAG 2.0 が W3C 勧告として公開されたのと同時に、ワーキンググループ・ノートとして公開されたものである。WCAG 2.0 とは異なり、「WCAG 2.0 解説書」の情報は随時更新されていく予定である。

この文書のステータス

この節では、この文書の発行された時点でのステータスを説明する。他の文書が、この文書にとって代わっている場合もある。現行のW3Cの発行文書およびこの技術レポートの改訂版は、http://www.w3.org/TR/ にある W3C テクニカルレポート・インデックス(英語)で参照可能である。

これは、ワーキンググループ・ノートの「WCAG 2.0 解説書」である。WCAG(Web Content Accessibility Guidelines)ワーキンググループ [英語]では、この文書は WCAG 2.0 勧告の達成基準を理解するために重要なものであると考えている。この文書のコンテンツはガイダンスを提供する参考情報であり、WCAG 2.0 に適合するための要件を定めた規定文書ではないことに留意してほしい。

ワーキンググループへのコメントは、オンライン・コメントフォーム [英語]を使って送っていただきたい。もしそれができない場合は、public-comments-wcag20@w3.org 宛に電子メールで送信することも可能である。公開メーリングリストのアーカイブ [英語]は誰でも利用可能である。この文書に関して寄せられたコメントは、この文書の将来のバージョンもしくは他の方法で対処されるかもしれない。また、コメントに対して、ワーキンググループが正式な返答をする予定はない。WCAG ワーキンググループのメーリングリストでの議論のアーカイブは一般に公開されており、この文書に関して寄せられたコメントについては、ワーキンググループが将来的に対処することがあるかもしれない。

この文書は、W3Cの ウェブアクセシビリティ・イニシアティブ(WAI)(英語)(WAI)の活動の一環として作成されたものである。WCAG ワーキンググループの目的については、 ワーキンググループ趣意書(英語)に記載されている。WCAG ワーキンググループは、WAI テクニカル・アクティビティ(英語)の一つである。

ワーキンググループ・ノートとしての公開は、W3C 会員による承認という意味を含むものではない。これはドラフト文書であり、いつでも更新されたり、他の文書に置き換えられたりすることがある。この文書を、作成作業中のもの以外として引用することは不適切である。

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.


目次

附録


「WCAG 2.0 解説書」のイントロダクション

「WCAG 2.0 解説書」は、"WCAG(Web Content Accessibility Guidelines)2.0" [WCAG20] を理解して実践するために不可欠なガイドである。WCAG 2.0 の規定となる定義や要件はすべて WCAG 2.0 自体の文書で読むことができるが、その考え方や条項に馴染みのない方もいるかもしれない。「WCAG 2.0 解説書」は、読者の皆さんがその意図やどのようにガイドラインと達成基準が連携しているのかをよりよく理解できるように、各ガイドライン及び各達成基準について、WCAG 2.0 の規定にはならない詳細な解説を提供している。また、それぞれの達成基準を満たすのに十分であることをワーキンググループが確認した実装方法及び実装方法の組合せの事例も紹介している。そして、それぞれの実装方法の詳細にもリンクを提供している。

この文書は、前置きなどではなく、ガイドラインとその達成基準に関する詳細な技術解説である。WCAG やその関連技術文書、教育用素材などへのイントロダクションは、ウェブコンテンツ・アクセシビリティ・ガイドライン (WCAG) 概要を参照のこと。

「WCAG 2.0 解説書」は、ガイドラインごとに構成されている。各ガイドラインには、ガイドライン X.X を理解する という節がある。そのガイドラインの意図が説明されているほか、実装方法の中でも、そのガイドラインには関係あるが、特定の達成基準には特に関係のない実装方法がそこに列挙されている。

ガイドライン X.X を理解する という節の後には、そのガイドラインの達成基準ごとに、達成基準 X.X.X を理解する という節が続いている。この節にはそれぞれ以下の情報が提供されている:

WCAG 2.0 文書の各ガイドラインからは、この文書の ガイドライン X.X を理解する という節に直接リンクしている。それと同様に、WCAG 2.0 文書の各達成基準からも、この文書の 達成基準 X.X.X を理解する という節に直接リンクしている。

個々の実装方法に関する情報は、この文書中にあるリンクから WCAG 2.0 の実装方法 [英語] で関心のある実装方法を参照のこと。

さまざまな障害や支援技術に関する情報については、"Wikipedia" にある「障害 (disabilities)」[英語] を参照のこと。

アクセシビリティの4つの原則を理解する

ガイドライン及び達成基準は、誰もがウェブコンテンツにアクセスして利用するために必要な土台となる、次の4つの原則を中心に構成されている。ウェブを利用したい誰もが、コンテンツに求めるのは次のことである:

  1. 知覚可能 - 情報およびユーザインタフェースの構成要素は、利用者が知覚できる方法で利用者に提示可能でなければならない。

    • これは、利用者が提示されている情報を知覚できなければならないことを意味する(利用者の感覚すべてに対して不可視であってはならない)。

  2. 操作可能 - ユーザインタフェースの構成要素およびナビゲーションは操作可能でなければならない。

    • これは、利用者がインタフェースを操作できなければならないことを意味する(インタフェースが、利用者の実行できないインタラクションを要求してはならない)。

  3. 理解可能 - 情報およびユーザインタフェースの操作は理解可能でなければならない。

    • これは、利用者がユーザインタフェースの操作と情報とを理解できなければならないことを意味する(コンテンツ又は操作が、理解できないものであってはならない)。

  4. 堅牢性 - コンテンツは、支援技術を含む様々なユーザエージェントが確実に解釈できるように十分に堅牢でなければならない。

    • これは、利用者が技術の進歩に応じてコンテンツにアクセスできなければならないことを意味する(技術やユーザエージェントの進化していったとしても、コンテンツはアクセシブルなままであるべきである)。

もし、これらのいずれかが当てはまらなければ、障害のある利用者はウェブを利用することができなくなる。

それぞれの原則の下には、障害のある利用者のためのこれらの原則に対処するのに役立つ、ガイドライン及び達成基準がある。障害のある人を含むすべての利用者にとってコンテンツをより使いやすくする、多くの一般的な利用者ビリティ・ガイドラインがある。しかし、WCAG 2.0 においては、障害のある利用者に特有な問題に対処するガイドラインだけを含めている。つまり、障害のある人がウェブにアクセスすることを阻む問題、あるいはアクセスをひどく妨げる問題が、WCAG 2.0 には含まれている。

ガイダンスのレイヤー

ガイドライン

それぞれの原則の下には、その原則に対応するガイドラインのリストがあり、全部で12のガイドラインがある。ガイドラインだけの一覧は、WCAG 2.0 目次で見ることができる。ガイドラインの重要な目的の一つは、コンテンツが、できるだけ多くの利用者にとってそのままでアクセシブルであるようにすることであり、そしてさまざまな利用者の感覚的、身体的及び認知的能力に合うさまざまな形態で再提示可能であるようにすることである。

達成基準

各ガイドラインの下には、WCAG 2.0 に適合するためには何をしなければならないのかを具体的に記述した達成基準がある。それは、WCAG 1.0 における "チェックポイント" によく似たものである。それぞれの達成基準は、あるウェブコンテンツをテストしたときに適合もしくは不適合となるように記述されている。そして、達成基準は技術に依存しないように書かれている。

WCAG 2.0 の達成基準はすべて、コンテンツがその達成基準を満たしているかどうかを客観的に判断できるテスト可能な基準として記述されている。テストには、ソフトウェアを用いて自動化可能なものもあれば、その一部又は全部に人間によるテストを必要とするものもある。

コンテンツが達成基準を満たしていたとしても、そのコンテンツはさまざまな障害のある利用者にとって利用可能であるとは限らない。ある利用者にとってのアクセシビリティを確保する上では、専門家による定性的なヒューリスティック評価が重要である。さらに、利用者ビリティ・テスティングを推奨する。利用者ビリティ・テスティングは、その意図した目的に応じて、利用者がコンテンツをどれだけうまく使えるかを判断することを目的としている。

さまざまな種類の障害のある人がどのようにウェブを利用しているのかを理解している人が、コンテンツをテストすべきである。また、人間による検証を行う際には、障害のある利用者を検証者に含めることを推奨する。

あるガイドラインの各達成基準には、「満たす方法」文書へのリンクがあり、その文書では次のものが提供されている:

  • その達成基準を満たすのに達成基準を満たすことのできる実装方法

  • 任意の参考にすべき実装方法、そして

  • 達成基準の意図の説明、及びメリット、事例

達成基準を満たすことのできる実装方法及び参考にすべき実装方法

WCAG 2.0 の中に技術特有の実装方法を記述するのではなく、ガイドライン及び達成基準自体は技術非依存となるように記述されている。特定の技術(例えば、HTML)を用いてガイドラインを満たすためのガイダンスや事例を提供するために、ワーキンググループは達成基準ごとにその達成基準を満たすのに十分であると考えられる達成基準を満たすことのできる実装方法というものを特定した。達成基準を満たすことのできる実装方法の一覧は、「WCAG 2.0 技術書」の中でメンテナンスされている(「WCAG 2.0 への適合方法(How to meet WCAG 2.0)」にも反映されている)。 こうすることで、新しい実装方法が見つかったときやウェブ技術及び支援技術の進化に応じて、その一覧を更新していくことが可能である。

留意すべきは、すべての実装方法は参考情報であるということである。"達成基準を満たすことのできる実装方法" は、WCAG ワーキンググループがその達成基準を満たすのに十分であると考えたものである。しかし、必ずしもそれらの特定の実装方法を用いる必要はない。もし、ワーキンググループが挙げた実装方法以外のものを用いるのであれば、その達成基準を満たすことのできる実装方法として確立する何らかの手段が必要となるであろう。

ほとんどの達成基準には、達成基準を満たすことのできる実装方法が複数挙げられている。挙げられている達成基準を満たすことのできる実装方法を用いて、達成基準を満たすことができる。ワーキンググループが文書化していなくても、達成基準を満たすことのできる実装方法が他にもあるかもしれない。達成基準を満たすことのできる実装方法が新たに確認されれば、一覧に追加されることだろう。

達成基準を満たすことのできる実装方法に加えて、数多くの参考にすべき実装方法があり、それらはアクセシビリティをさらに向上させることができるが、達成基準の要件を完全に満たすことができない、テスト可能ではない、及び/又はある状況においては有効な実装方法だが効果的でも役に立つわけでもない状況もある、といった理由から、達成基準を満たすことのできる実装方法としては認められなかったものである。それらは、参考にすべき実装方法として挙げられていて、この文書中では達成基準を満たすことのできる実装方法のすぐ下にある。コンテンツ制作者には、ウェブページのアクセシビリティを向上させるために、必要に応じてこれらの実装方法を用いることを推奨する。

編集注記:ワーキンググループが実装方法の解説を書き上げていない場合、その実装方法のタイトルの後に "(リンク追加予定)" と記述してある。


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

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

ガイドライン 1.1 の意図

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

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

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

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

  • 音声しか含まないファイルへの手話ビデオの提供 (リンク追加予定)

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

1.1.1 非テキストコンテンツ: 利用者に提示されるすべての非テキストコンテンツには、同等の目的を果たす代替テキストがある。ただし、以下に挙げる場合は除く (レベル A):

  • コントロール、入力: 非テキストコンテンツが、コントロールまたは利用者の入力を受け入れるものである場合、代替テキストは、その目的を説明する識別名を提供している。(コントロールおよび利用者の入力を受け入れるコンテンツに関するその他の要件は、ガイドライン 4.1 を参照のこと。)

  • 時間の経過に伴って変化するメディア: 非テキストコンテンツが、時間の経過に伴って変化するメディアである場合、代替テキストは、少なくとも、その非テキストコンテンツを識別できる説明を提供している。(メディアに関するその他の要件は、ガイドライン 1.2 を参照のこと。)

  • 試験: 非テキストコンテンツが、テキストで提示されると無効になる試験あるいは演習の場合、代替テキストは、少なくともその非テキストコンテンツを識別できる説明を提供している。

  • 感覚的: 非テキストコンテンツが、特定の感覚的体験を創り出すことを主に意図している場合、代替テキストは、少なくともその非テキストコンテンツを識別できる説明を提供している。

  • CAPTCHA 非テキストコンテンツが、コンピュータではなく人間がコンテンツにアクセスしていることを確認する目的で用いられている場合、代替テキストは、その非テキストコンテンツの目的を特定し、説明している。なおかつ、他の感覚による知覚に対応して出力するCAPTCHAの代替形式を提供することで、様々な障害に対応している。

  • 装飾、整形、非表示: 非テキストコンテンツが、装飾だけを目的にしている、あるいは見た目の整形のためだけに用いられている、または利用者に提供されるものではない場合、支援技術が無視できるように実装されている。

この達成基準の意図

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

CAPTCHA に関する注記

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

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

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

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

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

補足情報

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

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

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

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

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

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

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

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

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

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

  • この達成基準は、視覚的なコンテンツを知覚するのが困難な利用者の役に立つ。支援技術が、テキストを読み上げたり、視覚的に提示したり、点字に変換したりすることができるようになる。

  • 代替テキストは、写真、図面、その他の画像(例: 線画、グラフィックデザイン、絵画、3D表現)、グラフ、チャート、アニメーションなどの意味を理解するのが困難な利用者の役に立つこともある。

  • 耳が聞こえない、耳が聞こえづらい、あるいは何らかの理由で音声情報を理解するのが困難な人が、テキストでの表現を読むことができるようになる。テキストを手話に自動変換する研究が現在進行中である。

  • 視聴覚の両方に障害のある利用者は、テキストを点字で読むことができるようになる。

  • 加えて、代替テキストは非テキストコンテンツの検索を可能とし、コンテンツをさまざまな方法で再利用できるようにする。

達成基準 1.1.1 の事例

  1. データのグラフ

    6月、7月、そして8月にどれだけの数の商品が売れたかを比較している棒グラフがある。簡潔なラベルには、「図1:6月、7月、8月の売上」と書かれている。長めの説明には、グラフの種類が示されていて、そのグラフから見てとれるものに相当する、データの概要、傾向や意味合いが提供されている。可能なところでは、実際のデータがテーブルで提供されている。

  2. 演説を録音した音声

    「議会での議長の演説」という音声クリップへのリンクがある。そして、テキストのトランスクリプトへのリンクが、その音声クリップへのリンクの直後に提供されている。

  3. 車のエンジンがどのように動くのかを紹介するアニメーション

    車のエンジンがどのように動くのかを見せているアニメーションがある。音声はなく、そのアニメーションはエンジンがどのように動くかを解説するチュートリアルの一部である。チュートリアルのテキストがすでに全ての説明を提供しているため、そのアニメーションはテキストの代替物であり、その代替テキストにはアニメーションの簡潔な説明のみが記述されていて、より詳細な情報はチュートリアルのテキストを参照している。

  4. 交通情報ウェブカメラ

    利用者がある大都市の至る所に設置されたさまざまな Web カメラを選択することのできる Web サイトがある。どれか一つのカメラを選択すると、画像が2分おきに更新される。簡潔な代替テキストでは、その Web カメラを 「交通情報 Web カメラ」と説明している。また、そのサイトでは、Web カメラがカバーしているルートのそれぞれの所要時間を表で提供している。そして、その表も2分おきに更新されている。

  5. ニュース記事にある歴史的な出来事の写真

    国際サミット会議に関するニュース記事と一緒に、2人の世界的なリーダーが握手をしている写真がある。代替テキストには、「X国のX大統領が、Y国のY首相と握手している」と記述されている。

  6. 外交関係を議論するコンテンツにある歴史的な出来事の写真

    外交上の衝突におけるニュアンスを説明するための異なる文脈で同じ写真が使われている。首相と握手している大統領の画像が、もつれた外交関係を議論している Web サイトに登場している。最初の代替テキストには、「X国のX大統領が、2009年1月2日に、Y国のY首相と握手している」と書かれている。補足の代替テキストは、両首脳の顔の表情と二人が立っている部屋の説明をしていて、さらにその部屋にいる他の人たちのことも示している。その補足的な説明は、写真と同じページにあるかもしれないし、リンクあるいはその他の標準的なプログラムによるメカニズムによってその画像と関連付けられた別のファイルにあるかもしれない。

  7. 記者会見を録音した音声

    ウェブページに、記者会見を録音した音声へのリンクがある。リンクテキストは、録音された音声を示している。また、そのページには記者会見のテキストのトランスクリプトへのリンクもある。トランスクリプトには、話者が発言した全ての逐語的な記録がある。そこには、例えば、喝采、笑い、聴衆からの質問など、その録音の一部であるその他の重要な音声とあわせて、誰が話しているのかも記されている。

  8. E-ラーニングアプリケーション

    回答が正しいかどうかを示すために効果音を用いている E-ラーニングアプリケーションがある。チャイム音はその回答が正解であることを示し、ビープ音はその回答が正解ではないことを示している。テキストの説明もあり、その音を聞いたり理解したりすることができない利用者も、その回答が正解かどうかを理解することができる。

  9. リンクのあるサムネール画像

    「スモールヴィル・タイムス」のウェブサイトにリンクしている、新聞の一面のサムネール画像がある。その代替テキストには、「スモールヴィル・タイムス」と記述されている。

  10. 異なるサイトで使われている同じ画像

    世界地図の画像に対する異なる代替テキストの例: 旅行サイトで海外旅行コーナーへのリンクとして用いられている世界地図の画像には、「海外旅行」という代替テキストがある。同じ画像が、「国際キャンパス」という代替テキストとともに、ある大学のウェブサイトでリンクとして用いられている。

  11. イメージマップ

    ビルのフロアプランのイメージマップ画像はインタラクティブで、利用者が特定の部屋を選択して、その部屋に関する情報のあるページへ移動することができる。「ビルのフロアプラン。より詳細な情報は部屋を選択してください。」という簡潔な代替テキストが、そのイメージマップの画像全体とインタラクションの目的を説明している。

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

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

状況 A: 短い説明によって、非テキストコンテンツと同じ目的を果たし、同じ情報を提示できる場合:
  1. 次に挙げる短い代替テキストの実装方法を用いて、G94: 非テキストコンテンツと同じ目的を果たし、同じ情報を提示する短い代替テキストを提供する

状況 B: 短い説明によって、非テキストコンテンツと同じ目的を果たし、同じ情報を提示できない場合(例:チャート又はダイアグラム):
  1. 次に挙げる短い代替テキストの実装方法及び次に挙げる長い説明の実装方法の一つを用いて、G95: 非テキストコンテンツを簡潔に説明する短い代替テキストを提供する

状況 C: 非テキストコンテンツがコントロールである、又は利用者の入力を受け入れる場合:
  1. 次に挙げる短い代替テキストの実装方法を用いて、G82: 非テキストコンテンツの目的を示す代替テキストを提供する

  2. H44: label要素を用いて、テキストのラベルとフォーム・コントロールを関連付ける (HTML)

  3. H65: label要素を用いることができないとき、title属性を用いてフォーム・コントロールを特定する (HTML)

状況 D: 非テキストコンテンツが時間の経過に伴って変化するメディアである場合(ライブの映像しか含まないコンテンツ及びライブの音声しか含まないコンテンツを含む); テキストで提示されると無効になる試験又は演習; 又は、特定の感覚的体験を創り出すことを主に意図しているコンテンツ:
  1. 次に挙げる短い代替テキストの実装方法を用いて、ラベルを記述する。

  2. 次に挙げる短い代替テキストの実装方法を用いて、G68: ラベルを記述して、ライブの音声しか含まないコンテンツ及びライブの映像しか含まないコンテンツの目的を説明する

  3. 次に挙げる短い代替テキストの実装方法を用いて、G100: 非テキストコンテンツの一般的な名前、又は説明的な名前を提供する

状況 E: 非テキストコンテンツが CAPTCHA である場合:
  1. G143: 代替テキストを提供して、CAPTCHAの目的を説明する、かつG144: 異なるモダリティを用いて、同じ目的を果たす CAPTCHA をもう一つウェブページで提供する

状況 F: 非テキストコンテンツを支援技術が無視するようにしなければならない場合:
  1. 次に挙げるウェブコンテンツ技術特有の実装方法を用いて、支援技術が非テキストコンテンツを無視するように実装する、又はマークアップする。

前述の "達成基準を満たすことのできる実装方法" を用いる際の短い代替テキストの実装方法 above
  1. H36: 送信 / 実行ボタンとして用いる画像の alt 属性を使用する (HTML)

  2. H2: 隣り合った画像とテキストリンクを同じリンクの中に入れる (HTML)

  3. H37: img 要素の alt 属性を用いる (HTML)

  4. H35: applet 要素に代替テキストを提供する (HTML)

  5. H53: object 要素のボディに代替テキストを記述する (HTML)

  6. H24: イメージマップの area 要素に代替テキストを提供する (HTML)

  7. H86: ASCII アート、絵文字、及びリート語に代替テキストを提供する (HTML)

  8. H30: a 要素のリンクの目的を説明するテキストリンクを提供する (HTML)

  9. G196: 画像のグループにある一つの画像に代替テキストを提供して、そのグループのすべての画像を説明する

Long text alternative techniques for use in 前述の "達成基準を満たすことのできる実装方法" を用いる際の長い代替テキストの実装方法
  1. H45: longdesc 属性を用いる (HTML)

  2. H53: object 要素のボディに代替テキストを記述する (HTML)

達成基準 1.1.1 でさらに対応が望まれる実装方法(参考)

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

General Techniques for Informative Non-Text Content (Advisory)
  • Identifying informative non-text content (リンク追加予定)

  • Keeping short descriptions short (リンク追加予定)

  • Describing images that include text (リンク追加予定)

  • Providing a longer description of the non-text content where only a descriptive label is required using a technology-specific technique (for an accessibility-supported content technology) for long description listed above (リンク追加予定)

  • Providing different sizes for non-text content when it cannot have an equivalent accessible alternative (リンク追加予定)

  • Using server-side scripts to resize images of text (リンク追加予定)

General Techniques for Live Non-Text Content (Advisory)
  • Linking to textual information that provides comparable information (e.g., for a traffic Webcam, a municipality could provide a link to the text traffic report.) (リンク追加予定)

General techniques to minimize the barrier of CAPTCHAs
  • Providing more than two modalities of CAPTCHAs (リンク追加予定)

  • Providing access to a human customer service representative who can bypass CAPTCHA (リンク追加予定)

  • Not requiring CAPTCHAs for authorized users (リンク追加予定)

HTML Techniques (Advisory)
CSS Techniques (Advisory)
ARIA Techniques (Advisory)
  • Using the ARIA presentation role to indicate elements are purely presentational (リンク追加予定)

Metadata Techniques (Advisory)
  • Using metadata to associate text transcriptions with a video (リンク追加予定)

  • Using metadata to associate text transcriptions with audio-only content (リンク追加予定)

    • 事例:Providing, in metadata, URI(s) that points to an audio description and a text transcript of a video.

    • 事例:Providing, in metadata, URI(s) that point to several text transcripts (English, French, Dutch) of an audio file.

重要な用語

(この文書で用いられている)支援技術

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

注記 1: 代替のプレゼンテーション(例:合成音声や拡大表示したコンテンツ)、代替入力手法(例:音声認識)、付加的なナビゲーションあるいは位置確認のメカニズム、およびコンテンツ変換(例:テーブルをよりアクセシブルにするもの)を含めて支援技術により提供される機能。

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

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

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

  • 画面拡大ソフトおよびその他の視覚的な表示に関する支援技術。視覚障害、知覚障害、および読書困難などの障害のある人が、レンダリング後のテキストおよび画像の視覚的な読みやすさを改善するために、テキストのフォント、サイズ、間隔、色、音声との同期などを変更するのに使用している。

  • スクリーンリーダー。全盲の人がテキスト情報を合成音声あるいは点字で読み取るために使用している。

  • 音声変換ソフトウェア。認知障害、言語障害、および学習障害のある人が、テキストを合成音声に変換するために使用している。

  • 音声認識ソフトウェア。何らかの身体障害のある利用者が使用することがある。

  • 代替キーボード。特定の身体障害のある人がキーボードを擬似操作するのに使用している(ヘッドポインタ、シングルスイッチ、呼気・吸気スイッチ、およびその他の特別な入力デバイスを使った代替キーボードを含む)。

  • 代替ポインティングデバイス。特定の身体障害のある人がマウスポインタとボタンを擬似操作するのに使用している。

CAPTCHA

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

注記 1: CAPTCHA テストは、不明瞭な画像あるいは音声ファイルで提示される文字を利用者に入力するよう求めることが多い。

注記 2: チューリングテストは、人間とコンピュータを判別するために設計されたテストの仕組みである。その名は、これを考案した有名なコンピュータ科学者のアラン・チューリングにちなんで名付けられた。この用語は、カーネギーメロン大学の研究者たちによる造語であった。 [CAPTCHA]

識別名

ソフトウェアがウェブコンテンツ内の構成要素を利用者に識別させることのできるテキスト

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

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

非テキストコンテンツ

プログラムで解釈できる文字の並びではないコンテンツ、あるいはその文字の並びが自然言語で何も表現していないコンテンツ。

注記: これには、(文字で作る模様である)ASCII アート、顔文字、(当て字を用いる)リート語、そして文字を表現している画像が含まれる。

装飾だけを目的

美的な目的だけを果たしていて、情報は提供せず、機能性も備えていない。

注記: その単語を手直ししたり置き換えたりしてもその目的が変わらないのであれば、テキストは単に装飾だけを目的にしたものといえる。

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

特定の感覚的な体験

単に装飾だけを目的にしたものではなく、また第一に重要な情報を伝えたり機能を提供したりするものではない感覚的な体験。

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

テキスト

プログラムで解釈できる文字の連続で、その連続が自然言語で何かを表現しているもの。

代替テキスト

非テキストコンテンツとプログラムで関連付けられている、あるいは非テキストコンテンツとプログラムで関連付けられているテキストから参照されるテキスト。プログラムで関連付けられたテキストとは、その場所が非テキストコンテンツからプログラムで定めることのできるテキストである。

事例: チャートの画像は、チャートの直後にある段落でテキストで説明されている。チャートの簡潔な代替テキストは、説明が後に続くことを示している。

注記:より詳細な情報は、代替テキストを理解するを参照のこと。


時間の経過に伴って変化するメディア
ガイドライン 1.2 を理解する

ガイドライン 1.2: 時間の経過に伴って変化するメディアには代替コンテンツを提供する。

ガイドライン 1.2 を理解する

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

  • 音声しか含まない

  • 映像しか含まない

  • 音声と映像を含む

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

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

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

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

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

同期したメディア

情報や時間経過をベースにしたインタラクティブな構成要素を提示するために、他のフォーマットと同期した音声または映像。ただし、そのメディアがテキストの代替メディアではっきりとそのようにラベル付けされているものは除く。

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

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

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

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

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

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

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

収録済の音声しか含まないメディア及び収録済の映像しか含まないメディア
達成基準 1.2.1 を理解する

1.2.1 収録済音声しか含まないメディア及び収録済の映像しか含まないメディア: 収録済の音声しか含まないメディア及び収録済の映像しか含まないメディアは、次の事項が当てはまる。ただし、その音声あるいは映像がテキストの代替メディアであって、そのことがはっきりとラベル付けされている場合は除く。 (レベル A):

  • 収録済の音声しか含まないコンテンツ: 時間の経過に伴って変化するメディアの代替が、収録済の音声しか含まないコンテンツと等価な情報を提供している。

  • 収録済の映像しか含まないコンテンツ: 時間に伴って変化するメディアの代替あるいは音声トラックが、収録済の映像しか含まないコンテンツと等価な情報を提供している。

この達成基準の意図

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

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

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

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

  • この達成基準は、視覚的なコンテンツを知覚するのが困難な利用者の役に立つ。支援技術が、代替テキストを音声で読み上げたり、視覚的に提示したり、点字に変換したりすることが可能になる。

  • 時間の経過に伴って変化するメディアの代替は、それがテキストベースであれば、収録済の映像コンテンツの意味を理解するのが困難な利用者の役に立つことがある。

  • 音声が聞こえない、音声が聞こえにくい、又は何らかの理由で音声情報を理解しづらい利用者が、テキストのプレゼンテーションを読むことができるようになる。また、テキストを手話に自動通訳する研究が現在進められている。

  • 視聴覚の両方に障害のある利用者が、テキストを点字で読むことができるようになる。

  • 加えて、テキストは、非テキストコンテンツを検索可能なものにし、コンテンツをさまざまな方法で再利用できるようにする。

達成基準 1.2.1 の事例

  • 演説を録音した音声

    「議会での議長の演説」という音声クリップへのリンクがある。そして、テキストによるトランスクリプトへのリンクが、その音声クリップへのリンクの直後に提供されている。

  • 記者会見を録音した音声

    ウェブページに、記者会見を録音した音声へのリンクがあり、リンクテキストが録音された音声であることを示している。また、そのページには記者会見のテキストのトランスクリプトへのリンクもある。トランスクリプトには、話者が発言した全ての逐語的な記録がある。そこには、例えば、喝采、笑い、聴衆からの質問など、その録音の一部であるその他の重要な音声とあわせて、誰が話しているのかも記されている。

  • 車のエンジンがどのように動くのかを紹介するアニメーション

    車のエンジンがどのように動くのかを見せているアニメーションがある。音声はなく、そのアニメーションはエンジンがどのように動くかを解説するチュートリアルの一部である。チュートリアルのテキストがすでに全ての説明を提供しているため、そのアニメーションはテキストの代替物であり、その代替テキストにはアニメーションの簡潔な説明のみが記述されていて、より詳細な情報はチュートリアルのテキストを参照している。

  • 音声トラック付きの、映像しか含まないファイル

    無音映画に音声トラックがあり、映像に見られる動きや振る舞いを説明している。

関連リソース

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

達成基準 1.2.1 の実装方法及び不適合事例 - 収録済の音声しか含まないコンテンツ及び映像しか含まないコンテンツ

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

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

状況 A: 収録済の音声しか含まないコンテンツの場合:
  1. G158: 音声しか含まないコンテンツの時間の経過に伴って変化するメディアの代替を提供する

状況 B: 収録済の映像しか含まないコンテンツの場合:
  1. G159: 映像しか含まないコンテンツの時間の経過に伴って変化するメディアの代替を提供する

  2. G166: 重要な映像コンテンツを説明する音声を提供する

達成基準 1.2.1 でさらに対応が望まれる実装方法(参考)

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

  • Providing a transcript of a live audio only presentation after the fact (リンク追加予定)

  • Linking to textual information that provides comparable information (e.g., for a traffic Webcam, a municipality could provide a link to the text traffic report.) (リンク追加予定)

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

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

重要な用語

時間の経過に伴って変化するメディアの代替

時間に伴って変化する視覚的および聴覚的情報のトランスクリプトを含み、時間に伴って変化する情報のやりとりの結果を得る手段を提供する文書。

注記: 同期したメディアのコンテンツを作るために用いられる脚本は、編集後の最終的な同期したメディアを正確に描写したものに訂正されている場合のみ、この定義を満たすことになる。

音声しか含まない

音声のみを含んだ、時間の経過に伴って変化する表現(映像やインタラクションを含まない)。

テキストの代替メディア

テキストで(直接あるいは代替テキストによって)既に提示されている情報以上のものは提示していないメディア。

注記: テキストの代替メディアは、テキストの代替プレゼンテーションの恩恵を受ける人たちのために提供される。テキストの代替メディアになるのは、音声しか含まないメディア、映像しか含まないメディア(手話の映像を含む)、あるいは音声付映像メディアである。

収録済

ライブではない情報。

映像しか含まない

映像しか含まない、時間の経過に伴って変化する表現(音声を含まず、インタラクションも含まない)。


収録済の音声コンテンツのキャプション:
達成基準 1.2.2 を理解する

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

この達成基準の意図

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

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

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

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

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

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

達成基準 1.2.2 の事例

  • キャプションを提供しているチュートリアル

    結び目の作り方を紹介している映像があり、次のようなキャプションが提供されている。

    "(音楽)

    水兵、兵士、そして木こりのような人たちにとっては、

    ロープを使って結び目を作るのは、重要なスキルでした。"

    Whit Anderson氏による、トランスクリプトのフォーマットのサンプルより。

  • 複雑な法律文書には、段落ごとに同期したメディアクリップがあり、その段落の内容を話している人がいる。各クリップは、その対応する段落と関連付けられていて、その同期したメディアには、キャプションが提供されていない。

  • 取扱説明書で、ある部品に関して記述されていて、その使用方法の説明部分には同期したメディアクリップがあり、その部品の正しい使用方法を紹介している。その同期したメディアには、キャプションが提供されていない。

達成基準 1.2.2 の実装方法及び不適合事例 - 収録済の音声コンテンツのキャプション

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  1. G93: オープン・キャプション(常に表示)を提供する

  2. クローズド・キャプションをサポートしたビデオ・プレーヤーのある、容易に利用可能なメディア・フォーマットを用いて、G87: クローズド・キャプションを提供する

  3. 次のいずれかのウェブコンテンツ技術特有の実装方法を用いて、G87: クローズド・キャプションを提供する

達成基準 1.2.2 でさらに対応が望まれる実装方法(参考)

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

  • Providing a note saying "No sound is used in this clip" for video-only clips (リンク追加予定)

  • Using SMIL 1.0 to provide captions for all languages for which there are audio tracks (リンク追加予定)

  • Using SMIL 2.0 to provide captions for all languages for which there are audio tracks (リンク追加予定)

重要な用語

音声

音声再生の技術。

注記: 音声は、合成的に生成されたものであったり(音声合成を含む)、実世界で録音したものであったり、またその両方もありうる。

キャプション

そのメディアのコンテンツを理解するのに必要な、発話および発話ではない音声情報の両方に対する、同期した視覚的表現あるいは代替テキスト

注記 1:Captions are similar to dialogue-only subtitles except captions convey not only the content of spoken dialogue, but also equivalents for non-dialogue audio information needed to understand the program content, including sound effects, music, laughter, speaker identification and location.

注記 2:クローズド・キャプションは、プレーヤーによっては ON/OFF を切り替えることのできる等価物である。

注記 3:オープン・キャプションは、OFFにすることのできないキャプションである。例えば、キャプションが映像に埋め込まれた、視覚的に等価な画像化された文字である場合がある。

注記 4: キャプションは、映像の関連情報を分かりにくくしたり遮ったりすべきではない。

注記 5: 国によっては、キャプションはサブタイトル(字幕)と呼ばれている。

注記 6:音声ガイドは既に視覚的に提示されている情報の説明なので、キャプションにしてもよいが、そうする必要があるわけではない。

テキストの代替メディア

テキストで(直接あるいは代替テキストによって)既に提示されている情報以上のものは提示していないメディア。

注記: テキストの代替メディアは、テキストの代替プレゼンテーションの恩恵を受ける人たちのために提供される。テキストの代替メディアになるのは、音声しか含まないメディア、映像しか含まないメディア(手話の映像を含む)、あるいは音声付映像メディアである。

収録済

ライブではない情報。

同期したメディア

情報や時間経過をベースにしたインタラクティブな構成要素を提示するために、他のフォーマットと同期したまたは映像。ただし、そのメディアがテキストの代替メディアではっきりとそのようにラベル付けされているものは除く。


収録済の映像コンテンツの音声ガイド又は代替:
達成基準 1.2.3 を理解する

1.2.3 収録済の映像コンテンツの音声ガイドまたは代替: 同期したメディアには、時間の経過に伴って変化するメディアの代替あるいは収録済映像コンテンツの音声ガイドを提供する。ただし、そのメディアがテキストの代替メディアで、はっきりとそのようにラベル付けされている場合は除く。 (レベル A)

この達成基準の意図

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

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

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

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

注記 1: 達成基準 1.2.3、1.2.5、及び 1.2.7 では、映像トラックにある情報のすべてが音声トラックですでに提供されている場合には、音声ガイドを必要としない。

注記 2: 達成基準 1.2.3、1.2.5、及び 1.2.8 は、お互いに重なり合う部分がある。これは、最低限の適合レベルではコンテンツ制作者に選択肢を与え、より高い適合レベルでは付加的な要件を提示するためである。達成基準 1.2.3 のレベル A では、コンテンツ制作者には、音声ガイド又は完全な代替テキストのどちらかを提供するという選択肢がある。レベル AA で適合したい場合、達成基準 1.2.5 において、コンテンツ制作者は音声ガイドを提供しなければならない。もし達成基準 1.2.3 を満たすための代替コンテンツとして音声ガイドを選択していれば、レベル AA の要件をすでに満たしていることになるが、そうでなければこれは付加的な要件ということになる。達成基準 1.2.8 のレベル AAA では、コンテンツ制作者は拡張したテキストの説明を提供しなければならない。達成基準 1.2.3 及び 1.2.5 において音声ガイドだけを提供することで要件を満たしていた場合には、達成基準 1.2.8 が付加的な要件ということになる。しかし、達成基準 1.2.3 をテキストの説明による代替を提供することで満たし、なおかつ達成基準 1.2.5 の音声ガイドの要件を満たしている場合には、達成基準 1.2.8 は新しい要件を付加することにはならない。

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

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

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

達成基準 1.2.3 の事例

  • 音声ガイドを提供している映画

    音声ガイド: タイトル "Teaching Evolution ケーススタディ ボニー・チェン" くちばしが長くて薄い鳥の写真を、先生が見せている。

    ボニー・チェン: "これらの写真はすべて、フロリダのエバーグレイド国立公園で撮影されたものです。"

    音声ガイド: 先生が生徒一人ひとりに2つの平らで薄い木の棒切れを手渡ししています。

    ボニー・チェン: "今日、皆さんは、こんなくちばしをした、脚の長い鳥になったふりをしてください。"

    音声ガイド: 先生が、2つの棒切れを口にあてて、くちばしの形を作っています。

    音声のトランスクリプトは、"Teaching Evolution ケーススタディ ボニー・チェン"(copyright WGBH and Clear Blue Sky Productions, Inc.) の冒頭の数分間に基づいいる。

  • ある研修ビデオでの、時間の経過に伴って変化するメディアの代替

    ある企業が、従業員のための研修ビデオを購入し、その企業のイントラネット上に置いている。そのビデオでは、新しい技術の使い方を説明していて、同時にそれを説明しながら実演する人物が登場している。ビデオの発話部分の合間に、視覚的なデモの音声ガイドを挿入する時間的な余裕がないため、その企業では、そのデモを見ることができない人を含む従業員すべてがその内容をよりよく理解することができるように、時間の経過に伴って変化するメディアに代替コンテンツを提供している。

達成基準 1.2.3 の実装方法及び不適合事例 - 収録済の映像コンテンツの音声ガイド又は代替

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  1. 次の実装方法のどれか一つを用いて、G69: 時間の経過に伴って変化するメディアに代替を提供する

  2. G78: 音声ガイドを含んだ、利用者が選択可能な副音声トラックを提供する

  3. 次のどれか一つを用いて、G173: ムービーの音声ガイド付バージョンを提供する

  4. 次のどれか一つを用いて、G8: 拡張した音声ガイド付のムービーを提供する

達成基準 1.2.3 でさらに対応が望まれる実装方法(参考)

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

  • Providing audio description in multiple languages in SMIL 1.0 (リンク追加予定)

  • Providing audio description in multiple languages in SMIL 2.0 (リンク追加予定)

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

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

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

重要な用語

時間の経過に伴って変化するメディアの代替

時間に伴って変化する視覚的および聴覚的情報のトランスクリプトを含み、時間に伴って変化する情報のやりとりの結果を得る手段を提供する文書。

注記: 同期したメディアのコンテンツを作るために用いられる脚本は、編集後の最終的な同期したメディアを正確に描写したものに訂正されている場合のみ、この定義を満たすことになる。

音声ガイド

音声トラックに追加されたナレーションで、主音声のトラックだけでは理解できない重要で視覚的な細部を説明するもの。

注記 1: 映像の音声ガイドは、動作やしぐさ、登場人物、場面の変化、画面上の文字、およびその他の視覚的なコンテンツに関する情報を提供する。

注記 2: 標準的な音声ガイドでは、ナレーションが会話の合間に追加されている。(拡張した音声ガイドも参照のこと。)

注記 3:すべての映像の情報がすでに既存の音声で提供されている場合、補足の音声ガイドは不要である。

注記 4: "ビデオ説明" や "説明ナレーション" とも呼ばれる。

テキストの代替メディア

テキストで(直接あるいは代替テキストによって)既に提示されている情報以上のものは提示していないメディア。

注記: テキストの代替メディアは、テキストの代替プレゼンテーションの恩恵を受ける人たちのために提供される。テキストの代替メディアになるのは、音声しか含まないメディア、映像しか含まないメディア(手話の映像を含む)、あるいは音声付映像メディアである。

収録済

ライブではない情報。

同期したメディア

情報や時間経過をベースにしたインタラクティブな構成要素を提示するために、他のフォーマットと同期した音声または映像。ただし、そのメディアがテキストの代替メディアではっきりとそのようにラベル付けされているものは除く。

映像

連続した写真や画像を動かす技術。

注記: 映像は、アニメあるいは写真の画像、もしくはその両方で構成可能である。


ライブの音声コンテンツのキャプション:
達成基準 1.2.4 を理解する

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

この達成基準の意図

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

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

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

達成基準 1.2.4 の事例

  • ウェブキャスト

    ニュースの配信者が、ライブのウェブキャストでキャプションを提供している。

関連リソース

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

達成基準 1.2.4 の実装方法及び不適合事例 - ライブの音声コンテンツのキャプション

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  1. G9: ライブの同期したメディアのキャプションを作成する、かつG93: オープン・キャプション(常に表示)を提供する

  2. クローズド・キャプションをサポートするビデオ・プレーヤーのある、すぐに利用可能なメディア・フォーマットを用いて、G9: ライブの同期したメディアのキャプションを作成する、かつG87: クローズド・キャプションを提供する

  3. 次のどれか一つを用いて、G9: ライブの同期したメディアのキャプションを作成する、かつG87: クローズド・キャプションを提供する

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

達成基準 1.2.4 でさらに対応が望まれる実装方法(参考)

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

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

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

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

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

重要な用語

音声

音声再生の技術。

注記: 音声は、合成的に生成されたものであったり(音声合成を含む)、実世界で録音したものであったり、またその両方もありうる。

キャプション

そのメディアのコンテンツを理解するのに必要な、発話および発話ではない音声情報の両方に対する、同期した視覚的表現あるいは代替テキスト

注記 1: キャプションは、発話のみの字幕と似ているが、次の点において異なる。キャプションは、発話コンテンツだけでなく、その番組コンテンツを理解するのに必要な、発話ではない音声情報と等価な内容も伝える。つまり、効果音、音楽、笑い声、話者の特定、そして位置なども含まれるのである。

注記 2: クローズド・キャプションは、プレーヤーによっては ON/OFF を切り替えることのできる等価物である。

注記 3: オープン・キャプションは、OFFにすることのできないキャプションである。例えば、キャプションが映像に埋め込まれた、視覚的に等価な画像化された文字である場合がある。

注記 4: キャプションは、映像の関連情報を分かりにくくしたり遮ったりすべきではない。

注記 5: 国によっては、キャプションはサブタイトル(字幕)と呼ばれている。

注記 6: 音声ガイドは既に視覚的に提示されている情報の説明なので、キャプションにしてもよいが、そうする必要があるわけではない。

ライブ

実世界のイベントから取り込まれ、放送による遅延があるだけで受け手に送信される情報。

注記 1: 放送の遅延は、時間的に短い(通常は自動的な)遅れで、例えば放送局に音声(あるいは映像)を待ち行列に入れる、あるいは検閲する時間を与えるために用いられるものだが、編集できるほどの長さではない。

注記 2: もし情報が完全にコンピュータで生成されたものならば、それはライブではない。

同期したメディア

情報や時間経過をベースにしたインタラクティブな構成要素を提示するために、他のフォーマットと同期した音声または映像。ただし、そのメディアがテキストの代替メディアではっきりとそのようにラベル付けされているものは除く。


収録済の映像コンテンツの音声ガイド:
達成基準 1.2.5 を理解する

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

この達成基準の意図

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

注記 1:達成基準 1.2.3、1.2.5、及び 1.2.7 では、映像トラックにある情報のすべてが音声トラックですでに提供されている場合には、音声ガイドを必要としない。

注記 2: 達成基準 1.2.3、1.2.5、及び 1.2.8 は、お互いに重なり合う部分がある。これは、最低限の適合レベルではコンテンツ制作者に選択肢を与え、より高い適合レベルでは付加的な要件を提示するためである。達成基準 1.2.3 のレベル A では、コンテンツ制作者には、音声ガイド又は完全な代替テキストのどちらかを提供するという選択肢がある。 レベル AA で適合したい場合、達成基準 1.2.5 において、コンテンツ制作者は音声ガイドを提供しなければならない。もし達成基準 1.2.3 を満たすための代替コンテンツとして音声ガイドを選択していれば、レベル AA の要件をすでに満たしていることになるが、そうでなければこれは付加的な要件ということになる。 達成基準 1.2.8 のレベル AAA では、コンテンツ制作者は拡張したテキストの説明を提供しなければならない。達成基準 1.2.3 及び 1.2.5 において音声ガイドだけを提供することで要件を満たしていた場合には、達成基準 1.2.8 が付加的な要件ということになる。 しかし、達成基準 1.2.3 をテキストの説明による代替を提供することで満たし、なおかつ達成基準 1.2.5 の音声ガイドの要件を満たしている場合には、達成基準 1.2.8 は新しい要件を付加することにはならない。

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

  • 全盲あるいはロービジョンの利用者、及び認知限界により何が起こっているのかを視覚的に解釈しづらい利用者が、視覚的な情報を音声ガイドから得られるようになる。

達成基準 1.2.5 の事例

  • 音声ガイドを提供している映画

    音声ガイド: タイトル "Teaching Evolution ケーススタディ Bonnie Chen" くちばしが長くて薄い鳥の写真を、先生が見せている。

    ボニー・チェン: "これらの写真はすべて、フロリダのエバーグレイド国立公園で撮影されたものです。"

    音声ガイド: 先生が生徒一人ひとりに2つの平らで薄い木の棒切れを手渡ししています。

    ボニー・チェン: "今日、皆さんは、こんなくちばしをした、脚の長い鳥になったふりをしてください。"

    音声ガイド: 先生が、2つの棒切れを口にあてて、くちばしの形を作っています。

    音声のトランスクリプトは、"Teaching Evolution ケーススタディ ボニー・チェン"(copyright WGBH and Clear Blue Sky Productions, Inc.) の冒頭の数分間に基づいいる。

達成基準 1.2.5 の実装方法及び不適合事例 - 収録済の映像コンテンツの音声ガイド

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  1. G78: 音声ガイドを含んだ、利用者が選択可能な副音声トラックを提供する

  2. 次のどれか一つを用いて、G173: ムービーの音声ガイド付バージョンを提供する

  3. 次のどれか一つを用いて、G8: 拡張した音声ガイド付のムービーを提供する

達成基準 1.2.5 でさらに対応が望まれる実装方法(参考)

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

  • Providing audio description in multiple languages in SMIL 1.0 (リンク追加予定)

  • Providing audio description in multiple languages in SMIL 2.0 (リンク追加予定)

  • Providing audio description for live synchronized media (リンク追加予定)

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

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

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

重要な用語

音声ガイド

音声トラックに追加されたナレーションで、主音声のトラックだけでは理解できない重要で視覚的な細部を説明するもの。

注記 1:映像の音声ガイドは、動作やしぐさ、登場人物、場面の変化、画面上の文字、およびその他の視覚的なコンテンツに関する情報を提供する。

注記 2: 標準的な音声ガイドでは、ナレーションが会話の合間に追加されている。(拡張した音声ガイドも参照のこと。)

注記 3:すべての映像の情報がすでに既存の音声で提供されている場合、補足の音声ガイドは不要である。

注記 4: "ビデオ説明" や "説明ナレーション" とも呼ばれる。

収録済

ライブではない情報。

同期したメディア

情報や時間経過をベースにしたインタラクティブな構成要素を提示するために、他のフォーマットと同期した音声または映像。ただし、そのメディアがテキストの代替メディアではっきりとそのようにラベル付けされているものは除く。

映像

連続した写真や画像を動かす技術。

注記: 映像は、アニメあるいは写真の画像、もしくはその両方で構成可能である。


収録済の音声コンテンツの手話通訳:
達成基準 1.2.6 を理解する

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

この達成基準の意図

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

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

  • 普段使う言語が手話の人は、読解力に限界があることがある。そういった人は、キャプションを読んで理解することができない恐れがあり、同期したメディアのコンテンツを利用するには手話を必要とする。

達成基準 1.2.6 の事例

  • 事例 1. ある企業が、従業員すべてに対して重要な発表をしている。総会は本社で行われていて、その模様がウェブへストリーミング配信されている。総会の場には手話通訳者がいて、ライブの映像にはプレゼンテーションをしている人物及び手話通訳者の全身が映し出されている。

  • 事例 2. 事例 1 にあるのと同じ発表が、遠隔地にいる従業員にはウェブキャストで届けられている。画面が一つしかないため、手話通訳者は画面のコーナーに映し出されている。

  • 事例 3. ある大学が、講義をする教授の同期したメディアによるプレゼンテーションを作成して、講義のオンライン版を提供している。そのプレゼンテーションには、化学の実験を解説して実演している教授の映像がある。講義内容の手話通訳を制作して、ウェブ上で同期したメディア版とあわせて提供している。

達成基準 1.2.6 の実装方法及び不適合事例 - 収録済の音声コンテンツの手話通訳

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

達成基準 1.2.6 でさらに対応が望まれる実装方法(参考)

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

Metadata Techniques
  • Using metadata to associate sign language alternatives of a video to enable choice of sign language (リンク追加予定)

    • Example:Providing, in metadata, URI(s) that point to several English sign language translations (ASL, SASL, BSL, Auslan, ISL, NZSL) of a Web page.

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

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

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

重要な用語

音声

音声再生の技術。

注記: 音声は、合成的に生成されたものであったり(音声合成を含む)、実世界で録音したものであったり、またその両方もありうる。

収録済

ライブではない情報。

手話通訳

ある言語、通常は話し言葉を、手話に訳すこと。

注記: 本来の手話は、同じ国や地域の話し言葉とは関係のない独立したものである。

同期したメディア

情報や時間経過をベースにしたインタラクティブな構成要素を提示するために、他のフォーマットと同期した音声または映像。ただし、そのメディアがテキストの代替メディアではっきりとそのようにラベル付けされているものは除く。


収録済の映像コンテンツの拡張した音声ガイド:
達成基準 1.2.7 を理解する

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

この達成基準の意図

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

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

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

  • 全盲あるいはロービジョンの利用者、及び認知限界により何が起こっているのかを視覚的に解釈しづらい利用者が、視覚的な情報を音声ガイドから得ている。しかし、主音声の発話があまりにも多いと、音声ガイドでは十分に説明しきれない。そのような場合に、拡張した音声ガイドは、利用者が映像を理解するのに必要な情報を補足することができる。

達成基準 1.2.7 の事例

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

達成基準 1.2.7 の実装方法及び不適合事例 - 収録済の映像コンテンツの拡張した音声ガイド

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  1. 次のどれか一つを用いて、G8: 拡張した音声ガイド付のムービーを提供する

達成基準 1.2.7 でさらに対応が望まれる実装方法(参考)

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

  • Adding extended audio description in multiple languages in SMIL 1.0 (リンク追加予定)

  • Adding extended audio description in multiple languages in SMIL 2.0 (リンク追加予定)

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

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

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

重要な用語

音声ガイド

音声トラックに追加されたナレーションで、主音声のトラックだけでは理解できない重要で視覚的な細部を説明するもの。

注記 1: 映像の音声ガイドは、動作やしぐさ、登場人物、場面の変化、画面上の文字、およびその他の視覚的なコンテンツに関する情報を提供する。

注記 2: 標準的な音声ガイドでは、ナレーションが会話の合間に追加されている。(拡張した音声ガイドも参照のこと。)

注記 3: すべての映像の情報がすでに既存の音声で提供されている場合、補足の音声ガイドは不要である。

注記 4: "ビデオ説明" や "説明ナレーション" とも呼ばれる。

拡張した音声ガイド

追加の説明を付加する時間を作るために映像を一時停止させて、視聴覚のプレゼンテーションに付加した音声ガイド。

注記: この実装方法は、追加の音声ガイドがないと映像の意味が損なわれてしまい、かつ、会話やナレーションの合間が短すぎるときのみに用いられる。

収録済

ライブではない情報。

同期したメディア

情報や時間経過をベースにしたインタラクティブな構成要素を提示するために、他のフォーマットと同期した音声または映像。ただし、そのメディアがテキストの代替メディアではっきりとそのようにラベル付けされているものは除く。

映像

連続した写真や画像を動かす技術。

注記: 映像は、アニメあるいは写真の画像、もしくはその両方で構成可能である。


収録済のメディアの代替:
達成基準 1.2.8 を理解する

1.2.8 収録済のメディアの代替: 収録済同期したメディアすべて及び収録済の映像しか含まないメディアすべてに、時間の経過に伴って変化するメディアの代替を提供する。 (レベル AAA)

この達成基準の意図

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

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

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

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

注記 1: 達成基準 1.2.3、1.2.5、及び 1.2.7 では、映像トラックにある情報のすべてが音声トラックですでに提供されている場合には、音声ガイドを必要としない。

注記 2: 達成基準 1.2.3、1.2.5、及び 1.2.8 は、お互いに重なり合う部分がある。 これは、最低限の適合レベルではコンテンツ制作者に選択肢を与え、より高い適合レベルでは付加的な要件を提示するためである。 達成基準 1.2.3 のレベル A では、コンテンツ制作者には、音声ガイド又は完全な代替テキストのどちらかを提供するという選択肢がある。 レベル AA で適合したい場合、達成基準 1.2.5 において、コンテンツ制作者は音声ガイドを提供しなければならない。もし達成基準 1.2.3 を満たすための代替コンテンツとして音声ガイドを選択していれば、レベル AA の要件をすでに満たしていることになるが、そうでなければこれは付加的な要件ということになる。 達成基準 1.2.8 のレベル AAA では、コンテンツ制作者は拡張したテキストの説明を提供しなければならない。達成基準 1.2.3 及び 1.2.5 において音声ガイドだけを提供することで要件を満たしていた場合には、達成基準 1.2.8 が付加的な要件ということになる。 しかし、達成基準 1.2.3 をテキストの説明による代替を提供することで満たし、なおかつ達成基準 1.2.5 の音声ガイドの要件を満たしている場合には、達成基準 1.2.8 は新しい要件を付加することにはならない。

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

  • よく見ることができないか全く見ることができず、なおかつよく聞こえないか全く聞くことができない利用者が、視聴覚的なプレゼンテーションの情報を利用することができるようになる。

達成基準 1.2.8 の事例

  • 事例 1. ある研修ビデオでの、時間の経過に伴って変化するメディアの代替

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

関連リソース

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

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

達成基準 1.2.8 の実装方法及び不適合事例 - 収録済のメディアの代替

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

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

状況 A: 収録済の同期したメディアの場合:
  1. 次の実装方法のどれか一つを用いて、G69: 時間の経過に伴って変化するメディアに代替を提供する

状況 B: 収録済の映像しか含まないコンテンツの場合:
  1. G159: 映像しか含まないコンテンツの時間の経過に伴って変化するメディアの代替を提供する

達成基準 1.2.8 でさらに対応が望まれる実装方法(参考)

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

  • H46: Using noembed with embed (HTML)

  • Providing a corrected script (リンク追加予定)

  • Adding detail to audio description (リンク追加予定)

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

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

重要な用語

時間の経過に伴って変化するメディアの代替

時間に伴って変化する視覚的および聴覚的情報のトランスクリプトを含み、時間に伴って変化する情報のやりとりの結果を得る手段を提供する文書。

注記: 同期したメディアのコンテンツを作るために用いられる脚本は、編集後の最終的な同期したメディアを正確に描写したものに訂正されている場合のみ、この定義を満たすことになる。

収録済

ライブではない情報。

同期したメディア

情報や時間経過をベースにしたインタラクティブな構成要素を提示するために、他のフォーマットと同期した音声または映像。ただし、そのメディアがテキストの代替メディアではっきりとそのようにラベル付けされているものは除く。

映像しか含まない

映像しか含まない、時間の経過に伴って変化する表現(音声を含まず、インタラクションも含まない)。


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

1.2.9 ライブの音声しか含まないコンテンツの代替: ライブ音声しか含まないコンテンツと等価な情報を提示する時間の経過に伴って変化するメディアの代替を提供する。 (レベル AAA)

この達成基準の意図

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

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

達成基準 1.2.9 の事例

  • ある広告会社が、ウェブベースのキャプションサービスを利用して、ライブのイベントのキャプションを提供している。そのサービスによるキャプションは、ストリーミングの音声制御コントロールのあるウェブペーイのサブフレームに表示されている。

  • フリンジ劇場のライブのラジオ劇が、ウェブで放送されている。俳優たちが大部分は用意された台本通りに演じていて、番組の予算が限られているため、(脚本家の許諾を得た上で)プロデューサーは劇の台本へのリンクを提供している。

  • ストリーミングの音声サーバは、例えば Flash や Silverlight のように、テキスト及びグラフィックも使用可能なメディア形式を利用している。速記者が、あるイベントでライブのキャプションを書き起こしていて、それがその場で組み込まれて、メディアプレーヤーで閲覧可能なメディア配信のライブのキャプションとして使われている。

  • ある CEO が、ニュース速報の報道に反応して、報道メディア向けに電話による記者発表を行っている。その音声を録音して、インターネット上でも配信したが、時間の制約があって、ウェブ・キャプション付加サービスを間に合わせることができなかった。CEO がそこで読み上げる記者発表の内容は予め準備されていたので、その会社は発表内容のトランスクリプトを同時に提供することにした。

関連リソース

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

達成基準 1.2.9 の実装方法及び不適合事例 - ライブの音声しか含まないコンテンツの代替

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

達成基準 1.2.9 でさらに対応が望まれる実装方法(参考)

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

  • Using metadata to associate text transcriptions with audio-only content (リンク追加予定)

    Example:Providing, in metadata, URI(s) that point to several text transcripts (English, French, Dutch) of an audio file.

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

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

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

重要な用語

時間の経過に伴って変化するメディアの代替

時間に伴って変化する視覚的および聴覚的情報のトランスクリプトを含み、時間に伴って変化する情報のやりとりの結果を得る手段を提供する文書。

注記: 同期したメディアのコンテンツを作るために用いられる脚本は、編集後の最終的な同期したメディアを正確に描写したものに訂正されている場合のみ、この定義を満たすことになる。

音声しか含まない

音声のみを含んだ、時間の経過に伴って変化する表現(映像やインタラクションを含まない)。

ライブ

実世界のイベントから取り込まれ、放送による遅延があるだけで受け手に送信される情報。

注記 1: 放送の遅延は、時間的に短い(通常は自動的な)遅れで、例えば放送局に音声(あるいは映像)を待ち行列に入れる、あるいは検閲する時間を与えるために用いられるものだが、編集できるほどの長さではない。

注記 2: もし情報が完全にコンピュータで生成されたものならば、それはライブではない。


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

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

ガイドライン 1.3 の意図

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

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

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

1.3.1 情報および関係性: 表現を通じて伝達されている情報、構造、および関係性が、プログラムで解釈可能である。または、それらがテキストで提供されている。 (レベル A)

この達成基準の意図

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

画面を見ている利用者は、さまざまな視覚的な手がかりによって構造を知覚する。例えば、見出しは大きめで太字のフォントになっていることがほとんどで、段落からは空行をはさんで離れている。リスト項目は、その先頭にビュレットがあって、インデントされていることが多い。段落と段落の間には空行がある。共通の特徴を有するアイテムは、表の行と列で整理されている。フォームの複数のテキストフィールドは、テキストのラベルを共有するグループとして配置されていることがある。異なる背景色を用いて、幾つかのアイテムが互いに関係のあることを示していることもある。特別な状態にある語句は、フォントの種類を変えること及び/又は太字、イタリック、下線付きにしたりすることによって示されている、など。

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

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

用語集にある用語へのリンクを a 要素(又は、使用している技術特有のリンク要素)を用いて実装して、異なるフォントで示していれば、スクリーンリーダーの利用者は、たとえフォントの違いに関する情報は受け取れなかったとしても、用語集にある用語のところではそれがリンクであることが音声読み上げを聞いていて分かるだろう。

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

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

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

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

  • この達成基準は、ユーザエージェントが個々の利用者のニーズに応じてコンテンツに適応できるようにすることによって、さまざまな障害のある利用者の役に立つ。

  • <<!--削除?--

    全盲の(スクリーンリーダーを使用している)利用者が、色を用いて伝えられている情報をテキストでも得られるようになる(色を用いて情報を伝えている画像の代替テキストを含む)。

  • 点字ピンディスプレイを使用している盲ろうの利用者は、色に依存した情報を利用できないことがある。-->>

達成基準 1.3.1 の事例

  • 必須項目のある入力フォーム

    入力フォームに、いくつかの必須項目がある。必須項目のラベルを、赤で表示している。さらに、各ラベルの最後には、アスタリスクの記号文字 "*" が付いている。フォームへの入力に関する説明文には、フォームへの入力に関する説明文には、"すべての必須項目は赤字で示してあり、アスタリスク (*) が付いています。" と書かれていて、例示が後に続いている。

  • 必須項目を示すために色とテキストを用いている入力フォーム

    入力フォームに、必須項目と任意項目の両方がある。入力フォームの先頭にある説明文には、必須項目のラベルが赤字になっていて、"必須" という代替テキストのあるアイコンも付いている。赤字とアイコンの両方が、フォームのテキストフィールドとプログラムで関連付けられているので、支援技術の利用者はどれが必須項目なのかが判断できる。

  • 各セルの見出しがプログラムで解釈可能なバスの時刻表

    バスの運行スケジュールが、1行目には縦にバス停の名前が並び、1列目には横に異なるバスが並んでいる表で示されている。各セルには、バスがそのバス停に到着する時刻が書かれている。支援技術が、各セルにある時刻がどのバスとどのバス停とに関連付けられているのかを解釈することができるように、各バス停と各バスのセルは、それぞれの対応する行又は列の見出しとして示されている。

  • チェックボックスのラベルがプログラムで解釈可能な入力フォーム

    あるフォームでは、各チェックボックスに対するラベルが、支援技術によってプログラムで解釈可能になっている。

  • テキスト文書

    構造がプログラムで解釈できるように、シンプルなテキスト文書は、タイトルの前に2行の空行があり、アスタリスクを使ってリスト項目を示し、その他の標準的な書式の決まりに従ってフォーマットされている。

関連リソース

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

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

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

状況 A: ウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムで解釈可能にするセマンテックな構造を提供している場合:
  1. G115: セマンティックな要素を用いて、構造をマークアップする、かつH49: セマンティックなマークアップを用いて、強調したテキスト又は特別なテキストを示す (HTML)

  2. G117: テキストを用いて、テキストの表現のバリエーションによって伝えている情報を伝達する

  3. G140: 情報と構造を表現から分離して、異なる表現を可能にする

  4. 次の実装方法を用いて、表現によって伝えられている情報及び関係性をプログラムで解釈できるようにする

状況 B: 用いているウェブコンテンツ技術が、表現によって伝えている情報及び関係性をプログラムで解釈可能にするセマンテックな構造を提供していない場合:
  1. G117: テキストを用いて、テキストの表現のバリエーションによって伝えている情報を伝達する

  2. 表現によって伝えられている情報及び関係性をプログラムで解釈可能にする、又は次の実装方法を用いてテキストで入手可能にする:

達成基準 1.3.1 でさらに対応が望まれる実装方法(参考)

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

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

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

重要な用語

表現

利用者が知覚できる形でのコンテンツのレンダリング。

プログラムで解釈(プログラムで解釈可能)

コンテンツ制作者が提供したデータからソフトウェアが解釈できること。また、その際に、支援技術を含むさまざまなユーザエージェントが、この情報を抽出して利用者にさまざまなモダリティで提示できること。

事例 1: マークアップ言語では、一般に入手可能な支援技術が、要素および属性に直接アクセスすることにより解釈できる。

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

関係性

コンテンツの異なる部分間における意味のある関係。

構造
  1. ウェブページの構成要素が相互に関係して系統的に整理されている状態で、かつ

  2. ウェブページの集合が整理されている状態。


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

1.3.2 意味のある順序: コンテンツが提供されている順序がその意味に影響を及ぼす際は、正確な読み上げ順序プログラムで解釈可能にする。 (レベル A)

この達成基準の意図

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

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

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

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

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

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

達成基準 1.3.2 の事例

  • 事例 1: 段組をしている文書では、コンテンツを線形化した表現は、ある段の先頭から最後へと流れていき、その後次の段の先頭へと流れていく。

  • 事例 2: CSS を用いて、ナビゲーションバー、ページの本文、及びサイドメニューを配置している。それらの視覚的な表現は、プログラムで解釈できる順序とは合致していないが、そのページの意味はその見た目の順序には依存していない。

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

達成基準 1.3.2 でさらに対応が望まれる実装方法(参考)

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

  • Using left-justified text for languages that are written left to right and right-justified text for languages that are written right-to-left(リンク追加予定)

  • Providing a link to linearized rendering (リンク追加予定)

  • Providing a style switcher between style sheets that affect presentation order (リンク追加予定)

重要な用語

正確な音声読み上げ順序

コンテンツの意味を変更しない順番で単語や段落が提示される、あらゆる順序。

プログラムで解釈(プログラムで解釈可能)

コンテンツ制作者が提供したデータからソフトウェアが解釈できること。また、その際に、支援技術を含むさまざまなユーザエージェントが、この情報を抽出して利用者にさまざまなモダリティで提示できること。

事例 1: マークアップ言語では、一般に入手可能な支援技術が、要素および属性に直接アクセスすることにより解釈できる。

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


感覚的な特徴:
達成基準 1.3.3 を理解する

1.3.3 感覚的な特徴: コンテンツを理解し操作するための説明を、形、大きさ、視覚的な位置、方向、または音のような、構成要素が人間の感覚に示す特徴だけで提供しない。 (レベル A)

注記: 色に関する要件は、ガイドライン 1.4を参照のこと。

この達成基準の意図

この達成基準の意図は、すべての利用者が形又はサイズを知覚できない、あるいは空間的な位置又は方向に関する情報を利用できない場合でも、すべての利用者がコンテンツを利用するための説明を理解できるようにすることである。コンテンツが、コンテンツの構造からは入手できないオブジェクトの形又は配置が分かることに依存していることがある(例えば、"円いボタン" あるいは "右のボタン")。障害のある利用者は、使用している支援技術の性質のために、形又は配置を知覚できないことがある。この達成基準は、このような情報に依存しているあらゆるものを明確にするために、補足の情報を提供することを要求している。

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

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

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

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

達成基準 1.3.3 の事例

  • 事例: 複数のページによるオンライン調査

    複数のページによるオンライン調査では、あるページから次のページへ移動するためのリンクに緑色の矢印のアイコンを使っていて、それをコンテンツの右下に置いている。矢印には "次へ" というラベルがはっきりと記述されていて、"次の調査へ進むには、最後の質問の右下にある '次へ' というラベルの付いた緑色の矢印のアイコンを選択してください。" という説明文が書かれている。この例では、アイコンを特定できるように、配置、色及びラベルを用いている。

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

達成基準 1.3.3 でさらに対応が望まれる実装方法(参考)

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

  • Using an image with a text alternative for graphical symbols instead of a Unicode font glyph with the desired graphical appearance but different meaning (リンク追加予定)

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

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


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

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

ガイドライン 1.4 の意図

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

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

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

  • Using readable fonts (リンク追加予定)

  • Making sure any text in images of text is at least 14 points and has good contrast (リンク追加予定)

  • Providing a highly visible highlighting mechanism for links or controls when they receive keyboard focus (リンク追加予定)

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

1.4.1 色の使用: 情報を伝える、何が起こるかあるいは何が起きたかを示す、利用者の反応を促す、あるいは視覚的な要素を区別する唯一の視覚的な手段として、色のみを使用しない。 (レベル A)

注記: この達成基準は、特に色の知覚に関するものである。その他の知覚形態については、色やその他の視覚的な表現のコーディングへのプログラムによるアクセスも含めて、ガイドライン 1.3 で網羅されている。

この達成基準の意図

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

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

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

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

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

  • ロービジョンの利用者が、色覚の限界を感じることがよくある。

  • 年配の利用者は、色がよく見えないかもしれない。

  • 色弱の利用者が、色で伝えられている情報をその他の視覚的な手段で知覚できるようになる。

  • テキストしか表示しない、色数が制限されている、又はモノクロのディスプレイを使用している利用者は、色に依存している情報を知覚することができないことがある。

達成基準 1.4.1 の事例

  • 必須項目を示すために色とテキストを用いている入力フォーム

    入力フォームに、必須項目と任意項目の両方がある。 入力フォームの先頭にある説明文には、必須項目のラベルが赤字になっていて、"必須" という代替テキストのあるアイコンも付いている。 赤字とアイコンの両方が、フォームのテキストフィールドとプログラムで関連付けられているので、支援技術の利用者はどれが必須項目なのかが判断できる。

  • 試験

    学生が、化合物の SVG イメージを見て、ダイアグラムに用いられている色に基づいてそこにある化学元素を確認している。代替テキストが、各元素の名前と元素の色を関連付けていて、ダイアグラム内での元素の配置を示している。色を知覚できない学生は、その化合物についてクラスメイトと同じ情報を得ている。(この実装方法は、ガイドライン 1.1 のレベル A も満たしている。)

  • 非活性のフォーム要素

    マークアップ又はスクリプトによって使用不可の状態になっているフォーム要素は、ユーザエージェントによってグレー表示され、非活性になっている。使用不可の状態では、これらの要素はフォーカスを受け取らない。支援技術は、使用不可の状態になっている要素をプログラムで解釈することが可能で、ページ上でその要素を見つけた際にこの情報を利用者に提供するであろう。色の変化及びフォーカスがあたらないことの重複によって、そのコントロールの状態に関する情報を視覚的に提供している。

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

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

状況 A: 特定の語句、背景、又は他のコンテンツの色を用いて情報を示している場合:
  1. G14: 色の違いで伝えている情報をテキストでも入手可能にする

  2. G122: 色の手がかりを用いる際には、必ずテキストの手がかりも提供する

  3. G182: テキストの色の違いで情報を伝える際は、視覚的な手がかりを補足する

  4. G183: リンク又はコントロールを色だけで識別している箇所の視覚的な手がかりを補足するために、周囲にあるテキストとのコントラスト比を 3:1 以上にする

状況 B: 情報を伝える画像の中で色を用いている場合:
  1. G111: 色とパターンを併用する

  2. G14: 色の違いで伝えている情報をテキストでも入手可能にする

達成基準 1.4.1 でさらに対応が望まれる実装方法(参考)

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


音声制御:
達成基準 1.4.2 を理解する

1.4.2 音声制御: ウェブページ上にある音声が3秒より長く自動的に再生される場合、その音声を一時停止あるいは停止するメカニズムを提供する、あるいはシステム全体の音量レベルとは別々に音量を調整するメカニズムを提供する。 (レベル A)

注記: この達成基準を満たさないコンテンツでは、利用者がそのページ全体を使用できない恐れがあるため、Webページ上のすべてのコンテンツは他の達成基準を満たすために用いられているか否かにかかわらず、この達成基準を満たさなければならない。適合要件 5: 非干渉を参照のこと。

この達成基準の意図

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

注記: 利用者があるページへやってきた時に音声が自動再生されると、スクリーンリーダーの利用者はその音声を停止させるメカニズムを探しづらくなることがある。なぜなら、スクリーンリーダーの利用者は、読み上げ音声を聞きながらナビゲートしており、自動的に開始した音声がそのナビゲーションを邪魔してしまうかもしれないからである。そのため、WCAG ワーキンググループでは、音声を自動的に再生しないことを推奨し(特に、3秒よりも長く続く場合)、利用者がそのページにやってきた後、利用者によって音声の再生を停止させるのではなく、利用者の起こしたアクションによって音声が再生を開始することを勧める。

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

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

  • スクリーンリーダーを使用している利用者が、他に再生されている音声に邪魔されることなく、スクリーンリーダーの音声を聞くことができるようになる。難聴及びシステム全体の音量を用いているスクリーンリーダーの利用者(システム全体の音量を下げて、スクリーンリーダーの音量を上げるということができないため)にとっては、特に重要である。

  • また、この達成基準は、音声が再生されていると、視覚的なコンテンツ(テキストを含む)に集中しづらい利用者に対しても役に立つ。

達成基準 1.4.2 の事例

  • ページを開いたときに、音声ファイルが自動的に再生を開始する。しかし、利用者が、そのページの先頭にある「音を消す」というリンクを選択することで、その音声を停止させることができる。

  • 音声が再生されるFlashのスプラッシュページがあり、3秒以内にその音声が停止する。

  • 音声が自動的に再生されるFlashのスプラッシュページの先頭に、利用者が音声を停止できるコントロールがある。

達成基準 1.4.2 の実装方法及び不適合事例 - 音声制御

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

達成基準 1.4.2 でさらに対応が望まれる実装方法(参考)

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

  • Providing a site-wide preference to turn off audio in addition to providing a control near the top of the Web page that turns off sounds that play automatically (リンク追加予定)

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

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

重要な用語

メカニズム

結果を得るためのプロセスあるいはテクニック。

注記 1: メカニズムは、コンテンツ内で明白に提供されることもあれば、あるいは、プラットフォームまたは支援技術を含むユーザエージェントのどちらかで提供されるものに依存することもある。

注記 2: メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。


最低限のコントラスト:
達成基準 1.4.3 を理解する

1.4.3 最低限のコントラスト: テキストおよび画像化された文字の視覚的な表現には、少なくとも 4.5:1 のコントラスト比をもたせる。ただし、次に挙げる場合は除く (レベル AA):

  • 大きな文字: サイズの大きなテキストおよびサイズの大きな画像化された文字には、少なくとも3:1のコントラスト比がある。

  • 付随的: テキストあるいは画像化された文字において、以下の場合はコントラストの要件は該当しない: アクティブではないユーザインタフェース要素の一部分である、装飾だけを目的にしている、視覚的に確認できない、あるいは重要な他の視覚的なコンテンツを含む写真の一部分である。

  • ロゴタイプ: ロゴあるいはブランド名の一部である文字には、コントラストの要件はない。.

この達成基準の意図

この達成基準の意図は、中度のロービジョンの利用者(コントラストを強化する支援技術を使用していない利用者)がテキストを読めるように、テキストとその背景とのコントラストを十分に確保することである。色弱ではない利用者にとっては、読解力によって評価されるように(Knoblauch et al., 1991)、色相及び彩度が文字の読みやすさに影響を与えることはほとんど又は全くない。色弱は、輝度コントラストに多少の影響を及ぼす可能性がある。そのため、この勧告では、色弱の利用者にとってもテキストと背景のコントラストが十分になるように、色が主要因とならないような方法でコントラストを算出している。

装飾を目的にしていて、情報を何も伝えていないテキストは対象外である。例えば、背景でランダムに使われている語句があり、その語句を並び替えたり置き換えたりしても意味が変わらないのであれば、それは装飾を目的にしたものであり、この達成基準を満たす必要はない。

サイズの大きいテキスト及び文字の線幅が広めのテキストは、低めのコントラストでも読みやすい。そのため、サイズの大きいテキストに対するコントラスト要件は、低めになっている。コンテンツ制作者は、特にタイトルなど、ページのデザインにサイズの大きいテキストを用いる際は、より多くの色の中から選ぶことができる。18 ポイント又は太字で 14 ポイントのテキストが、低めのコントラストで十分なサイズの大きさとしている(「関連リソース」にある "The American Printing House for the Blind Guidelines for Large Printing and The Library of Congress Guidelines for Large Print" [英語] を参照のこと)。"18 ポイント" 及び "太字" は、異なるフォントでは異なる意味合いを持つこともあるが、特別に細い線のフォント又は文字の形が分かりにくくなるような独特の見た目や特徴のあるフォントについては対象外とする。とても多くのさまざまなフォントがあるため、ここでは一般的な基準を用いることとして、用語集にて装飾的なフォント又は細い線のフォントに関する注記を付けている。

また、前述のテキストに対するコントラストの要件は、達成基準 1.4.3 で述べられているように、画像化された文字(画像フォーマットで保存された文字)にも適用される。

この要件は、画像化された文字が情報を伝えることを目的としている状況に対して適用される。例えば、写真の中にたまたま入っていた街頭の標識にあるような付随的なテキストは、対象外である。また、何らかの理由で、すべての利用者が視覚的に確認できないことを意図しているテキストも対象外である。

この達成基準には、「意味のあるその他の視覚的なコンテンツを含む写真の一部分である」という例外がある。この例外は、テキストの写っている写真と特定の見た目にするためにテキストの代わりに画像化された文字とを区別することを意図している。

注記 1: 認知障害のある利用者は、低めのコントラストの色の組合せ又は色相を必要とすることがある。そのため、コンテンツ制作者にコンテンツの前景色と背景色を調節するメカニズムを提供することを認め、それを推奨する。選択可能な組合せの中には、この達成基準にあるコントラスト比よりも低いレベルのコントラストがあってもよい。もし、この達成基準に合わせて設定したデフォルトの値に戻すことのできるメカニズムが提供されていれば、その場合はこの達成基準に反していることにはならない。

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

この達成基準は、テキスト(文字)だけに適用されるが、図表やグラフで提示されるデータにも似たような問題が起こる。そのようなデータでも、色のコントラストを十分に確保すべきである。

「達成基準 1.4.6 より十分なコントラスト」を理解するも参照のこと

コントラスト比を定めた論理的根拠

3:1 のコントラスト比は、[ISO-9241-3] 及び [ANSI-HFES-100-1988] によって推奨されている、標準的なテキスト及び視力における最低限のレベルである。4.5:1 のコントラスト比は、中度の弱い視力、先天的又は後天的な色弱、あるいは加齢に伴うコントラスト感度の衰えに起因する、コントラスト感度の低下を考慮している。

論理的根拠は、次のことに基づいている。
a) ANSI(American National Standards Institute:米国の国家規格)スタンダードでは、最低限の許容可能なコントラストとして、コントラスト比 3:1 を採用しており、b)集団内では、20/40 の視力は、おおよそ 1.5 のコントラスト感度低下と関連付けられているという実証的事実がある [ARDITI-FAYE] 。したがって、視力が 20/40 の利用者は、"3 * 1.5 = 4.5:1" のコントラスト比を必要とするであろう。類似した実証的事実及び同じ論理に沿うと、視力が 20/80 の利用者は、約 7:1 のコントラスト比を必要とすることになる。

色相は、色弱の利用者(先天的及び後天的の両方)によって知覚のされ方がさまざまなため、色及び相対的な輝度コントラストが色弱ではない利用者とは異なる。このため、有効なコントラスト及び読みやすさは、色弱の利用者に対しては異なったものになる。しかし、色弱は多様であるため、(コントラストのために)量的なデータに基づいて有効で一般的な色の組合せを規定することは、適切であるとはいえない。十分な輝度コントラストを要求することで、色の知覚に依存しないコントラストを要求し、この問題に対応している。幸いにも、輝度の寄与のほとんどは、分光感度において大部分が重なる中波長及び長波長の受容体からくるものである。その結果は、有効な輝度コントラストが一般的に特定の色弱に関係なく計算できるということである。ただし、赤色を知覚しにくい第一色弱の利用者の場合、暗い色(一般的に黒のようである)に対して主に波長の長い色を用いることは除く(この理由から、WCAG ワーキンググループは、黒の背景に赤の前景を使うことを避けるという参考にすべき実装方法を提供している)。より詳細な情報は、[ARDITI-KNOBLAUCH][ARDITI-KNOBLAUCH-1996][ARDITI] を参照のこと。

レベル AA で 4.5:1 のコントラスト比を選択したのは、20/40 程度まで視力の低下した利用者におけるコントラスト感度の低下を補うためである(20/40 は約 4.5:1 という計算になる)。また、20/40 は、80歳前後の高齢者の標準的な視力として、よく報告される視力である [GITTINGS-FOZARD]

レベル AAA で 7:1 のコントラスト比を選択したのは、20/80 程度まで視力の低下した利用者におけるコントラスト感度の低下を補うためである。これ以上に視力が低下した利用者は、通常は支援技術を使用して、コンテンツを利用している(その支援技術には、コントラスト増強と画面拡大の機能が搭載されている)。そのため、7:1 というコントラスト比は、一般的に支援技術を使用していない利用者のコントラスト感度の低下を補い、同様に色弱の利用者に対してもコントラストを向上させる。

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

計算式に関する注記

RGB 値の非線形から線形への変換は、IEC/4WD 61966-2-1 [IEC-4WD] 及び "A Standard Default Color Space for the Internet - sRGB" [sRGB] に基づいている。

コントラストの計算式(L1/L2)は、[ISO-9241-3] および [ANSI-HFES-100-1988] の標準規格に基づいている。

ANSI/HFS 100-1988 は、L1 及び L2 の計算に含めるために、周辺光からの寄与を必要としている。用いている .05 という値は、[IEC-4WD] の Typical Viewing Flare 及び 論文[sRGB](M. Stokes et al)に基づいている。

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

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

注記 2: キーボード・フォーカスを示すための実装方法については、「達成基準 2.4.7 視覚的に認識可能なフォーカス」を理解する も参照のこと。

注記 3: コンテンツを閲覧するのに特定の色の組合せを必要とする利用者が、好みのカラースキームでコンテンツを閲覧できるようにするために、コンテンツ制作者がページの特定のセクションに色を指定しないことが役に立つことがある。より詳細な情報は、「達成基準 1.4.5 画像化された文字」を理解する を参照のこと。

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

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

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

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

状況 A: 太字でないテキストが18ポイント(日本語は22ポイント)未満、太字のテキストが14ポイント(日本語は18ポイント)未満の場合:
  1. G18: テキスト(及び画像化された文字)とその背景のコントラストを、少なくとも 4.5:1以上にする

  2. G148: 背景色及びテキストの色を指定しない、なおかつ、それらの設定を変更するウェブコンテンツ技術の機能を用いない

  3. G174: 十分なコントラスト比のあるコントロールを提供して、利用者が十分なコントラストのある表示へ切り替えることができるようにする

状況 B: 太字でないテキストが少なくとも18ポイント(日本語は22ポイント)以上、太字のテキストが少なくとも14ポイント(日本語は18ポイント)以上の場合:
  1. G145: テキスト(及び画像化された文字)とその背景のコントラストを、少なくとも 3:1以上にする

  2. G148: 背景色及びテキストの色を指定しない、なおかつ、それらの設定を変更するウェブコンテンツ技術の機能を用いない

  3. G174: 十分なコントラスト比のあるコントロールを提供して、利用者が十分なコントラストのある表示へ切り替えることができるようにする

達成基準 1.4.3 でさらに対応が望まれる実装方法(参考)

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

  • G156: テキスト・ブロックの前景及び背景を変更できる、一般に入手可能なユーザエージェントのあるウェブコンテンツ技術を用いる

  • Using a higher contrast value for text that is over a patterned background (リンク追加予定)

  • Using Unicode text and style sheets instead of images of text (リンク追加予定)

  • Using a higher contrast values for lines in diagrams (リンク追加予定)

  • Using greater contrast level for red-black text/background combinations (リンク追加予定)

  • Using colors that are composed predominantly of mid spectral components for the light and spectral extremes (blue and red wavelengths) for the dark

  • Using a light pastel background rather than a white background behind black text to create sufficient but not extreme contrast (リンク追加予定)

  • Making icons using simple line drawings that meet the contrast provisions for text (リンク追加予定)

  • Providing sufficient color contrast in graphs and charts (リンク追加予定)

  • Using a 3:1 contrast ratio or higher as the default presentation (リンク追加予定)

  • Providing sufficient color contrast for empty text fields (リンク追加予定)

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

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

重要な用語

コントラスト

(L1 + 0.05) / (L2 + 0.05)

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

  • L2は、暗いほうの色の相対輝度である。

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

注記 2: コンテンツ制作者は、テキストのレンダリング(例:フォントのスムージングやアンチエイリアス)に関する利用者の設定を制御できないため、テキストのコントラスト比はアンチエイリアスをオフにした状態で評価される。

注記 3: 達成基準 1.4.3 および 1.4.6 の目的上、コントラストは通常の使用においてテキストがレンダリングされる際に指定されている背景色に対して測定される。もし背景色の指定がない場合は、背景色には白を想定することになる。

注記 4: 背景色は、テキストが通常の使用においてレンダリングされる際に背景となるコンテンツの指定された色である。テキストの色が指定されている際に背景色が指定されていない場合は問題がある。なぜなら、利用者のデフォルトの背景色は未知であり、コントラストが十分かどうかを評価することができないからである。同じ理由で、背景色が指定されている際にテキストの色が指定されていない場合も問題ありということになる。

注記 5: 文字の周囲に縁取りがある際、その縁取りがコントラストを強めることもあり、文字とその背景色におけるコントラストの計算に用いられる。ただし、文字の周囲の細い縁取りは文字として扱われる。文字の周囲の太い縁取りが、かさ(暈:ハロー、後光)のようになって、文字の細かい字画を埋めていれば、背景色として考慮されることになる。

注記 6: WCAG への適合は、典型的な表現において隣接すると制作者が想定してコンテンツで指定した色の組み合わせに対して評価されるべきである。制作者は、ユーザエージェントによる色の変更などのように通常とは異なる表現を考慮する必要はない。ただし、それが制作者のソースコードによって起こる場合は除く。

画像化された文字

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

注記:これには、重要なその他の視覚的なコンテンツを含む画像の一部であるテキストは含まれない。

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

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

少なくとも18ポイント、もしくは14ポイントの太字。あるいは、中国語、日本語、そして韓国語のフォントではそれと同等の文字サイズ(訳注: 日本語では、22ポイント、もしくは18ポイントの太字)。

注記 1: 特別に細い線のフォント、あるいは文字の形が分かりにくくなるような独特の見た目や特徴のあるフォントは、コントラストが低いとき特に読みづらい。

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

注記 3: 文字の実際のサイズは、コンテンツ制作者が指定したサイズと利用者のディスプレイあるいはユーザエージェントの設定の両方に依存している。 For many mainstream body text fonts, 14 and 18 point is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text (assuming that the body font is 100%),しかし、制作者は、使用する特定のフォントについて、このことをチェックしておく必要がある。フォントが相対単位で定義されている時、実際の文字ポイントのサイズは、表示画面のため、ユーザエージェントによって計算される。この評価基準を評価する時には、文字ポイントのサイズは、ユーザエージェントから取得されるべきであり、またはユーザエージェントが行うフォントの計算基準に基づいて計算するべきである。ロービジョンの利用者に対しては、自分で適切な設定を選択することを想定している。

注記 4: フォントサイズを指定せずにテキストを用いる際は、サイズを指定していないテキストに対して主要ブラウザで用いられる最小のフォントサイズをそのテキストのサイズとみなすのが妥当であろう。もし、レベル1の見出しが、主要なブラウザで14ポイントの太字あるいはそれ以上のサイズでレンダリングされるならば、それは「サイズの大きな」テキストであると考えてよい。相対的な拡大縮小は、同じやり方でそのデフォルトのサイズから算出することが可能である。

注記 5: ローマ字のテキストにおける18ポイントおよび14ポイントのサイズは、拡大印刷の最小サイズ(14ポイント)と標準的な大きい文字サイズ(18ポイント)からきている。例えば、中国語、日本語、韓国語など、その他の文字については、「同等な」サイズはその言語での拡大印刷の最小サイズと拡大印刷でその次に大きな標準のサイズとなる。

装飾だけを目的

美的な目的だけを果たしていて、情報は提供せず、機能性も備えていない。

注記: その単語を手直ししたり置き換えたりしてもその目的が変わらないのであれば、テキストは単に装飾だけを目的にしたものといえる。

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

テキスト

プログラムで解釈できる文字の連続で、その連続が自然言語で何かを表現しているもの。

利用者インターフェース要素

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

注記 1: 複数の利用者インターフェース要素が単一のプログラム的要素として実装されることがある。ここでいう要素は、プログラミングテクニックではなく、別々のコントロールとして利用者が知覚するものを指す。

注記 2: 利用者インターフェース要素には、スクリプトで生成されるコンポーネントやフォーム要素、リンクが含まれる。

事例: アプレットには、コンテンツ内を行ごと、ページごと、あるいはランダムに移動するために用いられる "コントロール" がある。これらはどれも識別名があり、個別に設定可能なので、それぞれが "利用者インターフェース要素" となる。


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

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

この達成基準の意図

この達成基準の意図は、軽度の視覚障害のある利用者が、例えば画面拡大ソフトのような支援技術を使わずにそのまま読むことができるように、テキストベースのコントロールを含む視覚的にレンダリングされるテキスト(視覚的に見ることができるように表示されたテキストの文字 [vs. text characters that are still in data form such as ASCII])を問題なく拡大可能にすることである。利用者がメリットを享受できるのは、ウェブページ上のすべてのコンテンツを拡大できることだが、テキストが最も重要な意味を持つ。

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

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

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

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

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

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

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

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

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

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

達成基準 1.4.4 の事例

  • 視覚障害のある利用者が、ウェブページのテキストのサイズをブラウザで 1 em から 1.2 em に変更している。利用者は小さいサイズではテキストを読むことができないが、大きいサイズのテキストは読むことができる。ページ上のすべての情報は、テキストのサイズが大きくなってもまだ表示されている。

  • ページを拡大するためのコントロールがウェブページにある。さまざまな設定を選択すると、そのサイズで最適なデザインとなるようにページのレイアウトが変更される。

  • 利用者が、ユーザエージェントの拡大機能を使って、コンテンツのサイズを変更している。すべてのコンテンツは滑らかに拡大し、ユーザエージェントが必要に応じてスクロールバーを提供している。

関連リソース

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

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

達成基準 1.4.4 でさらに対応が望まれる実装方法(参考)

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

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

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

重要な用語

(この文書で用いられている)支援技術

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

注記 1: 代替のプレゼンテーション(例:合成音声や拡大表示したコンテンツ)、代替入力手法(例:音声認識)、付加的なナビゲーションあるいは位置確認のメカニズム、およびコンテンツ変換(例:テーブルをよりアクセシブルにするもの)を含めて支援技術により提供される機能。

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

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

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

  • 画面拡大ソフトおよびその他の視覚的な表示に関する支援技術。視覚障害、知覚障害、および読書困難などの障害のある人が、レンダリング後のテキストおよび画像の視覚的な読みやすさを改善するために、テキストのフォント、サイズ、間隔、色、音声との同期などを変更するのに使用している。

  • スクリーンリーダー。全盲の人がテキスト情報を合成音声あるいは点字で読み取るために使用している。

  • 音声変換ソフトウェア。認知障害、言語障害、および学習障害のある人が、テキストを合成音声に変換するために使用している。

  • 音声認識ソフトウェア。何らかの身体障害のある利用者が使用することがある。

  • 代替キーボード。特定の身体障害のある人がキーボードを擬似操作するのに使用している(ヘッドポインタ、シングルスイッチ、呼気・吸気スイッチ、およびその他の特別な入力デバイスを使った代替キーボードを含む)。

  • 代替ポインティングデバイス。特定の身体障害のある人がマウスポインタとボタンを擬似操作するのに使用している。

キャプション

そのメディアのコンテンツを理解するのに必要な、発話および発話ではない音声情報の両方に対する、同期した視覚的表現あるいは代替テキスト

注記 1: キャプションは、発話のみの字幕と似ているが、次の点において異なる。キャプションは、発話コンテンツだけでなく、その番組コンテンツを理解するのに必要な、発話ではない音声情報と等価な内容も伝える。つまり、効果音、音楽、笑い声、話者の特定、そして位置なども含まれるのである。

注記 2:クローズド・キャプションは、プレーヤーによっては ON/OFF を切り替えることのできる等価物である。

注記 3: オープン・キャプションは、OFFにすることのできないキャプションである。例えば、キャプションが映像に埋め込まれた、視覚的に等価な画像化された文字である場合がある。

注記 4: キャプションは、映像の関連情報を分かりにくくしたり遮ったりすべきではない。

注記 5: 国によっては、キャプションはサブタイトル(字幕)と呼ばれている。

注記 6:音声ガイドは既に視覚的に提示されている情報の説明なので、キャプションにしてもよいが、そうする必要があるわけではない。

画像化された文字

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

注記:これには、重要なその他の視覚的なコンテンツを含む画像の一部であるテキストは含まれない。

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

テキスト

プログラムで解釈できる文字の連続で、その連続が自然言語で何かを表現しているもの。


画像化された文字:
達成基準 1.4.5 を理解する

1.4.5 画像化された文字: 使用している技術で意図した視覚的な表現が可能である場合は、画像化された文字ではなくテキストを用いて情報を伝える。ただし、以下に挙げる場合は除く (レベル AA):

  • カスタマイズ可能: 画像化された文字が利用者の要求に応じて視覚的にカスタマイズできる。

  • 必要不可欠: 文字の特定の表現が、伝えようとする情報にとって必要不可欠である。

注記: ロゴタイプ(ロゴあるいはブランド名の一部である文字)は必要不可欠なものであるとみなす。

この達成基準の意図

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

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

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

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

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

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

  • ロービジョンの利用者(コンテンツ制作者の指定した書体、サイズ、及び/又は色では、テキストが読みづらいことがある)

  • 視覚追跡に問題のある利用者(コンテンツ制作者の指定した行間及び/又は配置では、テキストが読みづらいことがある)

  • 読字に影響を及ぼす認知障害のある利用者

達成基準 1.4.5 の事例

  • スタイルを指定した見出し

    特定のフォント及びサイズで見出しを提示するために、ビットマップ画像を用いるのではなく、コンテンツ制作者はCSSを用いて同じ見栄えにしている。

  • 動的に生成された画像

    あるウェブページでは、サーバサイドのスクリプトを用いてテキストを画像として提示している。そのページには、利用者が生成される画像のフォントサイズ及び前景色と背景色を調節することのできるコントロールがある。

  • 引用

    あるウェブページに引用がある。その引用部分自体は、イタリックのテキストで、左側をインデントした状態で提示されている。その引用した部分の人名が、引用の下に1.5倍の行間を空けて、左側からさらにインデントした状態になっている。そのテキストの配置、行間スペースの指定、そしてテキストの書体・サイズ・色及び装飾には、CSS を用いている。

  • ナビゲーション

    ウェブページに、ナビゲーション・リンクのメニューがあり、アイコンとテキストの両方でリンク先を示している。CSSを用いて、テキストの書体、サイズ、前景色及び背景色、そしてナビゲーション・リンク間の間隔を指定している。

  • 文字を含んだロゴ

    あるウェブサイトには、各ウェブページの左上のコーナーに組織のロゴがある。そのロゴには、ロゴタイプ(ロゴの一部又は全部に文字)がある。 文字の視覚的な表現は、そのロゴのアイデンティティに不可欠であり、その文字の特徴を変更することができないGIF画像としてそこにある。そして、その画像には、代替テキストがある。

  • 書体のサンプル

    ウェブページに、特定の書体に関する情報がある。その書体を他の書体に置き換えると、サンプルとしての目的が損なわれてしまう。そのサンプルは、その文字の特徴を変更することができない JPEG 画像としてそこにある。そして、その画像には、代替テキストがある。

  • 手紙の原本

    ウェブページに、手紙の原本を描写したものがある。オリジナルの体裁でその手紙見せることが、その手紙の書かれた時代に関する情報を伝える上で不可欠である。その手紙は、その文字の特徴を変更することができない GIF 画像としてそこにある。そして、その画像には、代替テキストがある。

  • 記号的な文字

    利用者がテキストのブロックを入力できるフォームがある。そのフォームは、テキストのスタイル指定やスペルチェックなどの機能のボタンをたくさん提供している。ボタンの中には、文字を用いたものがあり、その文字に自然言語で何かを表現する並び順はない。例えば、フォントを太字にする機能には "B"、テキストをイタリックにする機能には "I"、そしてスペルチェックの機能には "ABC" が使われている。その記号的な文字は、その文字の特徴を変更することができない GIF 画像としてボタンになっている。そして、そのボタンには、代替テキストがある。

  • 画像化された文字のカスタマイズ可能なフォント設定

    あるウェブサイトでは、利用者がフォントを設定できるようになっており、このウェブサイトのすべての画像化された文字は、その設定に基づいて提供される。

関連リソース

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

達成基準 1.4.5 の実装方法及び不適合事例 - 画像化された文字

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

達成基準 1.4.5 でさらに対応が望まれる実装方法(参考)

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

非テキストコンテンツ向けの一般的な実装方法
  1. Identifying informative non-text content (リンク追加予定)

CSS による実装方法
  1. C12: 文字サイズをパーセントで指定する (CSS)

  2. C13: 文字サイズをサイズ名で指定する (CSS)

  3. C14: 文字サイズを em で指定する (CSS)

  4. C8: CSS の letter-spacing プロパティを用いて、単語内の文字間を制御する (CSS)

  5. C6: コンテンツを構造のマークアップに基づいて配置する (CSS)

  6. Avoid applying text styling to text characters within a word (リンク追加予定)

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

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

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

重要な用語

必要不可欠

もし取り除いてしまうと、コンテンツの情報あるいは機能を根本的に変えてしまい、かつ、情報および機能が WCAG に適合する他の方法では提供することができない。

画像化された文字

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

注記:これには、重要なその他の視覚的なコンテンツを含む画像の一部であるテキストは含まれない。

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

テキスト

プログラムで解釈できる文字の連続で、その連続が自然言語で何かを表現しているもの。

視覚的にカスタマイズ

フォント、サイズ、色、および背景を設定可能。


より十分なコントラスト:
達成基準 1.4.6 を理解する

1.4.6 より十分なコントラスト: テキストおよび画像化された文字の視覚的な表現には、少なくとも 7:1 のコントラスト比がある。ただし、以下に挙げる場合は除く (レベル AAA):

  • 大きな文字: サイズの大きなテキストおよびサイズの大きな画像化された文字には、少なくとも 4.5:1 のコントラスト比がある。

  • 付随的: テキストあるいは画像化された文字において、以下の場合はコントラストの要件は該当しない: アクティブではないユーザインタフェース要素の一部分である、装飾だけを目的にしている、視覚的に確認できない、あるいは重要な他の視覚的なコンテンツを含む写真の一部分である。

  • ロゴタイプ:ロゴあるいはブランド名の一部である文字には、コントラストの要件はない。.

この達成基準の意図

この達成基準の意図は、中度のロービジョンの利用者(コントラストを強化する支援技術を使用していない利用者)がテキストを読めるように、テキストとその背景とのコントラストを十分に確保することである。色弱ではない利用者にとっては、読解力によって評価されるように(Knoblauch et al., 1991)、色相及び彩度が文字の読みやすさに影響を与えることはほとんど又は全くない。色弱は、輝度コントラストに多少の影響を及ぼす可能性がある。そのため、この勧告では、色弱の利用者にとってもテキストと背景のコントラストが十分になるように、色が主要因とならないような方法でコントラストを算出している。

装飾を目的にしていて、情報を何も伝えていないテキストは対象外である。例えば、背景でランダムに使われている語句があり、その語句を並び替えたり置き換えたりしても意味が変わらないのであれば、それは装飾を目的にしたものであり、この達成基準を満たす必要はない。

サイズの大きいテキスト及び文字の線幅が広めのテキストは、低めのコントラストでも読みやすい。そのため、サイズの大きいテキストに対するコントラスト要件は、低めになっている。コンテンツ制作者は、特にタイトルなど、ページのデザインにサイズの大きいテキストを用いる際は、より多くの色の中から選ぶことができる。18 ポイント又は太字で 14 ポイントのテキストが、低めのコントラストで十分なサイズの大きさとしている(「関連リソース」にある "The American Printing House for the Blind Guidelines for Large Printing and The Library of Congress Guidelines for Large Print" [英語] を参照のこと)。"18 ポイント" 及び "太字" は、異なるフォントでは異なる意味合いを持つこともあるが、特別に細い線のフォント又は文字の形が分かりにくくなるような独特の見た目や特徴のあるフォントについては対象外とする。とても多くのさまざまなフォントがあるため、ここでは一般的な基準を用いることとして、用語集にて装飾的なフォント又は細い線のフォントに関する注記を付けている。

注記: フォントの見た目を滑らかにするためにアンチエイリアス処理がされている際は、暗さ又は明るさを損なうことがある。それにより、実際のコントラストが引き下げられる可能性がある。フォントの線幅をより太くすれば、この問題を軽減することになるだろう。大きめのフォントを用いて、ユーザエージェントのフォント・スムージング機能をオンにして読みやすさをテストすることを推奨する。

また、前述のテキストに対するコントラストの要件は、達成基準 1.4.5 で述べられているように、画像化された文字(画像フォーマットで保存された文字)にも適用される。

この要件は、画像化された文字が情報を伝えることを目的としている状況に対して適用される。例えば、写真の中にたまたま入っていた街頭の標識にあるような付随的なテキストは、対象外である。また、何らかの理由で、すべての利用者が視覚的に確認できないことを意図しているテキストも対象外である。

この達成基準には、「意味のあるその他の視覚的なコンテンツを含む写真の一部分である」という例外がある。この例外は、テキストの写っている写真と特定の見た目にするためにテキストの代わりに画像化された文字とを区別することを意図している。

この達成基準は、テキスト(文字)だけに適用されるが、図表やグラフで提示されるデータにも似たような問題が起こる。そのようなデータでも、色のコントラストを十分に確保すべきである。

コントラスト比を定めた論理的根拠

3:1 のコントラスト比は、[ISO-9241-3] 及び [ANSI-HFES-100-1988] によって推奨されている、標準的なテキスト及び視力における最低限のレベルである。4.5:1 のコントラスト比は、中度の弱い視力、先天的又は後天的な色弱、あるいは加齢に伴うコントラスト感度の衰えに起因する、コントラスト感度の低下を考慮している。

論理的根拠は、次のことに基づいている。 a) ANSI(American National Standards Institute:米国の国家規格)スタンダードでは、最低限の許容可能なコントラストとして、コントラスト比 3:1 を採用しており、b)集団内では、20/40 の視力は、おおよそ 1.5 のコントラスト感度低下と関連付けられているという実証的事実がある [ARDITI-FAYE] 。したがって、視力が 20/40 の利用者は、"3 * 1.5 = 4.5:1" のコントラスト比を必要とするであろう。類似した実証的事実及び同じ論理に沿うと、視力が 20/80 の利用者は、約 7:1 のコントラスト比を必要とすることになる。

色相は、色弱の利用者(先天的及び後天的の両方)によって知覚のされ方がさまざまなため、色及び相対的な輝度コントラストが色弱ではない利用者とは異なる。このため、有効なコントラスト及び読みやすさは、色弱の利用者に対しては異なったものになる。しかし、色弱は多様であるため、(コントラストのために)量的なデータに基づいて有効で一般的な色の組合せを規定することは、適切であるとはいえない。十分な輝度コントラストを要求することで、色の知覚に依存しないコントラストを要求し、この問題に対応している。幸いにも、輝度の寄与のほとんどは、分光感度において大部分が重なる中波長及び長波長の受容体からくるものである。その結果は、有効な輝度コントラストが一般的に特定の色弱に関係なく計算できるということである。ただし、赤色を知覚しにくい第一色弱の利用者の場合、暗い色(一般的に黒のようである)に対して主に波長の長い色を用いることは除く(この理由から、WCAG ワーキンググループは、黒の背景に赤の前景を使うことを避けるという参考にすべき実装方法を提供している)。より詳細な情報は、[ARDITI-KNOBLAUCH][ARDITI-KNOBLAUCH-1996][ARDITI] を参照のこと。

レベル AA で 4.5:1 のコントラスト比を選択したのは、20/40 程度まで視力の低下した利用者におけるコントラスト感度の低下を補うためである(20/40 は約 4.5:1 という計算になる)。また、20/40 は、80歳前後の高齢者の標準的な視力として、よく報告される視力である [GITTINGS-FOZARD]

レベル AAA で 7:1 のコントラスト比を選択したのは、20/80 程度まで視力の低下した利用者におけるコントラスト感度の低下を補うためである。これ以上に視力が低下した利用者は、通常は支援技術を使用して、コンテンツを利用している(その支援技術には、コントラスト増強と画面拡大の機能が搭載されている)。そのため、7:1 というコントラスト比は、一般的に支援技術を使用していない利用者のコントラスト感度の低下を補い、同様に色弱の利用者に対してもコントラストを向上させる。

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

計算式に関する注記

RGB 値の非線形から線形への変換は、IEC/4WD 61966-2-1 [IEC-4WD] 及び "A Standard Default Color Space for the Internet - sRGB" [sRGB] に基づいている。

コントラストの計算式(L1/L2)は、[ISO-9241-3] および [ANSI-HFES-100-1988] の標準規格に基づいている。

ANSI/HFS 100-1988 は、L1 及び L2 の計算に含めるために、周辺光からの寄与を必要としている。用いている .05 という値は、[IEC-4WD] の Typical Viewing Flare 及び 論文[sRGB](M. Stokes et al)に基づいている。

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

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

注記 2: キーボード・フォーカスを示すための実装方法については、「達成基準 2.4.7 視覚的に認識可能なフォーカス」を理解するも参照のこと。

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

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

達成基準 1.4.6 の事例

達成基準 1.4.6 の実装方法及び不適合事例 - より十分なコントラスト

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

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

状況 A: 太字でないテキストが18ポイント(日本語は22ポイント)未満、太字のテキストが14ポイント(日本語は18ポイント)未満の場合:
  1. G17: テキスト(及び画像化された文字)とその背景のコントラストを、少なくとも 7:1以上にする

  2. G148: 背景色及びテキストの色を指定しない、なおかつ、それらの設定を変更するウェブコンテンツ技術の機能を用いない

  3. G174: 十分なコントラスト比のあるコントロールを提供して、利用者が十分なコントラストのある表示へ切り替えることができるようにする

状況 B: 太字でないテキストが少なくとも18ポイント(日本語は22ポイント)以上、太字のテキストが少なくとも14ポイント(日本語は18ポイント)以上の場合:
  1. G18: テキスト(及び画像化された文字)とその背景のコントラストを、少なくとも 4.5:1以上にする

  2. G148: 背景色及びテキストの色を指定しない、なおかつ、それらの設定を変更するウェブコンテンツ技術の機能を用いない

  3. G174: 十分なコントラスト比のあるコントロールを提供して、利用者が十分なコントラストのある表示へ切り替えることができるようにする

達成基準 1.4.6 でさらに対応が望まれる実装方法(参考)

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

  • G156: テキスト・ブロックの前景及び背景を変更できる、一般に入手可能なユーザエージェントのあるウェブコンテンツ技術を用いる

  • Using a higher contrast value for text that is over a patterned background (リンク追加予定)

  • Using Unicode text and style sheets instead of images of text (リンク追加予定)

  • Using a higher contrast values for lines in diagrams (リンク追加予定)

  • Using greater contrast level for red-black text/background combinations

  • Using colors that are composed predominantly of mid spectral components for the light and spectral extremes (blue and red wavelengths) for the dark

  • Using a light pastel background rather than a white background behind black text to create sufficient but not extreme contrast (リンク追加予定)

  • Making icons using simple line drawings that meet the contrast provisions for text (リンク追加予定)

  • Providing sufficient color contrast in graphs and charts (リンク追加予定)

  • Using a 3:1 contrast ratio or higher as the default presentation (リンク追加予定)

  • Providing sufficient color contrast for empty text fields (リンク追加予定)

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

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

重要な用語

コントラスト

(L1 + 0.05) / (L2 + 0.05)

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

  • L2は、暗いほうの色の相対輝度である。

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

注記 2: コンテンツ制作者は、テキストのレンダリング(例:フォントのスムージングやアンチエイリアス)に関する利用者の設定を制御できないため、テキストのコントラスト比はアンチエイリアスをオフにした状態で評価される。

注記 3: 達成基準 1.4.3 および 1.4.6 の目的上、コントラストは通常の使用においてテキストがレンダリングされる際に指定されている背景色に対して測定される。もし背景色の指定がない場合は、背景色には白を想定することになる。

注記 4: 背景色は、テキストが通常の使用においてレンダリングされる際に背景となるコンテンツの指定された色である。テキストの色が指定されている際に背景色が指定されていない場合は問題がある。なぜなら、利用者のデフォルトの背景色は未知であり、コントラストが十分かどうかを評価することができないからである。同じ理由で、背景色が指定されている際にテキストの色が指定されていない場合も問題ありということになる。

注記 5: 文字の周囲に縁取りがある際、その縁取りがコントラストを強めることもあり、文字とその背景色におけるコントラストの計算に用いられる。ただし、文字の周囲の細い縁取りは文字として扱われる。文字の周囲の太い縁取りが、かさ(暈:ハロー、後光)のようになって、文字の細かい字画を埋めていれば、背景色として考慮されることになる。

注記 6: WCAG への適合は、典型的な表現において隣接すると制作者が想定してコンテンツで指定した色の組み合わせに対して評価されるべきである。制作者は、ユーザエージェントによる色の変更などのように通常とは異なる表現を考慮する必要はない。ただし、それが制作者のソースコードによって起こる場合は除く。

画像化された文字

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

注記:これには、重要なその他の視覚的なコンテンツを含む画像の一部であるテキストは含まれない。

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

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

少なくとも18ポイント、もしくは14ポイントの太字。あるいは、中国語、日本語、そして韓国語のフォントではそれと同等の文字サイズ(訳注: 日本語では、22ポイント、もしくは18ポイントの太字)。

注記 1: 特別に細い線のフォント、あるいは文字の形が分かりにくくなるような独特の見た目や特徴のあるフォントは、コントラストが低いとき特に読みづらい。

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

注記 3: 文字の実際のサイズは、コンテンツ制作者が指定したサイズと利用者のディスプレイあるいはユーザエージェントの設定の両方に依存している。多くの主流となっている本文フォントにおいて、本文テキストのデフォルトのサイズは、14ポイントと18ポイントは、1.2emと1.5em、または、(本文フォントが100%であると仮定して)デフォルトサイズの120%と150%に、おおよそ同等である。しかし、制作者は、使用する特定のフォントについて、このことをチェックしておく必要がある。フォントが相対単位で定義されている時、実際の文字ポイントのサイズは、表示画面のため、ユーザエージェントによって計算される。この評価基準を評価する時には、文字ポイントのサイズは、ユーザエージェントから取得されるべきであり、またはユーザエージェントが行うフォントの計算基準に基づいて計算するべきである。ロービジョンの利用者に対しては、自分で適切な設定を選択することを想定している。

注記 4: フォントサイズを指定せずにテキストを用いる際は、サイズを指定していないテキストに対して主要ブラウザで用いられる最小のフォントサイズをそのテキストのサイズとみなすのが妥当であろう。もし、レベル1の見出しが、主要なブラウザで14ポイントの太字あるいはそれ以上のサイズでレンダリングされるならば、それは「サイズの大きな」テキストであると考えてよい。相対的な拡大縮小は、同じやり方でそのデフォルトのサイズから算出することが可能である。

注記 5: ローマ字のテキストにおける18ポイントおよび14ポイントのサイズは、拡大印刷の最小サイズ(14ポイント)と標準的な大きい文字サイズ(18ポイント)からきている。例えば、中国語、日本語、韓国語など、その他の文字については、「同等な」サイズはその言語での拡大印刷の最小サイズと拡大印刷でその次に大きな標準のサイズとなる。(訳注:日本語では、22ポイント、18ポイントの太字を目安とする。)

装飾だけを目的

美的な目的だけを果たしていて、情報は提供せず、機能性も備えていない。

注記: その単語を手直ししたり置き換えたりしてもその目的が変わらないのであれば、テキストは単に装飾だけを目的にしたものといえる。

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

テキスト

プログラムで解釈できる文字の連続で、その連続が自然言語で何かを表現しているもの。

利用者インターフェース要素

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

注記 1: 複数の利用者インターフェース要素が単一のプログラム的要素として実装されることがある。ここでいう要素は、プログラミングテクニックではなく、別々のコントロールとして利用者が知覚するものを指す。

注記 2: 利用者インターフェース要素には、スクリプトで生成されるコンポーネントやフォーム要素、リンクが含まれる。

事例: アプレットには、コンテンツ内を行ごと、ページごと、あるいはランダムに移動するために用いられる "コントロール" がある。これらはどれも識別名があり、個別に設定可能なので、それぞれが "利用者インターフェース要素" となる。


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

1.4.7 小さい背景音又は背景音なし: 収録済音声しか含まないコンテンツで、(1) 前景に主として話し言葉を含み、(2) 音声 CAPTCHA あるいは音声ロゴではなく、かつ(3) 例えば、歌やラップなどのように、主として音楽表現を意図した発声ではないものについては、以下に挙げるうちの少なくとも1つがあてはまる。 (レベル AAA):

  • 背景音なし: 音声は背景音を含まない。

  • 消音: 背景音を消すことができる。

  • 20 dB: 背景音は、前景にある話し言葉のコンテンツより少なくとも20デシベルは低い。ただし、時折1~2秒間だけ続く音は除く。

    注記: "デシベル" の定義によれば、この要件を満たす背景音は、前景にある話し言葉のコンテンツよりも約4分の1の大きさになる。

この達成基準の意図

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

20 dB(デシベル)という値は、 Large area assistive listening systems (ALS): Review and recommendations [LAALS] and In-the-ear measurements of interference in hearing aids from digital wireless telephones [HEARING-AID-INT] に基づいている。

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

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

達成基準 1.4.7 の事例

関連リソース

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

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

達成基準 1.4.7 でさらに対応が望まれる実装方法(参考)

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

  • Providing a way for users to adjust auditory levels of foreground and background sound independently (リンク追加予定)

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

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

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

重要な用語

音声しか含まない

音声のみを含んだ、時間の経過に伴って変化する表現(映像やインタラクションを含まない)。

CAPTCHA

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

注記 1:CAPTCHA テストは、不明瞭な画像あるいは音声ファイルで提示される文字を利用者に入力するよう求めることが多い。

注記 2:チューリングテストは、人間とコンピュータを判別するために設計されたテストの仕組みである。その名は、これを考案した有名なコンピュータ科学者のアラン・チューリングにちなんで名付けられた。この用語は、カーネギーメロン大学の研究者たちによる造語であった。 [CAPTCHA]

収録済

ライブではない情報。


視覚的な表現:
達成基準 1.4.8 を理解する

1.4.8 視覚的な表現: テキスト・ブロックの視覚的な表現には、以下を実現するメカニズムが利用できる (レベル AAA):

  1. 利用者が、前景色と背景色を選択できる。

  2. 幅が、80文字(図形記号を含む)以下(中国語、日本語、韓国語の場合は、40文字以下)である。

  3. テキストが、均等割り付けされていない (両端揃えではない)。

  4. 段落中の行送り幅(行間隔)は、少なくとも1.5文字分ある。そして、段落の間隔は、その行送り幅の少なくとも1.5倍以上ある。

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

この達成基準の意図

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

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

読字障害又は視覚障害のある利用者にとっては、長い行のテキストは大きな障壁となりうる。彼らは、自分が読んでいる位置を把握し続けることや、テキストの行送りを目で追うことが苦手である。テキストのブロックの幅を狭くすることで、そういった利用者はテキストのブロックを読んでいるときに次の行へ読み進めていきやすくなる。そのため、行の幅は図形記号を含めて80文字以下(中国語、日本語、韓国語の場合は、40文字以下)とすべきである。諸研究によれば、中国語、日本語、及び韓国語の文字は、アルファベット文字と同じ読みやすさで表示すると、幅がほぼ2倍になる。そこで、中国語、日本語、及び韓国語の文字の場合は、行の長さの最長を半分にしている。

認知障害のある利用者は、行送り幅(行間隔)が接近していると、テキストを目で追うのが困難である。行送り幅及び段落の間隔をさらに空けることで、次の行へ移動しやすくなり、段落の終わりにたどりついたことも認識しやすくなる。例えば、行送り幅には1.5倍と1行おきというように、さまざまな選択肢があるのがベストである。段落中の行送り幅が1.5文字分あるというのは、テキストが 'シングルスペース'(そのフォントでのデフォルトの行送り幅)のときと比較して、ある行のベースラインが次の行のベースラインと150%離れていることを意味する。そして、段落の間隔が行送り幅の1.5倍以上あるというのは、ある段落の最終行のベースラインが次の段落の最初の行のベースラインから250%離れていることを意味する(言い換えれば、2つの段落の間に、シングルスペースの空行の150%に相当する、空行が1行あるということである)。

いくらかの認知障害のある利用者は、均等割り付けされているテキストを読むのに問題を抱えている。左右両端を揃えた状態で行ごとに単語間(日本語では文字間)がまちまちの場合、空白が "白い川" のようにページの下のほうへ流れていると、テキストが読みづらくなり、全く読めなくなることもありうる。また、テキストの均等割り付けは、単語間が近くなりすぎて、単語と単語の分かれ目が分かりづらくなってしまうこともある。

テキストのサイズ変更は、視覚的にレンダリングされるテキスト(視覚的に見ることができるように表示されたテキストの文字 [vs. text characters that are still in data form such as ASCII])を、利用者がすべてのコンテンツを見るのに左右にスクロールすることのないように、問題なく拡大可能にすることである。それが可能なようにコンテンツが制作されていると、コンテンツは折り返しになる。これにより、ロービジョンの利用者及び認知障害のある利用者は、混乱することなく、テキストのサイズを拡大することができるようになる。

コンテンツを拡大することは、第一にユーザエージェントが果たすべき役割である。UAAG 1.0 チェックポイント 4.1 を満たしているユーザエージェントは、利用者がテキストの拡大及び縮小を設定できるようにしている。コンテンツ制作者が果たすべき役割は、ユーザエージェントがコンテンツを効果的に拡大できるように、そして表示されているビューポートの横幅の中でコンテンツが折り返すように、ウェブコンテンツを制作することである。テキストのサイズ拡大に関するその他の情報は、「達成基準 1.4.4 テキストのサイズ変更」を理解するを参照のこと。

横スクロールする必要がないという要件は、長い語句を1行に表示すると利用者が横にスクロールする必要があるような、小さい画面の端末に適用することを意図していない。この要件の目的のためには、コンテンツ制作者は、標準的なデスクトップ/ラップトップの画面でブラウザのウィンドウを最大化した状態で、コンテンツがこの要件を満たすようにしなければならない。利用者は一般的に何年も自分のコンピュータを使い続けるので、この基準をテストする際には、最新のデスクトップ/ラップトップの画面解像度ではなく、数年間にわたって普及しているデスクトップ/ラップトップの画面解像度を考慮すべきである。

一つの単語が全画面の幅の半分以上になるほど長くないかぎり、折り返して全体を表示することが可能である。とても長い URI は、拡大された画面からはみ出してしまうかもしれないが、URI は "読む" ためのテキストではないとみなされるので、この基準に反することはない。

この基準は、利用者が横スクロールをする必要が絶対にないということを意味するわけではない。単に、1行のテキストを読むために、利用者が横スクロールを繰り返す必要がないということを意味しているだけである。例えば、テキストが同じ幅の二段組になっているページは、この基準を自動的に満たしていることになるだろう。ページを拡大するというのは、一つめの段が画面上に全部見えていて、利用者がページを縦にスクロールするだけで読むことができるということを意味する。2つめの段を読むには、利用者は右へ横スクロール移動して、右側の段が画面の幅の中に完全に見える状態にして、それ以上は横にスクロールすることなく、その段を読むであろう。

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

この達成基準は、コンテンツの表現はそのままでテキストを読めるようにすることにより、ロービジョンの利用者の役に立つ。テキストの色及びサイズを調節できるようにすることにより、ロービジョンの利用者は、自分が見やすくなるようにテキストを調節することができるようになる。

この達成基準は、認知障害、言語障害、及び学習障害のある利用者がテキストを知覚して、テキストのブロック内での位置を把握できるようにする。

  • 認知障害のある利用者は、自分に最適な前景色と背景色の組合せを選ぶことができると、テキストをより読むことができるようになる。

  • 認知障害のある利用者は、テキストのブロックの幅が狭くて、行送り幅及び段落の間隔を調整できると、自分の読んでいる位置を把握しやすくなる。

  • 認知障害のある利用者は、単語と単語の間隔が均一になっていると、テキストをより容易に読むことができるようになる。

達成基準 1.4.8 の事例

次の画像は、段落内でシングルスペース(1行送り)、1.5文字分の行送り幅(1.5行送り)、及びダブルスペース(2行送り)になっているテキストの例を示している。

シングルスペースのテキストの例(テキストの各行の間に間隔がない) 1.5文字分の行送り幅のテキストの例(間隔がテキスト1行分の半分に等しい) ダブルスペースのテキストの例(間隔が各行間にテキスト1行分に等しい)

図形記号(グリフ)の例としては、"A"、"→" (矢印の記号)、そして "さ" (日本語の文字)などが挙げられる。

関連リソース

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

達成基準 1.4.8 の実装方法及び不適合事例 - 視覚的な表現

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

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

要件 1: 前景色及び背景色を利用者が選択可能にする実装方法
  1. C23: メインコンテンツのテキストの色及び背景色は指定しないが、バナー、特集、ナビゲーションなどの二次的なコンテンツのテキストの色及び背景色を CSS で指定する (CSS) または、

  2. C25: テキストの色及びテキストの背景色は指定しないが、ウェブページのエリア分けをするために、罫線及びレイアウトを CSS で指定する (CSS) または、

  3. G156: テキスト・ブロックの前景及び背景を変更できる、一般に入手可能なユーザエージェントのあるウェブコンテンツ技術を用いる または、

  4. G148: 背景色及びテキストの色を指定しない、なおかつ、それらの設定を変更するウェブコンテンツ技術の機能を用いない または、

  5. G175: 複数の前景色及び背景色を選択できるツールをウェブページ上で提供する

要件 2: 幅が図形記号を含めて80文字以下(中国語、日本語、韓国語の場合は40文字以下)になるようにする実装方法
  1. H87: 閲覧中のウィンドウ幅を狭くしたときに、ユーザエージェントによるテキストの折り返しを阻まない (HTML) または、

  2. C20: ブラウザのウィンドウサイズを変更した際に、行幅が80文字以下になるように、カラム幅を相対サイズで指定する (CSS)

要件 3: テキストを均等割り付け(左右両端揃え)にしないようにする実装方法
  1. C19: CSS で配置を左寄せ又は右寄せのどちらかに指定する (CSS) または、

  2. G172: テキストの両端揃えを解除するメカニズムを提供する または、

  3. G169: テキストを片側だけに寄せて配置する

要件 4: 段落内の行送り幅(行間隔)が少なくとも1.5文字分、及び段落の間隔がその行送り幅の少なくとも1.5倍になるようにする実装方法:
  1. G188: 行送り幅(行間隔)及び段落間を広げられるボタンをページ上で提供する または、

  2. C21: 行送り幅(行間隔)を CSS で指定する (CSS)

要件 5: 利用者が全画面表示にしたウィンドウで1行のテキストを読む際に横スクロールする必要がない状態で、テキストを支援技術を用いなくても200%までサイズ変更できるようにする実装方法
  1. 閲覧中のウィンドウ幅を狭くしたときに、ユーザエージェントによるテキストの折り返しを阻まない(リンク追加予定)

  2. G146: リキッド・レイアウトを用いる 、かつ 次の実装方法の一つ以上を用いて、コンテンツにあるその他の大きさと相対的な大きさにする:

  3. C26: 利用者が1行のテキストを横スクロールせずに読むことができるレイアウトに切り替えるオプションをコンテンツ内で提供する (CSS)

達成基準 1.4.8 でさらに対応が望まれる実装方法(参考)

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

  • Using a hover effect to highlight a paragraph, list items, or table cells (HTML, CSS) (リンク追加予定)

  • Presenting text in sans serif font or providing a mechanism to achieve this (CSS) (リンク追加予定)

  • Using vertical (bulleted or numbered) lists rather than inline lists (リンク追加予定)

  • Using upper and lower case according to the spelling conventions of the text language (リンク追加予定)

  • Providing large fonts by default (リンク追加予定)

  • Avoiding the use of text in raster images (リンク追加予定)

  • Avoiding scaling font sizes smaller than the user-agent default (リンク追加予定)

  • Providing sufficient inter-column spacing (リンク追加予定)

  • Avoiding centrally aligned text (リンク追加予定)

  • Avoiding chunks of italic text (リンク追加予定)

  • Avoiding overuse of different styles on individual pages and in sites (リンク追加予定)

  • Making links visually distinct (リンク追加予定)

  • Providing expandable bullets (リンク追加予定)

  • Show/hide bullet points (リンク追加予定)

  • Putting an em-space or two spaces after sentences (リンク追加予定)

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

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

重要な用語

テキスト・ブロック

テキストの一文よりも長いもの。

メカニズム

結果を得るためのプロセスあるいはテクニック。

注記 1:メカニズムは、コンテンツ内で明白に提供されることもあれば、あるいは、プラットフォームまたは支援技術を含むユーザエージェントのどちらかで提供されるものに依存することもある。

注記 2: メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。

全画面表示のウィンドウで

最も一般的なデスクトップ/ラップトップのディスプレイで、ビューポート(情報の表示域)を最大化した状態。

注記: 利用者は一般的にコンピュータを数年間使い続けるので、最新のデスクトップやラップトップの画面解像度を基準にするのではなく、数年間にわたって一般的なデスクトップやラップトップの画面解像度を考慮するのが最もよい。


画像化された文字(例外なし):
達成基準 1.4.9 を理解する

1.4.9 画像化された文字(例外なし): 画像化された文字は、装飾だけを目的に用いられているか、その情報を伝える上でテキストを特定の形で表現することが必要不可欠である。 (レベル AAA)

注記: ロゴタイプ(ロゴあるいはブランド名の一部である文字)は必要不可欠なものであるとみなす。

この達成基準の意図

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

これは、テキストをその表現が変更できるように実装すること、又は利用者が代替の表現を選択できるメカニズムを提供することを意味する。画像化された文字を使用することは、すべての利用者がテキストの表現を変えることができない実装の一例である。

ある状況においては、文字の特定の視覚的な表現がその情報を伝える上で不可欠である。その特定の視覚的な表現でないと、その情報が損なわれてしまうことになる。そのような場合は、テキストを変更できるような方法で実装する必要はない。例えば、ある書体を紹介する際のようにテキストの特定の視覚的な様相を示す場合や、企業ロゴにある文字のようにアイデンティティを伝える文字などが挙げられる。

装飾を目的にした文字は、その表現を変更できるように実装する必要はない。

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

  • ロービジョンの利用者(コンテンツ制作者の指定した書体、サイズ、及び/又は色では、テキストが読みづらいことがある)

  • 視覚追跡に問題のある利用者(コンテンツ制作者の指定した行間及び/又は配置では、テキストが読みづらいことがある)

  • 読字に影響を及ぼす認知障害のある利用者

達成基準 1.4.9 の事例

  • 引用

    あるウェブページに引用がある。その引用部分自体は、イタリックのテキストで、左側をインデントした状態で提示されている。その引用した部分の人名が、引用の下に1.5倍の行間を空けて、左側からさらにインデントした状態になっている。そのテキストの配置、行間スペースの指定、そしてテキストの書体・サイズ・色及び装飾には、CSS を用いている。

  • ナビゲーション

    ウェブページに、ナビゲーション・リンクのメニューがあり、アイコンとテキストの両方でリンク先を示している。CSSを用いて、テキストの書体、サイズ、前景色及び背景色、そしてナビゲーション・リンク間の間隔を指定している。

  • 文字を含んだロゴ

    あるウェブサイトには、各ウェブページの左上のコーナーに組織のロゴがある。 そのロゴには、ロゴタイプ(ロゴの一部又は全部に文字)がある。 文字の視覚的な表現は、そのロゴのアイデンティティに不可欠であり、その文字の特徴を変更することができないGIF画像の中にある。そして、その画像には、代替テキストがある。

  • 書体のサンプル

    ウェブページに、特定の書体に関する情報がある。その書体を他の書体に置き換えると、サンプルとしての目的が損なわれてしまう。そのサンプルは、その文字の特徴を変更することができない JPEG 画像の中にある。そして、その画像には、代替テキストがある。

  • 手紙の原本

    ウェブページに、手紙の原本を描写したものがある。オリジナルの体裁でその手紙見せることが、その手紙の書かれた時代に関する情報を伝える上で不可欠である。その手紙は、その文字の特徴を変更することができない GIF 画像の中にある。そして、その画像には、代替テキストがある。

  • 記号的な文字

    利用者がテキストのブロックを入力できるフォームがある。そのフォームは、テキストのスタイル指定やスペルチェックなどの機能のボタンをたくさん提供している。ボタンの中には、文字を用いたものがあり、その文字に自然言語で何かを表現する並び順はない。例えば、フォントを太字にする機能には "B"、テキストをイタリックにする機能には "I"、そしてスペルチェックの機能には "ABC" が使われている。その記号的な文字は、その文字の特徴を変更することができない GIF 画像としてボタンになっている。そして、そのボタンには、代替テキストがある。

関連リソース

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

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

達成基準 1.4.9 でさらに対応が望まれる実装方法(参考)

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

General Techniques for Non-Decorative Content
  • Using server-side scripts to resize images of text (リンク追加予定)

CSS Techniques

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

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

重要な用語

必要不可欠

もし取り除いてしまうと、コンテンツの情報あるいは機能を根本的に変えてしまい、かつ、情報および機能が WCAG に適合する他の方法では提供することができない。

画像化された文字

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

注記: これには、重要なその他の視覚的なコンテンツを含む画像の一部であるテキストは含まれない。

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

装飾だけを目的

美的な目的だけを果たしていて、情報は提供せず、機能性も備えていない。

注記: その単語を手直ししたり置き換えたりしてもその目的が変わらないのであれば、テキストは単に装飾だけを目的にしたものといえる。

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

テキスト

プログラムで解釈できる文字の連続で、その連続が自然言語で何かを表現しているもの。


キーボード操作可能:
ガイドライン 2.1 を理解する

ガイドライン 2.1: 全ての機能をキーボードから利用できるようにする。

ガイドライン 2.1 の意図

すべての機能がキーボードを用いて利用可能であれば、キーボードの利用者、音声入力(キーボード入力を生成する)、マウス(オンスクリーン・キーボードを使用する)、及び出力として疑似的なキーストロークを生成する広範囲に及ぶ支援技術が、その機能を利用することができることになる。この柔軟性は他の入力形態にはないもので、キーボード入力が時間に依存していないかぎり、広く一般にサポートされていて、さまざまな障害のある利用者が操作可能な入力形態は他にはない。

普遍的なキーボード入力を提供することが、他の種類の入力をサポートをサポートすべきではないという意味ではないことに注意してほしい。最適化された音声入力、最適化されたマウス/ポインタなども、有用である。重要なのは、それらと同様にキーボード入力及び制御も提供することである。

中には、もともとキーボードを持たないものもある。例えば、PDA 又は携帯電話がそうである。しかし、こういったデバイスにウェブ閲覧機能がある場合には、テキスト又は "キーストローク" を生成する何らかの手段があるはずである。このガイドラインでは、キーボード、キーボード・エミュレータ、又はキーボードあるいはテキスト入力を生成するその他のハードウェアあるいはソフトウェアにより生まれるキーストロークにより、ウェブコンテンツが制御可能であるべきだということを認識するために、"キーボード・インタフェース" という用語を用いている。

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

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

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

キーボード操作:
達成基準 2.1.1 を理解する

2.1.1 キーボード操作: コンテンツのすべての機能は、個々のキーストロークに特定のタイミングを要することなく、キーボード・インタフェースを通じて操作可能である。ただし、その根本的な機能が単に利用者の動作の終点に依存しておらず、利用者の動作による軌跡に依存して実現されている場合は除く。 (レベル A)

注記 1: 前述の例外は、コンテンツの根本的な機能に関するものであり、入力手法に関するものではない。例えば、テキスト入力に手書き入力を用いるのであれば、その入力手法(手書き)は利用者の動作による軌跡(たとえば手書き入力に用いるマウスの動き)に依存した入力を必要とするが、その根本的な機能(テキスト入力)は利用者の動作による軌跡に依存した入力を必要とするものではない。

注記 2: これは、キーボード操作に加えて、マウス入力あるいはその他の入力手段を提供することを禁ずるものでも妨げるものでもない。

この達成基準の意図

この達成基準の意図は、可能なかぎり、コンテンツをキーボード又はキーボード・インタフェースで操作できるようにすることである(代替キーボードでも使用可能になる)。コンテンツがキーボード又は代替キーボードで操作可能であれば、全盲の(目と手を一緒に使うマウスのようなデバイスを使用できない)利用者、及び代替キーボード又はキーボード・エミュレータのような入力デバイスを使わなければならない利用者が、操作できることになる。キーボード・エミュレータには、音声入力ソフトウェア、呼気/吸気操作ソフトウェア、オンスクリーン・キーボード、スキャニングソフトウェア、そして多種多様な支援技術及び代替キーボードがある。また、ロービジョンの利用者は、ポインタを目で追うのが困難なことがあり、キーボードでソフトウェアを操作できれば、そのソフトウェアがとても使いやすくなる(又は、単に使えるようになる)。

"特定のタイミング" の事例としては、利用者が短時間のうちに複数のキーストロークを繰り返す又は実行する必要がある状況、あるいはキーストロークが登録されるまでは長い間キーを押下していなければならないような状況などが挙げられる。

"ただし、その根本的な機能が単に利用者の動作の終点に依存しておらず、利用者の動作による軌跡に依存して実現されている場合は除く。" というフレーズがあるのは、キーボードから合理的に制御できないものを区別するためである。

ポインティング・デバイスにより実行されるアクションのほとんどは、キーボードでも実行可能である(例えば、クリックする、選択する、動かす、拡大・縮小する)。しかし、ポインティング・デバイスでは可能だが、ものすごい数のキーストロークでないとキーボードでは不可能な入力がある。手書き描画、水彩画、及び障害物コースでのヘリコプター操縦などは、どれも軌跡(たとえば手書き入力に用いるマウスの動き)に依存した入力を要する機能の例である。直線や正の幾何学的図形を描くこと、ウィンドウのサイズを変更すること、及びある場所へオブジェクトをドラッグして移動させること(その位置への軌跡に意味がない際)は、軌跡に依存した入力を必要としない。

マウスキーを使用することでは、この達成基準を満たしたことにはならないだろう。なぜなら、アプリケーションに対しては、キーボードと等価なのではなく、マウスと等価だからである(つまり、アプリケーションからはマウスのように見えてしまうためである)。

利用者の入力機能を設計する際に、利用者がそのOSのキーボード・アクセシビリティ機能を使用する可能性があることを考慮するのは当然のことである。例えば、修飾キーがロックされているかもしれない。しかし、修飾キーのロックと衝突するイベントを送って予期しない結果が生じることのないように、コンテンツはそのような環境においても機能し続ける必要がある。

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

  • 全盲の利用者(目と手を一緒に使うマウスのようなデバイスを使用できない)

  • ロービジョンの利用者(画面上のポインタを見つけたり目で追ったりするのが困難なことがある)

  • 手に震えのある利用者は、マウスを使うのがとても困難なため、通常はキーボードを使用している。

達成基準 2.1.1 の事例

  • 事例 1: 描画プログラム

    ある描画プログラムは、利用者がキーボード操作でオブジェクトの作成、サイズ設定、配置及び回転をすることが可能である。

  • 事例 2: ドラッグ&ドロップ機能

    ドラッグ&ドロップを用いているアプリケーションが、オブジェクトを移動させるための "カット&ペースト" 又はフォーム・コントロールをサポートしている。

  • 事例 3: 離れている点の間を移動および接続

    点つなぎプログラムは、利用者が画面上の点を移動し、スペースキーで現在の点と直前の点を結ぶことができる。

  • 事例 4: 例外 - お絵描きプログラム

    水彩画を描くプログラムは、ひと筆がその動きの速さや持続にかなり依存して変化するため、例外の一つとして認められる。

  • 事例 5: 例外 - ヘリコプター操縦訓練シミュレータ

    ヘリコプター操縦訓練シミュレータは、シミュレータの性質上、リアルタイムなヘリコプターの動作を教えるものであるため、例外の一つとして認められる。

  • 事例 6: オプションのキーボード付き PDA

    通常はスタイラス・ペンで操作する PDA に、オプションで接続可能なキーボードがある。そのキーボードは、標準的な方法でウェブ閲覧を可能にする。ウェブコンテンツがキーボードのみでも利用できるように設計されているので、そのキーボードでも操作可能である。

達成基準 2.1.1 の実装方法及び不適合事例 - キーボード操作

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  1. Ensuring keyboard control by using one of the following techniques.

  2. G90: Providing keyboard-triggered event handlers using one of the following techniques:

達成基準 2.1.1 でさらに対応が望まれる実装方法(参考)

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

  • Using XHTML role, state, and value attributes if repurposing static elements as interactive user interface components (リンク追加予定) AND SCR29: Adding keyboard-accessible actions to static HTML elements (Scripting)

  • Providing keyboard shortcuts to important links and form controls (リンク追加予定)

  • Using unique letter combinations to begin each item of a list (リンク追加予定)

  • Choosing the most abstract event handler (リンク追加予定) (Scripting)

  • Using the onactivate event (リンク追加予定) (Scripting)

  • Avoiding use of common user-agent keyboard commands for other purposes (リンク追加予定)

重要な用語

機能性

利用者のアクションにより実現可能なプロセスおよび結果。

キーボード・インターフェース

キーストローク入力を取得するためにソフトウェアが用いるインターフェース。

注記 1: キーボードをもともと含んでいない技術であっても、キーボードインターフェースによって利用者がキーストローク入力をプログラムに提供できるようにする。

事例:タッチスクリーンPDAには、外部キーボードへのコネクタとあわせて、そのOSに組み込まれたキーボード・インターフェースがある。PDA上のアプリケーションはそのインターフェースを用いて、外部キーボード、あるいは手書き解釈プログラムや「キーボード・エミュレーション」機能付きの音声テキスト変換アプリケーションのような擬似キーボード出力を提供する他のアプリケーションのいずれかからキーボード入力を取得することができる。

注記 2:マウスキーのようなキーボード操作によるマウス・エミュレータによるアプリケーション(あるいは、そのアプリケーションの一部)の操作は、キーボード・インターフェースからの操作として見なされていない。それはプログラムの操作がキーボード・インターフェースからではなく、そのポインティング・デバイスからの操作だからである。


フォーカス移動:
達成基準 2.1.2 を理解する

2.1.2 フォーカス移動: キーボード・インタフェースを用いてキーボード・フォーカスをそのページのある構成要素に移動できる場合、キーボード・インタフェースだけを用いてその構成要素からフォーカスを外すことが可能である。また、もしその操作が矢印キー、あるいはTabキー以外の操作を必要とするならば、キーボード・フォーカスをその構成要素から外す方法を利用者に知らせる。 (レベル A)

注記: この達成基準を満たさないコンテンツでは、利用者がそのページ全体を使用できない恐れがあるため、Webページ上のすべてのコンテンツは他の達成基準を満たすために用いられているか否かにかかわらず、この達成基準を満たさなければならない。適合要件 5: 非干渉を参照のこと。.

この達成基準の意図

この達成基準の意図は、コンテンツがウェブページ上の一部分にキーボード・フォーカスを "閉じ込める" ことのないようにすることである。これは、一つのページの中に複数のフォーマットを組み合わせていて、プラグインを用いてレンダリングする又はアプリケーションを埋め込んでいる際によく起こる問題である。

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

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

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

達成基準 2.1.2 の事例

  • カレンダーのウィジェット

    カレンダーのウィジェットは、利用者がキーボードを用いてそのカレンダーにアイテムを追加、削除又は更新することができるようになっている。ウィジェットにあるコントロールは、そのウェブページの Tab キーによるフォーカス移動順序の一部に入っていて、利用者がウィジェットのコントロールもその他のリンク又はコントロールをTabキーで移動できる。

    利用者が Tab キーでフォーカスをアプレットの中に入れると、そこから先のフォーカス移動及びその他のキーストロークはそのアプレットが処理することになる。そして、そのアプレットから外へ出るのに用いるキーストロークに関する説明文が、そのアプレットに入る前及びそのアプレットの中にある。

  • モーダル・ダイアログボックス

    ウェブアプリケーションで、ダイアログボックスが出てくる。そのダイアログボックスの下部には、"キャンセル" と "OK" の2つのボタンがある。ダイアログボックスが開くと、フォーカスはそのダイアログボックスから外へ抜け出せなくなる。ダイアログボックスの最後のコントロールで Tab キーを押すと、フォーカスはダイアログボックスの最初のコントロールへ移動してしまうのである。"キャンセル" ボタン又は "OK" ボタンを押下すると、そのダイアログボックスは閉じられる。

達成基準 2.1.2 の実装方法及び不適合事例 - フォーカス移動

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  1. G21: Ensuring that users are not trapped in content

達成基準 2.1.2 でさらに対応が望まれる実装方法(参考)

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

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

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

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

重要な用語

キーボード・インターフェース

キーストローク入力を取得するためにソフトウェアが用いるインターフェース。

注記 1: キーボードをもともと含んでいない技術であっても、キーボードインターフェースによって利用者がキーストローク入力をプログラムに提供できるようにする。

事例:タッチスクリーンPDAには、外部キーボードへのコネクタとあわせて、そのOSに組み込まれたキーボード・インターフェースがある。PDA上のアプリケーションはそのインターフェースを用いて、外部キーボード、あるいは手書き解釈プログラムや「キーボード・エミュレーション」機能付きの音声テキスト変換アプリケーションのような擬似キーボード出力を提供する他のアプリケーションのいずれかからキーボード入力を取得することができる。

注記 2:マウスキーのようなキーボード操作によるマウス・エミュレータによるアプリケーション(あるいは、そのアプリケーションの一部)の操作は、キーボード・インターフェースからの操作として見なされていない。それはプログラムの操作がキーボード・インターフェースからではなく、そのポインティング・デバイスからの操作だからである。


キーボード操作(例外なし):
達成基準 2.1.3 を理解する

2.1.3 キーボード操作(例外なし): コンテンツのすべての機能は、個々のキーストロークに特定のタイミングを要することなく、キーボード・インタフェースを通じて操作可能である。 (レベル AAA)

この達成基準の意図

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

達成基準 2.1.3 の実装方法及び不適合事例 - キーボード操作(例外なし)

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  1. この達成基準には、特に実装方法があるわけではない。達成基準 2.1.1 の実装方法を参照のこと。アナログで時間の経過に依存した入力があるためにその実装方法が不可能な場合は、このレベル AAA の達成基準に適合することはできない。

重要な用語

機能性

利用者のアクションにより実現可能なプロセスおよび結果。

キーボード・インターフェース

キーストローク入力を取得するためにソフトウェアが用いるインターフェース。

注記 1: キーボードをもともと含んでいない技術であっても、キーボードインターフェースによって利用者がキーストローク入力をプログラムに提供できるようにする。

事例: タッチスクリーンPDAには、外部キーボードへのコネクタとあわせて、そのOSに組み込まれたキーボード・インターフェースがある。PDA上のアプリケーションはそのインターフェースを用いて、外部キーボード、あるいは手書き解釈プログラムや「キーボード・エミュレーション」機能付きの音声テキスト変換アプリケーションのような擬似キーボード出力を提供する他のアプリケーションのいずれかからキーボード入力を取得することができる。

注記 2: マウスキーのようなキーボード操作によるマウス・エミュレータによるアプリケーション(あるいは、そのアプリケーションの一部)の操作は、キーボード・インターフェースからの操作として見なされていない。それはプログラムの操作がキーボード・インターフェースからではなく、そのポインティング・デバイスからの操作だからである。


十分な時間:
ガイドライン 2.2 を理解する

ガイドライン 2.2: 利用者がコンテンツを読んだり使用したりするのに十分な時間を提供する。

ガイドライン 2.2 の意図

障害のある利用者の多くは、そうでない利用者と比べると、タスクを完了するのにより長い時間を必要とする。それは、身体的に反応するのに時間がかかることがある、何かを読むのに時間がかかることがある、ロービジョンのために何かを見つけたり読んだりするのに時間がかかることがある、あるいはより時間を要する支援技術を使用してコンテンツを利用していることがあるからである。このガイドラインは、利用者がコンテンツに要求されるタスクを自分の必要とする時間をかけて完了できるようにすることに焦点を当てている。主なアプローチとして、制限時間を取り除くこと、又はタスクを完了するために十分な時間を利用者が追加できるようにすることを挙げている。ただし、それが不可能な場合に対する例外が認められている。

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

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

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

調整可能な制限時間:
達成基準 2.2.1 を理解する

2.2.1 調整可能な制限時間: コンテンツに制限時間を設定する場合は、次のうちの少なくとも1つが当てはまる。 (レベル A):

  • 解除: 制限時間内に、利用者がその制限時間を解除することができる。または、

  • 調整: 制限時間内に、利用者が制限時間をデフォルトの設定の少なくとも10倍の長さまでの範囲で調整できる。または、

  • 延長: 時間切れになる前に利用者に警告し、利用者が少なくとも20秒間の猶予をもって、例えば "スペースキーを押す" などの簡単な操作で延長でき、そして利用者が制限時間を少なくとも10倍以上延長することができる。または、

  • リアルタイムの例外: 制限時間がリアルタイムのイベント(例えば、オークション)に必須の要素で、その制限時間に代わる手段が存在しない。または、

  • 必要不可欠な例外: 制限時間が必要不可欠なもので、制限時間を延長することがコンテンツの動作を無効にすることになる。または、

  • 20時間の例外: 制限時間が20時間よりも長い。

注記: この達成基準は、制限時間の結果として、コンテンツあるいは状況の変化が予期せず起こることなく、利用者がタスクを完了できるようにするためのものである。この達成基準は、利用者のアクションの結果としてのコンテンツあるいは状況の変化を制限する達成基準 3.2.1と併せて考慮されるべきである。

この達成基準の意図

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

利用者による開始がなく、設定時間後又は定期的に発生する処理は、どれも制限時間である。コンテンツの一部又は全部の更新(例えば、ページのリフレッシュ)、コンテンツの変更、利用者が入力の要求に応じるウィンドウの期限切れなどが含まれる。

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

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

  • サーバによる制限時間のあるリダイレクトは、以下にあるよくある不適合事例で参照可能である。

  • ログインの時間切れのようなサーバによる制限時間には、達成基準 2.2.5が対応している。

  • サーバによる制限時間のないリダイレクト(例: 3xx のレスポンスコード)は、制限時間はなく、瞬時に働くので、この達成基準には適用されない。

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

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

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

  • 上限として20時間を基準に選んだのは、一般に人が一日で起きている時間よりも長いからである。

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

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

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

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

  • 手話通訳者が音声が聞こえない利用者に音声コンテンツを通訳しているような状況では、制限時間を調整できることも重要である。.

  • 読字障害、認知障害及び学習障害のある利用者は、情報を読んで理解するのに時間がかかることがあり、コンテンツを一時停止させることによって、その情報を読む時間を延長させることができるようになる。

達成基準 2.2.1 の事例

  • あるウェブサイトは、クライアントサイドの制限時間を用いて、コンピュータから離れてしまう可能性のある利用者を保護している。何も活動がないと、ウェブページは利用者がまだ時間が必要かどうかを確認する。もし利用者からの反応がなければ、そこでタイムアウトになる。

  • ウェブページに、最新のニュース見出しを回転させて自動的に更新する部分がある。インタラクティブなコントロールがあり、利用者は更新する間隔の時間をデフォルトの10倍の長さに延ばすことができる。そのコントロールは、マウス又はキーボードのどちらかで操作可能である。

  • ウェブページにアニメーションがあり、至るところに現れては消えるテキストがある。テキストがスクロールして画面を横切るものもあれば、表示されると短時間で背景にフェードしていくものもある。テキストを読むのが困難な利用者がテキストが消えてしまう前に読むことができるように、そのページには一時停止ボタンがある。

  • オークションにおいて、利用者が入札しなければならない時間に制限時間がある。その制限時間は、特定にアイテムに入札したい利用者すべてに適用されるので、特定の利用者だけに時間の延長を認めると公平ではなくなってしまう。そのため、制限時間はこの種のコンテンツには必須であり、この達成基準によって、制限時間の延長、調整、又は解除を要求されることはない。

  • オンラインチケット購入サイトでは、利用者が席を確保して購入内容を確認するのに2分間の制限時間が与えられている。そのようなサイトのチケットはすぐに売り切れてしまうため、それ以上チケットを確保しておくと、そのサイトの機能を発揮できない可能性がある。そのため、これは制限時間が必要不可欠で、コンテンツを有効なまま延長することができない事例の一つである。しかし、そのサイトは、制限時間の始まる前に、例えば氏名、支払方法などの必要な情報を利用者が提供できるようにするなどして、できるかぎり多くのプロセスを制限時間外で行えるようにしている。

  • チケット購入サイトは、利用者が選択した席の購入を確認するために2分間の制限時間を与えているが、時間切れが近づくと利用者に警告を出し、例えば、"時間を延長する" ボタンを押すなどの簡単な操作で、利用者がこの制限時間を何分間か延長できるようにしている。

関連リソース

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

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

達成基準 2.2.1 の実装方法及び不適合事例 - 調整可能な時間制限

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

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

状況 A: セッションの時間制限がある場合:
  1. G133:Providing a checkbox on the first page of a multipart form that allows users to ask for longer session time limit or no session time limit

  2. G198: Providing a way for the user to turn the time limit off

状況 B: 制限時間がページ上のスクリプトで制御されている場合:
  1. G198: Providing a way for the user to turn the time limit off

  2. G180: Providing the user with a means to set the time limit to 10 times the default time limit

  3. SCR16: Providing a script that warns the user a time limit is about to expire (Scripting)AND SCR1: Allowing the user to extend the default time limit (Scripting)

状況 C: コンテンツを読むのに制限時間がある場合:
  1. G4: Allowing the content to be paused and restarted from where it was paused

  2. G198: Providing a way for the user to turn the time limit off

  3. SCR33: Using script to scroll content, and providing a mechanism to pause it (Scripting)

  4. SCR36: Providing a mechanism to allow users to display moving, scrolling, or auto-updating text in a static window or area (Scripting)

達成基準 2.2.1 でさらに対応が望まれる実装方法(参考)

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

  • Using a script to poll the server and notify a user if a time limit is present (リンク追加予定) (Scripting)

重要な用語

必要不可欠

もし取り除いてしまうと、コンテンツの情報あるいは機能を根本的に変えてしまい、かつ、情報および機能が WCAG に適合する他の方法では提供することができない。


一時停止、停止、非表示:
達成基準 2.2.2 を理解する

2.2.2 一時停止、停止、非表示: 動きのある、点滅している、スクロールする、あるいは自動更新する情報に対しては、それぞれ次のすべてがあてはまる。 (レベル A):

  • 動き、点滅、スクロール: 動きのある、点滅している、あるいはスクロールしている情報が、(1) 自動的に開始し、(2) 5秒よりも長く継続し、そして (3) その他のコンテンツと並行して提示される場合、利用者がそれらを一時停止、停止、あるいは非表示にすることのできるメカニズムがある。ただし、その動き、点滅、またはスクロールが必要不可欠な動作の一部である場合は除く。

  • 自動更新: 自動更新する情報が、(1) 自動的に開始し、そして (2) その他のコンテンツと並行して提示される場合、利用者がそれを一時停止、停止、あるいは非表示にする、もしくはその更新頻度を調整することのできるメカニズムがある。ただし、その自動更新が必要不可欠な動作の一部である場合は除く。

注記 1: 明滅する、あるいは閃光を放つコンテンツに関する要件は、ガイドライン 2.3を参照のこと。

注記 2: この達成基準を満たさないコンテンツでは、利用者がそのページ全体を使用できない恐れがあるため、Webページ上のすべてのコンテンツは他の達成基準を満たすために用いられているか否かにかかわらず、この達成基準を満たさなければならない。適合要件 5: 非干渉を参照のこと。

注記 3: 周期的にソフトウェアによって自動的に更新されるコンテンツ、またはユーザエージェントにストリーム配信されるコンテンツは、コンテンツ再生の一時停止と再開の操作の間に生成あるいは受信される情報を保持したり、提示したりする必要はない。これは技術的に不可能であることが考えられ、多くの状況において利用者の混乱を招くことにつながる可能性があるためである。

注記 4: コンテンツの読み込み中やそれに類似した状況の一部として表示されるアニメーションについては、この段階ですべての利用者に対していかなる対話も発生する可能性がなく、かつコンテンツ読み込みの進行状況を表示しないことが利用者の混乱を招いたり、コンテンツが動作を停止した、あるいはコンテンツが破損しているという誤解を生じたりする可能性がある場合には、必要不可欠なものと考えることができる。

この達成基準の意図

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

"動き、点滅、スクロール" は、視覚的に認識できるコンテンツが何らかの動きをしているコンテンツのことを指している。よくある例としては、動画、同期したメディアのプレゼンテーション、アニメーション、リアルタイムのゲーム、スクロールする株価表示などが挙げられる。そして、"自動更新" は、あらかじめ設定された間隔で更新されたり消えたりするコンテンツのことを指している。時間の経過に伴って変化するコンテンツのよくある例としては、音声、自動的に更新される天気情報、ニュース、株価更新、及び自動進行するプレゼンテーションやメッセージなどがある。動き、点滅、スクロールと自動更新に対する要件は、次のものを除いて同じである:

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

  • 5秒間だけでその後は停止するというのは自動更新を無意味にするので、自動更新には5秒という例外はない。

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

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

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

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

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

  2. 情報の意味がリアルタイム又は "状態" にある場合には、一時停止した後にそれを再開した時点(一時停止を止めた時点)での表示へジャンプするほうがよい。例えば、気象レーダー、株価表示、交通情報カメラ、又はオークションのタイマーなどは、もし一時停止したことによって再開時に古い情報が表示されると、誤った情報を提供してしまうことになるだろう。

    注記: コンテンツを非表示にすることは、一時停止した後にそれを再開した時点(一時停止を止めた時点)での表示へジャンプするのと同じ効果が得られる。

注記: "点滅" と "閃光" は、同じコンテンツを指すことがありえる。

  • "点滅" は、利用者を注意散漫にさせる問題を引き起こすコンテンツを指している。点滅が停止する(又は停止させることが可能である)かぎり、短い間であれば許容することができる。

  • "閃光" は、(3秒よりも長く、大きさと明るさが十分な場合に)光過敏性発作を誘発する恐れのあるコンテンツを指している。これは、光過敏性発作を誘発する恐れがあるため、たとえ1秒間だけであったとしても許容されない。そして、閃光をオフにすることも選択肢にはならない。なぜなら、光過敏性発作は利用者がオフにする前に誘発される恐れがあるからである。

  • 通常、点滅は1秒間に3回以上の速度にはならないが、そうなる可能性もある。点滅が1秒間に3回以上の速度の場合には、それも閃光であるとみなされるであろう。

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

  • 5秒後に点滅を停止するコンテンツを提供すること、又は利用者が点滅するコンテンツを停止できるメカニズムを提供することで、特定の障害のある利用者がウェブページとやりとりできるようになる。

  • 点滅するコンテンツを使用する一つの方法は、そのコンテンツへ利用者の注意を引くことである。これは画面を見ている利用者すべてに対して効果的な方法ではあるが、点滅が持続するとある利用者に対しては問題を引き起こす恐れがある。読み書き能力の低い利用者、読字障害及び知的障害のある利用者、及び注意力欠如障害のある利用者などにとっては、点滅するコンテンツはウェブページの残りのコンテンツとのやりとりを困難にするか、又は不可能にさえしてしまうことがある。

達成基準 2.2.2 の事例

  • 利用者の行動に影響を与えずに一時停止できる不可欠なアニメーション

    あるウェブサイトは、プロセスを紹介するアニメーションによって、利用者が 'どのように機能するか' を理解するのを手助けしている。アニメーションには "一時停止" ボタンと "再開" ボタンがある。

  • 株価表示

    株価表示のティッカーには、 "一時停止" ボタンと "再開" ボタンがある。ティッカーを一時停止すると、現在表示している株価のところで一時停止する。再開すると、ティッカーは停止したところから再開するが、画面が遅れていることを示す注意書きが出る。株価表示のティッカーの意図は、通常リアルタイムの情報を提供することなので、ティッカーを最新の取引株価に進めるボタンもあるかもしれない。

  • 利用者がリアルタイムで完了するのではなく、交代するように設計されたゲーム

    1つのグループが、ゲームの競争的な形勢を無効にすることなく、ゲームを一時停止することができる。

  • ウェブ広告

    ある広告は、閲覧者の注意を引くために点滅するが、5秒後に停止する。

  • フォームのプロンプト

    フォームは、利用者がフォームへの記入を終えても送信ボタンを押下しないと、送信ボタンの近くにある矢印を点滅させる。その点滅は5秒後に停止する。

  • アニメーション

    アニメーションがページの上部で再生されるが、アニメーションの下部には "アニメーションを一時停止する" ボタンがある。

  • "読み込み中" のアニメーション

    再生を開始するまでに大きなファイルを一定のパーセンテージまでダウンロードする必要のあるページ上に、読み込み中であることを示すアニメーションが表示されている。ページ上のコンテンツはそのアニメーションだけで、映像を読み込んでいる間、利用者にしばらく待つ必要があることを知らせている。その動きのあるコンテンツは、他のコンテンツと並行して提示されているわけではないので、アニメーションを一時停止、停止、又は非表示にするメカニズムを提供する必要はない。接続回線の遅い利用者に対して、たとえそのアニメーションが5秒以上再生されていたとしてもである。

  • 全ページ広告

    あるサイトは、利用者が無償のコンテンツを利用する前に、すべての利用者が15秒の広告を閲覧することを要求している。その広告を閲覧することがすべての利用者に対する要件であり、他のコンテンツと並行して提示されていないので、広告を一時停止、停止、又は非表示にするメカニズムを提供する必要はない。

関連リソース

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

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

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

達成基準 2.2.2 でさらに対応が望まれる実装方法(参考)

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

  • Providing a mechanism to stop all content that blinks within a Web page (リンク追加予定)

  • Providing the user with a means to stop moving content even if it stops automatically within 5 seconds (リンク追加予定)

重要な用語

点滅

注意を引くように、2つの視覚的な状態を交互に切り替えること。

注記: 閃光も参照のこと。(ある頻度で、ある程度以上に大きく、明るく点滅することによって、閃光として分類されることもありうる。)

必要不可欠

もし取り除いてしまうと、コンテンツの情報あるいは機能を根本的に変えてしまい、かつ、情報および機能が WCAG に適合する他の方法では提供することができない。

一時停止

利用者の要求により停止し、利用者の要求があるまで再開しない。


制限時間なし:
達成基準 2.2.3 を理解する

2.2.3 制限時間なし: 制限時間が、コンテンツの提示するイベントあるいは動作の必要不可欠な部分ではない。ただし、インタラクティブではない同期したメディアおよびリアルタイムのイベントは除く。 (レベル AAA)

この達成基準の意図

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

注記: 例えば、手話のように、映像のみのコンテンツはガイドライン 1.1でカバーされている。

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

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

  • 手話通訳者が音声が聞こえない利用者に音声コンテンツを通訳しているような状況では、制限時間を調整できることも重要である。

達成基準 2.2.3 の事例

  • 試験を完了する時間が点数に影響しないように考案されている試験

    制限時間を用いてオンライン試験の結果を評価するのではなく、制限時間がないときの点数をもとに試験の結果を評価している。

  • 利用者がリアルタイムで完了するのではなく、交代するように設計されたゲーム

    1つのグループが、ゲームの競争的な形勢を無効にすることなく、ゲームを一時停止することができる。

関連リソース

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

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

達成基準 2.2.3 の実装方法及び不適合事例 - 時間制限なし

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  1. G5: Allowing users to complete an activity without any time limit

達成基準 2.2.3 でさらに対応が望まれる実装方法(参考)

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

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

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

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

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

重要な用語

必要不可欠

もし取り除いてしまうと、コンテンツの情報あるいは機能を根本的に変えてしまい、かつ、情報および機能が WCAG に適合する他の方法では提供することができない。

リアルタイムのイベント

a) 閲覧しているのと同時に発生するイベントで、b) コンテンツによって完全に生成されるものではないイベント。

事例 1: ライブパフォーマンスのウェブ放送(閲覧と同時に発生していて、収録済ではない)。

事例 2: 利用者が入札するオンラインのオークション(閲覧と同時に発生している)。

事例 3: アバターを用いたバーチャルな世界での互いのやりとり(コンテンツによって完全に生成されるものではなく、閲覧と同時に発生する)。

同期したメディア

情報や時間経過をベースにしたインタラクティブな構成要素を提示するために、他のフォーマットと同期した音声または映像。ただし、そのメディアがテキストの代替メディアではっきりとそのようにラベル付けされているものは除く。


中断:
達成基準 2.2.4 を理解する

2.2.4 中断: 利用者が中断を延期あるいは抑制することができる。ただし、緊急を要する中断は除く。 (レベル AAA)

この達成基準の意図

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

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

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

  • 注意力欠如障害のある利用者が、邪魔されずにコンテンツに集中できるようになる。

  • ロービジョンの利用者又はスクリーンリーダーを使用している利用者が、コンテンツを閲覧している間はコンテンツを更新されずにすむようになる(あるトピックを読み始めたのに、違うトピックで読み終えてしまった場合、話の内容が断絶してしまい、誤った理解をしてしまう恐れがある)。

達成基準 2.2.4 の事例

  • 事例 1. 利用者設定

    ウェブポータルの設定ページには、現在のセッションが終わるまで、緊急のアラートは除いて、すべての更新及びアラートを延期するオプションがある。

関連リソース

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

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

達成基準 2.2.4 の実装方法及び不適合事例 - 中断

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

達成基準 2.2.4 でさらに対応が望まれる実装方法(参考)

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

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

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

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

重要な用語

緊急

健康、安全や財産を守るために直ちに行動をとる必要のある、突然で予期されなかった状況あるいは出来事。


再認証:
達成基準 2.2.5 を理解する

2.2.5 再認証: 認証済のセッションが切れたときは、再認証後でもデータを失うことなく利用者が操作を継続できる。 (レベル AAA)

この達成基準の意図

この達成基準の意図は、非活動の制限時間がある又はトランザクションを完了させる途中で利用者をログアウトさせてしまうその他の状況がある、認証済のトランザクションを、すべての利用者が完了できるようにすることである。

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

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

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

  • この達成基準は、タスクを完了するのに時間の追加を必要とする利用者の役に立つ。認知限界のある利用者は、ゆっくり読むので、質問を読んで回答するのに追加の時間を必要とすることがある。スクリーンリーダーを使用している利用者は、複雑なフォームをナビゲートして完了させるのに追加の時間を必要とするかもしれない。運動障害のある利用者又は代替入力デバイスでナビゲートする利用者は、フォーム内をナビゲートして入力を完了させるのに、やはり追加の時間を必要とすることがある。

  • 手話通訳者が音声が聞こえない利用者に音声コンテンツを通訳しているような状況では、制限時間を調整できることも重要である。

達成基準 2.2.5 の事例

  • ショッピングサイトの支払手続

    手をほとんど使うことのできない利用者が、ショッピングサイトにログインしている。アプリケーションでクレジットカード情報を入力するのに時間がとてもかかり、利用者が支払手続をしている間に制限時間が切れてしまう。利用者がその支払手続に戻ってきてフォームを送信しようとすると、そのサイトは再認証するためのログイン画面を表示する。利用者がログインした後、支払手続のプロセスは同じ段階で同じ情報の状態に戻してくれる。セッションはタイムアウトになったものの、サーバが一時的に送信を受け付けて保存していて、再認証が完了した後に利用者を同じ状態に戻したため、利用者はデータを失わずに済んだのである。

  • 電子メールプログラムでの認証

    ある電子メールプログラムは、30分後に認証がタイムアウトする。そのプログラムは、タイムアウトの数分前に利用者にプロンプトを出し、再認証するために新しいウィンドウを開くリンクを提供している。作成中のメールがあった元のウィンドウはそのままで、再認証後に、利用者はそのデータを送信することができる。

  • 制限時間のあるアンケート

    単一のウェブペーイで提供されている長いアンケートの最初に、セッションが15分経過後にタイムアウトすることを知らせる情報がある。また、アンケートはどの時点でも保存することが可能で、後から完了させることも可能であることが、利用者には知らされている。そのウェブページには、部分的に完了したフォームを保存するためのボタンが幾つかある。さらに、依存しているアクセシビリティ・サポーテッドなウェブコンテンツ技術の一覧にあるJavaScriptによって、セッションがタイムアウトに近づいたらポップアップで知らせてもらうことを利用者が選択できるようになっている。

関連リソース

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

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

達成基準 2.2.5 の実装方法及び不適合事例 - 再認証

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  1. Providing options to continue without loss of data using one of the following techniques:

注記:Refer to Techniques for Addressing Success Criterion 2.2.1 for techniques related to providing notifications about time limits.

達成基準 2.2.5 でさらに対応が望まれる実装方法(参考)

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

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

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

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


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

ガイドライン 2.3: 光過敏性発作を引き起こす恐れのないようにコンテンツを設計する。

ガイドライン 2.3 の意図

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

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

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

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

  • Ensuring that content does not violate spatial pattern thresholds (リンク追加予定)

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

2.3.1 3回の閃光又は閾値以下: ウェブページには、どの1秒間においても3回を超える閃光を放つものがない。あるいは、閃光一般閃光閾値および赤色閃光閾値を下回っている。 (レベル A)

注記: この達成基準を満たさないコンテンツでは、利用者がそのページ全体を使用できない恐れがあるため、Webページ上のすべてのコンテンツは他の達成基準を満たすために用いられているか否かにかかわらず、この達成基準を満たさなければならない。適合要件 5: 非干渉を参照のこと。.

この達成基準の意図

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

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

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

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

同時に放たれていて、かつ隣接している閃光を組み合わせた領域は、実際に同時に閃光を放っている領域全体を意味する。その領域は、あらゆる視野角10度以内で同時に閃光を放っている隣接した領域を合計していくことによって算出される。

注記: "点滅" と "閃光" は、同じコンテンツを指すことがありえる。

  • "点滅" は、利用者を注意散漫にさせる問題を引き起こすコンテンツを指している。点滅が停止する(又は停止させることが可能である)かぎり、短い間であれば許容することができる。

  • "閃光" は、(3秒よりも長く、大きさと明るさが十分な場合に)光過敏性発作を誘発する恐れのあるコンテンツを指している。これは、光過敏性発作を誘発する恐れがあるため、たとえ1秒間だけであったとしても許容されない。そして、閃光をオフにすることも選択肢にはならない。なぜなら、光過敏性発作は利用者がオフにする前に誘発される恐れがあるからである。

  • 通常、点滅は1秒間に3回以上の速度にはならないが、そうなる可能性もある。点滅が1秒間に3回以上の速度の場合には、それも閃光であるとみなされるであろう。

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

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

達成基準 2.3.1 の事例

  • あるウェブサイトに、閃光を放つマシンガンの銃口の映像があるが、閃光を放つ画像のサイズを画面の閃光閾値を下回る小さい部分に限定している。

  • とても明るい稲妻の閃光のシーンがある映画が、稲妻があらゆる1秒間に3回だけ閃光を放つように編集されている。

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

達成基準 2.3.1 でさらに対応が望まれる実装方法(参考)

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

  • Reducing contrast for any flashing content (リンク追加予定)

  • Avoiding fully saturated reds for any flashing content (リンク追加予定)

  • Reducing the number of flashes even if they do not violate thresholds (リンク追加予定)

  • Providing a mechanism to suppress any flashing content before it begins (リンク追加予定)

  • Slowing down live material to avoid rapid flashes (as in flashbulbs) (リンク追加予定)

  • Freezing the image momentarily if 3 flashes within one second are detected (リンク追加予定)

  • Dropping the contrast ratio if 3 flashes within one second are detected (リンク追加予定)

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

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

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

重要な用語

閃光

十分な大きさがあり、ある周波数において発作を誘発する恐れのある、相対輝度の相反する変化の組合せ。

注記 1: 許容されない閃光のタイプに関する情報は、一般閃光閾値および赤色閃光閾値を参照のこと。

注記 2: 点滅も参照のこと。

一般閃光閾値および赤色閃光閾値

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

  1. あらゆる1秒間の間隔において、3つより多くの一般閃光がある。および/または、3つより多くの赤色閃光がある。もしくは、

  2. 一般的な画面との距離で、閃光のある領域が、画面上の視野角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. を参照のこと)。

ウェブページ

HTTP によって単一の URI から得られる埋め込みではないリソースと、レンダリングに用いられたり、ユーザエージェントで一緒にレンダリングされる目的で用いられたりしているその他のリソース。

注記 1: どのような "その他のリソース" も第一のリソースと一緒にレンダリングされるであろうが、必ずしもお互いが同時にレンダリングされる必要があるわけではない。

注記 2: このガイドラインに適合する目的において、ウェブページと見なされる適合範囲内ではリソースは『埋め込みではない』ものでなければならない。

事例 1: すべての埋め込まれた画像とメディアを含んだウェブリソース。

事例 2: Ajaxを用いたウェブメールのプログラム。そのプログラムは http://example.com/mail に存在しているが、受信箱、アドレス帳、そしてカレンダーがある。受信箱、アドレス帳やカレンダーを起動するリンクあるいはボタンがあるが、ページ全体の URI は変わらない。

事例 3: カスタマイズ可能なポータルサイトで、利用者がさまざまなコンテンツのモジュール一式の中から表示させるコンテンツを選択できる。

事例 4: ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、ウェブサイトの中のほんの1ページなのかもしれない。


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

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

この達成基準の意図

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

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

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

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

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

達成基準 2.3.2 の事例

  • とても明るい稲妻の閃光のシーンがある映画が、稲妻があらゆる1秒間に3回だけ閃光を放つように編集されている。

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

達成基準 2.3.2 でさらに対応が望まれる実装方法(参考)

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

  • Reducing contrast for any flashing content (リンク追加予定)

  • Avoiding fully saturated reds for any flashing content (リンク追加予定)

  • Reducing the number of flashes even if they don't violate thresholds (リンク追加予定)

  • Slowing down live material to avoid rapid flashes (as in flashbulbs) (リンク追加予定)

  • Freezing the image momentarily if 3 flashes within one second are detected (リンク追加予定)

  • Dropping the contrast ratio if 3 flashes within one second are detected (リンク追加予定)

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

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

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

重要な用語

閃光

十分な大きさがあり、ある周波数において発作を誘発する恐れのある、相対輝度の相反する変化の組合せ。

注記 1: 許容されない閃光のタイプに関する情報は、一般閃光閾値および赤色閃光閾値を参照のこと。

注記 2: 点滅も参照のこと。

ウェブページ

HTTP によって単一の URI から得られる埋め込みではないリソースと、レンダリングに用いられたり、ユーザエージェントで一緒にレンダリングされる目的で用いられたりしているその他のリソース。

注記 1: どのような "その他のリソース" も第一のリソースと一緒にレンダリングされるであろうが、必ずしもお互いが同時にレンダリングされる必要があるわけではない。

注記 2: このガイドラインに適合する目的において、ウェブページと見なされる適合範囲内ではリソースは『埋め込みではない』ものでなければならない。

事例 1: すべての埋め込まれた画像とメディアを含んだウェブリソース。

事例 2: Ajaxを用いたウェブメールのプログラム。そのプログラムは http://example.com/mail に存在しているが、受信箱、アドレス帳、そしてカレンダーがある。受信箱、アドレス帳やカレンダーを起動するリンクあるいはボタンがあるが、ページ全体の URI は変わらない。

事例 3: カスタマイズ可能なポータルサイトで、利用者がさまざまなコンテンツのモジュール一式の中から表示させるコンテンツを選択できる。

事例 4: ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、ウェブサイトの中のほんの1ページなのかもしれない。


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

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

ガイドライン 2.4 の意図

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

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

  • 利用者に自分がどこにいるのかを知らせる

  • 利用者が他のどこかへ行けるようにする

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

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

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

  • Limiting the number of links per page (リンク追加予定)

  • Providing mechanisms to navigate to different sections of the content of a Web page (リンク追加予定)

  • Making links visually distinct (リンク追加予定)

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

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

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

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

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

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

  • この達成基準に適合していないと、障害のある利用者がウェブページのメインコンテンツへ素早くかつ容易に到達するのが困難になることがある。

  • 同じサイト上で幾つかのページを訪れるスクリーンリーダーの利用者が、メインコンテンツが読み上げられるまでに、どのページにもあるすべての見出しのグラフィック及びたくさんのナビゲーション・リンクを聞かなくてすむようになる。

  • キーボード又はキーボード・インタフェースだけを使用している利用者が、少ないキーストロークだけでコンテンツに到達できるようになる。そうでなければ、メインコンテンツ部分にあるリンクに到達するまでにたくさんのキーストロークが必要になってしまうかもしれない。これには長い時間がかかってしまう恐れがあり、利用者によっては深刻な肉体的苦痛を伴うことがある。

  • 画面拡大ソフトを使用している利用者が、新しいページへ来るたびに、どこからメインコンテンツが始まるのかを見つけるために、同じ見出し又はその他の情報のブロックの中を探し回らなくてすむようになる。

  • リンクがリストにまとめられていると、認知限界のある利用者及びスクリーンリーダーを使用している利用者のためになることがある。

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

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  • Providing keyboard access to important links and form controls (リンク追加予定)

  • Providing skip links to enhance page navigation (リンク追加予定)

  • Providing access keys (リンク追加予定)

  • Using accessibility supported technologies which allow structured navigation by user agents and assistive technologies (リンク追加予定)

  • C6: コンテンツを構造のマークアップに基づいて配置する (CSS)

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

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

メカニズム

結果を得るためのプロセスあるいはテクニック。

注記 1:メカニズムは、コンテンツ内で明白に提供されることもあれば、あるいは、プラットフォームまたは支援技術を含むユーザエージェントのどちらかで提供されるものに依存することもある。

注記 2: メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。

ウェブページ

HTTP によって単一の URI から得られる埋め込みではないリソースと、レンダリングに用いられたり、ユーザエージェントで一緒にレンダリングされる目的で用いられたりしているその他のリソース。

注記 1: どのような "その他のリソース" も第一のリソースと一緒にレンダリングされるであろうが、必ずしもお互いが同時にレンダリングされる必要があるわけではない。

注記 2: このガイドラインに適合する目的において、ウェブページと見なされる適合範囲内ではリソースは『埋め込みではない』ものでなければならない。

事例 1: すべての埋め込まれた画像とメディアを含んだウェブリソース。

事例 2: Ajaxを用いたウェブメールのプログラム。そのプログラムは http://example.com/mail に存在しているが、受信箱、アドレス帳、そしてカレンダーがある。受信箱、アドレス帳やカレンダーを起動するリンクあるいはボタンがあるが、ページ全体の URI は変わらない。

事例 3: カスタマイズ可能なポータルサイトで、利用者がさまざまなコンテンツのモジュール一式の中から表示させるコンテンツを選択できる。

事例 4: ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、ウェブサイトの中のほんの1ページなのかもしれない。


ページタイトル:
達成基準 2.4.2 を理解する

2.4.2 ページタイトル: ウェブページには、主題または目的を説明したタイトルがある。 (レベル A)

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

  • この達成基準により、そのウェブページにある情報が自分のニーズに関係があるかどうかを、すべての利用者が素早くかつ容易に確認できるようになる。

  • 視覚障害のある利用者が、複数のページが開いている際に、コンテンツを区別できるようになる。

  • 認知障害、短期記憶限界、及び読字障害のある利用者も、そのタイトルでコンテンツを確認できるようになる。

  • この達成基準により、重度の運動障害があり、操作モードが音声に依存している利用者が、ウェブページ間を行き来しているときにも役に立つ。

  • HTML のウェブページ

    HTML で制作したウェブページの内容を示したタイトルが、ユーザエージェントのタイトルバーに表示されるように、<title> でマークアップされている。

  • 文書

    ウェブコンテンツ・アクセシビリティ・ガイドライン 2.0 のページタイトルが、"ウェブコンテンツ・アクセシビリティ・ガイドライン 2.0" となっている。

  • ウェブ・アプリケーション

    あるインターネット銀行のアプリケーションでは、利用者が自分の銀行口座をチェックしたり、過去の明細を確認したり、振込をしたりすることができる。そのウェブアプリケーションは、ウェブページごとにタイトルを動的に生成している。例えば、"ジョン・スミスさんの講座: XYZ 銀行"、"口座番号 1234-5678 の取引明細 - 2005年12月: XYZ 銀行" など。

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

  1. G88: Providing descriptive titles for Web pages AND associating a title with a Web page using one of the following techniques:

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

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

ウェブページ

HTTP によって単一の URI から得られる埋め込みではないリソースと、レンダリングに用いられたり、ユーザエージェントで一緒にレンダリングされる目的で用いられたりしているその他のリソース。

注記 1: どのような "その他のリソース" も第一のリソースと一緒にレンダリングされるであろうが、必ずしもお互いが同時にレンダリングされる必要があるわけではない。

注記 2: このガイドラインに適合する目的において、ウェブページと見なされる適合範囲内ではリソースは『埋め込みではない』ものでなければならない。

事例 1: すべての埋め込まれた画像とメディアを含んだウェブリソース。

事例 2: Ajaxを用いたウェブメールのプログラム。そのプログラムは http://example.com/mail に存在しているが、受信箱、アドレス帳、そしてカレンダーがある。受信箱、アドレス帳やカレンダーを起動するリンクあるいはボタンがあるが、ページ全体の URI は変わらない。

事例 3: カスタマイズ可能なポータルサイトで、利用者がさまざまなコンテンツのモジュール一式の中から表示させるコンテンツを選択できる。

事例 4: ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、ウェブサイトの中のほんの1ページなのかもしれない。


フォーカス順序:
達成基準 2.4.3 を理解する

2.4.3 フォーカス順序: ウェブページ順番にナビゲートできて、そのナビゲーション順序が意味あるいは操作に影響を及ぼす場合、フォーカス可能な構成要素は意味および操作性を保持した順序でフォーカスを受け取る。 (レベル A)

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

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

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

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

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

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

  • 論理的で、使いやすいフォーカス順序は、ページの操作をキーボード使用に依存している運動障害のある利用者の役に立つ。

  • 字を読むのが困難な障害のある利用者は、Tab キーを押下してフォーカスが予期しないどこかへ移動してしまうと、迷子のようになってしまう恐れがある。

  • 視覚障害のある利用者は、Tab キーを押下してフォーカスが予期しないどこかへ移動してしまったり、インタラクティブな要素に囲まれているコンテンツを容易に見つけることができなかったりすると、迷子のようになってしまう恐れがある。

  • 画面拡大ソフトを使用していて、拡大率を高くしている利用者には、ページのごく小さい一部分だけしか見えないことがある。そのような利用者は、フォーカス順序が論理的でないと、誤った文脈でコンテンツのある一部分を解釈してしまう恐れがある。

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

  2. ツリー・コンポーネントを行き来するための矢印キーを用いたナビゲーション。利用者は、上下の矢印キーを使って、ツリーのノードからノードへと移動することができる。左向き矢印キーを押下するとノードを展開して、それから下矢印キーを押下すると新しく展開されたノードへと移動していく。このナビゲーション順序は、ツリー・コントロールで予期される順序に従っている。そして、アイテムが展開されたり閉じられたりするたびに、ナビゲーション順序に追加されたり削除されたりする。

  3. あるウェブページは、スクリプトでモードレス・ダイアログ(ダイアログボックスを閉じなくても作業が続行できるタイプのダイアログボックス)を実装している。起動ボタンを押下すると、ダイアログが開く。ダイアログ内にあるインタラクティブな要素が、フォーカス順序のボタンのすぐ後に挿入される。ダイアログが開いているときには、フォーカス順序は、そのボタンからダイアログ内の要素へ移動し、それからボタンの後にあるインタラクティブな要素へと移動する。ダイアログが閉じているときは、フォーカス順序はボタンからその次に続いている要素へ移動する。

  4. あるウェブページは、スクリプトでモーダル・ダイアログ(ダイアログボックスの中だけで強制的に作業をさせるダイアログボックスで、それが閉じられない限り作業の続行ができない)を実装している。起動ボタンを押下すると、ダイアログが開き、そのダイアログにある最初のインタラクティブな要素にフォーカスがあたる。ダイアログが開いているかぎり、フォーカスはダイアログ内の要素だけに限定される。ダイアログが閉じられると、フォーカスはボタン又はボタンの次にある要素へ戻る。

  5. HTML で制作されたウェブページには、左側にナビゲーションがある。そのナビゲーションは、HTML ではメインコンテンツの後にあり、CSS を用いてページの左側に表示されるように指定されている。tabindex 属性又はJavaScriptを用いずに、フォーカスがメインコンテンツへ移動できるようにするためである。

    注記: この事例は達成基準を満たしているが、必ずしもすべての CSS による配置が当てはまるとはかぎらない。配置が複雑になると、意味及び操作性を保持できることもあれば、できなくなることもある。

  6. 次の例は、この達成基準に適合できない

    ある企業のウェブサイトに、マーケティングデータを収集するフォームがあり、利用者がその企業の発行する幾つかのニュースレターに登録できるようになっている。マーケティングデータを収集するためのフォームのセクションには、氏名、郵便番号、県、市町村、番地などのテキストフィールドがある。フォームのその他のセクションには、利用者が配信してほしいニュースレターを指定することができるように幾つかのチェックボックスがある。しかし、そのフォームのタブ移動順序は、フォームの異なるセクション間を行ったり来たりする。そのため、フォーカスは、氏名のテキストフィールドからあるチェックボックスへ、次に番地のテキストフィールドへ、そしてまた別のチェックボックスへというふうに移動してしまう。

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

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

  1. G59: Placing the interactive elements in an order that follows sequences and relationships within the content

  2. 次の実装方法の一つを用いて、コンテンツ内の順序及び関係性に従った順序でフォーカスを要素に与える:

  3. 次の実装方法の一つを用いて、ウェブページを動的に変化させる:

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

  • Providing a highly visible highlighting mechanism for links or controls when they receive keyboard focus (リンク追加予定)

  • Creating alternative presentation orders (リンク追加予定)

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

順番にナビゲート

キーボードインターフェースを用いてフォーカスを前進させるために指定された順序でナビゲート。

ウェブページ

HTTP によって単一の URI から得られる埋め込みではないリソースと、レンダリングに用いられたり、ユーザエージェントで一緒にレンダリングされる目的で用いられたりしているその他のリソース。

注記 1: どのような "その他のリソース" も第一のリソースと一緒にレンダリングされるであろうが、必ずしもお互いが同時にレンダリングされる必要があるわけではない。

注記 2: このガイドラインに適合する目的において、ウェブページと見なされる適合範囲内ではリソースは『埋め込みではない』ものでなければならない。

事例 1: すべての埋め込まれた画像とメディアを含んだウェブリソース。

事例 2: Ajaxを用いたウェブメールのプログラム。そのプログラムは http://example.com/mail に存在しているが、受信箱、アドレス帳、そしてカレンダーがある。受信箱、アドレス帳やカレンダーを起動するリンクあるいはボタンがあるが、ページ全体の URI は変わらない。

事例 3: カスタマイズ可能なポータルサイトで、利用者がさまざまなコンテンツのモジュール一式の中から表示させるコンテンツを選択できる。

事例 4: ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、ウェブサイトの中のほんの1ページなのかもしれない。


文脈におけるリンクの目的:
達成基準 2.4.4 を理解する

2.4.4 文脈におけるリンクの目的: それぞれのリンクの目的が、リンクのテキストのみから解釈できる、あるいはリンクのテキストとプログラムで解釈可能なリンクの文脈とをあわせて解釈できる。ただし、リンクの目的が一般的にみて利用者にとって曖昧な場合は除く。 (レベル A)

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

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

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

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

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

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

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

  • この達成基準により、運動障害のある利用者が、リンク先のコンテンツへ行って、また元へ戻ってくるという無駄なキーストロークなしに、必要のないリンクをスキップすることができるようになる。

  • 認知限界のある利用者が、必要のないコンテンツへ行ったり来たりしているうちに居場所を見失わなくてすむようになる。

  • 視覚障害のある利用者が、リンクの文脈を探ることによって、リンクの目的を判断できるようになる。

  • リンクがリンク先の URI にある情報を説明するテキストを含んでいる

    あるページに、"中世の歴史には大量の虐殺があった" という文がある。そして、"中世の歴史" がリンクである。

  • リンクの前にリンク先の URI にある情報を説明するテキストがある

    あるページに、"アイルランド政府の電子選挙委員会に関する詳細を Go Vote! で見る" という文がある。そして、"Go Vote!" がリンクである。

  • アイコンとテキストの両方が同じリンク内にある

    自動投票機のアイコンと "アイルランド政府の電子選挙委員会" というテキストが、一つのリンクになっている。リンクの目的がアイコンの隣にあるリンクのテキストで説明されているので、そのアイコンの代替テキストは空である。

  • 書籍名のリスト

    リストにある書籍が、HTML、PDF、そして mp3(人が本を読み上げているのを録音したもの)の3つのフォーマットで利用可能である。各書籍のタイトルを3回(フォーマットごとに1回)聞かないですむように、各書籍の最初のリンクが書籍のタイトルで、2つめのリンクは "PDF"、3つめのリンクは "mp3" となっている。

  • ニュース記事の要約

    あるウェブページに、ニュース記事が集められている。メインページでは、各記事の最初の部分が少しだけあって、その後に "続きを読む" というリンクがある。スクリーンリーダーでは、現在の段落を読むためのコマンドによって、リンクの目的を解釈するための文脈が得られる。

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

  1. G91: Providing link text that describes the purpose of a link

  2. 次に挙げるウェブコンテンツ技術特有の実装方法の一つを用いて、利用者が簡潔なリンクテキスト又は長いリンクテキストを選べるようにする:

  3. G53: Identifying the purpose of a link using link text combined with the text of the enclosing sentence

  4. 次に挙げる実装方法の一つを用いて、リンクの目的の説明を補足する:

  5. 次に挙げる実装方法の一つを用いて、プログラムで判断されるリンクの文脈と一緒にリンクの目的を特定する:

注記:Because of the extensive user agent limitations in supporting access to the title attribute, authors should use caution in applying this technique. For this reason, it is preferred that the author use technique C7: Using CSS to hide a portion of the link text (CSS) or H30: a 要素のリンクの目的を説明するテキストリンクを提供する (HTML).

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

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

一般的にみて利用者にとって曖昧

リンクおよびリンクと同時に利用者に提供されているウェブページのすべての情報からその目的が断定できない(すなわち、障害のない利用者でも、そのリンクがどうなるかがはそれを選択するまでは分からない)。

事例: 「注目すべき輸出品はグァバです。」という文中にある "グァバ" という単語がリンクだとする。そのリンクは、グァバの定義、輸出されているグァバの量を挙げる図表、あるいはグァバを収穫している人々の写真へリンクされているかもしれない。そのリンクを選択するまでは、すべての利用者が分からず、障害のある利用者だけが不利な立場になるわけではない。

リンクの目的

ハイパーリンクを起動することで得られる結果の本質。

プログラムで解釈可能なリンクの文脈

リンクとの関係性からプログラムで解釈したり、リンクテキストと併用したり、異なるモダリティで利用者に提示したりすることが可能な補足情報。

事例: HTMLでは、英語でリンクからプログラムで解釈可能な情報には、そのリンクと同じ段落、リスト、あるいはテーブルのセルにあるテキスト、あるいはリンクのあるテーブルのセルと関連付けられたテーブルの見出しセルにあるテキストなどがある。

注記: スクリーンリーダーは句読点を解釈するので、フォーカスが文中のリンクにあるときには、その文から文脈を提供することも可能である。


複数のページ探索手段:
達成基準 2.4.5 を理解する

2.4.5 複数のページ探索手段: ウェブページ一式の中からあるウェブページを見つけることのできる手段が1つよりも多くある。ただし、ウェブページがプロセスの結果あるいはプロセスの中の1つのステップである場合は除く。 (レベル AA)

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

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

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

  • 認知限界のある利用者は、階層構造を用いたナビゲーション・スキームは分かりづらいことがあるため、検索機能を使うほうがより容易なことがある。

  • 検索メカニズム

    大手の食品加工企業のサイトには、その製品を用いたレシピがある。そのサイトは、特定の食材を使ったレシピを検索できる検索メカニズムを提供している。あらに、食品のいろいろなカテゴリを挙げたリストボックスも提供している。利用者は検索のキーワードに "スープ" と入力して、又はリストボックスから "スープ" を選択して、その企業のスープ製品から作るレシピの一覧があるページへ行くことができる。

  • ウェブページ間のリンク

    あるヘアサロンが、サービスを宣伝するためにウェブサイトを制作した。そのサイトは5ページしかない。各ページには、ウェブページ間を順に前後へ移動できるリンクがある。さらに、各ウェブページには、その他のウェブページへ移動するリンクの一覧がある。

  • コンテンツがプロセス又はタスクの結果である場合 - 送金確認

    あるオンライン銀行サイトでは、ウェブを通じて口座間の送金ができる。口座の名義人が送金を完了する以外には、送金確認ページを見つける方法はない。

  • コンテンツがプロセス又はタスクの結果である場合 - 検索エンジンの検索結果

    ある検索エンジンが、利用者の入力に応じた検索結果を提供している。その検索プロセスを行う以外に、その検索結果ページを見つける方法はない。

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

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

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

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

プロセス

ある目的を達するために必須の各アクションから成る利用者のアクションの連続。

事例 1: ショッピングサイト上の一連のウェブページで目的を果たすためには、利用者が選択肢となりうる製品、価格および内容を閲覧し、製品を選択して、注文を送信し、配送先情報および支払情報を提供する必要がある。

事例 2: アカウント登録ページでは、登録フォームにアクセスする前にチューリングテスト(訳注:CAPTCHAなど)を完了させる必要がある。

ウェブページ一式

共通の目的を共有し、同じコンテンツ制作者、グループ、あるいは組織により制作されたウェブページの集合。

注記: 異なる言語のバージョンは、違うウェブページ一式と見なされるであろう。

ウェブページ

HTTP によって単一の URI から得られる埋め込みではないリソースと、レンダリングに用いられたり、ユーザエージェントで一緒にレンダリングされる目的で用いられたりしているその他のリソース。

注記 1: どのような "その他のリソース" も第一のリソースと一緒にレンダリングされるであろうが、必ずしもお互いが同時にレンダリングされる必要があるわけではない。

注記 2: このガイドラインに適合する目的において、ウェブページと見なされる適合範囲内ではリソースは『埋め込みではない』ものでなければならない。

事例 1: すべての埋め込まれた画像とメディアを含んだウェブリソース。

事例 2: Ajaxを用いたウェブメールのプログラム。そのプログラムは http://example.com/mail に存在しているが、受信箱、アドレス帳、そしてカレンダーがある。受信箱、アドレス帳やカレンダーを起動するリンクあるいはボタンがあるが、ページ全体の URI は変わらない。

事例 3: カスタマイズ可能なポータルサイトで、利用者がさまざまなコンテンツのモジュール一式の中から表示させるコンテンツを選択できる。

事例 4: ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、ウェブサイトの中のほんの1ページなのかもしれない。


見出し及びラベル:
達成基準 2.4.6 を理解する

2.4.6 見出し及びラベル: 見出しおよびラベルは、主題または目的を説明している。 (レベル AA)

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

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

  • 分かりやすい見出しは、読む速度が遅くなる障害のある利用者及び短期記憶に限界のある利用者に特に役立つ。そのような利用者にとっては、それぞれのセクションの内容を予測できるようにセクションの見出しが記述されていると役立つ。

  • 求めているコンテンツへたどりつくまでに必要なキーストローク数を減少することが、手を使いづらい利用者又は手を使うことに苦痛を伴う利用者に役立つ。

  • この達成基準は、例えば目次のように、前後に関係なく、ラベル及び見出しだけを読み上げたとき、又はページ内の見出しから見出しへ移動したときに、ラベル及び見出しが分かりやすいようにすると、スクリーンリーダーを使用している利用者に役立つ。

    また、この達成基準は、一度にほんの少しの単語しか見ることのできない、ロービジョンの利用者にも役立つ。

  • 事例 1:ニュースサイト

    ニュースサイトのホームに、その時間帯のトップニュースの見出しが並んでいる。それぞれの見出しの下には、記事の冒頭の35ワードと、記事の全文へのリンクがある。そして、見出しはどれも、記事の主題を明快に伝えている。

  • 事例 2:上手な文章の書き方ガイド

    文章の書き方に関するガイドに、次のセクション見出しがある。上手な文章の書き方、無駄な語句を取り除く、不要な語句を見つけ出す、など。これらのセクション見出しは明快かつ簡潔で、情報の構造が見出しの構造にも反映されている。

  • 事例 3: さまざまな記事で一貫した見出し

    ウェブサイトには、ある学会の論文が掲載されている。その学会への投稿する論文は、次のような構成とすることが必須となっている: 要約、イントロダクション、(その論文に固有なその他のセクション)、結論、筆者略歴、用語集、そして参考文献。そうして、論文の独自性とセクション見出しの一貫性とのバランスをうまくとりながら、各ウェブページのタイトルはそのページにある論文をはっきりと特定している。

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

  1. G130: Providing descriptive headings

  2. G131: Providing descriptive labels

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

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

  • Using unique section headings in a Web Page (リンク追加予定)

  • Starting section headings with unique information (リンク追加予定)

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

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

ラベル

ウェブコンテンツにある構成要素を識別するために、利用者に提示されているテキスト、あるいは代替テキストのある構成要素。

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

注記 2: ラベルという用語は、HTML における label 要素だけに限定されない。


視覚的に認識可能なフォーカス:
達成基準 2.4.7 を理解する

2.4.7 視覚的に認識可能なフォーカス: キーボード操作が可能なユーザインタフェースは、キーボード・フォーカスの表示が視覚的に認識できる操作モードがある。 (レベル AA)

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

  • キーボードだけでそのページを操作している利用者が、キーボードで操作しているコンポーネントを視覚的に常時確認できるようになる。

  • 注意力欠如、短期記憶限界、又は遂行機能における限界のある利用者が、フォーカスがどこにあるのかを見つけることができるようになる。

  • テキストフィールドがフォーカスを受け取ると、縦の棒がテキストフィールド内に表示されて、利用者がテキストを挿入できることを示す。もしくは、すべてのテキストがハイライト表示され、利用者がそのテキストを上書きできることを示す。

  • ユーザインタフェースのコントロールがフォーカスを受け取ると、その周りに視覚的に認識できる枠線が表示される。

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  • Highlighting a link or control when the mouse hovers over it (リンク追加予定)

  • Providing a highly visible highlighting mechanism for links or controls when they receive keyboard focus (リンク追加予定)

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


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

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

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

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

  • 利用者がサイト内での自分の現在位置を確認しやすくするリンク

    ある大学の教育学部に研究会がある。研究会のウェブサイトのホームには、学部のウェブサイトのホーム及び大学のウェブサイトのホームへのリンクがある。

  • パンくずリスト

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

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  • Providing a link to the home page or main page (リンク追加予定)

  • Providing an easy-to-read version of information about the organization of a set of Web pages (リンク追加予定)

  • Providing a sign language version of information about the organization of a set of Web pages(リンク追加予定)

  • Providing an easy-to-read summary at the beginning of each section of content (リンク追加予定)

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

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

ウェブページ一式

共通の目的を共有し、同じコンテンツ制作者、グループ、あるいは組織により制作されたウェブページの集合。

注記: 異なる言語のバージョンは、違うウェブページ一式と見なされるであろう。


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

2.4.9 リンクの目的: それぞれのリンクの目的がリンクのテキストだけから特定できるメカニズムが利用可能である。ただし、リンクの目的が一般的にみて利用者にとって曖昧な場合は除く。 (レベル AAA)

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

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

"メカニズム" という用語を用いているのは、コンテンツ制作者がすべてのリンクを前後の文脈に関係なく完全に理解できるようにするか、あるいはそのようにする方法を提供できるようにするためである。リンクすべてをリンクテキストだけでも曖昧ではないようにすることで、ページによっては、分かりやすくなる利用者もいれば、分かりづらくなってしまう利用者もいる。

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

  • 運動障害のある利用者が、関心のないウェブページをスキップできるようになり、関係のないページへ行ってからまた元のページの戻ってくるような無駄なキーストロークを避けることができるようになる。

  • 認知限界のある利用者が、関係のないコンテンツへ行ったり来たりして迷子にならずにすむようになる。

  • 視覚障害のある利用者が、元のページに戻ってきて自分のいる場所が分からなくなるようなことがなくなる。そして、リンク先が説明されているので、情報を探す上で、スクリーンリーダーのリンク一覧がより有益になる。

  • アイコンとテキストの両方が同じリンク内にある

    自動投票機のアイコンと "アイルランド政府の電子選挙委員会" というテキストが、一つのリンクになっている。

  • 書籍名のリスト

    リストにある書籍が、HTML、PDF、そして mp3(人が本を読み上げているのを録音したもの)の3つのフォーマットで利用可能である。書籍のタイトルの後に、さまざまなフォーマットへのリンクがある。例えば、レンダリングされるリンクテキストにはフォーマット名しかないが、それぞれのリンクに関連付けられているテキストには、例えば "ガリバー旅行記 MP3版" というように、書籍のタイトルとフォーマットの両方がある。

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

  1. G91: Providing link text that describes the purpose of a link using one of the following techniques:

  2. 次の技術特有の実装方法の一つを用いて、利用者が短めのリンクテキスト又は長めのリンクテキストを選べるようにする:

  3. 次の実装方法の一つを用いて、リンクの目的を補足説明する:

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

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

一般的にみて利用者にとって曖昧

リンクおよびリンクと同時に利用者に提供されているウェブページのすべての情報からその目的が断定できない(すなわち、障害のない利用者でも、そのリンクがどうなるかがはそれを選択するまでは分からない)。

事例: 「注目すべき輸出品はグァバです。」という文中にある "グァバ" という単語がリンクだとする。そのリンクは、グァバの定義、輸出されているグァバの量を挙げる図表、あるいはグァバを収穫している人々の写真へリンクされているかもしれない。そのリンクを選択するまでは、すべての利用者が分からず、障害のある利用者だけが不利な立場になるわけではない。

メカニズム

結果を得るためのプロセスあるいはテクニック。

注記 1:メカニズムは、コンテンツ内で明白に提供されることもあれば、あるいは、プラットフォームまたは支援技術を含むユーザエージェントのどちらかで提供されるものに依存することもある。

注記 2: メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。


セクション見出し:
達成基準 2.4.10 を理解する

2.4.10 セクション見出し: セクションの見出しを用いてコンテンツを体系化している。 (レベル AAA)

注記 1: "見出し" はその一般的な意味で用いられており、タイトルやさまざまなタイプのコンテンツに見出しを付加するその他の手段を含む。

注記 2: この達成基準でいうセクションとは、ユーザインタフェース要素のまとまりではなく、文書におけるセクションを意味している。ユーザインタフェース要素は、達成基準4.1.2でカバーされている。

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

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

  • 全盲の利用者が、ウェブページのあるセクションからいつ別のセクションへ移動したのかが分かるようになり、各セクションの目的が分かるようになる。

  • 学習障害のある利用者が、見出しがあることによって、ページ全体のコンテンツの構造をより容易に理解できるようになる。

  • キーボードでコンテンツをナビゲートしている利用者が、フォーカスを見出しから見出しへとジャンプできるようになり、関心のあるコンテンツを素早く見つけることができるようになる。

  • 一部のコンテンツを更新したページでは、見出しを使うことによって、更新したコンテンツへ素早く到達できるようになる。

  • メニューにさまざまなコース料理のセクションがある。各セクションには、前菜、サラダ、スープ、メイン料理、デザートという見出しがある。

  • あるウェブアプリケーションには、設定ページがあり、関連する設定ごとのグループに分けられている。各セクションには各グループを説明する見出しがある。

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

  1. G141: Organizing a page using headings

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

  • Using the 'live' property to mark live regions (リンク追加予定) (ARIA)

  • Providing mechanisms to navigate to different sections of the content of a Web page (リンク追加予定)

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

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

セクション

1つ以上の関連するトピックあるいは考えを扱う自己完結的なコンテンツの一部。

注記: セクションは1つ以上の段落から成り、グラフィック、表、リスト、およびサブセクションを含む。

利用者インターフェース要素

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

注記 1: 複数の利用者インターフェース要素が単一のプログラム的要素として実装されることがある。ここでいう要素は、プログラミングテクニックではなく、別々のコントロールとして利用者が知覚するものを指す。

注記 2: 利用者インターフェース要素には、スクリプトで生成されるコンポーネントやフォーム要素、リンクが含まれる。

事例: アプレットには、コンテンツ内を行ごと、ページごと、あるいはランダムに移動するために用いられる "コントロール" がある。これらはどれも識別名があり、個別に設定可能なので、それぞれが "利用者インターフェース要素" となる。


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

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

ガイドライン 3.1 の意図

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

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

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

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

  • Setting expectations about content in the page from uncontrolled sources (リンク追加予定)

  • Providing sign language interpretation for all content (リンク追加予定)

  • Using the clearest and simplest language appropriate for the content (リンク追加予定)

  • Avoiding centrally aligned text (リンク追加予定)

  • Avoiding text that is fully justified (to both left and right margins) in a way that causes poor spacing between words or characters (リンク追加予定)

  • Using left-justified text for languages that are written left to right and right-justified text for languages that are written right-to-left (リンク追加予定)

  • Limiting text column width (リンク追加予定)

  • Avoiding chunks of italic text (リンク追加予定)

  • Avoiding overuse of different styles on individual pages and in sites (リンク追加予定)

  • Making links visually distinct (リンク追加予定)

  • Using images, illustrations, video, audio, or symbols to clarify meaning (リンク追加予定)

  • Providing practical examples to clarify content (リンク追加予定)

  • Using a light pastel background rather than a white background behind black text (リンク追加予定)

  • Avoiding the use of unique interface controls unnecessarily (リンク追加予定)

  • Using upper and lower case according to the spelling rules of the text language (リンク追加予定)

  • Avoiding unusual foreign words (リンク追加予定)

  • Providing sign language versions of information, ideas, and processes that must be understood in order to use the content (リンク追加予定)

  • Making any reference to a location in a Web page into a link to that location (リンク追加予定)

  • Making references to a heading or title include the full text of the title (リンク追加予定)

  • Providing easy-to-read versions of basic information about a set of Web pages, including information about how to contact the Webmaster (リンク追加予定)

  • Providing a sign language version of basic information about a set of Web pages, including information about how to contact the Webmaster (リンク追加予定)

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

3.1.1 ページの言語: それぞれのウェブページのデフォルトの自然言語プログラムで解釈できる。 (レベル A)

この達成基準の意図

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

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

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

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

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

  • スクリーンリーダー又はテキストを合成音声に変換するその他の技術を使用している利用者。

  • 例えば、文字及びアルファベットを認識したり、単語を読み取ったりすることのように、書かれたものを流暢かつ正確に読むのが困難な利用者。

  • テキストを音声に変換するソフトウェアを使用している、認知、言語、及び学習障害のある利用者。

  • 同期したメディアではキャプションを頼りにしている利用者。

達成基準 3.1.1 の事例

  • 2つの言語で書かれたコンテンツのあるウェブページ

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

関連リソース

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

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  1. H57: Using language attributes on the html element (HTML)

達成基準 3.1.1 でさらに対応が望まれる実装方法(参考)

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

  • Specifying the default language in the HTTP header (リンク追加予定)

  • using http or the Content-Language meta tag for metadata (リンク追加予定)

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

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

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

重要な用語

自然言語

人間とコミュニケーションをとるための言語で、話したり、書いたり、あるいは(視覚的あるいは触覚的な手段で)手話にするもの。

注記:手話も参照のこと。

プログラムで解釈(プログラムで解釈可能)

コンテンツ制作者が提供したデータからソフトウェアが解釈できること。また、その際に、支援技術を含むさまざまなユーザエージェントが、この情報を抽出して利用者にさまざまなモダリティで提示できること

事例 1: マークアップ言語では、一般に入手可能な支援技術が、要素および属性に直接アクセスすることにより解釈できる。

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

ウェブページ

HTTP によって単一の URI から得られる埋め込みではないリソースと、レンダリングに用いられたり、ユーザエージェントで一緒にレンダリングされる目的で用いられたりしているその他のリソース。

注記 1: どのような "その他のリソース" も第一のリソースと一緒にレンダリングされるであろうが、必ずしもお互いが同時にレンダリングされる必要があるわけではない。

注記 2: このガイドラインに適合する目的において、ウェブページと見なされる適合範囲内ではリソースは『埋め込みではない』ものでなければならない。

事例 1: すべての埋め込まれた画像とメディアを含んだウェブリソース。

事例 2: Ajaxを用いたウェブメールのプログラム。そのプログラムは http://example.com/mail に存在しているが、受信箱、アドレス帳、そしてカレンダーがある。受信箱、アドレス帳やカレンダーを起動するリンクあるいはボタンがあるが、ページ全体の URI は変わらない。

事例 3: カスタマイズ可能なポータルサイトで、利用者がさまざまなコンテンツのモジュール一式の中から表示させるコンテンツを選択できる。

事例 4: ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、ウェブサイトの中のほんの1ページなのかもしれない。


部分的に用いられている言語:
達成基準 3.1.2 を理解する

3.1.2 部分的に用いられている言語: コンテンツの一節あるいは語句それぞれの自然言語プログラムで解釈できる。ただし、固有名詞、技術用語、不確定な言語の言葉、およびすぐ前後にあるテキストの言語の一部になっている単語あるいは語句は除く。 (レベル AA)

この達成基準の意図

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

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

テキストの語句又は一節に他の言語が特定されていなければ、その自然言語がウェブページのデフォルトの自然言語となる(達成基準 3.1.1 を参照)。そのため、単一の言語の場合は、すべてのコンテンツの自然言語がプログラムで判断できることになる。

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

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

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

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

  • 点字通訳ソフトウェアが言語の変化に従うことができるようになる。例えば、アクセント文字の代わりに、制御コードを用いて、必要な制御コードを挿入し、2級英語点字による縮約の誤りを回避することができる。

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

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

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

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

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

  • スクリーンリーダー又はテキストを合成音声に変換するその他の技術を使用している利用者。

  • 例えば、文字及びアルファベットを認識したり、単語を読み取ったりすることのように、書かれたものを流暢かつ正確に読むのが困難な利用者。

  • テキストを音声に変換するソフトウェアを使用している、認知、言語、及び学習障害のある利用者。

  • 同期したメディアのコンテンツの音声トラックでの言語の変化を識別するのに、キャプションを頼りにしている利用者。

達成基準 3.1.2 の事例

  1. 英語の文章中にあるドイツ語の一節

    文章中に "He maintained that the DDR (German Democratic Republic) was just a ' Treppenwitz der Weltgeschichte'," とあり、ドイツ語の一節 'Treppenwitz der Weltgeschichte' がドイツ語であることが示されている。マークアップ言語によって、特定している箇所を除いては英語を文書全体の言語として示すこともできるし、段落レベルで示すこともできる。スクリーンリーダーがドイツ語の一節を読み上げる際は、その単語を正確に発音するために、発音規則を英語からドイツ語に変更する。

  2. 代わりの言語へのリンク

    ある HTML のウェブページには、そのページの他言語版へのリンクがある(例: ドイツ語、フランス語、オランダ語、スペイン語、など)。それぞれのリンクのテキストは言語名で、その言語で書かれている。リンクの言語はそれぞれ、lang 属性で示されている。

  3. フランス語の文章中で使われている "Podcast"

    "podcast" は、次の引用ではすぐ周囲にあるテキストの言語の一部である。"À l'occasion de l'exposition "Energie éternelle. 1500 arts d'art indien", le Palais des Beaux-Arts de Bruxelles a lancé son premier podcast. Vous pouvez télécharger ce podcast au format M4A et MP3," この場合、言語の変化を示す必要はない。

関連リソース

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

達成基準 3.1.2 の実装方法及び不適合事例 - 部分的に用いられている言語

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  1. H58: Using language attributes to identify changes in the human language (HTML)

達成基準 3.1.2 でさらに対応が望まれる実装方法(参考)

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

  • Making text that is not in the default human language of the Web page visually distinct (リンク追加予定)

  • Giving the names of any languages used in foreign passages or phrases (リンク追加予定)

  • Providing language markup on proper names to facilitate correct pronunciation by screen readers (リンク追加予定)

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

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

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

重要な用語

自然言語

人間とコミュニケーションをとるための言語で、話したり、書いたり、あるいは(視覚的あるいは触覚的な手段で)手話にするもの。

注記:手話も参照のこと。

プログラムで解釈(プログラムで解釈可能)

コンテンツ制作者が提供したデータからソフトウェアが解釈できること。また、その際に、支援技術を含むさまざまなユーザエージェントが、この情報を抽出して利用者にさまざまなモダリティで提示できること。

事例 1: マークアップ言語では、一般に入手可能な支援技術が、要素および属性に直接アクセスすることにより解釈できる。

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


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

3.1.3 一般的ではない用語: 慣用句および専門用語を含めて、一般的には使われることのない、または限定された用法で使われている単語あるいは語句の特定の定義を示すメカニズムが利用可能である。 (レベル AAA)

この達成基準の意図

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

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

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

  • 言葉をデコードしづらい。

  • 単語及び語句を理解しづらい。

  • 前後の文脈を用いて理解するのが困難である。

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

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

達成基準 3.1.3 の事例

  • 一般的ではない使われ方をしている単語の定義があるテキスト

    他の情報源からの定義を "カスケード表示" に表示するのではなく、定義検索で意図した定義が見つかるように、リスト又は辞書とその他のリソースの "カスケード表示" を整理する。("カスケード表示" は、辞書及びその他のリソースを最も正しい定義を提示しそうな順序で一覧表示する。これは、定義を検索している際に、チェックすべき順序を制御している。)

  • 用語集にある定義

    WCAG 2.0 では、"text" という単語を特別な用法で用いている。そこで、WCAG 2.0 で "text" という単語が使われているときは、同じウェブページにある用語集で提供されている "text" の定義へリンクしている。

  • ページ下部で提供されている単語の特別な定義

    ページ上の単語に、その単語の定義へのページ内リンクが提供されている。

関連リソース

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

注記: 次のリストにある製品名又はベンダー企業名は、WCAG ワーキンググループ又は W3C の WAI による推薦を意味するものではない。このリストは、単に便宜を提供するだけのものであり、どのようなリソースが参照可能なのかを知らせるだけのものである。

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

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

状況 A: 単語又は語句にそのウェブページ特有の意味がある場合:
  1. G101: Providing the definition of a word or phrase used in an unusual or restricted way for the first occurrence of the word or phrase in a Web page using one of the following techniques:

  2. G101: Providing the definition of a word or phrase used in an unusual or restricted way for each occurrence of the word or phrase in a Web page using one of the following techniques:

状況 B: 単語又は語句の意味が、同じウェブページ内で異なる場合:
  1. G101: Providing the definition of a word or phrase used in an unusual or restricted way for each occurrence of the word or phrase in a Web page using one of the following techniques:

達成基準 3.1.3 でさらに対応が望まれる実装方法(参考)

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

  • Using markup and visual formatting to help users recognize words that have special meaning (リンク追加予定)

  • Providing a voice-enabled dictionary search so that users who have difficulty typing or spelling can speak the word whose definition they need (リンク追加予定)

  • Providing a sign language dictionary to help users who are deaf find the necessary definitions (リンク追加予定)

  • Providing a mechanism for finding definitions for all words in text content (リンク追加予定)

  • Providing a mechanism to determine the meaning of each word or phrase in text content (リンク追加予定)

  • Avoiding unusual foreign words (リンク追加予定)

  • Using a series of dictionaries in cascading fashion to provide meanings (リンク追加予定)

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

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

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

重要な用語

慣用句

個々の単語の意味からはその意味を推測できず、そこにある単語を変えると意味が通じなくなる言い回し。

注記: 慣用句は、単語単位で直接翻訳すると、その(文化的あるいは言語特有の)意味が通じなくなる。

事例 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"(彼はニワトリとねぐらについた)となるが、「彼は早く寝た」という意味である。

専門用語

特定の分野の人々が特定の用法で用いる単語

事例: "StickyKeys"(固定キー)という用語は、支援技術 / アクセシビリティの分野における専門用語である。

メカニズム

結果を得るためのプロセスあるいはテクニック。

注記 1:メカニズムは、コンテンツ内で明白に提供されることもあれば、あるいは、プラットフォームまたは支援技術を含むユーザエージェントのどちらかで提供されるものに依存することもある。

注記 2: メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。

一般的には使われることのない、または限定された用法で使われている

そのコンテンツを正しく理解するために、そこではどの定義が適用されるのかを利用者が知っていることを要求するように用いられる用語。

事例: "gig" という用語は、音楽コンサートの話の中で使われている場合は、コンピュータのハードディスクドライブの容量に関する記事で使われている場合とは違うことを意味するが、適切な定義は文脈により決まってくる。それに対して、"text" という用語は、WCAG 2.0では非常に特殊な使われ方をしているので、その定義が用語集で提供されている。


略語:
達成基準 3.1.4 を理解する

3.1.4 略語: 略語の元の語あるいは意味を示すメカニズムが利用可能である。 (レベル AAA)

この達成基準の意図

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

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

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

  • 言葉をデコードしづらい。

  • 画面拡大ソフトを使用している(画面を拡大すると、前後の文脈の手がかりをつかみづらくなる)。

  • 記憶に限界がある。

  • 前後の文脈を用いて理解するのが困難である。

略語はさまざまなかたちで利用者を困惑させることがある:

  • 略語の中には、普通の単語のようには見えなくて、その言語の通常の規則に従って発音できないものがある。例えば、英語の単語 "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" と同じように発音する。

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

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

達成基準 3.1.4 の事例

  • 元の語句がコンテンツで初めて使用されているところで提供されている略語

    "World Wide Web Consortium" という名前が、ウェブページの最初の見出しとして使われている。略語の "W3C" が同じ見出しで括弧書きで示されている。

  • 辞書検索フォーム

    あるウェブサイトには、オンライン頭字語辞書サービスが提供する検索フォームがある。利用者が頭字語を入力すると、検索結果として、考えられうる元の語句の一覧が表示される。

  • 医療系ウェブサイト

    医療系のあるウェブサイトは、医者と患者の両方に情報を提供している。そのサイトには、カスケード式の辞書がある。とても専門的な医学辞書が最初で、一般向けの医学辞書が二番目にある。また、カスケードには、そのサイト固有の頭字語及び略語があり、最後に普通の辞書もある。リストの最後にある普通の辞書は、テキストにあるほとんどの単語の定義を提供している。また、専門的な医学辞書は、一般的ではない医学用語の定義を提供している。複数の辞書にある単語の定義は、カスケードの順序で一覧表示される。頭字語及び略語の意味は、頭字語及び略語の一覧が提供している。

  • 略語の元の語句

    それぞれの略語の元の語句が、プログラムで判断可能な方法で提供されている。テキストを読み上げるユーザエージェントは、その元の語句を用いて略語を読み上げることができる。その他のユーザエージェントは、ツールチップ又は状況に応じたヘルプで、その略語の元の語句を提供することができるかもしれない。

関連リソース

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

達成基準 3.1.4 の実装方法及び不適合事例 - 略語

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

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

状況 A: 略語がそのウェブページ内で一つの意味しか持たない場合:
  1. G102: Providing the expansion or explanation of an abbreviation for the first occurrence of the abbreviation in a Web page using one of the following techniques:

  2. G102: Providing the expansion or explanation of an abbreviation for all occurrences of the abbreviation in a Web page using one of the following techniques:

状況 B: 略語が同じウェブページで異なるものを意味している場合:
  1. G102: Providing the expansion or explanation of an abbreviation for all occurrences of abbreviations in a Web page using one of the following techniques:

達成基準 3.1.4 でさらに対応が望まれる実装方法(参考)

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

  • Using unique abbreviations in a Web page (リンク追加予定)

  • Using visual formatting to help users recognize abbreviations (リンク追加予定)

  • Providing access to a talking dictionary to support users who might have difficulty decoding written definitions (リンク追加予定)

  • Providing a voice-enabled dictionary search so that users who have difficulty typing or spelling can speak the word whose definition they need (リンク追加予定)

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

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

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

重要な用語

略語

単語、語句、あるいは名称の短縮形で、その略語が言語の一部になっていないもの。

注記 1:これには、以下のような頭文字語および頭字語を含む:

  1. 頭文字語は、その名称あるいは語句に含まれる単語や音節の頭文字による、名称あるいは語句の短縮形である。

    注記 1: すべての言語で定義されているわけではない。

    事例 1: SNCFは、フランス語の頭文字語で、フランス国有鉄道の "Société Nationale des Chemins de Fer" の頭文字を含んでいる。

    事例 2: ESPは、"extrasensory perception"(超感覚的知覚)の頭文字語である。

  2. 頭字語は、(名称や語句にある)頭文字あるいは他の単語の一部で一つの単語のように発音されるような省略形である。

    事例:NOAAは、米国の "National Oceanic and Atmospheric Administration" の頭文字による頭字語である。

注記 2: 会社名の頭字語だったものをそのまま会社名とする会社がある。そのような場合、その会社の新しい名前は単語(例:Ecma)であり、その単語はもはや頭字語ではない。

メカニズム

結果を得るためのプロセスあるいはテクニック。

注記 1:メカニズムは、コンテンツ内で明白に提供されることもあれば、あるいは、プラットフォームまたは支援技術を含むユーザエージェントのどちらかで提供されるものに依存することもある。

注記 2: メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。


読解レベル:
達成基準 3.1.5 を理解する

3.1.5 Reading Level: 固有名詞や(ビデオや書籍などの)タイトルを除いて、テキストが前期中等教育レベルを超えた読解力を必要とする際には、補足的コンテンツあるいは中等教育レベルを超えた読解力を必要としないバージョンが利用可能である。 (レベル AAA)

この達成基準の意図

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

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

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

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

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

ディスレクシア(失読症)などの読字障害は、書かれた単語又は印刷された単語を認識して、正しい音と関連付けづらくする。これを、文章を "デコード" するという。 デコードは、人がすらすらと読むためには、自動的でなければならない。文章を単語ごとにデコードするという行為は、ほとんどの人が自分の読んでいるものを理解するために用いることのできるメンタルなエネルギーのほとんどを消費する。簡潔でよく使われる単語及び簡潔な文を用いた文章はデコードしやすく、長文及び長い単語又は馴染みのない単語を用いている文章ほど、読解力も通常は必要としないものである。

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

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

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

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

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

教育レベル
初等教育 前期中等教育 後期中等教育 高等教育
学校教育の最初の6年 学校教育の7~9年目 学校教育の10~12年目 13年目以降の学校教育

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

注記: Open Society Mental Health Initiative によれば、読みやすさの概念は万国共通ではなく、読み書きと理解に問題を抱えたすべての人の能力に合致する文章を書くことは不可能だろうといわれている。最も明快で、かつ最も簡易な言葉遣いを用いることが非常に望ましいが、WCAG ワーキンググループではそれが達成されているかどうかを検証する方法を見つけることができなかった。読解レベルを用いているのは、明快な文章を推奨する達成基準にテスト可能性を持たせるためである。認知障害のある利用者に対しては、補足のコンテンツを提供することが効果的な実装方法の一つとなりえる。

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

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

  • 一般的な知識又は特定の情報を得るために、書き言葉(例: テキストあるいは点字の記事、説明文、又は新聞記事)を理解して解釈するのが困難である。

達成基準 の事例 3.1.5

  1. 複雑な研究記事の読みやすい要約がある科学雑誌

    ある科学雑誌には、その分野の専門家を対象とした、とても専門的な言葉遣いで書かれた記事がある。その雑誌の目次ページには、各記事の要約が平易な言葉で書かれている。その要約は、8年程度の学校教育を受けた一般読者を想定している。また、雑誌のメタデータには、Dublin Core(ダブリン・コア)の仕様を用いて、記事の想定している読者の教育レベルを "advanced" 、要約の想定している読者の教育レベルを "lower secondary education" と示してある。

  2. 一般会員向けの医療情報

    ある医科大学が、最近の医学的及び科学的発見を説明するウェブサイトを運営している。そのサイトの記事は、医療の知識のない人向けに書かれている。各記事では、Dublin Core(ダブリン・コア)の仕様を用いて、想定している読者の教育レベルを "lower secondary education" と示していて、その記事の Flesch Reading Ease のスコアもある。各ページにあるリンクは、教育レベル及びその他のメタデータを表示する。前期中等教育レベルの読者がその記事を読むことができるので、補足のコンテンツは必要ない。

  3. E-ラーニング・アプリケーション

    スペインの文化史に関するオンラインコースに、ムーア建築に関する単元がある。その単元のテキストは、さまざまな読解レベルを持った学生向けに書かれている。建築物の写真及び描画で、建築のコンセプト及び様式を図示している。グラフィック・オーガナイザーを用いて文章の複雑な関係性を図式化し、合成音声を用いた音声バージョンも提供している。各バージョンのメタデータでコンテンツの教育レベルを示し、スペイン語のテキスト向けに開発された計算式に基づくリーダビリティのスコアもある。この E-ラーニング・アプリケーションは、このメタデータ及び学生に関するメタデータを用いて、個々の学生のニーズに合ったバージョンの教材を提供している。

  4. 前期中等教育レベルの読解力を要する科学情報

    次のテキスト(合計116ワード)は、Flesch-Kincaid式によると、米国ではグレード 4.2 の読解力を必要とする。米国では、グレード 4.2 は初等教育レベルである。

    Science is about testing — and about looking closely. Some scientists use microscopes to take a close look. We're going to use a simple piece of paper.

    Here's what you do: Print this page and cut out the square to make a "window" one inch square. (It's easiest to fold the page in half before you cut.)

    Choose something interesting: a tree trunk, a leaf, flower, the soil surface, or a slice of soil from a shovel.

    Put your window over the thing and look at it closely. Take your time — this is not a race.

    To help you see more details, draw a picture of what's inside your square.

    Now let's think about what you've found.

    (Source: Howard Hughes Medical Institute http://www.hhmi.org/coolscience/forkids/inchsquare/)

関連リソース

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

達成基準 3.1.5 の実装方法及び不適合事例 - 読解レベル

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  1. G86: Providing a text summary that requires reading ability less advanced than the upper secondary education level

  2. G103: Providing visual illustrations, pictures, and symbols to help explain ideas, events, and processes

  3. G79: Providing a spoken version of the text

  4. G153: Making the text easier to read

  5. G160: Providing sign language versions of information, ideas, and processes that must be understood in order to use the content

注記: この達成基準には、サイトによって異なる方法で対処することができる。コンテンツの音声バージョンは、ある利用者に対しては有用であるし、また聴覚障害のある利用者にとっては、手話が彼らにとっての第一言語であることもあるので、ページの手話バージョンのほうが書き言葉のバージョンよりも理解しやすいかもしれない。中には、音声と手話の両方のバージョン又はその他の組合せを提供するサイトがあってもよい。どの実装方法も、問題を抱える利用者すべてに役立つわけではない。そのため、サイトをよりアクセシブルにしようとしているコンテンツ制作者のために、ここではさまざまな実装方法が達成基準を満たすことのできる実装方法として挙げられている。上記の番号の付いた実装方法又はその組合せを用いることが可能で、WCAG ワーキンググループでは達成基準に適合するには十分であると考えている。

達成基準 3.1.5 でさらに対応が望まれる実装方法(参考)

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

  • Providing text for navigational and landing pages that requires reading ability that is less advanced than the lower secondary education level (リンク追加予定)

  • Providing text for interior pages that requires reading ability at the lower secondary education level (リンク追加予定)

  • Including content summaries in metadata (リンク追加予定)

  • Using the clearest and simplest language appropriate for the content (リンク追加予定)

  • Using RDF to associate supplements with primary content (リンク追加予定)

  • Providing a clear representational image on the site's home page (リンク追加予定)

  • Clearly marking, by use of text or icon, content which has been optimized for easy reading (リンク追加予定)

  • Using sentences that contain no redundant words, that is, words that do not change the meaning of the sentence (リンク追加予定)

  • Using sentences that contain no more than two conjunctions (リンク追加予定)

  • Using sentences that are no longer than the typical accepted length for secondary education (Note: In English that is 25 words) (リンク追加予定)

  • Using sentences that do not contain complex words or phrases that could be replaced with more commonly used words without changing the meaning of the sentence (リンク追加予定)

  • Providing summaries for different sections of text (リンク追加予定)

  • Using metadata to associate alternatives at different reading levels. (リンク追加予定)

  • Using the Dublin Core accessibility element to associate text content with text, graphical, or spoken supplements (リンク追加予定)

  • Using the ISO AfA accessibility element to associate text content with text, graphical, or spoken supplements (リンク追加予定)

  • Using the IMS accessibility element to associate text content with text, graphical, or spoken supplements (リンク追加予定)

  • Making metadata viewable by humans (リンク追加予定)

    • 事例:Providing, in metadata, URI(s) that point to a pre-primary-reading-level and a primary-reading-level text transcript of a new scientific discovery advanced-reading-level article.

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

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

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

重要な用語

前期中等教育レベル

6年間の学校教育後に始まり、初等教育の開始から9年後に終わる、2年間あるいは3年間の教育。

注記: この定義は、教育の国際標準分類(International Standard Classification of Education)[UNESCO]をもとにしている。

補足的コンテンツ

元のコンテンツを説明したり、より明確にしたりするために付加されたコンテンツ。

事例 1: ウェブページの音声バージョン。

事例 2: 複雑なプロセスを示したイラスト。

事例 3: 調査研究でなされた主要な成果および提言を要約する段落。


発音(読み仮名)::
達成基準 3.1.6 を理解する

3.1.6 発音(読み仮名): 文脈において、発音が分からないと単語の意味が不明瞭になる場合、その単語の特定の発音(読み仮名)を示すメカニズムが利用可能である。 (レベル AAA)

この達成基準の意図

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

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

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

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

  • 言葉をデコードしづらい。

  • 前後の文脈を用いて理解するのが困難である。

  • 音声で読み上げる支援技術を使用している。

達成基準 3.1.6 の事例

  • 人名の読み方を提供

    日本語のウェブコンテンツが、人名の漢字のすぐ後に読み仮名を提供している。読み仮名は、漢字の後に括弧書きで示されている。漢字で書かれた語句の読み仮名を提供することによって、画面を見ている利用者とスクリーンリーダーの両方が、その語句を正しく読む/読み上げることができるようになる。ただし、スクリーンリーダーは2回読み上げることになる。つまり、まず最初に誤った読み方かもしれない漢字を読み上げて、その後に正しい読み方を提供する読み仮名を読み上げる。

  • ruby 要素で読み仮名を提供

    XHTML 1.1 を用いているウェブコンテンツが、語句の読み(発音)を示す ruby 要素を用いて、文字の上に読み仮名を提供している。

  • 発音の音声ファイルを提供

    ある文書に、発音が分からないとその意味を判断できない単語がある。単語にはそれぞれ、正しい発音を提供する音声ファイルへのリンクがある。利用者は、その単語の正しい発音を確認するためにそのリンクを選択することができる。

  • 用語集で発音の情報を提供

    ウェブページに用語集のセクションがある。用語集にある用語の中には、定義とあわせて発音の情報も提供されているものがある。そのコンテンツにある、発音が分からないと意味を判断できない単語には、用語集へのリンクがある。

  • 幾つかの言語で共通の文字だが、発音は言語によって異なる文字の発音に関する情報があるテキスト

    日本のある大学のウェブサイトに、中国語及び韓国語の学術的な文書から引用された短い一節が幾つかある。その引用は、日本語のテキストと同じ文字を使って書かれている。そこで、中国語及び韓国語の文字の正しい発音を示すために、発音の情報が提供されている。

注記: 日本語では、"発音" というよりも "読み仮名" を示すためにruby 要素を用いる。

関連リソース

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

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

達成基準 3.1.6 の実装方法及び不適合事例 - 発音及び読み仮名

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  1. G120: Providing the pronunciation immediately following the word

  2. G121: Linking to pronunciations

  3. G62: Providing a glossary that includes pronunciation information for words that have a unique pronunciation in the content and have meaning that depends on pronunciation

  4. 次の技術特有の実装方法を用いて、発音の情報を提供する:

達成基準 3.1.6 でさらに対応が望まれる実装方法(参考)

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

  • Providing pronunciations in a sound file, so that users can listen to the pronunciations of the word (リンク追加予定)

  • Providing a mechanism for finding pronunciations for all foreign words in text content (リンク追加予定)

  • Providing a mechanism to determine the pronunciations of each word or phrase in text content (リンク追加予定)

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

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

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

重要な用語

メカニズム

結果を得るためのプロセスあるいはテクニック。

注記 1:メカニズムは、コンテンツ内で明白に提供されることもあれば、あるいは、プラットフォームまたは支援技術を含むユーザエージェントのどちらかで提供されるものに依存することもある。

注記 2: メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。


予測可能:
ガイドライン 3.2 を理解する

ガイドライン 3.2: ウェブページの表示や動作を予測可能にする。

ガイドライン 3.2 の意図

この達成基準の意図は、障害のある利用者のために、ウェブページごとにコンテンツを予測可能な順序で提供すること、及び機能的でインタラクティブなコンポーネントのふるまいを予測可能にすることである。利用者がウェブページ全体の概観を把握するのが困難なことがある。例えば、スクリーンリーダーは、合成音声の一次元な流れでコンテンツを提示するため、空間的な関係性を理解しづらくする。認知障害のある利用者は、コンポーネントがページによって異なる場所に表示されると困惑してしまうことがある。

例えば、画面拡大ソフトを使用している利用者は、常時画面の一部分だけしか見ていない。そのため、一貫性のあるレイアウトによって、ナビゲーションバーやその他の構成要素が見つけやすくなる。一式のウェブページの中で、繰り返される構成要素を相対的に同じ順序で配置することにより、読字障害のある利用者が、各リンクのテキストをデコードするのに無駄な時間を費やすことなく、画面のある領域に集中することができるようになる。そして、手を十分に使えない利用者は、最少のキーストロークでタスクを完了できる方法をより容易に見つけ出すことができる。

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

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

  • Positioning labels to maximize predictability of relationships

オン・フォーカス:
達成基準 3.2.1 を理解する

3.2.1 オン・フォーカス: あらゆる要素がフォーカスを受け取る際、状況の変化を引き起こさない。 (レベル A)

この達成基準の意図

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

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

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

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

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

  • この達成基準は、状況の変化が予期せず起こる可能性を引き下げることによって、視覚障害、認知限界、及び運動障害のある利用者に役立つ。

達成基準 3.2.1 の事例

  • 事例 1: ドロップダウンメニュー

    ページ上にあるドロップダウンメニューによって、利用者がリンク先を選択できるようになっている。利用者がキーボードを使用して下のほうにあるアイテムを選択して(スペースキー又は Enter キーで)実行すると、新しいページへ移動する。しかし、利用者がドロップダウンメニューにある選択肢へ下りていって、Escape キー又は Tab キーでそのプルダウンメニューから抜け出た場合には、フォーカスはドロップダウンの外へ移動するので、新しいページには移動しない。

  • 不適合事例: ヘルプのダイアログ

    テキストフィールドがフォーカスを受け取ると、そのテキストフィールドについての説明とオプションを提供するヘルプのダイアログウィンドウが開く。キーボードの利用者がウェブページの中を Tab キーで移動していると、利用者がそのテキストフィールドへ Tab キーで移動するたびに、キーボード・フォーカスをコントロールから奪って、ダイアログが開く。

達成基準 3.2.1 の実装方法及び不適合事例 - オン・フォーカス

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  1. G107: Using "activate" rather than "focus" as a trigger for changes of context

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

達成基準 3.2.1 でさらに対応が望まれる実装方法(参考)

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

  • Not causing persistent changes of state or value when a component receives focus, or providing an alternate means to reset any changes(リンク追加予定)

  • Opening new windows only when best from an accessibility perspective (リンク追加予定)

  • Giving users advanced warning when opening a new window. (リンク追加予定)

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

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

重要な用語

状況の変化

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

状況における変化には以下に挙げるものの変化が含まれる:

  1. ユーザエージェント;

  2. ビューポート

  3. フォーカス

  4. ウェブページの意味を変えるコンテンツ

注記:コンテンツの変化が、常に状況の変化であるとは限らない。外枠を広げること、動的なメニュー、あるいはタブコントロールのように、コンテンツにおける小さな変化は、それが上記のいずれか(例:フォーカス)を変更しないかぎり、状況を変化させるものではない。

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


ユーザインタフェースによる状況の変化:
達成基準 3.2.2 を理解する

3.2.2 ユーザインタフェースによる状況の変化: 利用者が使用する前にその挙動を知らせてある場合を除いて、ユーザインタフェース要素の設定を変更することで状況の変化を引き起こさない。 (レベル A)

この達成基準の意図

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

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

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

  • この達成基準は、インタラクティブなコンテンツをより予測可能にすることによって、障害のある利用者に役立つ。予期しない状況の変化によって、視覚障害又は認知障害のある利用者はとても混乱してしまうので、コンテンツを利用できなくなってしまう。

  • 状況の変化に気づくことができない利用者は、サイトをナビゲートしている間に混乱した状態になりにくい。例えば、次のような利用者が当てはまる:

    • 全盲の利用者、又はロービジョンの利用者は、新しいウィンドウがポップアップで開くなどのように、視覚的な状況の変化がいつ起こるのかを把握するのが困難なことがある。この場合、前もって利用者に状況の変化が起こることを知らせておくと、利用者が [戻る] ボタンがいつものように動作しないことに気づいたときの混乱を最小限に抑えることができる。

  • ロービジョンの利用者、読字及び知的障害のある利用者、そして視覚的な手がかりを解釈しづらい利用者は、コンテンツ制作者が手がかりを追加することによって、状況の変化に気づくようになる。

達成基準 3.2.2 の事例

  • ウェブベースのカレンダー及びスケジュール管理アプリケーションに、カレンダーへのエントリーを作成するフォームがある。件名、時刻、場所を入力する標準的なテキストフィールドとあわせて、カレンダーへのエントリーの種類を選択するラジオボタン一式がある。その種類には、会議、アポイントメント、又はリマインダなどがある。利用者が "会議" のラジオボタンを選択すると、会議の参加者を入力するためのテキストフィールドがページ上に追加で表示される。また、"リマインダ" を選択すれば、異なったテキストフィールドが表示される。この場合、入力部分だけが変化し、全体の構造は同じままなので、基本的に状況は変化していないといえる。

  • フォームに、米国の電話番号を入力するテキストフィールドがある。すべての電話番号には、3桁のエリアコードがあり、その後に3桁の局番、そして最後に4桁の番号があり、それぞれの番号は別々のテキストフィールドに入力するようになっている。利用者があるテキストフィールドの入力を終えて、次のテキストフィールドの最初の桁を入力しようとすると、フォーカスが自動的に次のフィールドへ移動する。このふるまいは、フォームの先頭で利用者に対して説明されている。

達成基準 3.2.2 の実装方法及び不適合事例 - ユーザインタフェース要素における状況の変化

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  1. G80: Providing a submit button to initiate a change of context using a technology-specific technique listed below

  2. G13: Describing what will happen before a change to a form control that causes a change of context to occur is made

注記:A change of content is not always a change of context. This success criterion is automatically met if changes in content are not also changes of context.

達成基準 3.2.2 でさらに対応が望まれる実装方法(参考)

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

  • Giving users advanced warning when opening a new window. (リンク追加予定)

重要な用語

状況の変化

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

状況における変化には以下に挙げるものの変化が含まれる:

  1. ユーザエージェント;

  2. ビューポート

  3. フォーカス

  4. ウェブページの意味を変えるコンテンツ

注記:コンテンツの変化が、常に状況の変化であるとは限らない。外枠を広げること、動的なメニュー、あるいはタブコントロールのように、コンテンツにおける小さな変化は、それが上記のいずれか(例:フォーカス)を変更しないかぎり、状況を変化させるものではない。

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

利用者インターフェース要素

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

注記 1: 複数の利用者インターフェース要素が単一のプログラム的要素として実装されることがある。ここでいう要素は、プログラミングテクニックではなく、別々のコントロールとして利用者が知覚するものを指す。

注記 2: 利用者インターフェース要素には、スクリプトで生成されるコンポーネントやフォーム要素、リンクが含まれる。

事例: アプレットには、コンテンツ内を行ごと、ページごと、あるいはランダムに移動するために用いられる "コントロール" がある。これらはどれも識別名があり、個別に設定可能なので、それぞれが "利用者インターフェース要素" となる。


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

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

この達成基準の意図

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

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

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

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

  • 繰り返されているコンテンツを、サイトの各ページで同じ順序で提示することによって、利用者が各ページのどこにそれがあるのかを予測できるようになり、安心して利用できるようになる。これは、認知限界のある利用者、ロービジョンの利用者、知的障害のある利用者、そして全盲の利用者に役立つ。

達成基準 3.2.3 の事例

  • 一貫して配置されているコントロール

    検索のテキストフィールドが、全ページ上で最後に配置されていて、利用者はすぐに検索機能を見つけることができる。

  • 展開するナビゲーションメニュー

    ナビゲーションメニューに、サイトの主要コーナーにリンクしている7つの項目がある。利用者がその項目の一つを選択すると、サブナビゲーション項目のリストが、ナビゲーションメニューに挿入される。

  • 一貫して配置されているスキップ・ナビゲーションのコントロール

    ウェブサイトにあるすべてのページ上に、"本文へジャンプする" というリンクが一番最初のリンクとして置かれている。そのリンクによって、利用者はヘッダーの情報及びナビゲーション部分を通過して、ページのメインコンテンツ部分の開始位置へ移動することができる。

  • ナビゲーションへのスキップリンク

    ページの最後にあるナビゲーションへのスキップリンクがある。キーボード利用者が、必要なときに容易に見つけられるように、そのリンクは一貫して各ページの先頭にある。

関連リソース

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

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

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  1. G61: Presenting repeated components in the same relative order each time they appear

達成基準 3.2.3 でさらに対応が望まれる実装方法(参考)

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

  • Using templates to ensure consistency across multiple Web pages (リンク追加予定)

  • Creating layout, positioning, layering, and alignment (リンク追加予定)

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

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

重要な用語

相対的に同じ順序

他のアイテムと相対的に同じ位置。

注記: たとえ、他のアイテムが元の順序から挿入されていたり削除されていたりしたとしても、アイテムは相対的に同じ順序になっていると考えられる。例えば、展開するナビゲーションメニューは詳細を示すレベルを追加して挿入することがあり、派生したナビゲーション部分が音声読み上げ順序の中に挿入される。

ウェブページ一式

共通の目的を共有し、同じコンテンツ制作者、グループ、あるいは組織により制作されたウェブページの集合。

注記: 異なる言語のバージョンは、違うウェブページ一式と見なされるであろう。

ウェブページ

HTTP によって単一の URI から得られる埋め込みではないリソースと、レンダリングに用いられたり、ユーザエージェントで一緒にレンダリングされる目的で用いられたりしているその他のリソース。

注記 1: どのような "その他のリソース" も第一のリソースと一緒にレンダリングされるであろうが、必ずしもお互いが同時にレンダリングされる必要があるわけではない。

注記 2: このガイドラインに適合する目的において、ウェブページと見なされる適合範囲内ではリソースは『埋め込みではない』ものでなければならない。

事例 1: すべての埋め込まれた画像とメディアを含んだウェブリソース。

事例 2: Ajaxを用いたウェブメールのプログラム。そのプログラムは http://example.com/mail に存在しているが、受信箱、アドレス帳、そしてカレンダーがある。受信箱、アドレス帳やカレンダーを起動するリンクあるいはボタンがあるが、ページ全体の URI は変わらない。

事例 3: カスタマイズ可能なポータルサイトで、利用者がさまざまなコンテンツのモジュール一式の中から表示させるコンテンツを選択できる。

事例 4: ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、ウェブサイトの中のほんの1ページなのかもしれない。


一貫した識別性:
達成基準 3.2.4 を理解する

3.2.4 一貫した識別性: ウェブページ一式の中で同じ機能性を有する構成要素は、一貫性を持たせて識別できるようになっている。 (レベル AA)

この達成基準の意図

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

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

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

  • サイトのあるページで機能を学習した利用者が、他のページにも同じ機能があれば見つけることができるようになる。

  • 同じ機能を持つコンポーネントを示すために非テキストコンテンツを一貫した方法で用いることで、テキストを読んだり、代替テキストを見つけるのが困難な利用者が、代替テキストを頼りにすることなく、ウェブコンテンツを利用することができるようになる。

  • 代替テキストを頼りにしている利用者が、コンポーネントをより予測できるようになる。別のページでもラベルが一貫していれば、そのコンポーネントを探し出すことができる。

達成基準 3.2.4 の事例

  • 事例 1: 文書のアイコン

    文書のアイコンを使って、サイト中にある文書のダウンロードを示している。そのアイコンの代替テキストは、どれも "ダウンロード" という単語で始まっていて、その後に文書のタイトルの短縮形が続いている。異なる代替テキストを用いてるが、異なる文書の異なるタイトルを示すのは、代替テキストを一貫して使用しているとみなされる。

  • 事例 2: チェックマーク

    チェックマークのアイコンが、あるページでは "承認済" という意味だが、別のページでは "あり" という意味で使われている。異なる意味で使われているので、代替テキストも異なっている。

  • 事例 3: 他のページへの一貫したリンクのラベル

    あるウェブサイトが、オンライン記事を発行している。各記事は複数のウェブページにわたっており、各ページには記事の最初のページ、次のページ、そして前のページへのリンクがある。もし、次のページへのリンクのラベルが、"ページ 1"、"ページ 2"、となっていたとしても、ラベルは同一ではないが、一貫しているといえる。そのため、こういったラベルは、この達成基準の不適合事例ではない。

  • 事例 4: 似たような機能のアイコン

    E-コマース・アプリケーションは、プリンタのアイコンを使って、利用者が領収書や請求書を印刷できることを示している。アプリケーションのある部分では、プリンタのアイコンは "領収書を印刷" というラベルが付いていて、領収書を印刷するために使われている。一方で、他の部分では "請求書を印刷" というラベルで、請求書を印刷するために使われている。 ラベルの付け方("~を印刷")は一貫しているが、アイコンの異なる機能を反映してラベルは異なっている。そのため、これはこの達成基準の不適合事例ではない。

  • 事例 5: 保存アイコン

    よくある "保存する" アイコンが、サイト中で使われていて、ページを保存する機能が複数のウェブページで提供されている。

  • 不適合事例

    あるウェブページにある "検索" ボタンと他のページにある "探す" ボタンには、どちらもキーワードを入力するテキストフィールドがあって、そのウェブサイトの中から入力したキーワードに関連するトピックを一覧表示している。この場合、ボタンは同じ機能を持っていながら、ラベルに一貫性がない。

達成基準 3.2.4 の実装方法及び不適合事例 - 一貫した識別性

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  1. G197: Using labels, names, and text alternatives consistently for content that has the same functionality AND following the 達成基準を満たすことのできる実装方法 for Success Criterion 1.1.1 and 達成基準を満たすことのできる実装方法 for Success Criterion 4.1.2 for providing labels, names, and text alternatives.

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

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

達成基準 3.2.4 でさらに対応が望まれる実装方法(参考)

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

  • Ensuring that the text alternative conveys the function of the component and what will happen when the user activates it (リンク追加予定)

  • Using the same non-text content for a given function whenever possible (リンク追加予定)

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

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

重要な用語

同じ機能性

使うと同じ結果が得られる。

事例: あるウェブページ上にある "検索" ボタンと他のウェブページ上にある "さがす" ボタンは、どちらもキーワードを入力するテキストフィールドがあり、そのウェブサイトにある入力されたキーワードに関係のあるコンテンツをリスト表示する。この場合、同じ機能性を有しながらも、ラベルは一貫していないことになる。

ウェブページ

HTTP によって単一の URI から得られる埋め込みではないリソースと、レンダリングに用いられたり、ユーザエージェントで一緒にレンダリングされる目的で用いられたりしているその他のリソース。

注記 1: どのような "その他のリソース" も第一のリソースと一緒にレンダリングされるであろうが、必ずしもお互いが同時にレンダリングされる必要があるわけではない。

注記 2: このガイドラインに適合する目的において、ウェブページと見なされる適合範囲内ではリソースは『埋め込みではない』ものでなければならない。

事例 1: すべての埋め込まれた画像とメディアを含んだウェブリソース。

事例 2: Ajaxを用いたウェブメールのプログラム。そのプログラムは http://example.com/mail に存在しているが、受信箱、アドレス帳、そしてカレンダーがある。受信箱、アドレス帳やカレンダーを起動するリンクあるいはボタンがあるが、ページ全体の URI は変わらない。

事例 3: カスタマイズ可能なポータルサイトで、利用者がさまざまなコンテンツのモジュール一式の中から表示させるコンテンツを選択できる。

事例 4: ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、ウェブサイトの中のほんの1ページなのかもしれない。


利用者の要求による状況の変化:
達成基準 3.2.5 を理解する

3.2.5 利用者の要求による状況の変化: 状況の変化は利用者の要求によってのみ生じる。あるいは、そのような変化を止めるメカニズムが利用可能である。 (レベル AAA)

この達成基準の意図

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

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

注記: リンクをクリックするのは、"利用者の要求によってだけ生じる" アクションの一例である。

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

  • 状況の変化を見つけることができない、又は状況が変化したことに気づかない利用者が、サイトをナビゲートしている間に混乱した状態になりにくい。例えば、次のような利用者が当てはまる:

    • 全盲の利用者、又はロービジョンの利用者は、新しいウィンドウがポップアップで開くなどのように、視覚的な状況の変化がいつ起こるのかを把握するのが困難なことがある。この場合、前もって利用者に状況の変化が起こることを知らせておくと、利用者が [戻る] ボタンがいつものように動作しないことに気づいたときの混乱を最小限に抑えることができる。

  • ロービジョンの利用者、読字及び知的障害のある利用者、そして視覚的な手がかりを解釈しづらい利用者は、コンテンツ制作者が手がかりを追加することによって、状況の変化に気づくようになる。

  • 自動的なリダイレクトを、ブラウザではなくウェブサーバによって行えば、認知限界のある利用者は混乱しないですむ。

達成基準 3.2.5 の事例

  • "いま更新する" ボタン

    コンテンツを自動的に更新するかわりに、コンテンツの更新を要求する "いま更新する" ボタンをコンテンツ制作者が提供している。

  • 自動リダイレクト

    リダイレクトが起こったことに絶対気づかない方法で、古いページから新しいページへ利用者が自動的にリダイレクトされる。

関連リソース

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

達成基準 3.2.5 の実装方法及び不適合事例 - 利用者の要求による状況の変化

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

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

状況 A: ウェブページが自動更新を行う場合:
  1. G76: Providing a mechanism to request an update of the content instead of updating automatically

状況 B: 自動リダイレクトが可能な場合:
  1. SVR1: Implementing automatic redirects on the server side instead of on the client side (SERVER)

  2. G110: Using an instant client-side redirect using one of the following techniques:

状況 C: ウェブページがポップアップウィンドウを用いる場合:
  1. 次の実装方法の一つを用いてポップアップウィンドウを出す:

状況 D: select 要素上で onchange イベントを用いる場合:
  1. SCR19: Using an onchange event on a select element without causing a change of context (Scripting)

達成基準 3.2.5 でさらに対応が望まれる実装方法(参考)

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

  • Opening new windows by providing normal hyperlinks without the target attribute (リンク追加予定), because many user agents allow users to open links in another window or tab.

  • Opening new windows only when best from an accessibility perspective (リンク追加予定)

重要な用語

状況の変化

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

Changes in context include changes of:

  1. ユーザエージェント

  2. ビューポート

  3. フォーカス

  4. ウェブページの意味を変えるコンテンツ

注記: コンテンツの変化が、常に状況の変化であるとは限らない。外枠を広げること、動的なメニュー、あるいはタブコントロールのように、コンテンツにおける小さな変化は、それが上記のいずれか(例:フォーカス)を変更しないかぎり、状況を変化させるものではない。

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

メカニズム

結果を得るためのプロセスあるいはテクニック。

注記 1:メカニズムは、コンテンツ内で明白に提供されることもあれば、あるいは、プラットフォームまたは支援技術を含むユーザエージェントのどちらかで提供されるものに依存することもある。

注記 2: メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。


入力支援:
ガイドライン 3.3 を理解する

ガイドライン 3.3: 利用者が間違えないようにしたり、間違いを修正したりするのを助ける。

ガイドライン 3.3 の意図

誰でもミスをすることがある。しかし、何らかの障害のある利用者は、エラーを起こさずに入力するのがより困難である。さらに、エラーを起こしたことに気づきづらいこともある。視野が限られている、色の知覚に限界がある、又は支援技術を使用しているという理由で、エラーを示す典型的な方法が障害のある利用者にとっては分かりにくいことがある。このガイドラインは、重大なエラー又は元の状態に戻すことのできないエラーの数を減らして、利用者がすべてのエラーに気づけるようにするとともに、エラーを修正するにはどうすべきかを利用者が分かるようにしようとするものである。

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

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

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

入力エラー箇所の特定:
達成基準 3.3.1 を理解する

3.3.1 入力エラー箇所の特定: 入力エラーを自動的に発見した場合は、エラーとなっているアイテムを特定し、そのエラーを利用者にテキストで説明する。 (レベル A)

この達成基準の意図

この達成基準の意図は、利用者がエラーの発生に気づき、何が誤っていたのかを見つけ出すことができるようにすることである。エラーメッセージは、できるかぎり具体的なものであるべきである。フォームの送信がうまくいかなかった場合に、フォームを再度表示して、エラーになっているテキストフィールドを示すだけでは、利用者がエラーの発生を知覚するには不十分である。例えば、スクリーンリーダーの利用者は、エラーを示す何かが読み上げられるまでは、エラーがあることに気づかない。すると、単にそのページに何か問題があるのだと考えて、エラーが発生していることに気づく前に、スクリーンリーダーの利用者はそのフォームの送信を完全にあきらめてしまうことがある。

ユーザエージェント又は支援技術がエラーを特定して、エラーに関する情報を利用者に提供することのできる、プログラム的な情報を用いて、エラーがあることを示して、その内容を説明することができる。例えば、あるウェブコンテンツ技術では、利用者の入力には文字数制限があること、又はフォームのテキストフィールドが必須項目であることが明示できる。最近では、このようなプログラム的な情報をサポートしているウェブコンテンツ技術は少ししかないが、この達成基準ではそういった情報の有無は問わない。

テキストによる説明に加えて、例えば画像や色などのその他の方法でエラーを示すことは全く問題ない。

「達成基準 3.3.3 入力エラー修正方法の提示」を理解するも参照のこと。

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

  • 入力エラーに関する情報をテキストで提供することによって、全盲の利用者又は色弱の利用者がエラーが発生したという事実を知覚できるようになる。

  • この達成基準は、アイコン及びその他の視覚的な手がかりが表現している意味を理解するのが困難な、認知障害、言語障害、及び学習障害のある利用者にも役立つことがある。

達成基準 3.3.1 の事例

  • フォーム送信におけるエラーの特定

    ある航空会社のウェブサイトが、ディスカウントされた便の特別なプロモーションを展開している。利用者は、氏名、住所、電話番号、座席指定、及び電子メールアドレスなどの個人情報をシンプルなフォームに入力することを求められる。フォームにあるテキストフィールドのいずれかが、入力されていないか入力に誤りがある場合、どのテキストフィールドが未入力又はエラーであることを利用者に知らせるアラートが表示される。

    注記: この達成基準は、エラー箇所を示すために、色又はテキストの表示スタイルを用いることができないという意味ではない。エラー箇所がテキストでも示されていることを単に要求しているだけである。この事例では、色に加えて、2つのアスタリスク(*)が用いられている。

  • 複数の手がかりの提供

    利用者がフォームにある2つのテキストフィールドに入力し忘れている。エラーの説明及びそのテキストフィールドを見つけやすくするためにエラーであることを示すものを提供するのに加えて、テキストフィールドを黄色で強調表示して、視覚的にも見つけやすくしている。

達成基準 3.3.1 の実装方法及び不適合事例 - 入力エラー箇所の特定

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

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

状況 A: フォームに入力が必須のテキストフィールドがある場合:
  1. G83: Providing text descriptions to identify required fields that were not completed

  2. SCR18: Providing client-side validation and alert (Scripting)

状況 B: 利用者の入力する情報が特定のデータ・フォーマット又は特定の値でなければならない場合:
  1. G84: Providing a text description when the user provides information that is not in the list of allowed values

  2. G85: Providing a text description when user input falls outside the required format or values

  3. SCR18: Providing client-side validation and alert (Scripting)

  4. SCR32: Providing client-side validation and adding error text via the DOM (Scripting)

達成基準 3.3.1 でさらに対応が望まれる実装方法(参考)

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

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

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

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

重要な用語

入力エラー

利用者が提供した情報で、受け付けられないもの。

注記: 以下のものが含まれる:

  1. ウェブページでは必須とされているが、利用者が入力し忘れた情報

  2. 利用者が入力したが、要求されたデータ形式あるいは値ではない情報


ラベル又は説明文:
達成基準 3.3.2 を理解する

3.3.2 ラベル又は説明文: コンテンツが利用者の入力を要求する際は、入力箇所のラベルまたは入力方法の説明文を提供する。 (レベル A)

この達成基準の意図

この達成基準の意図は、利用者が入力を求められた際にミスをしないようにすることである。ミスをしないようにするためには、情報を入力するためのシンプルな説明文と手がかりを提供することが、ユーザインタフェースのよいデザインである。障害のある利用者は、障害のない利用者よりもミスをしてしまうことが多かったり、エラーを修正するのがより困難であったりするため、ミスをしないようにすることは障害のある利用者に対しては重要なことである。障害のある利用者は、ページと情報のやりとりをする際に、十分に文書化されたフォーム及び手順を頼りにしている。例えば、全盲の利用者は、どんな情報をテキストフィールドに入力すべきなのか、そしてどんな選択肢があるのかを正確に知る必要がある。フォームのコントロールに視覚的に関連付けられているシンプルな説明文は、認知障害のある利用者又は画面拡大ソフトを使用している利用者の役に立つ。

この達成基準の意図は、不要な情報でページを散らかしてしまうことではなく、障害のある利用者に役立つ重要な手がかり及び説明文を提供することである。情報又は説明文が多すぎると、それは単に邪魔なものでしかない。目標とすべきなのは、利用者の混乱を最小限に抑えて、必要以上のナビゲーションを提供することなく、利用者がタスクを完了するために十分な情報を提供することである。

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

  • label 要素を用いて input 要素とラベルを関連付けることによって、テキストフィールドがフォーカスを受け取ると、スクリーンリーダーがそのテキストフィールドのラベルを読み上げるようになる。

  • 関連付けられたテキストフィールドのすぐ近くにラベルを置くことによって、画面拡大ソフトの利用者にとっては、そのテキストフィールド及びラベルがページを拡大した画面内に収まりやすくなる。

  • 所定のデータ・フォーマットの例を提供することは、認知障害、言語障害、及び学習障害のある利用者が情報を正確に入力するのに役立つ。

  • 必須項目をはっきりと示すことによって、キーボードだけで操作している利用者が、不完全なままフォームを送信して、再度表示されたフォームをナビゲートし、未入力だったテキストフィールドを見つけ出してから情報を入力することを回避できるようになる。

達成基準 3.3.2 の事例

  • テキストフィールドがあり、利用者に米国の州名を2文字の略語で入力するように求めている。そのテキストフィールドにはリンクがあり、ポップアップウィンドウを開いて、アルファベット順に並んだ州名と略語の一覧を提供している。

  • 日付を入力するテキストフィールドに、その日付の正確なフォーマットを示す頭文字がある。

  • 名を入力するテキストフィールドが "名" というラベルではっきりと示されていて、姓を入力するテキストフィールドには "姓" というラベルがあり、利用者がどちらを入力すべきなのか迷わないようにしている。

  • 米国の電話番号が、エリアコード、局番、そして番号の3つのテキストフィールドに分かれている。エリアコードのテキストフィールドには括弧が付いていて、局番と番号のテキストフィールドの間にはハイフンが入っている。その句読法は、米国の電話番号フォーマットに馴染みのある利用者には視覚的な手がかりを提供していることになるが、テキストフィールドのラベル付けとしては句読法だけでは不十分である。また、"電話番号" という一つのラベルも、3つのテキストフィールドすべてをラベル付けすることはできない。これに対処するために、3つのテキストフィールドを fieldset 要素でグループ化して、legend 要素で "電話番号" というラベルを付けている。さらに、テキストフィールドに(句読法に加えて)視覚的なラベルを提供することはデザイン上不可能なので、title 属性を用いて、3つのテキストフィールドそれぞれに視覚的には認識できないラベルを提供している。3つのテキストフィールドそれぞれの属性値は、"エリアコード"、"局番"、そして "番号" となっている。

関連リソース

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

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

達成基準 3.3.2 の実装方法及び不適合事例 - ラベル又は説明文

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

達成基準 3.3.2 でさらに対応が望まれる実装方法(参考)

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

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

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

重要な用語

ラベル

ウェブコンテンツにある構成要素を識別するために、利用者に提示されているテキスト、あるいは代替テキストのある構成要素。

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

注記 2: ラベルという用語は、HTML における label 要素だけに限定されない。


入力エラー修正方法の提示:
達成基準 3.3.3 を理解する

3.3.3 入力エラー修正方法の提示: 入力エラーを自動的に発見した場合は、その修正方法が明らかであれば、その方法を利用者に提示する。ただし、セキュリティあるいはコンテンツの目的を損なう場合は除く。 (レベル AA)

この達成基準の意図

この達成基準の意図は、可能であれば、利用者が入力エラーを修正するのに適切な修正方法を入手できるようにすることである。

達成基準 3.3.1 は、入力エラー箇所を通知するためのものである。しかし、例えば、認知限界のある利用者は、入力エラーの修正方法を理解するのが困難なことがある。視覚障害のある利用者は、入力エラーの修正方法を正確に把握することができないことがある。フォーム送信がうまくいかなかった場合、利用者はエラーが発生したことには気づいていたとしても、そのエラーを修正する方法が分からないために、そのフォームを途中であきらめてしまうかもしれない。

コンテンツ制作者はエラー箇所を説明することができる、又はユーザエージェントがウェブコンテンツ技術特有のプログラムで判断できる情報に基づいてエラー箇所を説明できる。

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

  • 入力エラーを修正する方法に関する情報を提供することによって、学習障害のある利用者がフォームに問題なく入力できるようになる。そして、全盲の利用者又は視覚に障害のある利用者が、入力エラーの内容及びその修正方法をもっと容易に理解できるようになる。また、運動障害のある利用者は、入力内容を変更する必要のある回数を減らすことができる。

達成基準 3.3.3 の事例

  • 入力エラーを修正するためのヘルプの追加

    うまく送信されなかったフォームのエラー画面で、そのページで起こった入力エラーを正しい入力方法とあわせて説明していて、入力エラーになったテキストフィールドのヘルプを追加で提供している。

  • 限定された値の提示

    月の名前を入力するテキストフィールドがある。利用者が "12" と入力すると、修正する方法が提示される。

    • 入力可能な値の一覧。例えば、"どれか一つを選んでください: January, February, March, April, May, June, July, August, September, October, November, December"。

    • 入力すべき値を説明する。例えば、"月の名前を入力してください。"

    • 入力されたデータを異なるフォーマットに変換して提示する。例えば、"もしかして 'December' ですか ?"

関連リソース

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

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

達成基準 3.3.3 の実装方法及び不適合事例 - 入力エラー修正方法の提示

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

注記:In some cases, more than one of these situations may apply. For example, when a mandatory field also requires the data to be in a specific format.

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

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

状況 A: 必須項目に情報がない場合:
  1. G83: Providing text descriptions to identify required fields that were not completed

状況 B: 特定のデータフォーマットで情報を入力する必要がある場合:
  1. G85: Providing a text description when user input falls outside the required format or values

  2. G177: Providing suggested correction text

  3. SCR18: Providing client-side validation and alert (Scripting)

  4. SCR32: Providing client-side validation and adding error text via the DOM (Scripting)

状況 C: 利用者の入力する情報の値が限定されている場合:
  1. G84: Providing a text description when the user provides information that is not in the list of allowed values

  2. G177: Providing suggested correction text

  3. SCR18: Providing client-side validation and alert (Scripting)

  4. SCR32: Providing client-side validation and adding error text via the DOM (Scripting)

達成基準 3.3.3 でさらに対応が望まれる実装方法(参考)

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

  • G139: Creating a mechanism that allows users to jump to errors

  • Making error messages easy to understand and distinguishable from other text in the Web page (リンク追加予定)

  • Validating form submissions on the server (リンク追加予定)

  • When mandatory information has not been provided, including descriptions or examples of correct information in addition to identifying the field as mandatory (リンク追加予定)

  • Repeating and emphasizing suggestions for correcting each input error in the context of its form field (リンク追加予定)

  • Providing a way for the user to skip from each item in a list of suggestions to its corresponding form field (リンク追加予定)

  • Providing additional contextual help for the form field requiring change (リンク追加予定)

  • Accepting input data in a variety of formats (リンク追加予定)

  • G199: Providing success feedback when data is submitted successfully

利用者にアドバイスを提供するための実装方法:(参考)
  • Providing a text description that contains information about the number of input errors, suggestions for corrections to each item, and instructions on how to proceed (リンク追加予定)

  • Providing a text description that contains suggestions for correction as the first item (or one of the first items) of content, or emphasizing this information in the content(リンク追加予定)

  • Displaying errors and suggestions in the context of the original form (for example, re-displaying a form where input errors and suggestions for correction are highlighted and displayed in the context of the original form) (リンク追加予定)

HTML の実装方法(参考)
  • Providing "correct examples" for data and data formats as initial text in mandatory form fields (リンク追加予定)

  • Providing links to suggested correction text "close to" form fields, or providing the suggested correction text itself directly on the Web page "next to" form fields (リンク追加予定)

クライアントサイド・スクリプティングの実装方法(参考)
  • SCR18: Providing client-side validation and alert (Scripting)

  • Providing client-side validation and adding error text via the DOM (リンク追加予定)

  • Calling a function from the submit action of a form to perform client side validation (リンク追加予定)

WAI-ARIA の実装方法(参考)

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

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

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

重要な用語

入力エラー

利用者が提供した情報で、受け付けられないもの。

注記: 以下のものが含まれる:

  1. ウェブページでは必須とされているが、利用者が入力し忘れた情報

  2. 利用者が入力したが、要求されたデータ形式あるいは値ではない情報


法的義務・金銭的取引・データ変更・回答送信のエラー回避:
達成基準 3.3.4 を理解する

3.3.4 法的義務・金銭的取引・データ変更・回答送信のエラー回避: 利用者にとって法的な義務または金銭的な取引が生じる、データのストレージシステムにある利用者が自分で管理可能なデータを変更または削除する、あるいは利用者が試験の回答を送信するウェブページでは、次の少なくとも1つが当てはまる (レベル AA):

  1. 可逆性: 送信は元に戻すことができる。

  2. チェック可能: 利用者の入力したデータの入力エラーをチェックし、利用者に修正する機会を提供している。

  3. 確認可能: 送信を完了する前に、利用者が情報の点検、確認および修正をするメカニズムが利用可能である。

この達成基準の意図

この達成基準の意図は、障害のある利用者が元の状態に戻すことのできないタスクを行った際、ミスをしたことによる重大な結果を未然に防ぐことができるようにすることである。例えば、払い戻し不可の航空券の購入、又は証券取引口座での株購入の注文は、重大な結果につながる金銭的な取引である。利用者が発着日を間違えれば、その利用者は交換することができない誤った日付の航空券を購入したことになってしまう。利用者が購入する株式数を間違えると、考えていた数よりも多くの株式を購入したことになってしまう。どちらのミスも、すぐに処理される取引であり、後から変更することはできないものであり、また非常に高価である。同じように、旅行サービスのウェブサイトにある旅行履歴のように、後から使用する必要のあるデータベースのデータを無意識に修正又は削除してしまった場合、そのエラーを元の状態には戻せないことがある。また、試験のデータもこの達成基準に当てはまる。なぜなら、試験を有効にするために、利用者は一度送信した回答を修正することができないからである。そのため、利用者が自分の送信内容に誤りがないかどうかを確認できるようにする必要がある。

障害のある利用者は、ミスをしてしまう可能性が高い。読字障害のある利用者は、数字と文字を間違えてしまうことがあるし、運動障害のある利用者は間違ってキーを押してしまうことがある。元の状態に戻せるようにすることによって、利用者が重大な結果につながる恐れのあるミスを修正できるようになる。また、入力内容を確認して修正できるようにすることで、重大な結果につながることをしてしまう前に、利用者がミスに気づくことができるようになる。

利用者が自分で制御可能なデータというのは、利用者がアクセスすることを想定したデータのことを指す(例えば、利用者アカウントの氏名、住所など)。アクセスログ及び検索エンジンの監視データのようなものを指すわけではない。

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

  • ミスによる重大な結果を未然に防ぐ手段を提供することによって、ミスをする可能性の高い障害のある利用者すべてに役立つ。

達成基準 3.3.4 の事例

  • 注文内容確認

    ある小売店がウェブでオンラインショッピングのサービスを顧客に提供している。注文が申し込まれると、利用者が注文内容に間違いがないかを確認できるように、注文した商品、各商品の数、送り先の住所、支払方法などの注文情報が表示される。利用者は、注文内容を確認したり、変更したりすることができる。

  • 株売買

    ある金融サービスのウェブサイトで、利用者は株をオンラインで売買できる。利用者が株の売買の注文を出すと、システムは市場が開いているかどうかを確認する。時間外だった場合は、利用者にその取引が時間外取引になることを知らせて、通常の取引時間外であることのリスクについても伝える。そして、利用者はその注文をキャンセルするか、確認することができる。

関連リソース

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

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

達成基準 3.3.4 の実装方法及び不適合事例 - 法的義務・金銭的取引・データ変更・回答送信のエラー回避

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

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

状況 A: アプリケーションで、購入又は所得税申告の提出のように、法的なトランザクションが発生する場合:
  1. G164: Providing a stated period of time after submission of the form when the order can be updated or canceled by the user

  2. G98: Providing the ability for the user to review and correct answers before submitting

  3. G155: Providing a checkbox in addition to a submit button

状況 B: 利用者のアクションによって情報が削除される可能性がある場合:
  1. G99: Providing the ability to recover deleted information

  2. G168: Requesting confirmation to continue with selected action

  3. G155: Providing a checkbox in addition to a submit button

状況 C: ウェブページに試験を実施するアプリケーションがある場合:
  1. G98: Providing the ability for the user to review and correct answers before submitting

  2. G168: Requesting confirmation to continue with selected action

達成基準 3.3.4 でさらに対応が望まれる実装方法(参考)

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

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

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

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

重要な用語

入力エラー

利用者が提供した情報で、受け付けられないもの。

注記: 以下のものが含まれる:

  1. ウェブページでは必須とされているが、利用者が入力し忘れた情報

  2. 利用者が入力したが、要求されたデータ形式あるいは値ではない情報

法的な義務

法的に拘束力のある義務あるいは利益が発生する取引。

事例: 結婚許可証、株取引(金銭上および法的)、遺言、ローン、採用、軍隊への入隊登録、あらゆる契約、など

メカニズム

結果を得るためのプロセスあるいはテクニック。

注記 1:メカニズムは、コンテンツ内で明白に提供されることもあれば、あるいは、プラットフォームまたは支援技術を含むユーザエージェントのどちらかで提供されるものに依存することもある。

注記 2: メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。

利用者が自分で管理可能

利用者がアクセスすることを目的にしたデータ。

注記: これは、インターネットのログや検索エンジンの監視データのようなものは指していない。

事例: 利用者アカウントのための氏名と住所のフィールド。

ウェブページ

HTTP によって単一の URI から得られる埋め込みではないリソースと、レンダリングに用いられたり、ユーザエージェントで一緒にレンダリングされる目的で用いられたりしているその他のリソース。

注記 1: どのような "その他のリソース" も第一のリソースと一緒にレンダリングされるであろうが、必ずしもお互いが同時にレンダリングされる必要があるわけではない。

注記 2: このガイドラインに適合する目的において、ウェブページと見なされる適合範囲内ではリソースは『埋め込みではない』ものでなければならない。

事例 1: すべての埋め込まれた画像とメディアを含んだウェブリソース。

事例 2: Ajaxを用いたウェブメールのプログラム。そのプログラムは http://example.com/mail に存在しているが、受信箱、アドレス帳、そしてカレンダーがある。受信箱、アドレス帳やカレンダーを起動するリンクあるいはボタンがあるが、ページ全体の URI は変わらない。

事例 3: カスタマイズ可能なポータルサイトで、利用者がさまざまなコンテンツのモジュール一式の中から表示させるコンテンツを選択できる。

事例 4: ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、ウェブサイトの中のほんの1ページなのかもしれない。


ヘルプ:
達成基準 3.3.5 を理解する

3.3.5 ヘルプ: 状況に応じたヘルプが利用可能である。 (レベル AAA)

この達成基準の意図

この達成基準の意図は、利用者がミスをしないようにすることである。障害のある利用者は、障害のない利用者よりもミスをする可能性が高い。状況に応じたヘルプを提供することによって、利用者は自分がやっていることを失うことなく操作をする方法を確かめることができる。

状況に応じたヘルプは、ラベルがすべての機能を説明するのに不十分なときにだけ提供すればよい。状況に応じたヘルプが提供されていることは、利用者に対してはっきりと示すべきで、利用者が必要とするときにはいつでもヘルプを利用できるようにしなければならない。

コンテンツ制作者は、ヘルプの文章を提供することができる、又はユーザエージェントがウェブコンテンツ技術特有のプログラムで判断できる情報に基づいてヘルプの文章を提供することができる。

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

  • テキスト入力のヘルプを提供することによって、フォーム又はテキスト入力を必要とするその他のコンテンツでテキストを書くのが困難なことがよくある、書字障害のある利用者及び読字障害、知的障害のある利用者に役立つ。

  • さらに、このようなヘルプによる支援は、加齢によって、テキスト入力及び/又はマウス操作に同じような困難を伴う利用者にも役立つ。

達成基準 3.3.5 の事例

  • オンライン求職

    新規の利用者にとっては分かりにくい質問がいくつかある。各質問の横にあるヘルプのリンクが、その質問の説明を提供している。

関連リソース

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

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

達成基準 3.3.5 の実装方法及び不適合事例 - ヘルプ

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

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

状況 A: フォームがテキスト入力を求める場合:
  1. G71: Providing a help link on every Web page

  2. G193: Providing help by an assistant in the Web page

  3. G194: Providing spell checking and suggestions for text input

  4. G184: Providing text instructions at the beginning of a form or set of fields that describes the necessary input

状況 B: フォームが所定のデータフォーマットでのテキスト入力を求める場合:
  1. G89: Providing expected data format and example

  2. G184: Providing text instructions at the beginning of a form or set of fields that describes the necessary input

達成基準 3.3.5 でさらに対応が望まれる実装方法(参考)

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

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

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

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

重要な用語

状況に応じたヘルプ

そのとき実行されている機能に関する情報を提供するヘルプのテキスト。

注記: 明解なラベルは、状況に応じたヘルプとして機能しうる。


あらゆるエラー回避:
達成基準 3.3.6 を理解する

3.3.6 あらゆるエラー回避: 利用者に情報の送信を要求するウェブページでは、次の少なくとも1つが当てはまる (レベル AAA):

  1. 可逆性: 送信は元に戻すことができる。

  2. チェック可能: 利用者の入力したデータの入力エラーをチェックし、利用者に修正する機会を提供している。

  3. 確認可能: 送信を完了する前に、利用者が情報の点検、確認および修正をするメカニズムが利用可能である。

この達成基準の意図

この達成基準の意図は、障害のある利用者が、フォームのデータを送信するときにミスをしたことに起因する重大な結果を未然に防ぐことができるようにすることである。この達成基準は、利用者が情報を送信する必要のあるフォームすべてに適用されるという点において、達成基準 3.3.4 よりも上のレベルである。

障害のある利用者は、ミスをしてしまう可能性が高く、フォームでのエラーに気づく又は修正するのにも困難を伴うことが多い。例えば、読字障害のある利用者は、数字と文字を間違えてしまうことがある。そして、運動障害のある利用者は間違ってキーを押してしまうことがある。元の状態に戻せるようにすることによって、利用者がエラーを修正することができるようになる。また、情報を確認して修正できるようにすることによって、利用者はフォームのデータを送信する前にエラーに気づくことができる。

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

  • ミスによる重大な結果を未然に防ぐ手段を提供することによって、ミスをする可能性の高い障害のある利用者すべてに役立つ。

達成基準 3.3.6 の実装方法及び不適合事例 - エラー回避

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  1. Following the 達成基準を満たすことのできる実装方法 for Success Criterion 3.3.4 for all forms that require the user to submit information.

重要な用語

入力エラー

利用者が提供した情報で、受け付けられないもの。

注記: 以下のものが含まれる:

  1. ウェブページでは必須とされているが、利用者が入力し忘れた情報

  2. 利用者が入力したが、要求されたデータ形式あるいは値ではない情報

メカニズム

結果を得るためのプロセスあるいはテクニック。

注記 1:メカニズムは、コンテンツ内で明白に提供されることもあれば、あるいは、プラットフォームまたは支援技術を含むユーザエージェントのどちらかで提供されるものに依存することもある。

注記 2: メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。

ウェブページ

HTTP によって単一の URI から得られる埋め込みではないリソースと、レンダリングに用いられたり、ユーザエージェントで一緒にレンダリングされる目的で用いられたりしているその他のリソース。

注記 1: どのような "その他のリソース" も第一のリソースと一緒にレンダリングされるであろうが、必ずしもお互いが同時にレンダリングされる必要があるわけではない。

注記 2: このガイドラインに適合する目的において、ウェブページと見なされる適合範囲内ではリソースは『埋め込みではない』ものでなければならない。

事例 1: すべての埋め込まれた画像とメディアを含んだウェブリソース。

事例 2: Ajaxを用いたウェブメールのプログラム。そのプログラムは http://example.com/mail に存在しているが、受信箱、アドレス帳、そしてカレンダーがある。受信箱、アドレス帳やカレンダーを起動するリンクあるいはボタンがあるが、ページ全体の URI は変わらない。

事例 3: カスタマイズ可能なポータルサイトで、利用者がさまざまなコンテンツのモジュール一式の中から表示させるコンテンツを選択できる。

事例 4: ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、ウェブサイトの中のほんの1ページなのかもしれない。


互換性:
ガイドライン 4.1 を理解する

ガイドライン 4.1: 現在及び将来のユーザエージェントとの互換性を最大化する。

ガイドライン 4.1 の意図

このガイドラインの目的は、現在及び将来のユーザエージェント、特に支援技術との互換性をサポートすることである。そのためには、1)コンテンツ制作者が支援技術の機能を損なうようなこと(例: 形式が整えられていないマークアップ)、又は支援技術をだますようなこと(例:奇抜なマークアップ又はソースコードを用いる)をしないようにする。そして、2)支援技術が認識して情報のやりとりができる標準的な方法によって、コンテンツにある情報を支援技術に引き渡すようにする。ウェブコンテンツ技術はすぐに変化し、支援技術の開発者が急速に変化するウェブコンテンツ技術についていくのはとても大変なことなので、支援技術がもっと容易に新しいウェブコンテンツ技術にも対応していけるように、コンテンツが規則に従っていて互換性があることが重要である。

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

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

  • Avoiding deprecated features of W3C technologies (リンク追加予定)

  • Not displaying content that relies on technologies that are not accessibility-supported when the technology is turned off or not supported.

構文解析:
達成基準 4.1.1 を理解する

4.1.1 構文解析: マークアップ言語を用いて実装されているコンテンツにおいては、仕様で認められているものを除いて、要素には完全な開始タグおよび終了タグがあり、要素は仕様に準じて入れ子になっていて、要素には重複した属性がなく、どのIDも固有である。 (レベル A)

注記:閉じる山括弧(">")や不一致な属性値の引用符のように、その記述において重要な文字のない開始および終了タグは完全ではない。

この達成基準の意図

この達成基準の意図は、支援技術を含むユーザエージェントが、コンテンツを正確に解釈して解析できるようにすることである。コンテンツをデータ構造として解析できない場合、ユーザエージェントが異なればそのコンテンツの提示のされ方も異なったものになる、又はユーザエージェントがコンテンツを全く解析できない。ユーザエージェントの中には、独自の "修復技術" を用いて品質の低いソースコードのコンテンツをレンダリングするものもある。

修復技術はユーザエージェントによって異なるため、もしコンテンツがそのウェブコンテンツ技術の正式な文法で定義されている規則に従って制作されていなければ、コンテンツ制作者は、コンテンツはデータ構造として正確に解析される、又は支援技術を含む特殊なユーザエージェントによって正しくレンダリングされるものだと考えることはできない。マークアップ言語においては、要素及び属性における構文エラー、及び開始タグと終了タグを適切に入れ子にしていないことによって、ユーザエージェントがコンテンツを確実に解析できないというエラーにつながる。そのため、この達成基準では、コンテンツが正式な文法の規則のみを用いて解析できることを要件としている。

注記: "整形式(well formed)" という概念は、この達成基準で要件としていることに近い。しかし、正確な解析に求められる要件は、マークアップ言語によって異なる。そして、ほとんどの非 XML ベース言語は整形式であることの要件を明確には定義していない。そこで、マークアップ言語に一般的に適用可能にするために、この達成基準ではより細部まではっきりと述べる必要があった。"整形式(well formed)" という用語は XML で定義されているだけで、有効(valid)な HTML は整形式のソースコードを要求していない(終了タグは任意の場合もある)ため、この達成基準では "整形式(well formed)" という用語を用いていない。

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

  • ウェブページに完全な開始タグ及び終了タグがあり、仕様に準じて入れ子になっているようにすることで、支援技術がコンテンツを問題なく正確に解析できるようになる。

達成基準 4.1.1 の事例

関連リソース

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

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

達成基準 4.1.1 の実装方法及び不適合事例 - 構文解析

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

  1. G134: Validating Web pages

  2. G192: Fully conforming to specifications

  3. H88: Using HTML according to spec

  4. Ensuring that Web pages can be parsed by using one of the following techniques:

達成基準 4.1.1 でさらに対応が望まれる実装方法(参考)

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

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


プログラムで解釈可能な識別名・役割及び設定可能な値:
達成基準 4.1.2 を理解する

4.1.2 プログラムで解釈可能な識別名・役割及び設定可能な値: すべてのユーザインタフェース要素(フォーム要素、リンク、そしてスクリプトが生成するコンポーネントなどを含む)では、識別名および役割プログラムで解釈可能である。また、利用者が設定可能なステータス、プロパティ、そして値はプログラムで設定できる。そして、支援技術を含むユーザエージェントがこれらの項目が変更された通知を受け取ることができる。 (レベル A)

注記:この達成基準は、主に独自のユーザインタフェース要素を開発したりスクリプトを書いたりするコンテンツ制作者に向けたものである。例えば、標準的なHTMLのコントロールは、仕様に準じていればそれで既にこの達成基準を満たしていることになる。

この達成基準の意図

この達成基準の意図は、支援技術がコンテンツにあるユーザインタフェース・コントロールのステータスに関する情報を収集する、選択された状態にする(又は設定する)、そして最新の状態にしておくことができるようにする。

アクセシブルなウェブコンテンツ技術の標準的なコントロールを使用している際は、このプロセスはごく簡単である。ユーザインタフェース要素を仕様に準じて使用していれば、この達成基準には適合したことになる(以下にある、達成基準 4.1.2 の事例を参照のこと)

しかし、独自のコントロールを作成する場合、インタフェース要素には通常とは異なる役割、及び/又は機能を持たせるように(ソースコード又はスクリプト内に)プログラムされているため、コントロールが重要な情報を支援技術へ提供し、支援技術がそのコントロールを制御できるようにする手段を追加する必要がある。

ユーザインタフェース・コントロールの特に重要なステータスは、フォーカスがあるかどうかである。コントロールにフォーカスがあるステータスは、プログラムで判断することが可能であり、フォーカスの変化に関する通知がユーザエージェント及び支援技術に送られる。ユーザインタフェース・コントロールのステータスのその他の例としては、チェックボックス又はラジオボタンが選択されているかどうか、又は折り畳み可能なツリーあるいはリストが展開されているか折り畳まれているか、というのが挙げられる。

注記: 達成基準 4.1.2 は、すべてのユーザインタフェース・コンポーネントに対して、プログラムで判断可能な識別名を要求している。識別名は、視覚的に認識できたり、できなかったりする。識別名が視覚的に認識できなければならないときがある。それは、識別名がラベルの役割も果たすような場合である。より詳しい情報については、用語集にある識別名及びラベルの定義を参照のこと。

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

  • すべてのユーザインタフェース・コンポーネントに、役割、ステータス、及び値の情報を提供することによって、例えば、スクリーンリーダー、画面拡大ソフト、及び音声認識ソフトウェアなどのように、障害のある利用者が使用している支援技術との互換性を保つことができるようになる。

達成基準 4.1.2 の事例

達成基準 4.1.2 の実装方法及び不適合事例 - プログラムで解釈可能な識別名・役割及び設定可能な値

この節にある番号付の項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する実装方法、又は複数の実装方法の組合せを表している。WCAG 2.0 適合要件のすべてが満たされているならば、次に挙げる実装方法により、この達成基準だけを満たすことができる。

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

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

状況 A: マークアップ言語(例: HTML)で標準的なユーザインタフェース・コンポーネントを使用している場合:
  1. G108: Using markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes using technology-specific techniques below:

状況 B: マークアップ言語でスクリプト又はソースコードを用いて、標準的なユーザインタフェース・コンポーネントに再度目的を持たせる場合:
  1. Exposing the names and roles, allowing user-settable properties to be directly set, and providing notification of changes using one of the following techniques:

状況 C: プログラミング技術で標準的なユーザインタフェース・コンポーネントを用いる場合:
  1. G135: Using the accessibility API features of a technology to expose names and roles, to allow user-settable properties to be directly set, and to provide notification of changes

状況 D: プログラミング言語で独自のインタフェース・コンポーネントを作成する場合:
  1. G10: Creating components using a technology that supports the accessibility API features of the platforms on which the user agents will be run to expose the names and roles, allow user-settable properties to be directly set, and provide notification of changes

達成基準 4.1.2 でさらに対応が望まれる実装方法(参考)

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

  • Providing labels for all form controls that do not have implicit labels (リンク追加予定)

重要な用語

(この文書で用いられている)支援技術

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

注記 1: 代替のプレゼンテーション(例:合成音声や拡大表示したコンテンツ)、代替入力手法(例:音声認識)、付加的なナビゲーションあるいは位置確認のメカニズム、およびコンテンツ変換(例:テーブルをよりアクセシブルにするもの)を含めて支援技術により提供される機能。

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

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

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

  • 画面拡大ソフトおよびその他の視覚的な表示に関する支援技術。視覚障害、知覚障害、および読書困難などの障害のある人が、レンダリング後のテキストおよび画像の視覚的な読みやすさを改善するために、テキストのフォント、サイズ、間隔、色、音声との同期などを変更するのに使用している。

  • スクリーンリーダー。全盲の人がテキスト情報を合成音声あるいは点字で読み取るために使用している。

  • 音声変換ソフトウェア。認知障害、言語障害、および学習障害のある人が、テキストを合成音声に変換するために使用している。

  • 音声認識ソフトウェア。何らかの身体障害のある利用者が使用することがある。

  • 代替キーボード。特定の身体障害のある人がキーボードを擬似操作するのに使用している(ヘッドポインタ、シングルスイッチ、呼気・吸気スイッチ、およびその他の特別な入力デバイスを使った代替キーボードを含む)。

  • 代替ポインティングデバイス。特定の身体障害のある人がマウスポインタとボタンを擬似操作するのに使用している。

識別名

ソフトウェアがウェブコンテンツ内の構成要素を利用者に識別させることのできるテキスト

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

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

プログラムで解釈(プログラムで解釈可能)

コンテンツ制作者が提供したデータからソフトウェアが解釈できること。また、その際に、支援技術を含むさまざまなユーザエージェントが、この情報を抽出して利用者にさまざまなモダリティで提示できること。

事例 1: マークアップ言語では、一般に入手可能な支援技術が、要素および属性に直接アクセスすることにより解釈できる。

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

プログラムで設定

支援技術を含むユーザエージェントがサポートしている手法を用いてソフトウェアが設定する。

役割

ソフトウェアがウェブコンテンツにある構成要素の機能を識別できるためのテキストあるいは数字。

事例: 画像が、ハイパーリンク、コマンドボタン、あるいはチェックボックスのどれなのかを示している数字。

ユーザエージェント

ウェブコンテンツを抽出して利用者に提示するあらゆるソフトウェア。

事例: ウェブコンテンツの抽出、レンダリング、そしてインタラクションを支援する、ウェブブラウザ、メディアプレーヤー、プラグイン、およびその他のプログラムで、支援技術も含まれる。

利用者インターフェース要素

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

注記 1: 複数の利用者インターフェース要素が単一のプログラム的要素として実装されることがある。ここでいう要素は、プログラミングテクニックではなく、別々のコントロールとして利用者が知覚するものを指す。

注記 2: 利用者インターフェース要素には、スクリプトで生成されるコンポーネントやフォーム要素、リンクが含まれる。

事例: アプレットには、コンテンツ内を行ごと、ページごと、あるいはランダムに移動するために用いられる "コントロール" がある。これらはどれも識別名があり、個別に設定可能なので、それぞれが "利用者インターフェース要素" となる。


WCAG 2.0への適合を理解する

すべての WCAG 2.0 の達成基準は、客観的にコンテンツがその基準を満たしているかどうかを判断できるように、テスト可能な基準として記述されている。達成基準のテストには、自動的なテスティングと人間による判断の組合せを必要とする。コンテンツをテストするのは、さまざまな障害のある人がウェブをどのように使っているのかを理解している人でなければならない。

ここでいうテスティングやテスト可能というのは、機能面のテスティングのことを指している。つまり、コンテンツが想定していた通りに機能することを確認するということである。あるいは、ここでは、達成基準を満たしていることを確認するといってもよい。コンテンツはすべての達成基準を満たすことができるが、それでもさまざまな障害のある利用者がそのコンテンツを使うことができるとは限らない。そのため、必要とされる機能面のテスティングに加えて、利用者ビリティ・テスティングを実施することも推奨している。利用者ビリティ・テスティングの目的は、利用者がコンテンツの想定した目的に沿ってそのコンテンツをどこまで使うことができるかを確認することである。ゆえに、利用者ビリティ・テスティングを実施する際には、テスト参加者に障害のある利用者を含めることを推奨する。

適合とは何を意味するのか?

一般的に、基準への適合とは、その基準の「要件」に適合している、あるいは満たしていることを意味する。WCAG 2.0 において、「要件」となるのは達成基準である。WCAG 2.0に適合するためには、達成基準を満たす必要がある。つまり、達成基準に反するコンテンツがないということである。

注記:ある達成基準が適用されるコンテンツがない場合、その達成基準は満たされているということを意味する。

ほとんどの基準には、適合レベルは一つしかない。しかし、より高いレベルのアクセシビリティを要求したり可能にしたりするさまざまな状況に対処するために、WCAG 2.0 には3つの適合レベルがあり、そのため達成基準にも3つのレベルがある。

適合要件を理解する

コンテンツが WCAG 2.0 に「適合している」とみなされるためには、満たさなければならない5つの要件がある。この節では、それらの要件に関する簡単な注釈を提供する。なお、この節は、今後寄せられる質問に対処するため、あるいはさまざまな適合要件を満たす方法の新しい事例を提供するために、時間とともに拡充されていく予定である。

「適合要件 1」を理解する

1. 適合レベル: 以下に挙げる適合レベルの1つが完全に満たされていること。

  • レベル A: レベル A(適合の最低レベル)で適合するには、ウェブページがすべてのレベル A 達成基準を満たすか、あるいは適合した代替バージョンを提供する。

  • レベル AA: レベル AA で適合するには、ウェブページはすべてのレベル A およびレベル AA 達成基準を満たすか、あるいはレベル AA に適合した代替バージョンを提供する。

  • レベル AAA: レベル AAA で適合するには、ウェブページがすべてのレベル A、レベル AA、およびレベル AAA 達成基準を満たすか、あるいはレベル AAA に適合した代替バージョンを提供する。

注記 1: 適合には宣言したレベルのみを達成すればよいが、コンテンツ制作者は、達成した適合レベルよりも上のレベルの達成基準にも適合していれば、その達成基準すべてを(その適合宣言の中で)報告することを推奨する。

注記 2: レベル AAA 適合をサイト全体の基本的なポリシーとして要求することは推奨しない。なぜなら、コンテンツによっては、レベル AAA の達成基準をすべて満たすことができないからである。

最初の要件は、適合レベルに関するものである。基本的には、ページ上のすべての情報が適合している、もしくは、そのページから利用可能な適合した代替バージョンがあるということである。また、この要件は、少なくともレベル A の達成基準すべてを満たさなければ適合することはできないとうことも説明している。

注記が指摘しているのは、特定のレベルでの適合に留まらずに、より高いレベルの適合に向けても取り組み、もし自分たちが望むのであればその進捗状況を報告することをコンテンツ制作者に推奨するということである。

また、「適合した代替バージョン」を提供する実装方法も紹介している「適合した代替バージョンを理解する」も参照のこと。

「適合要件 2」を理解する

2. ページ全体: 適合性(および適合レベル)はウェブページ全体のみに対するものであり、ウェブページの一部が除外されている場合には認められない。

注記 1: 適合性を判断する際に、代替がそのページから直接得られる場合は、ページの一部のコンテンツに対する代替をそのページの一部であるとみなす。例えば、長い説明文や映像の代替表現など。

注記 2: コンテンツ制作者が制御できないコンテンツがあるために適合できないウェブページのコンテンツ制作者は、部分適合の説明を考慮するとよい。

この要件は、ページ全体が適合することを単に求めている。「ページの一部が適合している」という適合宣言をすることはできないのである。

あるページ上の情報への補足情報が他のページで提供されることがある。HTML の longdesc 属性がその一例である。longdesc 属性を用いると、その画像のあるページから利用者が移動できる別のページで画像の長い説明文を提供することができる。この注記では、そのような別ページのコンテンツも元のページの一部であると考えて、単一のウェブページであるとみなされる複数のウェブページによって適合要件 2 が満たされるということを明確にしている。また、代替を同一ページ上で提供することも可能である。例としては、ユーザインタフェースのコントロールと等価なものを作成することが挙げられる。

注記 1:適合要件 5 により、たとえページの一部分でアクセシビリティ・サポーテッドではないウェブコンテンツ技術を用いていたとしても、それがページの残りの部分の利用を妨げず、すべての情報及び機能がそのページ又はそのページから移動できる別ページのどこかで提供されているかぎり、ページ全体が適合できる。

注記 2:全体の一部として適合していないコンテンツを含めることが可能である。「適合要件 5を理解する」を参照のこと。

「適合要件 3」を理解する

3. 一連のプロセス: ウェブページプロセスを提示する一連の流れのページ群(つまり、利用者がある目的を達するために完了させる必要のある一連の手順)に含まれる場合、そのプロセス中のすべてのウェブページが指定したレベルまたはそれ以上のレベルで適合している(もし、プロセス中のページがそのレベルまたはそれ以上のレベルに適合していなければ、特定のレベルに適合できない)。

事例: オンラインストアに、製品を選択して購入するために用いられている一連のページがあるとする。この場合、すべてのページが適合すべきプロセスの一部なので、最初から最後(支払い)まで一連のすべてのページが、適合していること。

この要件では、プロセス全体が適合していない場合、そのプロセスの一部であるウェブページは適合しているとはみなされないことを述べている。例えば、ショッピングサイトでは、支払あるいはショッピング及び購入プロセスの一部であるその他のサイトの機能が適合していなかったとしたら、そのショッピングサイトは適合していることにならないということである。

「適合要件 4」を理解する

4. 技術のアクセシビリティ・サポーテッドな使用法のみ: 達成基準を満たすためには、用いる技術アクセシビリティ・サポーテッドな使用法だけに依存することができる。アクセシビリティ・サポーテッドではない技術で提供されている情報あるいは機能は、アクセシビリティ・サポーテッドな方法でも利用可能である(「アクセシビリティ・サポーテッドを理解する」を参照のこと)。

この適合要件は、後述の「アクセシビリティ・サポート」を理解するで説明されている。

「適合要件 5」を理解する

5. 非干渉: もし技術アクセシビリティ・サポーテッドではない方法で用いられている、あるいは技術が WCAG 2.0 に適合していない状態で用いられている場合、利用者がページの残りの部分へアクセスすることを妨げていない。加えて、全体としてウェブページは、以下のそれぞれの条件の下で適合要件を満たしている:

  1. 依存していないあらゆる技術が、ユーザエージェントでオンになっているとき

  2. 依存していないあらゆる技術が、ユーザエージェントでオフになっているとき、および

  3. 依存していないあらゆる技術が、ユーザエージェントでサポートされていないとき

さらに、適合性を満たすのに依存していないコンテンツも含めて、以下の達成基準はページ上の全てのコンテンツに適用される。なぜなら、これらを満たさないことはページの利用を妨げる可能性があるからである:

  • 1.4.2 - 音声制御,

  • 2.1.2 - フォーカス移動,

  • 2.3.1 - 3回の閃光または閾値以下、及び

  • 2.2.2 - 一時停止、停止、非表示

この要件は、基本的に、すべての情報がアクセシビリティ・サポーテッドであるウェブコンテンツ技術を用いても利用可能であるかぎり、なおかつ、アクセシビリティ・サポーテッドではないコンテンツが妨げとなっていないかぎり、アクセシビリティ・サポーテッドではないウェブコンテンツ技術を用いることができるということを述べている。

すべての情報がアクセシビリティ・サポーテッドであるウェブコンテンツ技術を用いた適合する方法でも利用可能であるかぎり、なおかつ、アクセシビリティ・サポーテッドではないコンテンツが妨げとなっていないかぎり、アクセシビリティ・サポーテッドではないウェブコンテンツ技術を適合していない方法で用いることができる。

特にページ利用の妨げとなる問題に対処する4つの達成基準がある。これら4つの達成基準の注記にもそのことが示されている。各達成基準の注記では、アクセシビリティ・サポーテッドではないウェブコンテンツ技術を用いて制作したコンテンツを含むすべてのコンテンツが、これらの達成基準を満たさなければならないことを示している。

事例: あるウェブページが "ZAP" というインタラクティブなグラフィックの新技術を組み込んでいたとする。ZAP はアクセシビリティ・サポーテッドではあるが、ZAP を用いて提示されている情報が、HTML のページでも提示しされている。そのため、ZAP には依存していないことになる。その場合、このページは適合要件 1 を満たしている。しかし、もし利用者が ZAP のコンテンツを Tab キーで移動しようとすると、フォーカスが ZAP のオブジェクトの中に入るとそこから抜け出せなくなる。一度中に入ると、利用者はフォーカスを外に出すことができなくなってしまう。そうすると、キーボード利用者は、ページの残り半分を利用することができない。また、ZAP のコンテンツは、さまざまな速度で明るく閃光を放ち続けていて、静止しない。それにより、注意力欠如(発達障害)のある利用者は気が散ってしまい、光感受性発作疾患のある利用者は発作を起こしてしまう可能性がある。適合要件 5 は、適合しているページ上でこういった状況が起こらないようにするためのものである。

「適合宣言」を理解する

適合する上では、適合宣言をすることは必須ではない。しかし、適合宣言をする際には、従わなければならないルールがある。

ある日付以降に追加されたコンテンツだけに適合宣言を行いたいことがあるかもしれない。あるいは、ある日付までのコンテンツには WCAG 1.0 への適合宣言を行い、その日付以降に制作又は更新したコンテンツには WCAG 2.0 への適合宣言したいこともあるかもしれない。WCAG 2.0 では、どのページが WCAG のどのバージョンに対して適合宣言をしているのかが明確であるかぎり、そういった適合宣言を禁止していない。

注記 1: "依存" している技術について語る際、それはウェブコンテンツ技術(HTML、CSS、JavaScript、など)のことであり、ユーザエージェント(ブラウザ、支援技術、など)ではない。

注記 2: 適合宣言は、適合の範囲内にある各ウェブページ上にはあるわけではない。

達成基準以上に施した追加措置に関する情報

適合宣言の任意要素の一つに、"アクセシビリティをさらに向上させるために、達成基準以上に施した追加措置に関する情報" というのがある。これには、適合しているその他の達成基準、実装した参考にすべき実装方法、特定の障害者のアクセス又はニーズを助けるために用いた追加の措置に関する情報などが含まれる。利用者がそのページのアクセシビリティを把握する上で役に立つあらゆる情報を含めるとよい。

適合宣言を報告するためのメタデータの使用

コンテンツに適合宣言を添付する最も有用な方法は、機械的に読み取り可能な標準のフォーマットで添付することだろう。この方法が広く普及すれば、検索ツールや特別なユーザエージェントがよりアクセシブルなコンテンツを探して提供するためにこの情報を利用することができるし、ユーザエージェントがコンテンツに適応することができるようになる。適合宣言を行うためのオプションに基づいたメタデータが数多く開発中であり、コンテンツ制作者及びツール開発者にはそれらをサポートすることを推奨する。

加えて、ひとたびレベル A での適合が達成されれば、個々の達成基準への適合を報告するために、メタデータを用いることが可能である。

また、例えば、現在開発中で、適合に関する詳細な情報を機械的に読み取り可能なフォーマットを提供できる Evaluation and Report Language (EARL) のように、プログラムによる報告のフォーマットもある。報告のフォーマットが形式化されて、そのサポートが進めば、ここに追記される予定である。

適合宣言の例

適合宣言の必須要素の例

例 1:2009年9月20日時点で、http://www.example.com にあるすべてのウェブページは、http://www.w3.org/TR/2006/REC-WCAG20-20081211/ にある WCAG 2.0 にレベル A で適合しています。

  • この適合宣言において依存している、アクセシビリティ・サポーテッドなコンテンツ技術の文書化された一式は、http://ISA.example.gov/AsCTsets/AS2-2008 にある ISA- AsCTset#1-2008 の一部である。

例 2:(正規表現を用いて)2009年8月12日時点で、http://www.example.com/(marketing|sales|contact)/ のパターンに合致するページ群は、http://www.w3.org/TR/2006/REC-WCAG20-20081211/ にある WCAG 2.0 にレベル AA で適合しています。

  • このコンテンツが "依存" している技術: XHTML 1.0 Transitional、CSS 2.0、及び JavaScript 1.2。

例 3:(ブール論理を用いて) 2009年1月6日時点で、http://example.com/ AND NOT (http://example.com/archive/ OR http://example.com/publications/archive/) は、http://www.w3.org/TR/2006/REC-WCAG20-20081211/ にある WCAG 2.0 にレベル AA で適合しています。

  • この適合宣言において依存している、アクセシビリティ・サポーテッドなコンテンツ技術の文書化された一式には、http://ISA.example.gov/AsCTsets/AS2-2008 にある ISA- AsCTset#1-2008 の XHTML 1.0 及び SMIL があります。

任意要素を含めた適合宣言の例

例 1: 2009年5月5日時点で、"G7: イントロダクション" のページ(http://telcor.example.com/nav/G7/intro.html)は、http://www.w3.org/TR/2006/REC-WCAG20-20081211/ にある WCAG 2.0 にレベル AA で適合しています。

  • 次の達成基準も追加で満たしています: 1.1.2、1.2.5、及び 1.4.3。

  • この適合宣言において依存している、アクセシビリティ・サポーテッドなコンテンツ技術の文書化された一式には、http://UDLabs.org/AsCTset#1-2006.html にある AsCTset#1-2006 です。

  • このコンテンツが "依存" している技術: XHTML 1.0 (Strict) 及び Real Video。

  • このコンテンツが "使用しているが依存はしていない" 技術: JavaScript 1.2、CSS2。

例 2: 2009年6月21日時点で、http://example.com/nav 及び http://example.com/docs という URI で始まるすべてのコンテンツは、http://www.w3.org/TR/2006/REC-WCAG20-20081211/ にある WCAG 2.0 にレベル AAA で適合しています。

  • この適合宣言において依存している、アクセシビリティ・サポーテッドなコンテンツ技術の文書化された一式には、http://smithreports.example.com/AsCTsets/AS2-2008 にある SMITH- AsCTset#2-2008 です。/p>

  • このコンテンツが "依存" している技術: XHTML 1.0 (Strict)、CSS2、JavaScript 1.2、JPEG、PNG。

  • このコンテンツを検証したユーザエージェント(支援技術を含む)は、http://example.com/docs/WCAG20/test/technologies.html で確認することができます。

例 3:2009年3月23日時点で、http://www.wondercall.example.com にあるサーバ上で利用可能なすべてのコンテンツは、http://www.w3.org/TR/2006/REC-WCAG20-20081211/ にある WCAG 2.0 にレベル A で適合しています。

  • このコンテンツが "依存" している技術: HTML 4.01。

  • このコンテンツが "使用しているが依存はしていない" 技術: CSS2 及び gif。

  • このコンテンツは、次のユーザエージェント及び支援技術を用いて検証しました: Firefox 1.5 on Windows Vista with Screenreader X 4.0、Firefox 1.5 on Windows XP SP 2 with Screenreader X 3.5、IE 6.0 on Windows 2000 SP4 with Screenreader Y 5.0、IE 6.0 on Windows 2000 SP4 with Screenreader Z 2.0、Firefox 1.5 on Windows XP SP2 with Screenreader X 4.0、Safari 2.0 with OS X 10.4。

適合宣言のための実装方法

参考にすべき実装方法
  • Expressing a conformance claim to WCAG 2.0 in Dublin Core elements (リンク追加予定)

「適合レベル」を理解する

まず、達成基準であるとみなされるには、満たさなければならない数多くの諸条件がある。次のことが含まれる:

  1. すべての達成基準は、すべての利用者が直面する可能性がある利用者ビリティの範疇を超えた問題に対処する、障害のある利用者にとって重要なアクセス上の問題でなければならない。言い換えれば、アクセシビリティの問題として考慮されるためには(そして、このようなアクセシビリティ・ガイドラインでカバーされるためには)、アクセス上の問題は、障害のない利用者に対して引き起こされる問題よりも、比例してより重大な問題を引き起こすものでなければならない。

  2. すべての達成基準は、テスト可能でなければならない。このことは重要である。なぜなら、テスト可能でなければ、あるページが達成基準に適合しているのか、もしくは適合していないのかを判断することができなくなるからである。達成基準が満たされているかどうかを高い信頼水準で判断することが可能であるかぎり、その達成基準は、機械と人間の評価を組み合わせることによってテストすることができる。

ワーキンググループが広範囲に及ぶ相互作用する問題を考慮した後に、達成基準には、3つの適合レベルの中から1つが割り当てられた。レベルを定めた際に用いられた共通の指標には、次のようなものが含まれていた:

  • その達成基準が必要不可欠かどうか(言い換えれば、もしその達成基準が満たされなかったとしたら、支援技術でさえもコンテンツをアクセシブルにすることができない)。

  • その達成基準が適用されるすべてのウェブサイト及びコンテンツの種類(例: さまざまな主題、コンテンツの種類、ウェブコンテンツ技術の種類)が、その達成基準を満たすことができるかどうか。

  • その達成基準が必要とするスキルは、コンテンツ制作者が無理なく習得できるものかどうか(つまり、その達成基準を満たすための知識及びスキルは、1週間あるいはそれ以下のトレーニングによって習得できるか)。

  • その達成基準が、"ルック&フィール" 及び/又はウェブページの機能に制限(機能、プレゼンテーション、表現の自由、デザイン又は審美的な面において、その達成基準がコンテンツ制作者にかける制限)を強いるかどうか。

  • その達成基準が満たされない場合、次善策がないかどうか。

「アクセシビリティ・サポート」を理解する

達成基準の多くは、支援技術あるいは主流のユーザエージェントが提供する特別なアクセシビリティ機能(たとえば、メディアプレーヤーが提供する "キャプションを表示" というオプション)を通じて、アクセシビリティを提供することを論じている。つまり、達成基準は、支援技術がコンテンツの情報をきちんと利用者に提示することができるように、ウェブコンテンツにおいてなすべきことを要求している。例を挙げると、あるトピックへ移動するためにクリックすべき画像は、支援技術を含むユーザエージェントがそれを見つけて利用者に示すことができるように代替テキストが提供されていなければ、全盲の利用者にとってはアクセシブルとはいえない。ここで重要なのは、代替テキストが支援技術を含むユーザエージェントが理解できて使用できるような方法、すなわち "アクセシビリティ・サポーテッド" な方法で提供されていなければならないということである。

もう一つ例を挙げるとするならば、ウェブページにある独自のコントロールがある。この場合、標準的なユーザエージェントは、利用者にその代替物を提示できるとはかぎらない。しかし、もしそのコントロールの識別名、役割、値、設定方法といった情報が、支援技術が理解できて制御可能な方法で提供されていれば、支援技術の利用者はそのコントロールを使用することができるであろう。

新しい技術が登場するときには、支援技術の利用者がそれを使用できるようにするために、次の2つを想定しなければならない。まず、支援技術を含むユーザエージェントが利用者にコンテンツを提示する必要のある情報すべてにアクセスできるように、その技術が設計されていなければならない。次に、ユーザエージェント及び支援技術には、その新しい技術に対応するために変更あるいは修正を行う必要が生じることがある。

"アクセシビリティ・サポーテッド" というのは、このどちらもが既になされていて、その技術がユーザエージェント及び支援技術によって利用者が使用可能であることを意味する。

"アクセシビリティ・サポーテッド" とするのに必要な支援技術によるサポートのレベル

このトピックは、あるウェブ技術が "アクセシビリティ・サポーテッド" であるとみなすには、どれだけ多くの、あるいはどの支援技術がそのウェブ技術をサポートしていなければならないのか、という疑問を生む。WCAG ワーキンググループ及び W3C は、ウェブ技術がアクセシビリティ・サポーテッドであるとみなすために、どれだけ多くの、あるいはどの支援技術がそのウェブ技術をサポートしていなければならないということについては特に定めない。なぜなら、これは複雑な要素が絡むことであり、環境や言語の両方によっても異なるからである。このことに関しては、WCAG ワーキンググループ及び W3C だけにとどまらず、広範囲かつ国際的な議論が必要である。このトピックを理解し調査するのに役立つ留意点には、次のようなことが挙げられる:

  1. ウェブ技術のアクセシビリティ・サポートは環境により異なる。

    • 特定のユーザエージェント及び支援技術が従業員すべてに提供されている企業では、ウェブ技術はそのユーザエージェント及び古い支援技術によってサポートされていればよいこともある。

    • 一般に公開されているウェブコンテンツは、より広範囲のユーザエージェントおよび支援技術で利用可能である必要がある。

  2. ウェブ技術のアクセシビリティ・サポートは、言語(及び方言)により異なる。

    • 古い支援技術のサポートのレベルは、言語および国によって様々である。中には、無償の支援技術が提供されている環境や国もある。

  3. 新しい技術は、古い支援技術ではサポートされない。

    • 新しい技術が既存の支援技術全てによってサポート可能でないことは明らかであり、その技術をすべての支援技術によってサポートされるように求めることは不可能である。

  4. 一つの支援技術によるサポートだけでは、通常は十分とはいえない。

    • (ある障害に対して)たった一つの支援技術だけがサポートしていることは、通常は十分とはいえない。コンテンツへアクセスするためにその支援技術を必要とする利用者のほとんどがそれを持っていなくて、その支援技術を購入する金銭的な余裕がない場合は、特にそうである。例外といえるのは、全員がある一つの支援技術を使用している会社の従業員へ配信される情報のみである。

  5. 一般の利用者が入手可能な現在の支援技術は、機能が不足していることが多い。

    • 障害のある一般の利用者が利用できないコンテンツを制作することは避けなければならない。多くの場合、支援技術を購入するコストは、それを必要とする利用者にとっては高額すぎる。また、無償あるいは低コストの支援技術は、今日では機能が不足していることが多いものの、ウェブコンテンツをレベルの最も低い(あるいは、中間レベルの)公分母に制限することは現実的に無理がある。このことが、対処していく必要のある、とても困難なジレンマを生んでいる。

そのため、ワーキンググループは、何をもってサポートしているとするかを定義するに留め、どこまで、どれだけ多くの、あるいはどの支援技術がそのウェブ技術をサポートしていなければならないかという判断については、組織、調達、地域社会などにとっての要件を定める各々の状況により近いところにいる地域や団体に委ねることとした。

一般に入手可能で、なおかつ堅牢な支援技術の不足は、利用者、技術開発者、そしてコンテンツ制作者にマイナスの影響を及ぼす問題であり、ワーキンググループは公開の場にてこのトピックについてより多くの議論がなされることを奨励する。

「アクセシビリティ・サポート」の技術的な定義

基本的に、ウェブコンテンツ技術は、利用者の使用している支援技術が対応していて、かつ主流なユーザエージェントのアクセシビリティ機能が対応していれば、"アクセシビリティ・サポーテッド" である。具体的に言うと、アクセシビリティ・サポーテッドな技術であるとみなすには、その技術において次のことが当てはまらなければならない:

アクセシビリティ・サポーテッド

ブラウザおよびその他のユーザエージェントにあるアクセシビリティ機能と同様に、利用者の支援技術でもサポートされている。

ウェブコンテンツ技術(あるいは、技術の機能)のアクセシビリティ・サポーテッドな使用であると見なすには、次の 1. と 2. の両方がそのウェブコンテンツ技術(あるいは、機能)で満たされなければならない:

  1. ウェブコンテンツ技術の使用法が、利用者の支援技術(AT)によりサポートされていなければならない。これは、その技術の使用法がコンテンツの自然言語において利用者の支援技術との相互運用性を検証されていることを意味する。

    かつ

  2. そのウェブコンテンツ技術には、利用者が利用可能で、アクセシビリティ・サポーテッドでもあるユーザエージェントがなければならない。これは、少なくとも次の1つが当てはまることを意味する:

    1. その技術が、アクセシビリティ・サポーテッドな広く配布されているユーザエージェントで自然にサポートされている(例えば、HTML や CSS など)。

      もしくは

    2. その技術が、アクセシビリティ・サポーテッドな広く配布されているプラグインでサポートされている。

      もしくは

    3. そのコンテンツが、例えば大学あるいは企業内ネットワークのような閉じた環境で利用可能であって、その技術が必要とし、その組織で使用されているユーザエージェントもアクセシビリティ・サポーテッドである。

      もしくは

    4. その技術をサポートするユーザエージェントが、アクセシビリティ・サポーテッドであって、次のようにダウンロードあるいは購入可能である:

      • 障害のない人よりも障害のある人に時間や労力がかかるようなことはなく、かつ

      • 障害のない人と同じくらい容易に障害のある人も探して入手することができる。

注記 1: WCAG ワーキンググループならびに W3C は、ウェブ技術のある特定の使用法がアクセシビリティ・サポーテッドであると分類するために、そのウェブ技術の特定の使用法に対して、どの支援技術のサポートあるいは支援技術によるどれだけのサポートがなければならないのかを指定しない("アクセシビリティ・サポーテッド" とするのに必要な支援技術によるサポートのレベルを参照のこと)。

注記 2: そのウェブ技術に依存していなくて、「適合要件 4:技術のアクセシビリティ・サポーテッドな使用法のみ」および「適合要件 5: 非干渉」を含む適合要件をページ全体が満たしているかぎり、そのウェブ技術をアクセシビリティ・サポーテッドではない方法で用いることができる。

注記 3: ウェブ技術がアクセシビリティ・サポーテッドな方法で用いられている際、その技術全体あるいはその技術の使用すべてがサポートされているということを暗に示すわけではない。ほとんどの技術は、HTML を含めて、少なくとも 1つの機能あるいは使用に対するサポートを欠いている。技術のアクセシビリティ・サポーテッドな使用法が、WCAG の要件を満たすために依存しうる場合のみ、ページは WCAG に適合する。

注記 4: 複数のバージョンを有するウェブコンテンツ技術を挙げる際は、アクセシビリティ・サポーテッドなバージョンを特定すべきである。

注記 5: コンテンツ制作者が技術のアクセシビリティ・サポーテッドな使用法を見つける方法の一つに、アクセシビリティ・サポーテッドであることが文書化されている使用法の資料を参考にすることである(「ウェブ技術のアクセシビリティ・サポーテッドな使用法を理解する」を参照のこと)。コンテンツ制作者、企業、技術ベンダー、あるいはその他の者が、ウェブコンテンツ技術のアクセシビリティ・サポーテッドな使用法を文書化してもよい。しかし、文書中の技術の使用法すべては、前述のアクセシビリティ・サポーテッドなウェブコンテンツ技術の定義を満たしていなければならない。

「ウェブ技術のアクセシビリティ・サポーテッドな使用法」を理解する

どのウェブ技術のどの使用法が、支援技術及びユーザエージェントのどのバージョンによって実際にサポートされているかを判断するのに必要な検証作業のすべてを、個々のコンテンツ制作者が行うことは通常不可能である。そのため、コンテンツ制作者は、どの支援技術がどのウェブ技術のどの使用法をサポートしているかについて文書化している公開資料に頼ってもよい。「公開」というのは、必ずしも公的機関によって作成されたものを指すわけではなく、一般に入手可能であるということのみを意味している。誰もが "ウェブ技術の使用法およびそのアクセシビリティ・サポート" という公開資料を作成することが可能である。資料作成者は、資料を作成し、コンテンツ制作者が参考資料として示すことのできる名前をつけてもよい。その資料が公開されているかぎり、コンテンツ制作者あるいは利用者などは、ニーズに合った使用法を容易に選択することが可能である。利用者やその他の者は、いずれかの時点で自分の環境又は言語に合致したウェブ技術を選んで、コンテンツを制作すべきウェブ技術を特定することができる。コンテンツ制作者には、精度と有用性において評価されている情報源を用いることを強く推奨する。そして、技術開発者には、その技術のアクセシビリティ・サポートに関する情報を提供することを強く推奨する。WCAGワーキンググループは、正確な情報を提供し、コンテンツ制作者と利用者双方にメリットのある文書のみが、長期的に市場の評価を得るものと考えている。

WCAG においては、公開された資料を用いたり、そのような資料にある技術の使用法のみを用いたりすることを要件にしていない。公開された資料は、適合において重要だが少々複雑な側面を、自分自身が支援技術のサポートに関する専門家ではない(あるいは、主流のユーザエージェント及び支援技術の進化を把握する時間がないだけの)コンテンツ制作者にとってより容易にする手法としてのみ説明されている。

コンテンツ制作者や企業などは、アクセシビリティ・サポーテッドな技術の使用に関する資料を独自に作成して用いたいと考えるかもしれないし、それは WCAG に適合する上では認められている。しかし、利用者、企業などは、用いた独自の資料あるいは公開資料から、その技術の使用法を特定してもよい。「附録 B. ウェブ技術の使用法のアクセシビリティ・サポートを文書化する」を参照のこと。

アクセシビリティ・サポートに関する記述

アクセシビリティ・サポートを明文化する適合宣言の方法の例には、次のようなものがある:

  1. 1. この適合宣言は、コンテンツの言語でのユーザエージェント A、ユーザエージェント B、ユーザエージェント C、及び支援技術 X、支援技術 Y そして支援技術 Z によるコンテンツの検証に基づいた、アクセシビリティ・サポートの要件を満たしています。これは、それらの製品を用いて、WCAG 2.0 のレベル A の達成基準すべてを満たすことができたことを意味します。

  2. 2. この適合宣言は、Techniques for WCAG 2.0 に記述されている実装方法及びユーザエージェント・ノートに基づいて、コンテンツの言語でのアクセシビリティ・サポートの要件を満たしています。また、(適合する上で依存した)技術のアクセシビリティ・サポート文書にも基づいており、"組織 XYZ によるアクセシビリティ・サポート文書" で参照可能です。

  3. 3. この適合宣言は、「WCAG 2.0 のための技術 Z のアクセシビリティ・サポーテッドな実装方法」で文書化されている技術 Z の使用法を基にして、コンテンツの言語でのアクセシビリティ・サポートの要件を満たしています。

  4. 4. この適合宣言は、技術 A のアクセシビリティ・ガイドライン及び技術 B のアクセシビリティ・ガイドラインにある使用法を基にして、コンテンツの言語でのアクセシビリティ・サポートの要件を満たしています。ユーザエージェント及び支援技術のサポート情報は、それらのガイドラインに記述されている「製品 XYZ アクセシビリティ・サポート要件」で確認することができます。

"プログラムで解釈" を理解する

いくつもの達成基準で、コンテンツ(又は、コンテンツの特定の部分)が "プログラムで解釈" できることを要件としている。これは、コンテンツが、支援技術を含むユーザエージェントがその情報にアクセスできるような方法で制作されていることを意味する。

ウェブコンテンツ技術(例えば、HTML、CSS、PDF、GIF、MPEG、Flash など)を用いて制作されたコンテンツが、さまざまなタイプの障害のある利用者にとってアクセシブルであるためには、用いられているウェブコンテンツ技術が、支援技術を含むユーザエージェント及びその他のユーザエージェントのアクセシビリティ機能と連携することが必要不可欠である。コンテンツが "プログラムで解釈" できることを要件としている達成基準に適合するためには、支援技術をサポートしているウェブコンテンツ技術を用いてコンテンツを実装する必要がある。

"プログラムで解釈" できるコンテンツは、(支援技術を含むユーザエージェントによって、)個々の利用者が必要とするさまざまな感覚(例: 視覚、聴覚)のフォーマット又はプレゼンテーションのスタイルに変換することが可能である。既存の支援技術が変換できない場合には、その情報は "プログラムで解釈" できるとはいえない。

この用語を用いているのは、情報が支援技術(及び、アクセシビリティを支援するその他のユーザエージェント)に対してアクセシブルでなければならない部分を、どのようにアクセシブルにする必要があるかに言及せずに、WCAG ワーキンググループがはっきりと特定できるようにするためである。ウェブコンテンツの絶え間なく変化しているという性質を考えると、これは重要なことである。この用語によって、ガイドラインに適合するために、何を "プログラムで解釈" できるようにする必要があるのかを、ガイドラインが特定できるようになる。そして、時間とともに更新可能な文書群(適合する方法、解説書、及び実装方法の文書)を別に用意することができて、ユーザエージェント及び支援技術のサポート状況に基づき、いずれかの時点で目的通りに機能して、十分であると考えられる特定の実装方法を挙げることが可能になる。

"アクセシビリティ・サポーテッド" vs. "プログラムで解釈"

"アクセシビリティ・サポーテッド" は、ウェブコンテンツ技術の特定の使い方に対するユーザエージェント(支援技術を含む)によるサポートと関係がある。ウェブコンテンツ技術のアクセシビリティ・サポーテッドな使い方は、支援技術及び主流なユーザエージェント(ブラウザ及びプレーヤーなど)のアクセシビリティ機能とと連携するものである。

"プログラムで解釈" は、ウェブコンテンツにある情報と関係がある。アクセシビリティ・サポーテッドなウェブコンテンツ技術が適切に用いられているならば、支援技術及びユーザエージェントはコンテンツにある情報にアクセスする(すなわち、コンテンツにある情報をプログラムで解釈する)ことができて、その情報を利用者に提示する。

情報が支援技術を含むユーザエージェントによって利用者に提示可能であるようにするために、この2つの概念は協力し合うものである。コンテンツ制作者は、ウェブコンテンツ技術のアクセシビリティ・サポーテッドな使い方に依存しなければならない。そして、情報をプログラムで解釈できるようにするために、その使い方を適切に用いなければならない。そうすることで、情報は支援技術及びユーザエージェントによって障害のある利用者に提示できるようになる。

"適合している代替バージョン" を理解する

適合要件 1 は、"適合している代替バージョン" があるかぎり、非適合のページを適合の範囲内に含めることを許容している。"適合している代替バージョン" は、次のように定義されている:

適合している代替バージョン

以下のようなバージョンのことを指す:

  1. 指定されたレベルで適合しており、かつ

  2. 同じ情報および機能のすべてを同一の自然言語で提供しており、かつ

  3. 適合していないコンテンツと同時に更新されていて、かつ

  4. 以下に挙げるうち少なくとも一つが当てはまること:

    1. アクセシビリティ・サポーテッドメカニズムを用いて、適合していないページから適合しているバージョンへ移動できる。もしくは、

    2. 適合しているバージョンからのみ適合していないバージョンへ移動できる。もしくは、

    3. 適合しているバージョンへ移動するメカニズムも提供している適合したページからのみ、適合していないバージョンへ移動できる。

注記 1: この定義においては、"・・・からのみ・・・へ移動できる" とは、条件付きのリダイレクトのような何らかのメカニズムがあり、利用者が特定のページから来ないかぎり、利用者が適合していないページに "たどり着く"(適合していないページを読み込む)ことがない、ということを意味する。

注記 2: 代替バージョンは、オリジナルのページと全く同じページである必要はない(例:適合した代替バージョンは複数のページであってもよい)。

注記 3: 複数の言語版がある場合は、適合した代替バージョンは提供されている各言語のものが必要となる。

注記 4: さまざまな技術環境あるいは利用者層に対応するために代替バージョンを提供してもよい。適合要件 1を満たすためには、1つのバージョンが完全に適合したものでなければならない。

注記 5: 適合していないバージョンと同じように自由に利用可能であるかぎり、適合した代替バージョンは、適合範囲内あるいは同じウェブサイト上にさえもある必要はない。

注記 6: 代替バージョンは、元のページを補助して理解を高める補足的なコンテンツと混同されないようにすべきである。

注記 7: 適合したバージョンを作り出すためにコンテンツ内で利用者選択の設定を行うことは、その選択を設定するのに用いられている手法がアクセシビリティ・サポーテッドであるかぎり、代わりのバージョンへの移動メカニズムとして条件を満たしているといえる。

これにより、適合宣言の範囲内にあるページ上のすべての情報及びすべての機能は、適合しているウェブページ上で利用可能になる。

なぜ代替バージョンを容認するのか?

なぜ WCAG では、適合宣言に含まれるウェブページの適合している代替バージョンを容認するのか? 言い換えれば、なぜ適合又は適合宣言の範囲内にあって、その適合レベルにある達成基準に適合していないページを含めるのか?

  • 時には、ウェブページが、まだアクセシビリティ・サポーテッドではないウェブコンテンツ技術を用いることがある。新しいウェブコンテンツ技術が登場する際、支援技術によるサポートは遅れをとる、又はターゲットとする利用者だけが利用可能になる。そのため、コンテンツ制作者は、すべての利用者に対して新しい技術だけに依存することはできないことがある。しかし、新しい技術を使用することには、その他の利点があるかもしれない。例えば、より良いパフォーマンス、広範囲のモダリティで利用可能、など。代替バージョンの要件は、アクセシブルな代替バージョンをアクセシビリティ・サポーテッドなウェブコンテンツ技術で提供することによって、コンテンツ制作者がそのような新しい技術を用いたウェブページをウェブサイトに含めることができるようにするためのものである。十分にサポートされている新しいウェブコンテンツ技術を利用できる人は、その新しいバージョンの利点を享受する。そこで、将来のアクセシビリティ・サポートを見据えているコンテンツ制作者は、代替バージョンのページを提供することによって、今の時点でも達成基準に適合することが可能である。また、支援技術がサポートするようになった際のことを考えて、新しいウェブコンテンツ技術を用いるページでアクセシビリティ機能を組み込んでおくこともできる。

  • さまざまな理由から、ウェブページ上のコンテンツを修正できないこともある。例えば、

    • 法的又は歴史的な理由で、文書の見た目をそのままコピーしたものを含めることが重要な意味を持っていることがある。

    • そのウェブページはあるウェブサイト内にあるが、そのサイトの所有者には元のページにあるコンテンツを修正できる法的な権利がないかもしれない。

    • 企業は、過去に公開したものを削除又は部分的に修正するのが法的に不可能なことがある。

    • コンテンツ制作者が、他の部署、政府機関、又は企業から、文書を部分的にでも変更するための許可を得ていないかもしれない。

  • ある障害に特別に対応するウェブページを制作することによって、その障害がある利用者にとっての最高の体験を提供することがある。そのような場合、すべての達成基準に適合することによって、ウェブページをすべての障害に対応させることは不可能又は非現実的かもしれない。完全に適合した '代替バージョン' のページがあるかぎり、代替バージョンの要件はそのような特別なページを適合宣言の範囲内に含めることを容認している。

  • アクセシビリティに取り組んでいるサイトの多くには、大量の古いウェブページがある。情報はアクセシブルなフォーマットで入手可能になってきているものの、そういったファイルを大量に削除するには、組織的な抵抗がかなり強かったり、手続き上の障壁があったりするものである。特に政府機関などのように、従来の印刷志向のプロセスを優先している組織もある。こういった組織はインターネットでの情報配信に適応し、アクセシブルなフォーマットの必要性も認識しているにもかかわらず、それでもなお紙の発想のままで、"第一の" バージョンとして紙印刷のために設計されたフォーマットにこだわっている(電子的にしか "発行" されたことのない文書に対してもである)。ワーキンググループは、こういったアプローチは今後廃止されていくべきだと考えるが、アクセシブルなバージョンがすぐに入手可能であるかぎりは、禁止できるものではないと考えている。

達成基準に適合していないウェブページを容認する際の懸念事項としては、障害のある利用者がそういった適合していないウェブページに遭遇し、そのコンテンツを利用することができずに、"適合している代替バージョン" も見つけることができない恐れがあることが挙げられる。そのため、代替バージョンの要件で鍵となるのは、適合していないウェブページに遭遇した際に、そのウェブページから適合しているページ(代替バージョン)を見つけられるようにすることである。それゆえ、代替ページを容認する適合要件は、利用者が代替バージョンの中からアクセシブルなバージョンを見つけることができる方法を要求している。

注意してほしいのは、代替バージョンを提供することは、WCAG に適合するための最後の選択肢であって、望ましい適合方法はすべてのコンテンツをそのままアクセシブルにすることである。

適合している代替バージョンを提供するための実装方法

The most important part of providing a 適合している代替バージョンを提供する上で最も重要なのは、適合していないバージョンから適合している代替バージョンを見つけるメカニズムを提供することである。ある特定の実装方法が特定のウェブコンテンツ又は状況において常に可能であるとは限らないため、これには数多くのさまざまな方法がある。例えば、コンテンツ制作者がサーバを制御できる場合には、利用者が常に前もって選択できるかなり効果的な実装方法が幾つかある。しかし、多くの場合、コンテンツ制作者はウェブサーバ上のサービスを制御することはできない。そういう場合には、他の実装方法がある。適合していないページでリンクを提供するのも効果的な実装方法だが、すべての適合していないウェブコンテンツ技術がハイパーテキストリンクをサポートしているわけではない。

次に挙げるのは、今までに確認されてきた実装方法である。WCAG ワーキンググループでは、時間とともにその他の実装方法も考案されることを期待している。そして、支援技術を含むユーザエージェントによってサポートされていることが実証されれば、それらのアプローチがここに追加されていくだろうと考えている。例えば、支援技術がアクセスできない新しいウェブコンテンツ技術の開発者は、代替バージョンへのリンクを利用者に自動的に提示する機能をそのウェブコンテンツ技術に組み込んでもよい。

ウェブページの適合している代替バージョンを提供する適合要件を満たすことができる実装方法

次の番号付き項目はいずれも、WCAG ワーキンググループが適合している代替バージョンを提供するのに十分であると考えた実装方法又は実装方法の組合せである。

  1. G136: Providing a link at the beginning of a nonconforming Web page that points to a 適合している代替バージョン

  2. G190: Providing a link adjacent to or associated with a non-conforming object that links to a 適合している代替バージョン

  3. C29: Using a style switcher to provide a 適合している代替バージョン (CSS)

  4. SVR2: Using .htaccess to ensure that the only way to access non-conforming content is from conforming content (SERVER)

  5. SVR3: Using HTTP referer to ensure that the only way to access non-conforming content is from conforming content (SERVER)

  6. SVR4: Allowing users to provide preferences for the display of 適合している代替バージョンs (SERVER)

ワーキンググループが確認したよくある適合要件を満たしていない事例
ウェブページの適合している代替バージョンを提供する適合要件でさらに対応が望まれる実装方法(参考)
  • Providing reciprocal links between conforming and non-conforming versions (リンク追加予定)

  • Excluding non-conforming content from search results (リンク追加予定)

  • Using content negotiation (リンク追加予定)

  • Not displaying content that relies on technologies that are not accessibility-supported when the technology is turned off or not supported. (リンク追加予定)

  • Using metadata to allow location of a conforming alternative version from the URI of a non-conforming page (リンク追加予定)

適合している代替バージョンの事例
  • 複数のバージョンのサイトがあるイントラネット

    ある大企業が、イントラネットのサイト上で新しいウェブコンテンツ技術を使うことによって、異なる技術をベースにしているさまざまな拠点、及び広範囲に及ぶユーザエージェント及び支援技術を使用している個々の従業員のニーズに対処しづらくなるかもしれないという懸念を抱いていた。この懸念を解消するために、その企業は、使用するウェブコンテンツ技術のアクセシビリティ・サポーテッドな使用法を限定して、すべてのレベル A 達成基準に適合した代替バージョンのコンテンツを制作した。

    ある情報サイトは、広範囲に及ぶ話題を網羅していて、利用者が自分の探しているトピックをすぐに見つけ出すことができるようにしたいと考えている。そうするために、そのサイトは、人気のある2つのユーザエージェントの最新バージョンでのみサポートされているインタラクティブなメニューシステムを実装した。その特定の利用者エー縁とを使用していない利用者もそのサイトを有効に利用できるようにするため、最新の技術をサポートしていないユーザエージェントには、そのインタラクティブなメニューシステムに依存しないナビゲーションのメカニズムを提供している。

"ウェブページ" を理解する

ウェブページの定義は、次の通りである:

ウェブページ

HTTP によって単一の URI から得られる埋め込みではないリソースと、レンダリングに用いられたり、ユーザエージェントで一緒にレンダリングされる目的で用いられたりしているその他のリソース。

注記 1: どのような "その他のリソース" も第一のリソースと一緒にレンダリングされるであろうが、必ずしもお互いが同時にレンダリングされる必要があるわけではない。

注記 2: このガイドラインに適合する目的において、ウェブページと見なされる適合範囲内ではリソースは『埋め込みではない』ものでなければならない。

事例 1: すべての埋め込まれた画像とメディアを含んだウェブリソース。

事例 2: Ajaxを用いたウェブメールのプログラム。そのプログラムは http://example.com/mail に存在しているが、受信箱、アドレス帳、そしてカレンダーがある。受信箱、アドレス帳やカレンダーを起動するリンクあるいはボタンがあるが、ページ全体の URI は変わらない。

事例 3: カスタマイズ可能なポータルサイトで、利用者がさまざまなコンテンツのモジュール一式の中から表示させるコンテンツを選択できる。

事例 4: ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、ウェブサイトの中のほんの1ページなのかもしれない。

このガイドラインでは、"ウェブページ" には、静的な HTML ページよりもずっと多くのものが含まれていることに注意することが重要である。このガイドラインで用いられている "ウェブページ" という用語によって、ガイドラインがより理解可能なものになる。しかし、この用語の意味は、ウェブコンテンツ技術の進化とともに拡大し、完全に 'ページのようなもの' ではないものが多い、広範囲に及ぶウェブコンテンツ技術を包含するようになってきている。バーチャルでインタラクティブなコミュニティ全体を提示することのできる "ページ" を包含しながら、ウェブ上に登場してますます増えている動的なウェブページも含んでいる。例えば、"ウェブページ" という用語には、単一の URI で提供される、実体験のようにインタラクティブな映画のような体験も含まれている。

"代替テキスト" を理解する

代替テキストとは、非テキストコンテンツを視覚的に認識できない利用者のために、その非テキストコンテンツの代わりに用いられるテキストのことである。非テキストコンテンツには、写真、図画、アプレット、音声ファイルなどがある。例えば、見ることができない利用者は、写真又は図画で提示されている情報を見ることができない。代替テキストはそのために提供されていて、利用者がその情報(代替テキスト)を音声に変換することができるようになる。将来は、情報をテキストで持っておくことで、その情報を手話、図画、又はより平易なテキストに変換できるようになるかもしれない。

障害のある利用者が、このテキストを利用できるようにするためには、テキストは "プログラムで解釈" できなければならない。つまり、テキストは、障害のある利用者の使用している支援技術(及び、ブラウザのアクセシビリティ機能)が読むことができて、利用できるものでなければならない。

また、支援技術を使用している利用者が利用することのできない非テキストコンテンツに遭遇した際に、その代替テキストを見つけ出すことが可能でなければならない。そのためには、テキストがその非テキストコンテンツと "プログラムで関連付け" られていなければならない。つまり、利用者が(自分が使えない)非テキストコンテンツを見つけたら、利用者は自分の支援技術を用いて(自分が利用できる)代替テキストを見つけることができなければならない。


附録 A 他の文書からの WCAG 2.0 の参照方法

WCAG 2.0 を参照するために用いる次の言葉を文書に挿入することが可能である。

情報提供を目的にして参照する場合

WCAG 2.0 を情報提供という意味で参照する際には、次のフォーマットを使用することができる。

ウェブコンテンツ・アクセシビリティ・ガイドライン 2.0、W3C 勧告 2008年12月11日 (http://www.w3.org/TR/200X/REC-WCAG20-20081211/  最新バージョン: http://www.w3.org/TR/WCAG20/)


他の標準規格から WCAG 2.0 を "推奨" 要件として参照する場合

標準規格(又は、規定における推奨)で、推奨要件の中で WCAG 2.0 を参照する際には、WCAG 2.0 全体を参照するのが望ましい。これは、WCAG 2.0 の3つのレベルすべてを考慮すべきだが、どれも必須ではないという意味になる。そのため、推奨要件の中で WCAG 2.0 を参照する際のフォーマットは次のようになる:

ウェブコンテンツ・アクセシビリティ・ガイドライン 2.0、W3C 勧告 2008年12月11日(http://www.w3.org/TR/200X/REC-WCAG20-20081211/)


他の標準規格から WCAG 2.0 を "必須" 要件として参照する場合

WCAG 2.0 を要件(例:標準規格又は規定の必須要件)の一部として引用する際、WCAG 2.0 の中で必須とする部分を含めなければならない。この方法で WCAG 2.0 を参照する際には、次のルールが適用される:

  1. どのレベルであれ、WCAG 2.0 に適合するには、すべてのレベル A 達成基準に適合する必要がある。WCAG 2.0 への適合の参照は、レベル A への部分的な適合であってはならない。

  2. レベル A 以上であれば、"必須" 要件にレベル AA 及び AAA の要件を部分的に加えてもよい。例えば、"すべてのレベル A 及び [レベル AA 及び AAA 達成基準の具体的なリスト]" に適合しなければならない。

  3. WCAG 2.0 へのレベル AA 適合が指定されている場合は、すべてのレベル A 及びすべてのレベル AA 達成基準に適合しなければならない。

  4. WCAG 2.0 へのレベル AAA 適合が指定されている場合は、すべてのレベル A、すべてのレベル AA 及びすべてのレベル AAA 達成基準に適合しなければならない。

    注記 1: レベル AAA 適合をサイト全体の基本的なポリシーとして要求することは推奨しない。なぜなら、コンテンツによっては、レベル AAA の達成基準をすべて満たすことができないからである。

    注記 2: WCAG で定義されている達成基準一式は、相互依存しており、個々の達成基準は読者には一見して分からないようなかたちでお互いの定義に依存している。どんな達成基準一式であっても、すべてのレベル A 達成基準が含まれていなければならない。


事例

レベル A 達成基準のみを引用する場合(レベル A 適合):

ウェブコンテンツ・アクセシビリティ・ガイドライン 2.0、W3C 勧告 2008年12月11日 レベル A 達成基準 (http://www.w3.org/TR/200X/REC-WCAG20-20081211/)

レベル A 及びレベル AA 達成基準を引用する場合(レベル AA 適合):

ウェブコンテンツ・アクセシビリティ・ガイドライン 2.0、W3C 勧告 2008年12月11日 レベル A 及び AA 達成基準 (http://www.w3.org/TR/200X/REC-WCAG20-20081211/)

レベル A 達成基準及びレベル AA、AAA から選択した達成基準を引用する場合:

ウェブコンテンツ・アクセシビリティ・ガイドライン 2.0、W3C 勧告 2008年12月11日 レベル A 達成基準及び達成基準 1.x.x, 2.y.y, … 3.z.z. (http://www.w3.org/TR/200X/REC-WCAG20-20081211/)

"必須" 要件で WCAG 2.0 を参照する例

公開されているウェブサイト上にあるすべてのウェブコンテンツは、ウェブコンテンツ・アクセシビリティ・ガイドライン 2.0、W3C 勧告 2008年12月11日 レベル A 達成基準及び達成基準 1.2.3, 2.4.5-6, 3.1.2 (http://www.w3.org/TR/200X/REC-WCAG20-20081211/)に適合しなければならない。


WCAG 関連文書のコンテンツへの参照

Understanding WCAG 2.0 に挙げられていて、その他の関連文書で説明されている実装方法は、WCAG 2.0 の勧告の一部ではなく、WCAG 2.0 勧告自体の引用を用いて参照すべきではない。関連文書にある実装方法への参照は、別々に行うべきである。

実装方法は、個々の実装方法文書、又は WCAG 2.0 実装方法の文書の原本をベースに引用することができる。例えば、"Using alt attributes on img elements" という実装方法は、次のように引用することが可能である。

"Using alt attributes on img elements," W3C ノート (URI: {実装方法の URI})

、又は

W3C (200x): WCAG2.0 HTML 実装方法 (URI: {URI of HTML Techniques})

実装方法は、あらゆる標準規格又は規定から "必須要件" として参照されることを想定したものではない。標準規格及び規定は、推奨する実装方法として選ぶことはあっても、いかなる特定の実装方法をも必須とすべきではない。


附録 B. ウェブ技術の使用法のアクセシビリティ・サポートを文書化する

ウェブ技術の使用法に関するアクセシビリティ・サポートの文書化は、ある特定の環境においてWCAG 2.0の達成基準を満たすことが可能かどうかを判断するために必要な情報を提供する。

ウェブ技術の使用法に関するアクセシビリティ・サポートの文書化においては、以下の情報を含める:

ターゲットとする環境は、その利用者にとって入手可能なユーザエージェント及び支援技術によって決まる。アクセシビリティ・サポートの文書化には、達成基準を満たす技術の機能の使用法、そしてユーザエージェント及び支援技術の機能に関する詳細な理解が必要である。このために、ウェブ技術及びユーザエージェントの開発者とベンダーには、製品のアクセシビリティ・サポートに関する情報を提供することが望まれる。同様に、支援技術の開発者とベンダーにも、その製品がサポートするウェブ技術の使用法に関する情報を提供することが望まれる。コンテンツ制作者は、ある技術の使用法に関してベンダーあるいは検証者のグループから信頼できる文書が提供されていないときのみ、その技術のアクセシビリティ・サポーテッドな使用法を文書化する必要がある。

例えば企業の職場などのように、制御された環境においては、利用可能なユーザエージェント及び支援技術は、特定のプラットフォーム上における特定のバージョンのユーザエージェントである可能性がある。ウェブ技術の使用法が、そのターゲットとなる環境においてアクセシビリティ・サポーテッドであるかどうかを判断するためには、コンテンツ制作者は、利用可能なユーザエージェント及び支援技術が、アクセシビリティ・サポート文書の中で挙げられている、サポートしているユーザエージェント及び支援技術に該当するかどうかを確認する必要がある。

ターゲットとするのがインターネットのような環境である場合は、コンテンツ制作者は旧バージョンを含むユーザエージェントとさまざまなプラットフォーム上でのより多様な組合せを考慮する必要があるかもしれない。

異なる自然言語を用いる環境は、ターゲットとなる環境も異なってくる。例えば、ウェブ技術のアクセシビリティ・サポーテッドな使用法は、英語の環境とアラビア言語の環境とでは異なる可能性がある。なぜなら、それぞれの言語をサポートするユーザエージェント及び支援技術が異なるかもしれないからである。

文書化する際には、すべての支援技術及びすべてのユーザエージェント、そしてそれぞれが互いに情報のやりとりをする方法に関するバージョン特有の情報を含める。それらのユーザエージェントにおけるサポートが似通っていれば、コンテンツ制作者が文書化されている技術の使用法がアクセシビリティ・サポーテッドかどうかを判断するのは簡単であろう。サポートされている使用法がバージョンによって異なる場合、コンテンツ制作者は、アクセシビリティ・サポートかどうかを判断する際には、利用者が使用可能なバージョンにおいてサポートされている使用法だけに依存することだけができる。

技術のある使用法が適合する上で依存されていなければ、その使用法がアクセシビリティ・サポートでなかったとしても、ウェブページの適合を妨げることにはならない。サポートされていない使用法がコンテンツで発生しない場合、あるいはそのコンテンツの適合したバージョンが利用可能である場合、そのウェブページは適合していることになる。例えば、あるウェブ技術のインタラクティブなコントロールにアクセシビリティ・サポートが欠如していたとしても、アクセシビリティ・サポーテッドであるノンインタラクティブなコンテンツでそのウェブ技術を使用することを禁じるものではない。

附録 C メタデータを理解する

この節では、WCAG 2.0 の達成基準に適合するために用いることのできるメタデータの実装方法について説明する。メタデータに関するより詳細な情報は、以下にあるリソースを参照のこと。

最も基本的なレベルでは、メタデータは本質的に 'データに関するデータ' であり、リソースを説明するため及び探すための両方に用いられる。

メタデータは、ウェブページ及びウェブページのアクセシブルなコンポーネントを説明するためにも、ウェブコンテンツの代替バージョンをお互いに関連付けるためにも用いることのできる強力なツールである。言い換えると、メタデータによる説明によって、利用者が自分の求めている又は好んでいる特定の情報を見つけることができるようになる。

WCAG と併用することで、メタデータは次のような数多くの役割を果たすことができる:

  1. 利用者が自分の使うことのできない非適合のページにやってきたときに、適合している代替バージョンを見つけられるようにするために、メタデータを用いて、ウェブページの適合している代替バージョンを適合していないウェブページと関連付けることができる。

  2. 制作されたページに複数のバージョンがあるとき、特に代替ページがさまざまな障害のある利用者に最適化されている場合に、その代替ページの場所を示して説明するために、メタデータを用いることができる。利用者はメタデータを用いて、代替バージョンを見つけることも、そのバージョンの特徴を確認することもできる。それによって、利用者は自分のニーズに最も合うものを探すことができる。

  3. (上記 1. 及び 2. のように、)ページ全体に対して用いるのに加えて、ページの一部分の代替バージョンを説明するためにメタデータを用いることができる。さらに、メタデータを用いて、ウェブページのコンポーネントの代替バージョンを探したり、(複数ある場合には)どちらのほうが利用者のニーズに合うのかを判断するために、各代替バージョンの説明を取得したりすることができる。

メタデータに関するリソース

メタデータによる説明は、リソースの題目又はその発行日などのように、定義済みの合意されたボキャブラリの値を提供する。そして、機械的に読み取ることが可能である。用いられているメタデータのスキームを理解しているソフトウェアは、有用なタスクを行うことができる。通常は、メタデータを持つオブジェクトには、そのようなメタデータによる説明が一つ以上ある。

メタデータのよく知られている仕様(スキーマ)には、次のようなものがある:

リソースの説明を提供するツールがいくつか入手可能である。あるいは、その説明は人的に提供することが可能である。メタデータの作成及びリソースの作成又は発行時点でのメタデータの収集がもっと容易になればなるほど、プロセスはより効果的になり、より多く使われるようになるはずである。

次のような例がある:

アクセシビリティ・メタデータの実装には、次のようなものがある:


附録 D リファレンス

ANSI-HFES-100-1988
ANSI/HFS 100-1988, American National Standard for Human Factors Engineering of Visual Display Terminal Workstations, Section 6, pp. 17-20.
ARDITI
Arditi, A. (2002). Effective color contrast: designing for people with partial sight and color deficiencies. New York, Arlene R. Gordon Research Institute, Lighthouse International. Also available at http://www.lighthouse.org/color_contrast.htm.
ARDITI-FAYE
Arditi, A. and Faye, E. (2004). Monocular and binocular letter contrast sensitivity and letter acuity in a diverse ophthalmologic practice. Supplement to Optometry and Vision Science, 81 (12S), 287.
ARDITI-KNOBLAUCH
Arditi, A. and Knoblauch, K. (1994). Choosing effective display colors for the partially-sighted. Society for Information Display International Symposium Digest of Technical Papers, 25, 32-35.
ARDITI-KNOBLAUCH-1996
Arditi, A. and Knoblauch, K. (1996). Effective color contrast and low vision. In B. Rosenthal and R. Cole (Eds.) Functional Assessment of Low Vision. St. Louis, Mosby, 129-135.
CAPTCHA
The CAPTCHA Project, Carnegie Mellon University. The project is online at http://www.captcha.net.
EPFND
Experts Issue Recommendations to Protect Public from Seizures Induced by TV / Videogames. A copy of the standard is available at http://www.epilepsyfoundation.org/aboutus/pressroom/pr20050919.cfm.
GITTINGS-FOZARD
Gittings, NS and Fozard, JL (1986). Age related changes in visual acuity. Experimental Gerontology, 21(4-5), 423-433.
HARDING-BINNIE
Harding G. F. A. and Binnie, C.D., Independent Analysis of the ITC Photosensitive Epilepsy Calibration Test Tape. 2002.
HEARING-AID-INT
Levitt, H., Kozma-Spytek, L., & Harkins, J. (2005). In-the-ear measurements of interference in hearing aids from digital wireless telephones. Seminars in Hearing, 26(2), 87.
IEC-4WD
IEC/4WD 61966-2-1: Colour Measurement and Management in Multimedia Systems and Equipment - Part 2.1: Default Colour Space - sRGB. May 5, 1998.
ISO-9241-3
ISO 9241-3, Ergonomic requirements for office work with visual display terminals (VDTs) - Part 3: Visual display requirements. Amendment 1.
I18N-CHAR-ENC
"Tutorial: Character sets & encodings in XHTML, HTML and CSS," R. Ishida, ed., This tutorial is available at http://www.w3.org/International/tutorials/tutorial-char-enc/.
KNOBLAUCH
Knoblauch, K., Arditi, A. and Szlyk, J. (1991). Effects of chromatic and luminance contrast on reading. Journal of the Optical Society of America A, 8, 428-439.
LAALS
Bakke, M. H., Levitt, H., Ross, M., & Erickson, F. (1999). Large area assistive listening systems (ALS): Review and recommendations (Final Report. NARIC Accession Number: O16430). Jackson Heights, NY: Lexington School for the Deaf/Center for the Deaf Rehabilitation Research Engineering Center on Hearing Enhancement.
sRGB
"A Standard Default Color Space for the Internet - sRGB," M. Stokes, M. Anderson, S. Chandrasekar, R. Motta, eds., Version 1.10, November 5, 1996. A copy of this paper is available at http://www.w3.org/Graphics/Color/sRGB.html.
UNESCO
International Standard Classification of Education, 1997. A copy of the standard is available at http://www.unesco.org/education/information/nfsunesco/doc/isced_1997.htm.
WCAG20
"Web Content Accessibility Guidelines 2.0," B. Caldwell, M Cooper, L Guarino Reid, and G. Vanderheiden, eds., W3 Recommendation 12 December 2008, http://www.w3.org/TR/2008/REC-WCAG20-20081211. The latest version of WCAG 2.0 is available at http://www.w3.org/TR/WCAG20/