すべての WCAG 2.0 の達成基準は、客観的にコンテンツがその基準を満たしているかどうかを判断できるように、テスト可能な基準として記述されている。達成基準のテストでは、自動的なテストと人間による判断を組み合わせる必要がある。様々な種類の障害のある人がどのようにウェブを利用しているのかを理解している人が、コンテンツをテストすべきである。
ここでいうテストやテスト可能というのは、機能面のテストのことを指している。つまり、コンテンツが想定していた通りに機能することを確認するということである。あるいは、ここでは、達成基準を満たしていることを確認するといってもよい。コンテンツがすべての達成基準を満たしていたとしても、それでも様々な障害のある利用者がそのコンテンツを使うことができるとは限らない。そのため、必要とされる機能面のテストに加えて、ユーザビリティテストを実施することも推奨している。ユーザビリティテスティングは、その用途に応じて、利用者がコンテンツをどれだけうまく使えるかを判断することを目的としている。ユーザビリティテストを実施する際には、テスト参加者に障害のある利用者を含めることを推奨する。
適合とは何を意味するのか？
基準への適合とは、その基準の「要件」に合っている、あるいは満たしていることを意味する。WCAG 2.0 において、「要件」となるのは達成基準である。WCAG 2.0 に適合するためには、達成基準を満たす必要がある。つまり、達成基準に反するコンテンツがないということである。
ある達成基準について、適用対象となるコンテンツを含まないコンテンツにおいては、その達成基準は満たされているということを意味する。
ほとんどの標準には、適合レベルは一つしかない。しかし、より高いレベルのアクセシビリティを要求したり可能にしたりする様々な状況に対応するために、WCAG 2.0 には三つの適合レベルがあり、そのため達成基準にも三つのレベルがある。
適合要件を理解する
コンテンツが WCAG 2.0 に「適合している」とみなされるためには、満たさなければならない五つの要件がある。この節では、それらの要件に関する簡単な注釈を提供する。なお、この節は、今後寄せられる質問に対処するため、あるいは様々な適合要件を満たす方法の新しい事例を提供するために、時間とともに拡充されていく予定である。
適合要件 1 を理解する
適合レベル: 以下に挙げる適合レベルの一つを完全に満たしていること。
- レベル A (適合の最低レベル) で適合するには、ウェブページがレベル A 達成基準のすべてを満たすか、又は適合している代替版を提供する。
- レベル AA で適合するには、ウェブページはレベル A 及びレベル AA 達成基準のすべてを満たすか、又はレベル AA に適合している代替版を提供する。
- レベル AAA で適合するには、ウェブページがレベル A、レベル AA、及びレベル AAA 達成基準のすべてを満たすか、又はレベル AAA に適合している代替版を提供する。
注記ウェブページは、記載したレベルでのみ WCAG 2.1 に適合できるが、コンテンツ制作者は、その適合レベルよりも高いレベルの達成基準の達成状況を (表明の中で) 示すことを推奨される。
注記コンテンツの中には、レベル AAA 達成基準のすべてを満たすことのできないものもあるため、サイト全体の一般的な方針としてレベル AAA での適合を要件とすることは推奨されない。
最初の要件は、適合レベルに関するものである。基本的には、ページ上のすべての情報が適合している、もしくは、そのページから利用可能な適合している代替版があるということである。また、この要件は、少なくともレベル A の達成基準すべてを満たさなければどのレベルでも適合することはできないということも説明している。
注記が指摘しているのは、特定のレベルでの適合に留まらずに、より高いレベルの適合に向けても取り組み、もし自分たちが望むのであればその進捗状況を報告することをコンテンツ制作者に推奨するということである。
また、「適合している代替版」を提供する達成方法を紹介している適合している代替版を理解するも参照のこと。
適合要件 2 を理解する
ウェブページ全体: 適合 (及び適合レベル) はウェブページ全体に対するもののみであり、ウェブページの一部が除外されている場合には適合にならない。
注記適合の判断をするときに、例えば、詳細な説明又は映像の代替の提示のように、代替となるものがそのページから直接得られる場合は、ページのコンテンツの一部に対する代替コンテンツはそのページの一部であるとみなされる。
注記コンテンツ制作者が制御できないコンテンツがあるために適合できないウェブページについては、部分適合に関する記述を行うことを検討するとよい。
注記ウェブページ全体には、さまざまな画面サイズ向けに自動的に提示される個々のウェブページのバリエーションを含む (例: レスポンジブウェブページのバリエーション)。ウェブページ全体が適合するためには、個々のバリエーションが適合するか、適合する代替バージョンが必要である。
この要件は、ページ全体が適合することを単に求めている。「ページの一部が適合している」という適合宣言をすることはできないのである。
あるページ上の情報への補足情報が他のページで提供されることがある。HTML の longdesc 属性がその一例である。longdesc 属性を用いると、その画像のあるページから利用者が移動できる別のページで画像の長い説明文を提供することができる。この注記では、そのような別ページのコンテンツも元のページの一部であると考えて、単一のウェブページであるとみなされる複数のウェブページによって適合要件 2 が満たされるということを明確にしている。また、代替を同一ページ上で提供することも可能である。例としては、ユーザインタフェースのコントロールと等価なものを作成することが挙げられる。
適合要件 5 により、たとえページの一部分でアクセシビリティ サポーテッドではないウェブコンテンツ技術を用いていたとしても、それがページの残りの部分の利用を妨げず、すべての情報及び機能がそのページ又はそのページから移動できる別ページのどこかで提供されている限り、ページ全体が適合できる。
適合していないコンテンツを含めることが可能である。適合要件 5 を理解するを参照のこと。
適合要件 3 を理解する
プロセス全体: ウェブページがプロセスを提示する一連の流れのウェブページ群 (つまり、ある目的を達成するために完了させる必要のある一連の手順) に含まれる場合、そのプロセス中のすべてのウェブページが指定したレベル又はそれ以上のレベルで適合している (もし、プロセス中のウェブページが一つでも特定のレベル又はそれ以上のレベルに適合していない場合、そのレベルに適合できない)。
あるオンラインストアには、製品を選択して購入するための一連のウェブページがある。このプロセスに含まれるあるウェブページが適合するためには、最初から最後 (支払い) までのすべてのウェブページが適合していなければならない。
この要件では、プロセス全体が適合していない場合、そのプロセスの一部であるウェブページは適合しているとはみなされないことを述べている。例えば、ショッピングサイトでは、支払あるいはショッピング及び購入プロセスの一部であるその他のサイトの機能が適合していなかったとしたら、そのショッピングサイトは適合していることにならないということである。
適合要件 4 を理解する
技術のアクセシビリティ サポーテッドな使用方法だけ: 達成基準を満たすために、用いる技術のアクセシビリティ サポーテッドな使用方法だけに依存している。アクセシビリティ サポーテッドではない方法で提供されている情報又は機能は、アクセシビリティ サポーテッドな方法でも利用できる (アクセシビリティサポートを理解するを参照)。
この適合要件は、後述のアクセシビリティサポートを理解するで説明されている。
適合要件 5 を理解する
非干渉: 技術がアクセシビリティ サポーテッドではない方法で用いられている場合、又は適合しない方法で用いられている場合、利用者がウェブページの他の部分へアクセスすることを妨げていない。加えて、全体としてウェブページは、以下のそれぞれの条件の下で適合要件を満たしていること:
- 依存していない技術がユーザエージェントで有効になっているとき
- 依存していない技術がユーザエージェントで無効になっているとき、及び
- 依存していない技術がユーザエージェントでサポートされていないとき
さらに、適合するために依存していないコンテンツも含めて、ページ上のすべてのコンテンツには以下の達成基準が適用される。なぜならば、これらを満たしていないことにより、ページの利用を妨げる可能性があるためである。
- 1.4.2 - 音声制御、
- 2.1.2 - キーボードトラップなし、
- 2.3.1 - 3回の閃光、又は閾値以下、及び
- 2.2.2 - 一時停止、停止、非表示
注記もし、あるページが適合できないならば (例えば、適合のテストページや事例のページの場合)、そのページを適合の範囲、あるいは、適合表明の範囲に含めることはできない。
この要件は、基本的に、すべての情報がアクセシビリティ サポーテッドであるウェブコンテンツ技術を用いても利用可能である限り、なおかつ、アクセシビリティ サポーテッドではないコンテンツが妨げとなっていない限り、アクセシビリティ サポーテッドではないウェブコンテンツ技術を用いることができるということを述べている。
すべての情報がアクセシビリティ サポーテッドであるウェブコンテンツ技術を用いた適合する方法でも利用可能で、なおかつ、アクセシビリティ サポーテッドではないコンテンツが妨げとなっていない限り、アクセシビリティ サポーテッドではないウェブコンテンツ技術を適合していない方法で用いることができる。
特にページ利用の妨げとなる問題に対処する四つの達成基準がある。これら四つの達成基準は、注記に示されている。各達成基準の注記では、アクセシビリティ サポーテッドではないウェブコンテンツ技術を用いて制作したコンテンツを含むすべてのコンテンツが、これらの達成基準を満たさなければならないことを示している。
あるウェブページが "ZAP" というインタラクティブなグラフィックの新技術を組み込んでいたとする。ZAP はアクセシビリティ サポーテッドではないが、ZAP を用いて提示されている情報が、HTML のページでも提示されている。そのため、ZAP には依存していないことになる。その場合、このページは適合要件 1 を満たしている。しかし、もし利用者が ZAP のコンテンツを Tab キーで移動しようとして、フォーカスが ZAP のオブジェクトの中に入るとそこから抜け出せなくなる。一度中に入ると、利用者はフォーカスを外に出すことができなくなってしまう。そうすると、キーボード利用者は、ページの残り半分を利用することができない。また、ZAP のコンテンツは、様々な速度で明るく閃光を放ち続けていて、静止しない。それにより、注意力欠如 (発達障害) のある利用者は気が散ってしまい、光感受性発作疾患のある利用者は発作を起こしてしまう可能性がある。適合要件 5 は、適合しているページ上でこういった状況が起こらないようにするためのものである。
適合宣言を理解する
適合する上では、適合宣言をすることは必須ではない。しかし、宣言する場合は、適合宣言に必要なすべての情報を提供しなければならない。この情報を提供する方法はいくつか存在する。
Schema.org は、ウェブページ内に開示メタデータを含めるためのそのような選択肢の一つを提供する。記述的なアクセシビリティプロパティの集合は、CreativeWork タイプで利用できる。これは、とりわけ、ページの全体的なアクセシビリティの概要を含める機能 (WCAG 適合宣言など) を提供し、コンテンツのアクセシビリティ機能を説明する機能 (例えば、代替テキスト、拡張解説、キャプションの入手可能性） を説明し、潜在的な危険性 (閃光など) を利用者に警告する。この情報は、RDFa、JSON、及び microdata のいずれかを使用してページに埋め込むことができる。これらのプロパティ及びその期待される値に関する詳細情報は、Web Schemas wiki でも入手できる。
schema.org メタデータで強化された宣言は次のとおり:
<div typeof="WebPage" vocab="http://schema.org/">
<p property="accessibilitySummary">On 23 March 2009, all content available on
the server at <a
href="http://www.wondercall.example.com">http://www.wondercall.example.com</a>
conforms to Web Content Accessibility Guidelines 2.0 at <a
href="https://www.w3.org/TR/2008/REC-WCAG20-20081211/"
>https://www.w3.org/TR/2008/REC-WCAG20-20081211/</a>.
Single-A conformance.</p>
<ul>
<li>The technology that this content "<a>relies upon</a>" is:
HTML 4.01.</li>
<li>The technologies that this content "<strong>uses but does not rely
upon</strong>" are: CSS2, and gif.</li>
<li>This content was tested using the following user agents and assistive
technologies: 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, and Firefox 1.5 on Windows XP SP2 with Screenreader
X 4.0, Safari 2.0 with OS X 10.4.</li>
</ul>
<p>This page includes both <span property="accessMode" content="textual">text</span>
and <span property="accessMode" content="visual">images</span>.
<span property="accessibilityFeature" content="alternativeText">Alternative
text</span> is included for all image content and <span
property="accessibilityFeature" content="longDescription">long
descriptions</span> are also provided for images that require more
than simple alternate text. All content is available in text, which
can be accessed by assistive technology.</p>
</div>
ある日付以降に追加されたコンテンツだけに適合宣言を行いたいことがあるかもしれない。あるいは、ある日付までのコンテンツには WCAG 1.0 への適合宣言を行い、その日付以降に制作又は更新したコンテンツには WCAG 2.0 への適合宣言をしたいこともあるかもしれない。WCAG 2.0 では、どのページが WCAG のどのバージョンに対して適合宣言をしているのかが明確である限り、そういった適合宣言を禁止していない。
「依存」している技術について言及する際、それはウェブコンテンツ技術 (HTML、CSS、JavaScript など) のことであり、ユーザエージェント (ブラウザ、支援技術など) のことではない。
適合宣言は、通常適合の範囲内にある各ウェブページ上に表示しない。
第三者によるコンテンツに伴う部分的な適合宣言
第三者によるコンテンツの実装を、制作者が用いる判断をする場合、WCAG の要件を満たしたものを選択するべきである。ページ上のすべてのコンテンツ (第三者によるコンテンツを含む) が WCAG のすべての達成基準を満たすのであれば、そのページは WCAG に適合していると言える。しかし、制作者の制御が及ばない正当な理由のみによってページが WCAG に適合できない場合は、制作者は部分適合を宣言することができる。ただしこれは不適合であることの声明であり、ページ上の一部のコンテンツにアクセスできない利用者がいるかもしれないことを認識することが重要である。
コンテンツに対して制作者の制御が及ばない理由のひとつは、そのコンテンツが第三者 (ブログ、ポータル、ニュースサイト) によって供給されるからである。また、ウェブページに第三者製のライブラリやプラグイン、ウィジェットが含まれる場合もある。
ウェブページ制作者の承認なく変更される可能性があるコンテンツはすべて監視し、適合していたページが突然不適合に陥ることのないようにすること。監視したり第三者によるコンテンツを修正することが不可能な場合は、そのページの不適合箇所を利用者に明示する必要がある。当該箇所以外が WCAG に適合するウェブページであれば、そのページは部分適合宣言の資格を持つ。
達成基準以上に施した追加措置に関する情報
適合宣言の任意要素の一つに、「アクセシビリティをさらに向上させるために、達成基準以上に施した追加措置に関する情報」がある。これには、適合しているその他の達成基準、実装した参考達成方法、特定の障害者のアクセス又はニーズを助けるために用いた追加の措置に関する情報などが含まれる。利用者がそのページのアクセシビリティを把握する上で役に立つあらゆる情報を含めるとよい。
適合宣言を報告するためのメタデータの使用
コンテンツに適合宣言を添付する最も有用な方法は、機械的に読み取り可能な標準のフォーマットで添付することだろう。この方法が広く普及すれば、検索ツールや特別なユーザエージェントがよりアクセシブルなコンテンツを探して提供するためにこの情報を利用することができるし、ユーザエージェントがコンテンツに適応することができるようになる。適合宣言を行うためのオプションに基づいたメタデータが数多く開発中であり、コンテンツ制作者及びツール開発者にはそれらをサポートすることを推奨する。
加えて、ひとたびレベル A での適合が達成されれば、個々の達成基準への適合を報告するために、メタデータを用いることが可能である。
また、例えば、現在開発中で、適合に関する詳細な情報を機械的に読み取り可能なフォーマットを提供できる Evaluation and Report Language (EARL) のように、プログラムによる報告のフォーマットもある。報告のフォーマットが形式化されて、そのサポートが進めば、ここに追記される予定である。
適合宣言のための達成方法
- SCR38: プログレッシブエンハンスメントで設計されたウェブページに対して、適合している代替版を作成する
- SVR2: 適合しているコンテンツからのみ、適合していないコンテンツにアクセスできるように、.htaccess を使用する
- SVR3: 適合しているコンテンツからのみ、適合していないコンテンツにアクセスできるように、HTTP リファラを使用する
- SVR4: 適合している代替版の表示に関する設定を利用者が行えるようにする
- C29: 適合している代替版を提供するために、スタイルスイッチャーを使用する
- F19: 適合要件 1 の失敗例 － 利用者に対して、不適合なウェブページの適合している代替版を見つける手段を提供していない
- G136: 不適合なウェブページの先頭に、適合している代替版を指すリンクを提供する
- G190: 適合している代替版へのリンクを、不適合のオブジェクトに隣接して、又は関連付けて提供する
適合宣言のための達成方法
- ダブリンコアの要素を用いて WCAG 2.0 への適合宣言を示す (リンク追加予定)
適合レベルを理解する
まず、達成基準であるとみなされるには、満たさなければならない数多くの諸条件がある。次のことが含まれる:
- すべての達成基準は、すべての利用者が直面する可能性があるユーザビリティ問題という側面以上に、障害のある利用者にとって重要なアクセス上の問題でなければならない。言い換えれば、アクセシビリティの問題として考慮されるためには (そして、このようなアクセシビリティ ガイドラインでカバーされるためには)、アクセス上の問題は、障害のない利用者に対して引き起こされる問題よりも、障害のある利用者に対して割合から言ってより重大な問題を引き起こすものでなければならない。
- すべての達成基準は、テスト可能でなければならない。このことは重要である。なぜなら、テスト可能でなければ、あるページが達成基準に適合しているのか、もしくは適合していないのかを判断することができなくなるからである。達成基準が満たされているかどうかを高い信頼水準で判断することが可能である限り、その達成基準は、機械と人間の評価を組み合わせることによってテストすることができる。
ワーキンググループが広範囲に及ぶ相互作用する問題を考慮した後に、達成基準には、三つの適合レベルの中から一つが割り当てられた。レベルを定めた際に用いられた共通の指標には、次のようなものが含まれていた:
- その達成基準が必要不可欠かどうか (言い換えれば、もしその達成基準が満たされなかったとしたら、支援技術でさえもコンテンツをアクセシブルにすることができない)。
- その達成基準が適用されるすべてのウェブサイト及びコンテンツの種類 (例: 様々な主題、コンテンツの種類、ウェブコンテンツ技術の種類) が、その達成基準を満たすことができるかどうか。
- その達成基準が必要とするスキルは、コンテンツ制作者が無理なく習得できるものかどうか (つまり、その達成基準を満たすための知識及びスキルは、1 週間あるいはそれ以下のトレーニングによって習得できるか)。
- その達成基準が、「ルック＆フィール」及び／又はウェブページの機能に制限 (機能、提示、表現の自由、デザイン又は審美的な面において、その達成基準がコンテンツ制作者にかける制限) を強いるかどうか。
- その達成基準が満たされない場合、次善策がないかどうか。
アクセシビリティサポートを理解する
達成基準の多くは、支援技術あるいは主流のユーザエージェントが提供する特別なアクセシビリティ機能 (例えば、メディアプレーヤーが提供する「キャプションを表示」というオプション) を通じて、アクセシビリティを提供することを論じている。つまり、達成基準は、支援技術がコンテンツの情報を問題なく利用者に提示することができるように、ウェブコンテンツにおいてなすべきことを要求している。例を挙げると、あるトピックへ移動するためにクリックすべき画像は、支援技術を含むユーザエージェントがそれを見つけて利用者に示すことができるようにテキストによる代替が提供されていなければ、全盲の利用者にとってはアクセシブルとはいえない。ここで重要なのは、テキストによる代替が、支援技術を含むユーザエージェントが理解できて使用できるような方法、すなわち「アクセシビリティ サポーテッド」な方法で提供されていなければならないということである。
もう一つ例を挙げるとするならば、ウェブページにある独自のコントロールがある。この場合、標準的なユーザエージェントは、利用者にその代替物を提示できるとはかぎらない。しかし、もしそのコントロールの名前 (name)、役割 (role)、値 (value)、設定方法といった情報が、支援技術が理解できて制御可能な方法で提供されていれば、支援技術の利用者はそのコントロールを使用することができるであろう。
新しい技術が登場するときには、支援技術の利用者がそれを使用できるようにするために、次の二つを想定しなければならない。まず、支援技術を含むユーザエージェントが利用者にコンテンツを提示する必要のある情報すべてにアクセスできるように、その技術が設計されていなければならない。次に、ユーザエージェント及び支援技術には、その新しい技術に対応するために変更あるいは修正を行う必要が生じることがある。
「アクセシビリティ サポーテッド」というのは、このどちらもが既になされていて、その技術がユーザエージェント及び支援技術によって利用者が使用可能であることを意味する。
「アクセシビリティ サポーテッド」とするのに必要な支援技術によるサポートのレベル
このトピックは、あるウェブ技術が「アクセシビリティ サポーテッド」であるとみなすには、どれだけ多くの、あるいはどの支援技術がそのウェブ技術をサポートしていなければならないのか、という疑問を生む。WCAG ワーキンググループ及び W3C は、ウェブ技術がアクセシビリティ サポーテッドであるとみなすために、どれだけ多くの、あるいはどの支援技術がそのウェブ技術をサポートしていなければならないということについては特に定めない。なぜなら、これは複雑な要素が絡むことであり、環境や言語の両方によっても異なるからである。このことに関しては、WCAG ワーキンググループ及び W3C だけにとどまらず、広範囲かつ国際的な議論が必要である。このトピックを理解し調査するのに役立つ留意点には、次のようなことが挙げられる:
ウェブ技術のアクセシビリティサポートは環境により異なる。
- ウェブ技術は、企業内で配備される特定のユーザエージェント及び支援技術によってのみサポートされていればよいこともある。(これらのユーザエージェント及び支援技術は、古いバージョンである場合もあれば、最新バージョンである場合もある。)
- 一般に公開されているウェブコンテンツは、古いバージョンを含む、より広範囲のユーザエージェント及び支援技術で利用可能である必要がある。
ウェブ技術のアクセシビリティサポートは、言語 (及び方言) により異なる。
- 古い支援技術のサポートのレベルは、言語及び国によって様々である。中には、無償の支援技術が提供されている環境や国もある。
新しい技術は、古い支援技術ではサポートされない。
- 新しい技術が既存の支援技術全てによってサポート可能でないことは明らかであり、その技術をすべての支援技術によってサポートされるように求めることは不可能である。
一つの古い支援技術によるサポートだけでは、通常は十分とはいえない。
- (ある障害に対して) たった一つの支援技術だけがサポートしていることは、通常は十分とはいえない。コンテンツへアクセスするためにその支援技術を必要とする利用者のほとんどがそれを持っていなくて、その支援技術を購入する金銭的な余裕がない場合は、特にそうである。例外といえるのは、全員がある一つの支援技術を使用している会社の従業員へ配信される情報のみである。
一般の利用者が入手可能な現在の支援技術は、機能が不足していることが多い。
- 障害のある一般の利用者が利用できないコンテンツを制作することは避けなければならない。多くの場合、支援技術を購入するコストは、それを必要とする利用者にとっては高額すぎる。また、無償あるいは低コストの支援技術は、今日では機能が非常に不足していることが多く、これらの支援技術に合わせて非常に低い (もしくは中程度の) レベルに制限する形でウェブコンテンツを制作するのは現実的ではない。このことが、対処していく必要のある、とても困難なジレンマを生んでいる。
そのため、ワーキンググループは、何をもってサポートしているとするかを定義するに留め、どこまで、どれだけ多くの、あるいはどの支援技術がそのウェブ技術をサポートしていなければならないかという判断については、組織、調達、地域社会などにとっての要件を定める各々の状況により近いところにいる地域や団体に委ねることとした。
一般に入手可能で、なおかつ堅牢な支援技術の不足は、利用者、技術開発者、そしてコンテンツ制作者にマイナスの影響を及ぼす問題であり、ワーキンググループは公開の場にてこのトピックについてより多くの議論がなされることを奨励する。
「アクセシビリティサポート」の技術的な定義
基本的に、ウェブコンテンツ技術は、利用者の使用している支援技術が対応していて、かつ、主流なユーザエージェントのアクセシビリティ機能が対応していれば、"アクセシビリティ サポーテッド" である。具体的に言うと、アクセシビリティ サポーテッドな技術であるとみなすには、その技術において次のことが当てはまらなければならない:
アクセシビリティ サポーテッド (accessibility supported) 利用者の支援技術と、ブラウザ及びその他のユーザエージェントにあるアクセシビリティ機能でサポートされていること。
あるウェブコンテンツ技術 (あるいは、ある技術の機能) の使用方法がアクセシビリティ サポーテッドであると認められるためには、そのウェブコンテンツ技術 (あるいは、機能) について、次の 1.と2.の両方が満たされていなければならない:
そのウェブコンテンツ技術の使用方法が、利用者の支援技術によりサポートされていなければならない。これは、その技術の使用方法が、そのコンテンツの自然言語における利用者の支援技術との相互運用性について検証されていることを意味する。
かつ
そのウェブコンテンツ技術には、アクセシビリティ サポーテッドで、利用者が利用できるユーザエージェントがなければならない。これは、少なくとも次の 4 つのうち一つを満たしていることを意味する:
その技術が (HTML や CSS のように)、広く配布されているアクセシビリティ サポーテッドなユーザエージェントに標準でサポートされている。
又は、
その技術が、広く配布されているアクセシビリティ サポーテッドなプラグインでサポートされている。
又は、
そのコンテンツが、大学あるいは企業内ネットワークのような閉じた環境で利用できるものであり、その技術に必要とされていて、その組織で使用されているユーザエージェントがアクセシビリティ サポーテッドである。
又は、
その技術をサポートするユーザエージェントが、アクセシビリティ サポーテッドであって、次のようにダウンロードあるいは購入できる:
- 障害のある人に障害のない人よりも時間や労力がかかるようなことはなく、かつ、
- 障害のある人も障害のない人と同じくらい容易に探して入手することができる。
Accessibility Guidelines Working Group 及び W3C は、あるウェブ技術の特定の使用方法がアクセシビリティ サポーテッドであると分類するために、どの支援技術によるどれだけのサポートが必要なのかを定めない(「アクセシビリティ サポーテッド」とするのに必要な支援技術によるサポートのレベルを参照)。
ウェブ技術は、それらに依存しておらず、かつページ全体が適合要件 4 及び適合要件 5 を含む適合要件を満たしている場合に限り、アクセシビリティ サポーテッドではない方法で用いることができる。
ウェブ技術がアクセシビリティ サポーテッドな方法で用いられている場合、その技術全体、又はその技術の使用方法すべてがアクセシビリティ サポーテッドであるということを暗に示すわけではない。ほとんどの技術は、HTML を含めてアクセシビリティ サポーテッドではない機能、又は使用方法が少なくとも一つある。ウェブページが WCAG に適合するのは、依存する技術のアクセシビリティ サポーテッドな使用方法を用いて WCAG の要件を満たしている場合だけである。
複数のバージョンを有するウェブコンテンツ技術を挙げる際は、アクセシビリティ サポーテッドなバージョンを特定すべきである。
コンテンツ制作者が技術のアクセシビリティ サポーテッドな使用方法を見つける方法の一つは、アクセシビリティ サポーテッドであることが文書化されている使用方法の資料を参考にすることである(ウェブ技術のアクセシビリティ サポーテッドな使用法を理解するを参照)。コンテンツ制作者、企業、技術ベンダー、あるいはその他の者が、ウェブコンテンツ技術のアクセシビリティ サポーテッドな使用方法を文書化してもよい。しかし、文書中の技術の使用方法すべては、前述のアクセシビリティ サポーテッドなウェブコンテンツ技術の定義を満たしていなければならない。
ウェブ技術のアクセシビリティ サポーテッドな使用法を理解する
どのウェブ技術のどの使用法が、支援技術及びユーザエージェントのどのバージョンによって実際にサポートされているかを判断するのに必要な検証作業のすべてを、個々のコンテンツ制作者が行うことは通常不可能である。そのため、コンテンツ制作者は、どの支援技術がどのウェブ技術のどの使用法をサポートしているかについて文書化している公開資料に頼ってもよい。「公開」というのは、必ずしも公的機関によって作成されたものを指すわけではなく、一般に入手可能であるということのみを意味している。誰もが「ウェブ技術の使用法及びそのアクセシビリティサポート」という公開資料を作成することが可能である。資料作成者は、資料を作成し、コンテンツ制作者が参考資料として示すことのできる名前をつけてもよい。その資料が公開されている限り、コンテンツ制作者あるいは利用者などは、ニーズに合った使用法を容易に選択することが可能である。利用者やその他の者は、いずれかの時点で自分の環境又は言語に合致したウェブ技術を選んで、コンテンツを制作すべきウェブ技術を特定することができる。コンテンツ制作者には、精度と有用性において評価されている情報源を用いることを強く推奨する。そして、技術開発者には、その技術のアクセシビリティサポートに関する情報を提供することを強く推奨する。WCAG ワーキンググループは、正確な情報を提供し、コンテンツ制作者と利用者双方にメリットのある文書のみが、長期的に市場の評価を得るものと考えている。
WCAG においては、公開された資料を用いたり、そのような資料にある技術の使用法のみを用いたりすることを要件にしていない。公開された資料は、適合において重要だが少々複雑な部分を、支援技術のサポートに関する専門家ではない (あるいは、単に主流のユーザエージェント及び支援技術の進化を把握する時間がない) コンテンツ制作者にとってより容易にする手法としてのみ説明されている。
コンテンツ制作者や企業などは、アクセシビリティ サポーテッドな技術の使用に関する資料を独自に作成して用いたいと考えるかもしれないし、それは WCAG に適合する上では認められている。一方、利用者、企業などは、用いた独自の資料あるいは公開資料から、その技術の使用法を特定してもよい。ウェブコンテンツ技術の使用法のアクセシビリティ サポートを文書化するを参照のこと。
アクセシビリティサポートに関する記述
アクセシビリティサポートを明文化する適合宣言の方法の例には、次のようなものがある:
- この適合宣言は、コンテンツの言語でのユーザエージェント A、ユーザエージェント B、ユーザエージェント C、及び支援技術 X、支援技術 Y そして支援技術 Z によるコンテンツの検証に基づいた、アクセシビリティサポートの要件を満たしています。これは、それらの製品を用いて、WCAG 2.0 のレベル A の達成基準すべてを満たすことができたことを意味します。
- この適合宣言は、Techniques for WCAG 2.0 に記述されている達成方法及びユーザエージェントノートに基づいて、コンテンツの言語でのアクセシビリティサポートの要件を満たしています。また、(適合する上で依存した) 技術のアクセシビリティサポート文書にも基づいており、「組織 XYZ によるアクセシビリティサポート文書」で参照可能です。
- この適合宣言は、「WCAG 2.0 のための技術 Z のアクセシビリティ サポーテッドな達成方法」で文書化されている技術 Z の使用法を基にして、コンテンツの言語でのアクセシビリティサポートの要件を満たしています。
- この適合宣言は、技術 A のアクセシビリティガイドライン及び技術 B のアクセシビリティガイドラインにある使用法を基にして、コンテンツの言語でのアクセシビリティサポートの要件を満たしています。ユーザエージェント及び支援技術のサポート情報は、それらのガイドラインに記述されている「製品 XYZ アクセシビリティサポート要件」で確認することができます。
「プログラムによる解釈」を理解する
いくつかの達成基準で、コンテンツ (又は、コンテンツの特定の部分) が「プログラムによる解釈」が可能であることを要件としている。これは、コンテンツが、支援技術を含むユーザエージェントがその情報にアクセスできるような方法で制作されていることを意味する。
ウェブコンテンツ技術 (例えば、HTML、CSS、PDF、GIF、MPEG など) を用いて制作されたコンテンツが、様々なタイプの障害のある利用者にとってアクセシブルであるためには、用いられているウェブコンテンツ技術が、支援技術を含むユーザエージェント及びその他のユーザエージェントのアクセシビリティ機能と連携することが必要不可欠である。コンテンツを「プログラムによる解釈」であることを要件としている達成基準に適合するためには、支援技術をサポートしているウェブコンテンツ技術を用いてコンテンツを実装する必要がある。
「プログラムによる解釈」が可能であるコンテンツは、(支援技術を含むユーザエージェントによって、) 個々の利用者が必要とする様々な感覚 (例: 視覚、聴覚) のフォーマット又はプレゼンテーションのスタイルに変換することが可能である。既存の支援技術が変換できない場合には、その情報はプログラムによる解釈が可能であるとはいえない。
この用語を用いているのは、情報が支援技術 (及び、アクセシビリティを支援するその他のユーザエージェント) に対してアクセシブルでなければならない部分を、アクセシブルにするために具体的にどのような方法を用いるかという点に言及せずに、WCAG ワーキンググループがはっきりと特定できるようにするためである。技術が絶え間なく変化しているということを考えると、これは重要なことである。この用語によって、ガイドラインを満たすために、何を「プログラムによる解釈」であるようにする必要があるのかをガイドライン中で特定できるようになる。そして、時間とともに更新可能な文書群 (WCAG 2.0 を満たす方法、WCAG 2.0 解説書、及び、WCAG 2.0 達成方法の文書) を別に用意することができて、ユーザエージェント及び支援技術のサポート状況に基づき、いずれかの時点で目的通りに機能して、十分であると考えられる特定の達成方法を挙げることが可能になる。
「アクセシビリティ サポーテッド」vs.「プログラムによる解釈」
「アクセシビリティ サポーテッド」は、ユーザエージェント (支援技術を含む) によるウェブコンテンツ技術の特定の使い方に対するサポートと関係がある。ウェブコンテンツ技術のアクセシビリティ サポーテッドな使い方は、支援技術及び主流なユーザエージェント (ブラウザ及びプレーヤーなど) のアクセシビリティ機能と連携するものである。
「プログラムによる解釈」は、ウェブコンテンツにある情報と関係がある。アクセシビリティ サポーテッドなウェブコンテンツ技術が適切に用いられているならば、支援技術及びユーザエージェントはコンテンツにある情報にアクセスする (すなわち、コンテンツにある情報をプログラムによる解釈する) ことができて、その情報を利用者に提示することができる。
情報が支援技術を含むユーザエージェントによって利用者に提示可能であるようにするために、この二つの概念は関連しているものである。コンテンツ制作者は、ウェブコンテンツ技術のアクセシビリティ サポーテッドな使い方に依存しなければならない。そして、情報をプログラムによる解釈が可能であるようにするために、その使い方を適切に用いなければならない。そうすることで、情報は支援技術及びユーザエージェントによって障害のある利用者に提示できるようになる。
適合している代替版を理解する
適合要件 1 は、適合している代替版がある限り、適合していないページを適合の範囲内に含めることを許容している。適合している代替版は、次のように定義されている:
適合している代替版 (conforming alternate version) 以下の事項を満たす版のことを指す:
- 指定されたレベルで適合しており、かつ
- 同じ情報及び機能のすべてを同一の自然言語で提供しており、かつ
- 不適合コンテンツと同時に更新されていて、かつ
以下に挙げる事項のうち少なくとも一つを満たしていること:
- アクセシビリティ サポーテッドな メカニズムを用いて、 不適合ページから適合版へ到達できる。もしくは、
- 不適合版に到達できるのは、適合版からのみである。
- 不適合版に到達できるのは、適合版に到達するメカニズムも提供している適合ページからのみである。
この定義において、「到達できるのは……からのみ」とは、利用者が適合版から来ていない限り、不適合ページに「到達する」 (読み込む) のを防ぐ条件付きリダイレクトのような何らかのメカニズムがある、ということを意味する。
代替版は、元のページと一対一で対応している必要はない (例えば、適合している代替版は複数のページであってもよい)。
複数の言語版が利用できる場合、各言語版に対して、適合している代替版を提供する必要がある。
代替版は異なる技術環境やユーザー層に適応するよう提供される。この場合、各版は可能なかぎり適合したものでなければならず、適合要件 1 を満たすためには、そのうちの一つの版が完全に適合したものでなければならない。
不適合版と同じように自由に利用可能であるかぎり、適合している代替版は、適合宣言の範囲に含まれている必要はなく、同一のウェブサイト上で提供されている必要もない。
代替版は、元のページを補助して理解を高める補足コンテンツと混同されないようにすべきである。
コンテンツ内で利用者が設定を行うことで適合版が作り出される仕組みは、その利用者の設定に用いられている手法がアクセシビリティ サポーテッドであるかぎり、代替版への到達メカニズムとして条件を満たしているといえる。
適合している代替版を理解するを参照。
これにより、適合宣言の範囲内にあるページ上のすべての情報及びすべての機能は、適合しているウェブページ上で利用可能になる。
適合している代替版に依存するコンテンツ制作者は、適合している代替版が利用可能であることをエンドユーザに知らせなければならない。これは、リンクテキストで明確に特定される、よりアクセシブルな版へのリンクを提供することで実現できる。あるいは、代替版をよりアクセシブルにする特定の方法 (「ハイコントラスト版」など) だけでなく、そのよりアクセシブルな版にアクセスする方法も文書化した説明書へのリンクを提供してもよい。
なぜ代替版を容認するのか？
なぜ WCAG では、適合宣言に含まれるウェブページの適合している代替版を容認するのか？ 言い換えれば、なぜ適合又は適合宣言の範囲内にあって、その適合レベルにある達成基準に適合していないページを含めるのか？
- 時には、ウェブページが、まだアクセシビリティ サポーテッドではないウェブコンテンツ技術を用いることがある。新しいウェブコンテンツ技術が登場する際、支援技術によるサポートは遅れをとる、又はターゲットとする利用者だけが利用可能になる。そのため、コンテンツ制作者は、すべての利用者に対して新しい技術だけに依存してコンテンツを提供することはできないことがある。しかし、新しい技術を使用することには、その他の利点があるかもしれない。例えば、より良いパフォーマンス、広範囲の感覚モダリティで利用可能、など。代替版の要件は、アクセシブルな代替版をアクセシビリティ サポーテッドなウェブコンテンツ技術で提供することによって、コンテンツ制作者がそのような新しい技術を用いたウェブページをウェブサイトに含めることができるようにするためのものである。十分にサポートされている新しいウェブコンテンツ技術を利用できる人は、その新しいバージョンの利点を享受する。将来のアクセシビリティサポートを見据えているコンテンツ制作者は、代替版のページを提供することによって、今の時点でも達成基準に適合することが可能である。また、支援技術がサポートするようになった際のことを考えて、新しいウェブコンテンツ技術を用いるページでアクセシビリティ機能を組み込んでおくこともできる。
様々な理由から、ウェブページ上のコンテンツを修正できないこともある。例えば、
- 法的又は歴史的な理由で、文書の見た目をそのままコピーしたものを含めることが重要な意味を持っていることがある。
- そのウェブページはあるウェブサイト内にあるが、そのサイトの所有者には元のページにあるコンテンツを修正できる法的な権利がないかもしれない。
- 企業は、過去に公開したものを削除又は部分的に修正するのが法的に不可能なことがある。
- コンテンツ制作者が、他の部署、政府機関、又は企業から、文書を部分的にでも変更するための許可を得ていないかもしれない。
- 時には、ある障害に特別に対応するウェブページを制作することによって、その障害がある利用者にとっての最高の体験を提供することがある。そのような場合、すべての達成基準に適合することによって、ウェブページをすべての障害に対応させることは不可能又は非現実的かもしれない。完全に適合している「代替版」のページがある限り、代替版の要件はそのような特別なページを適合宣言の範囲内に含めることを容認している。
- アクセシビリティに取り組んでいるサイトの多くには、大量の古いウェブページがある。情報はアクセシブルなフォーマットで入手可能になってきているものの、そういったファイルを大量に削除するには、組織的な抵抗がかなり強かったり、手続き上の障壁があったりするものである。特に政府機関などのように、従来の印刷志向のプロセスを優先している組織もある。こういった組織はインターネットでの情報配信に適応し、アクセシブルなフォーマットの必要性も認識しているにもかかわらず、それでもなお紙の発想のままで、「第一の」バージョンとして紙印刷のために設計されたフォーマットにこだわっている (電子的にしか「発行」されたことのない文書に対してもである)。ワーキンググループは、こういったアプローチは今後廃止されていくべきだと考えるが、アクセシブルなバージョンがすぐに入手可能である限りは、禁止できるものではないと考えている。
達成基準に適合していないウェブページを容認する際の懸念事項としては、障害のある利用者がそういった適合していないウェブページに遭遇し、そのコンテンツを利用することができずに、「適合している代替版」も見つけることができない恐れがあることが挙げられる。そのため、代替版の要件で鍵となるのは、適合していないウェブページに遭遇した際に、そのウェブページから適合しているページ (代替版) を見つけられるようにすることである。よって、代替ページを容認する適合要件は、利用者が複数の代替版の中からアクセシブルなバージョンを見つけることができる方法を提供することも要求している。
注意してほしいのは、代替版を提供することは、WCAG に適合するための最後の選択肢であって、望ましい適合方法はすべてのコンテンツをそのままアクセシブルにすることであるという点である。
適合している代替版を提供するための達成方法
適合している代替版を提供する上で最も重要なのは、適合していないバージョンから適合している代替版を見つけるメカニズムを提供することである。ある特定の達成方法が特定のウェブコンテンツ又は状況において常に可能であるとは限らないため、これには数多くの様々な方法がある。例えば、コンテンツ制作者がサーバーを制御できる場合には、利用者が常に前もって選択できるかなり効果的な達成方法がいくつかある。しかし、多くの場合、コンテンツ制作者はウェブサーバー上のサービスを制御することはできない。そういう場合には、他の達成方法がある。適合していないページでリンクを提供するのも効果的な達成方法だが、すべての適合していないウェブコンテンツ技術がハイパーテキストリンクをサポートしているわけではない。
次に挙げるのは、今までに確認されてきた達成方法である。WCAG ワーキンググループでは、時間とともにその他の達成方法も考案されることを期待している。そして、支援技術を含むユーザエージェントによってサポートされていることが実証されれば、それらのアプローチがここに追加されていくだろうと考えている。例えば、支援技術がアクセスできない新しいウェブコンテンツ技術の開発者は、代替版へのリンクを利用者に自動的に提示する機能をそのウェブコンテンツ技術に組み込んでもよい。
ウェブページの適合している代替版を提供する適合要件を満たすことができる達成方法
この節にある番号付きの各項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組み合わせを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。その他の達成方法についての詳細は、WCAG 達成基準の達成方法を理解するの「その他の達成方法」を参照のこと。
- G136: 不適合なウェブページの先頭に、適合している代替版を指すリンクを提供する
- G190: 適合している代替版へのリンクを、不適合のオブジェクトに隣接して、又は関連付けて提供する
- C29: 適合している代替版を提供するために、スタイルスイッチャーを使用する
- SCR38: プログレッシブエンハンスメントで設計されたウェブページに対して、適合している代替版を作成する
- SVR2: 適合しているコンテンツからのみ、適合していないコンテンツにアクセスできるように、.htaccess を使用する
- SVR3: 適合しているコンテンツからのみ、適合していないコンテンツにアクセスできるように、HTTP リファラを使用する
- SVR4: 適合している代替版の表示に関する設定を利用者が行えるようにする
ワーキンググループが確認したよくある適合要件を満たしていない事例
ウェブページの適合している代替版を提供する適合要件でさらに対応が望まれる達成方法 (参考)
- 適合しているバージョンと不適合のバージョンのバージョン間の相互リンクを提供する (リンク追加予定)
- 不適合のコンテンツが検索結果に表示されないようにする (リンク追加予定)
- コンテンツネゴシエーションを利用する (リンク追加予定)
- その技術がオフになっている、又はサポートされていないとき、アクセシビリティ サポーテッドではない技術に依存したコンテンツを表示しない。(future link)
- メタデータを用いて、適合していないページの URI から適合している代替版を発見できるようにする (リンク追加予定)
適合している代替版の事例
複数のバージョンのサイトがあるイントラネット
ある大企業が、イントラネットのサイト上で新しいウェブコンテンツ技術を使うことによって、異なる技術をベースにしている様々な拠点、及び広範囲に及ぶユーザエージェント及び支援技術を使用している個々の従業員のニーズに対処しづらくなるかもしれないという懸念を抱いていた。この懸念を解消するために、その企業は、使用するウェブコンテンツ技術のアクセシビリティ サポーテッドな使用法を限定して、すべてのレベル A 達成基準に適合している代替版のコンテンツを制作した。二つのバージョンは相互にリンクされている。
後方互換性を維持している情報サイト
ある情報サイトは、広範囲に及ぶ話題を網羅していて、利用者が自分の探しているトピックをすぐに見つけ出すことができるようにしたいと考えている。そうするために、そのサイトは、人気のある二つのユーザエージェントの最新バージョンでのみサポートされているインタラクティブなメニューシステムを実装した。その特定のユーザエージェントを使用していない利用者もそのサイトを有効に利用できるようにするため、最新の技術をサポートしていないユーザエージェントには、そのインタラクティブなメニューシステムに依存しないナビゲーションのメカニズムを提供している。
「ウェブページ」を理解する
ウェブページの定義は、次の通りである:
ウェブページ (Web page) 単一の URI から HTTP で得た埋め込まれていないリソースに加え、レンダリングに使われる、又はユーザエージェントがこのリソースと一緒にレンダリングすることを意図しているその他のあらゆるリソースを合わせたもの。
どのような「その他のリソース」も主たるリソースと一緒にレンダリングされるであろうが、これらのリソースが同時にレンダリングされるとは限らない。
このガイドラインの適合範囲に含まれる対象となるウェブページとみなされるためには、リソースが「埋め込まれていない」リソースでなければならない。
すべての埋め込まれている画像とメディアを含んだウェブリソース。
Asynchronous JavaScript and XML (AJAX) を用いたウェブメールのプログラム。そのプログラム全体は http://example.com/mailに存在しているが、受信箱、アドレス帳、カレンダーがある。リンク又はボタンがあり、それを押すと受信箱、アドレス帳やカレンダーを表示するが、ページのURIは全体を通して変わらない。
カスタマイズ可能なポータルサイトで、利用者が様々なコンテンツモジュールのセットから表示させるコンテンツを選択できるようなもの。
ブラウザで"http://shopping.example.com/"へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、ウェブサイトの中のほんの1ページなのかもしれない。
WCAG では、「ウェブページ」という言葉が、静的な HTML ページよりもずっと多くのものを含むものを指していることに注意することが重要である。このガイドラインで用いられている「ウェブページ」という用語によって、ガイドラインがより理解可能なものになる。しかし、この用語の意味は、ウェブコンテンツ技術の進化とともに拡大し、完全に 'ページのようなもの' ではないものが多い、広範囲に及ぶウェブコンテンツ技術を包含するようになってきている。バーチャルでインタラクティブなコミュニティ全体を提示することのできる「ページ」を包含しながら、ウェブ上に登場してますます増えている動的なウェブページも含んでいる。例えば、「ウェブページ」という用語には、単一の URI で提供される、実体験のようにインタラクティブな映画のような体験も含まれている。
「テキストによる代替」を理解する
テキストによる代替とは、非テキストコンテンツを視覚的に認識できない利用者のために、その非テキストコンテンツの代わりに用いられるテキストのことである。非テキストコンテンツには、写真、図、アプレット、音声ファイルなどがある。例えば、見ることができない利用者は、写真又は図で提示されている情報を見ることができない。テキストによる代替はそのために提供されていて、利用者がその情報 (テキストによる代替) を音声に変換することができるようになる。将来は、情報をテキストで持っておくことで、その情報を手話、画像、又は、より平易なテキストに変換できるようになるかもしれない。
障害のある利用者が、このテキストを利用できるようにするためには、テキストは「プログラムによる解釈が可能」でなければならない。つまり、テキストは、障害のある利用者の使用している支援技術 (及び、ブラウザのアクセシビリティ機能) が読むことができて、利用できるものでなければならない。
また、支援技術を使用している利用者が利用することのできない非テキストコンテンツに遭遇した際に、そのテキストによる代替を見つけ出すことが可能でなければならない。そのためには、テキストがその非テキストコンテンツと「プログラムで関連付け」られていなければならない。つまり、利用者が (自分が使えない) 非テキストコンテンツを見つけたら、利用者は自分の支援技術を用いて (自分が利用できる) テキストによる代替を見つけることができなければならない。
重要な用語
利用者の支援技術だけでなく、ブラウザ及びその他のユーザエージェントにあるアクセシビリティ機能でサポートされていること。
あるウェブコンテンツ技術 (又は、ある技術の機能) のアクセシビリティ サポーテッドな使用方法とみなされるためには、そのウェブコンテンツ技術 (又は機能) について、次の 1.と 2.の両方が満たされていなければならない:
そのウェブコンテンツ技術の使用方法が、利用者の支援技術によりサポートされていなければならない。これは、その技術の使用方法が、そのコンテンツの自然言語における利用者の支援技術との相互運用性について検証されていることを意味する。
かつ
そのウェブコンテンツ技術には、利用者が入手できるアクセシビリティ サポーテッドなユーザエージェントがなければならない。これは、次の四つのうち少なくとも一つを満たしていることを意味する:
その技術が、広く配布されているアクセシビリティ サポーテッドなユーザエージェントに標準でサポートされている (HTML、CSS など)。
又は、
その技術が、広く配布されているアクセシビリティ サポーテッドなプラグインでサポートされている。
又は、
そのコンテンツが、大学、企業内ネットワークのような閉じた環境で利用できるものである。この環境で、その技術に必要とされていて、その組織で使用されているユーザエージェントがアクセシビリティ サポーテッドである。
又は、
その技術をサポートするユーザエージェントが、アクセシビリティ サポーテッドであって、次の方法でダウンロード又は購入できる:
- 障害のある人の費用が、障害のない人の費用を上回ることがなく、かつ、
- 障害のある人も、障害のない人と同程度に容易に探して入手できる。
Accessibility Guidelines Working Group 及び W3C は、あるウェブ技術の特定の使用方法がアクセシビリティ サポーテッドであると分類するために、どの支援技術によるどれだけのサポートが必要なのかを定めない (「アクセシビリティ サポーテッド」とするのに必要な支援技術によるサポートのレベルを参照)。
ウェブ技術がアクセシビリティ サポーテッドな方法で用いられている場合、その技術全体、又はその技術の使用方法すべてがアクセシビリティ サポーテッドであるということを暗に示すわけではない。ほとんどの技術は、HTML を含めてアクセシビリティ サポーテッドではない機能、又は使用方法が少なくとも一つある。ウェブページが WCAG に適合するのは、依存する技術のアクセシビリティ サポーテッドな使用方法を用いて WCAG の要件を満たしている場合だけである。
複数のバージョンを有するウェブコンテンツ技術を挙げる際は、アクセシビリティ サポーテッドなバージョンを特定すべきである。
コンテンツ制作者が技術のアクセシビリティ サポーテッドな使用方法を見つける方法の一つは、アクセシビリティ サポーテッドであることが文書化されている使用方法の資料を参照することである (ウェブ技術のアクセシビリティ サポーテッドな使用法を理解するを参照)。コンテンツ制作者、企業、技術ベンダー、又はその他の者が、ウェブコンテンツ技術のアクセシビリティ サポーテッドな使用方法を文書化してもよい。しかし、文書中の技術の使用方法はすべて、上記のアクセシビリティ サポーテッドなウェブコンテンツ技術の定義を満たしている必要がある。
ユーザエージェントとして機能する、又は主流のユーザエージェントと一緒に機能するハードウェア及び／又はソフトウェアで、主流のユーザエージェントで提供されている機能以上の機能を、障害のある利用者の要求を満たすために提供するもの。
支援技術が提供する機能としては、代替の提示 (例: 合成音声や拡大表示したコンテンツ)、代替入力手法 (例: 音声認識)、付加的なナビゲーション又は位置確認のメカニズム、及びコンテンツ変換 (例: テーブルをよりアクセシブルにするもの) などを挙げることができる。
支援技術は、API を利用、監視することで、主流のユーザエージェントとデータやメッセージのやりとりをすることが多い。
主流のユーザエージェントと支援技術との区別は、絶対的なものではない。多くの主流のユーザエージェントは、障害者を支援する機能を提供している。基本的な差異は、主流のユーザエージェントが障害のある人もない人も含めて、広く多様な利用者を対象にしているのに対し、支援技術は、特定の障害のある利用者という、より狭く限られた人たちを対象にしているということである。支援技術により提供される支援は、対象とする利用者に特化した、よりニーズに適したものである。主流のユーザエージェントは、プログラムオブジェクトからのウェブコンテンツの抽出、マークアップの識別可能な構造への解釈といった、重要な機能を支援技術に対して提供する場合がある。
この文書の文脈において重要な支援技術としては、以下のものが挙げられる:
- 画面拡大ソフト及びその他の視覚的な表示に関する支援技術。視覚障害、知覚障害、及び読書困難などの障害のある人が、レンダリング後のテキスト及び画像の視覚的な読みやすさを改善するために、テキストのフォント、サイズ、間隔、色、音声との同期などを変更するのに使用している。
- スクリーンリーダー。全盲の人がテキスト情報を合成音声あるいは点字で読み取るために使用している。
- 音声変換ソフトウェア。認知障害、言語障害、及び学習障害のある人が、テキストを合成音声に変換するために使用している。
- 音声認識ソフトウェア。何らかの身体障害のある利用者が使用することがある。
- 代替キーボード。特定の身体障害のある人がキーボード操作をシミュレートするのに使用している (ヘッドポインタ、シングルスイッチ、呼気・吸気スイッチ、及びその他の特別な入力デバイスを使った代替キーボードを含む)。
- 代替ポインティングデバイス。特定の身体障害のある人がマウスポインタとボタンの動きをシミュレートするのに使用している。
与えられた規格、ガイドライン、又は仕様のすべての要件を満たすこと。
以下の事項を満たす版のことを指す:
- 指定されたレベルで適合しており、かつ
- 同じ情報及び機能のすべてを同一の自然言語で提供しており、かつ
- 不適合コンテンツと同時に更新されていて、かつ
以下に挙げる事項のうち少なくとも一つを満たしていること:
- アクセシビリティ サポーテッドな メカニズムを用いて、 不適合ページから適合版へ到達できる。もしくは、
- 不適合版に到達できるのは、適合版からのみである。
- 不適合版に到達できるのは、適合版に到達するメカニズムも提供している適合ページからのみである。
この定義において、「到達できるのは……からのみ」とは、利用者が適合版から来ていない限り、不適合ページに「到達する」 (読み込む) のを防ぐ条件付きリダイレクトのような何らかのメカニズムがある、ということを意味する。
代替版は、元のページと一対一で対応している必要はない (例えば、適合している代替版は複数のページであってもよい)。
複数の言語版が利用できる場合、各言語版に対して、適合している代替版を提供する必要がある。
異なる技術環境又は利用者層に対応するために、代替版が提供される場合がある。それぞれの版は、可能な限り適合させるべきである。適合要件 1 を満たすためには、一つの版が完全に適合している必要がある。
適合している代替版は、不適合版と同様に自由に利用可能である限り、適合宣言の範囲内に存在する必要はなく、同じウェブサイト上に存在する必要もない。
代替版は、元のページを補助して理解を高める補足コンテンツと混同されないようにすべきである。
コンテンツ内で利用者が設定を行うことで適合版が作り出される仕組みは、その利用者の設定に用いられている手法がアクセシビリティ サポーテッドであるかぎり、代替版への到達メカニズムとして条件を満たしているといえる。
適合している代替版を理解するを参照。
コンテンツの構造、提示、及びインタラクションを定義するコード又はマークアップも含めて、ユーザエージェントによって利用者に伝達される情報及び感覚的な体験。
利用者の操作により実現可能なプロセス及び結果。
人間とコミュニケーションをとるために話される、書かれる、又は (視覚的もしくは触覚的な手段で) 手話にされる言語。
手話も参照。
結果を得るためのプロセス又は手法。
メカニズムは、宣言する適合レベルのすべての達成基準を満たさなければならない。
利用者が知覚できる形式でコンテンツをレンダリングすること。
ある活動を完了させるために必要な利用者の一連の動作。
ショッピングサイト上の一連のウェブページで目的を果たすためには、利用者が選択肢となりうる製品、価格及び内容を閲覧した後、製品を選択して発注し、配送先情報及び支払情報を提供する必要がある。
アカウント登録ページでは、登録フォームにアクセスする前にチューリングテストに成功する必要がある。
ページに適用した際、その達成基準が 'false' と判定されないこと。
意味を伝えるために、手と腕の動き、顔の表情又は身体の姿勢の組み合わせを用いる言語。
元のコンテンツを説明、又はより明確にするために付加されたコンテンツ。
ウェブページの音声版。
複雑なプロセスを示したイラスト。
調査研究でなされた主要な成果及び提言を要約する段落。
ユーザエージェントがどのようにレンダリング、再生、又は実行するかを符号化するメカニズム。
このガイドラインで用いられている「ウェブ技術」及び (単独で用いられている) 「技術」という用語は、どちらもウェブコンテンツ技術を指す。
ウェブコンテンツ技術には、マークアップ言語、データ形式、及びプログラム言語などがあり、これらをコンテンツ制作者が単独で、又は組み合わせて用いることによって、静的なウェブページや同期したメディアによる提示、さらには動的なウェブアプリケーションに至るまでの様々なエンドユーザ体験を作ることができる。
ウェブコンテンツ技術のよくある事例としては、HTML、CSS、SVG、PNG、PDF、Flash、 JavaScript などがある。
ウェブコンテンツを取得して利用者に提示するあらゆるソフトウェア。
ウェブブラウザ、メディアプレーヤ、プラグイン、及びその他のプログラム。その他のプログラムには、ウェブコンテンツの取得、レンダリング、やり取りを支援する支援技術を含む。
単一の URI から HTTP で得た埋め込まれていないリソースに加え、レンダリングに使われる、又はユーザエージェントがこのリソースと一緒にレンダリングすることを意図しているその他のあらゆるリソースを合わせたもの。
どのような「その他のリソース」も主たるリソースと一緒にレンダリングされるであろうが、これらのリソースが同時にレンダリングされるとは限らない。
このガイドラインの適合範囲に含まれる対象となるウェブページとみなされるためには、リソースが「埋め込まれていない」リソースでなければならない。
単体のウェブリソースであり、埋め込まれている画像及びメディアのすべてを含んだもの。
Asynchronous JavaScript and XML (AJAX) を用いたウェブメールのプログラム。そのプログラム全体は http://example.com/mail に存在しているが、受信トレイ、連絡先、カレンダーがある。受信トレイ、連絡先、又はカレンダーを表示するリンク又はボタンが提供されているが、全体としてページの URI は変更されない。
カスタマイズ可能なポータルサイトで、利用者が様々なコンテンツモジュールのセットから表示させるコンテンツを選択できるようなもの。
ブラウザで "http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは 1 ページだけのウェブサイトかもしれないし、ウェブサイトの中のほんの 1 ページなのかもしれない。