WCAG 2.0への適合を理解する

適合とは何を意味するのか？

一般的に、基準への適合とは、その基準の「要件」に適合している、あるいは満たしていることを意味する。WCAG 2.0 において、「要件」となるのは達成基準である。WCAG 2.0に適合するためには、達成基準を満たす必要がある。つまり、達成基準に反するコンテンツがないということである。

ほとんどの標準には、適合レベルは一つしかない。しかし、より高いレベルのアクセシビリティを要求したり可能にしたりする様々な状況に対応するために、WCAG 2.0 には3つの適合レベルがあり、そのため達成基準にも3つのレベルがある。

適合要件を理解する

コンテンツが WCAG 2.0 に「適合している」とみなされるためには、満たさなければならない5つの要件がある。この節では、それらの要件に関する簡単な注釈を提供する。なお、この節は、今後寄せられる質問に対処するため、あるいは様々な適合要件を満たす方法の新しい事例を提供するために、時間とともに拡充されていく予定である。

適合要件 1 を理解する

1. 適合レベル: 以下に挙げる適合レベルの一つを完全に満たしていること。

• レベル A： レベル A（適合の最低レベル）で適合するには、ウェブページがすべてのレベル A 達成基準を満たすか、又は適合した代替バージョンを提供する。

• レベル AA： レベル AA で適合するには、ウェブページはすべてのレベル A 及びレベル AA 達成基準を満たすか、又はレベル AA に適合した代替バージョンを提供する。

• レベル AAA： レベル AAA で適合するには、ウェブページがすべてのレベル A、レベル AA、及びレベル AAA 達成基準を満たすか、又はレベル AAA に適合した代替バージョンを提供する。

注記 1： ウェブページは、宣言したレベルでのみ WCAG 2.0 に適合できるが、コンテンツ制作者は、そのレベルよりも高いレベルの達成基準の達成状況を（適合宣言中で）示すことを推奨されている。

注記 2： コンテンツの中には、レベル AAA のすべての達成基準を満たすことのできないものもあるため、サイト全体の制作方針としてレベル AAA での適合を要件とすることは推奨しない。

最初の要件は、適合レベルに関するものである。基本的には、ページ上のすべての情報が適合している、もしくは、そのページから利用可能な適合している代替バージョンがあるということである。また、この要件は、少なくともレベル A の達成基準すべてを満たさなければどのレベルでも適合することはできないということも説明している。

注記が指摘しているのは、特定のレベルでの適合に留まらずに、より高いレベルの適合に向けても取り組み、もし自分たちが望むのであればその進捗状況を報告することをコンテンツ制作者に推奨するということである。

また、「適合している代替バージョン」を提供する実装方法を紹介している「適合している代替バージョンを理解する」も参照のこと。

適合要件 2 を理解する

2. ウェブページ全体: 適合性（及び適合レベル）はウェブページ全体のみに対するものであり、ウェブページの一部が除外されている場合には認められない。

注記 1： 適合性を判断するときに、例えば、画像の詳細な説明又は映像の代替表現のように、代替コンテンツをそのウェブページから直接得られる場合は、ウェブページの一部のコンテンツに対する代替コンテンツをそのウェブページの一部であるとみなす。

注記 2： コンテンツ制作者が制御できないコンテンツがあるために適合できないウェブページについては、部分適合に関する記述を行うことを検討するとよい。

この要件は、ページ全体が適合することを単に求めている。「ページの一部が適合している」という適合宣言をすることはできないのである。

あるページ上の情報への補足情報が他のページで提供されることがある。HTML の longdesc 属性がその一例である。longdesc 属性を用いると、その画像のあるページから利用者が移動できる別のページで画像の長い説明文を提供することができる。この注記では、そのような別ページのコンテンツも元のページの一部であると考えて、単一のウェブページであるとみなされる複数のウェブページによって適合要件 2 が満たされるということを明確にしている。また、代替を同一ページ上で提供することも可能である。例としては、ユーザーインタフェースのコントロールと等価なものを作成することが挙げられる。

適合要件 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つの達成基準は、注記に示されている。各達成基準の注記では、アクセシビリティ・サポーテッドではないウェブコンテンツ技術を用いて制作したコンテンツを含むすべてのコンテンツが、これらの達成基準を満たさなければならないことを示している。

適合宣言を理解する

適合する上では、適合宣言をすることは必須ではない。しかし、適合宣言をする際には、従わなければならないルールがある。

ある日付以降に追加されたコンテンツだけに適合宣言を行いたいことがあるかもしれない。あるいは、ある日付までのコンテンツには WCAG 1.0 への適合宣言を行い、その日付以降に制作又は更新したコンテンツには WCAG 2.0 への適合宣言したいこともあるかもしれない。WCAG 2.0 では、どのページが WCAG のどのバージョンに対して適合宣言をしているのかが明確である限り、そういった適合宣言を禁止していない。

達成基準以上に施した追加措置に関する情報

適合宣言の任意要素の一つに、「アクセシビリティをさらに向上させるために、達成基準以上に施した追加措置に関する情報」がある。これには、適合しているその他の達成基準、実装した参考にすべき実装方法、特定の障害者のアクセス又はニーズを助けるために用いた追加の措置に関する情報などが含まれる。利用者がそのページのアクセシビリティを把握する上で役に立つあらゆる情報を含めるとよい。

適合宣言を報告するためのメタデータの使用

コンテンツに適合宣言を添付する最も有用な方法は、機械的に読み取り可能な標準のフォーマットで添付することだろう。この方法が広く普及すれば、検索ツールや特別なユーザーエージェントがよりアクセシブルなコンテンツを探して提供するためにこの情報を利用することができるし、ユーザーエージェントがコンテンツに適応することができるようになる。適合宣言を行うためのオプションに基づいたメタデータが数多く開発中であり、コンテンツ制作者及びツール開発者にはそれらをサポートすることを推奨する。

加えて、ひとたびレベル A での適合が達成されれば、個々の達成基準への適合を報告するために、メタデータを用いることが可能である。

また、例えば、現在開発中で、適合に関する詳細な情報を機械的に読み取り可能なフォーマットを提供できる Evaluation and Report Language (EARL) のように、プログラムによる報告のフォーマットもある。報告のフォーマットが形式化されて、そのサポートが進めば、ここに追記される予定である。

適合宣言の例

適合宣言のための実装方法

適合レベルを理解する

まず、達成基準であるとみなされるには、満たさなければならない数多くの諸条件がある。次のことが含まれる：

1. すべての達成基準は、すべての利用者が直面する可能性があるユーザビリティ問題という側面以上に、障害のある利用者にとって重要なアクセス上の問題でなければならない。言い換えれば、アクセシビリティの問題として考慮されるためには（そして、このようなアクセシビリティ・ガイドラインでカバーされるためには）、アクセス上の問題は、障害のない利用者に対して引き起こされる問題よりも、障害のある利用者に対して割合から言ってより重大な問題を引き起こすものでなければならない。

2. すべての達成基準は、テスト可能でなければならない。このことは重要である。なぜなら、テスト可能でなければ、あるページが達成基準に適合しているのか、もしくは適合していないのかを判断することができなくなるからである。達成基準が満たされているかどうかを高い信頼水準で判断することが可能である限り、その達成基準は、機械と人間の評価を組み合わせることによってテストすることができる。

ワーキンググループが広範囲に及ぶ相互作用する問題を考慮した後に、達成基準には、3つの適合レベルの中から1つが割り当てられた。レベルを定めた際に用いられた共通の指標には、次のようなものが含まれていた：

• その達成基準が必要不可欠かどうか（言い換えれば、もしその達成基準が満たされなかったとしたら、支援技術でさえもコンテンツをアクセシブルにすることができない）。

• その達成基準が適用されるすべてのウェブサイト及びコンテンツの種類（例： 様々な主題、コンテンツの種類、ウェブコンテンツ技術の種類）が、その達成基準を満たすことができるかどうか。

• その達成基準が必要とするスキルは、コンテンツ制作者が無理なく習得できるものかどうか（つまり、その達成基準を満たすための知識及びスキルは、1週間あるいはそれ以下のトレーニングによって習得できるか）。

• その達成基準が、「ルック＆フィール」及び/又はウェブページの機能に制限（機能、プレゼンテーション、表現の自由、デザイン又は審美的な面において、その達成基準がコンテンツ制作者にかける制限）を強いるかどうか。

• その達成基準が満たされない場合、次善策がないかどうか。

アクセシビリティ・サポートを理解する

達成基準の多くは、支援技術あるいは主流のユーザーエージェントが提供する特別なアクセシビリティ機能（例えば、メディアプレーヤーが提供する「キャプションを表示」というオプション）を通じて、アクセシビリティを提供することを論じている。つまり、達成基準は、支援技術がコンテンツの情報を問題なく利用者に提示することができるように、ウェブコンテンツにおいてなすべきことを要求している。例を挙げると、あるトピックへ移動するためにクリックすべき画像は、支援技術を含むユーザーエージェントがそれを見つけて利用者に示すことができるように代替テキストが提供されていなければ、全盲の利用者にとってはアクセシブルとはいえない。ここで重要なのは、代替テキストが、支援技術を含むユーザーエージェントが理解できて使用できるような方法、すなわち「アクセシビリティ・サポーテッド」な方法で提供されていなければならないということである。

もう一つ例を挙げるとするならば、ウェブページにある独自のコントロールがある。この場合、標準的なユーザーエージェントは、利用者にその代替物を提示できるとはかぎらない。しかし、もしそのコントロールの識別名、役割、値、設定方法といった情報が、支援技術が理解できて制御可能な方法で提供されていれば、支援技術の利用者はそのコントロールを使用することができるであろう。

新しい技術が登場するときには、支援技術の利用者がそれを使用できるようにするために、次の2つを想定しなければならない。まず、支援技術を含むユーザーエージェントが利用者にコンテンツを提示する必要のある情報すべてにアクセスできるように、その技術が設計されていなければならない。次に、ユーザーエージェント及び支援技術には、その新しい技術に対応するために変更あるいは修正を行う必要が生じることがある。

「アクセシビリティ・サポーテッド」というのは、このどちらもが既になされていて、その技術がユーザーエージェント及び支援技術によって利用者が使用可能であることを意味する。

「アクセシビリティ・サポーテッド」とするのに必要な支援技術によるサポートのレベル

このトピックは、あるウェブ技術が「アクセシビリティ・サポーテッド」であるとみなすには、どれだけ多くの、あるいはどの支援技術がそのウェブ技術をサポートしていなければならないのか、という疑問を生む。WCAG ワーキンググループ及び W3C は、ウェブ技術がアクセシビリティ・サポーテッドであるとみなすために、どれだけ多くの、あるいはどの支援技術がそのウェブ技術をサポートしていなければならないということについては特に定めない。なぜなら、これは複雑な要素が絡むことであり、環境や言語の両方によっても異なるからである。このことに関しては、WCAG ワーキンググループ及び W3C だけにとどまらず、広範囲かつ国際的な議論が必要である。このトピックを理解し調査するのに役立つ留意点には、次のようなことが挙げられる：

1. ウェブ技術のアクセシビリティ・サポートは環境により異なる。

   • 特定のユーザーエージェント及び支援技術が従業員すべてに提供されている企業では、ウェブ技術はそのユーザーエージェント及び古い支援技術によってサポートされていればよいこともある。

   • 一般に公開されているウェブコンテンツは、より広範囲のユーザーエージェント及び支援技術で利用可能である必要がある。

2. ウェブ技術のアクセシビリティ・サポートは、言語（及び方言）により異なる。

   • 古い支援技術のサポートのレベルは、言語及び国によって様々である。中には、無償の支援技術が提供されている環境や国もある。

3. 新しい技術は、古い支援技術ではサポートされない。

   • 新しい技術が既存の支援技術全てによってサポート可能でないことは明らかであり、その技術をすべての支援技術によってサポートされるように求めることは不可能である。

4. 一つの古い支援技術によるサポートだけでは、通常は十分とはいえない。

   • （ある障害に対して）たった一つの支援技術だけがサポートしていることは、通常は十分とはいえない。コンテンツへアクセスするためにその支援技術を必要とする利用者のほとんどがそれを持っていなくて、その支援技術を購入する金銭的な余裕がない場合は、特にそうである。例外といえるのは、全員がある一つの支援技術を使用している会社の従業員へ配信される情報のみである。

5. 一般の利用者が入手可能な現在の支援技術は、機能が不足していることが多い。

   • 障害のある一般の利用者が利用できないコンテンツを制作することは避けなければならない。多くの場合、支援技術を購入するコストは、それを必要とする利用者にとっては高額すぎる。また、無償あるいは低コストの支援技術は、今日では機能が非常に不足していることが多く、これらの支援技術に合わせて非常に低い（もしくは中程度の）レベルに制限する形でウェブコンテンツを制作するのは現実的ではない。このことが、対処していく必要のある、とても困難なジレンマを生んでいる。

そのため、ワーキンググループは、何をもってサポートしているとするかを定義するに留め、どこまで、どれだけ多くの、あるいはどの支援技術がそのウェブ技術をサポートしていなければならないかという判断については、組織、調達、地域社会などにとっての要件を定める各々の状況により近いところにいる地域や団体に委ねることとした。

一般に入手可能で、なおかつ堅牢な支援技術の不足は、利用者、技術開発者、そしてコンテンツ制作者にマイナスの影響を及ぼす問題であり、ワーキンググループは公開の場にてこのトピックについてより多くの議論がなされることを奨励する。

「アクセシビリティ・サポート」の技術的な定義

基本的に、ウェブコンテンツ技術は、利用者の使用している支援技術が対応していて、かつ、主流なユーザーエージェントのアクセシビリティ機能が対応していれば、"アクセシビリティ・サポーテッド" である。具体的に言うと、アクセシビリティ・サポーテッドな技術であるとみなすには、その技術において次のことが当てはまらなければならない：

アクセシビリティ・サポーテッド

ブラウザおよびその他のユーザエージェントにあるアクセシビリティ機能と同様に、ユーザの支援技術でもサポートされている。

ウェブコンテンツ技術（あるいは、ウェブコンテンツ技術の機能）のアクセシビリティ・サポーテッドな使用であると見なすには、次の 1. と 2. の両方がそのウェブコンテンツ技術（あるいは、機能）で満たされなければならない：

1. ウェブコンテンツ技術の使用方法が、ユーザの支援技術 (AT) によりサポートされていなければならない。これは、そのウェブコンテンツ技術の使用方法がコンテンツの自然言語においてユーザの支援技術との相互運用性を検証されていることを意味する。

   かつ

2. そのウェブコンテンツ技術には、利用者が利用可能で、アクセシビリティ・サポーテッドでもあるユーザエージェントがなければならない。これは、少なくとも次の一つを満たしていることを意味する：

   1. そのウェブコンテンツ技術が、（HTMLやCSSといったウェブコンテンツ技術がそうであるように、）広く配布されているアクセシビリティ・サポーテッドなユーザエージェントで元々サポートされている。

      又は、

   2. そのウェブコンテンツ技術が、アクセシビリティ・サポーテッドな広く配布されているプラグインでサポートされている。

      又は、

   3. そのコンテンツが、例えば大学あるいは企業内ネットワークのような閉じた環境で利用可能であって、そのウェブコンテンツ技術が必要とし、その組織で使用されているユーザエージェントもアクセシビリティ・サポーテッドである。

      又は、

   4. そのウェブコンテンツ技術をサポートするユーザエージェントが、アクセシビリティ・サポーテッドであって、次のようにダウンロードあるいは購入可能である：

      • 障害のない人よりも障害のある人に時間や労力がかかるようなことはなく、かつ、

      • 障害のない人と同じくらい容易に障害のある人も探して入手することができる。

注記 1： WCAG ワーキンググループならびに W3C は、ウェブコンテンツ技術のある特定の使用方法がアクセシビリティ・サポーテッドであると分類するために、そのウェブコンテンツ技術の特定の使用方法に対して、どの支援技術のサポートあるいは支援技術によるどれだけのサポートが必要なのかを指定しない（「アクセシビリティ・サポーテッド」とするのに必要な支援技術によるサポートのレベルを参照のこと）。

注記 2： そのウェブコンテンツ技術に依存していなくて、適合要件 4: ウェブコンテンツ技術のアクセシビリティ・サポーテッドな使用方法のみおよび適合要件 5: 非干渉を含む適合要件をウェブページ全体が満たしているかぎり、そのウェブコンテンツ技術をアクセシビリティ・サポーテッドではない方法で用いることができる。

注記 3： ウェブコンテンツ技術がアクセシビリティ・サポーテッドな方法で用いられている場合、そのウェブコンテンツ技術全体又はそのウェブコンテンツ技術の使用方法すべてがアクセシビリティ・サポーテッドであるということを暗に示すわけではない。ほとんどのウェブコンテンツ技術は、HTML を含めてアクセシビリティ・サポーテッドではない機能又は使用方法が少なくとも一つある。ウェブページが WCAG に適合するのは、ウェブコンテンツ技術のアクセシビリティ・サポーテッドな使用方法を用いて WCAG の要件を満たしている場合だけである。

注記 4： 複数のバージョンを有するウェブコンテンツ技術を挙げる際は、アクセシビリティ・サポーテッドなバージョンを特定すべきである。

注記 5： コンテンツ制作者がウェブコンテンツ技術のアクセシビリティ・サポーテッドな使用方法を見つける方法の一つは、アクセシビリティ・サポーテッドであることが文書化されている使用方法の資料を参考にすることである（ウェブ技術のアクセシビリティ・サポーテッドな使用法を理解するを参照のこと）。コンテンツ制作者、企業、技術ベンダー、あるいはその他の者が、ウェブコンテンツ技術のアクセシビリティ・サポーテッドな使用方法を文書化してもよい。しかし、文書中のウェブコンテンツ技術の使用方法すべては、前述のアクセシビリティ・サポーテッドなウェブコンテンツ技術の定義を満たしていなければならない。

ウェブ技術のアクセシビリティ・サポーテッドな使用法を理解する

どのウェブ技術のどの使用法が、支援技術及びユーザーエージェントのどのバージョンによって実際にサポートされているかを判断するのに必要な検証作業のすべてを、個々のコンテンツ制作者が行うことは通常不可能である。そのため、コンテンツ制作者は、どの支援技術がどのウェブ技術のどの使用法をサポートしているかについて文書化している公開資料に頼ってもよい。「公開」というのは、必ずしも公的機関によって作成されたものを指すわけではなく、一般に入手可能であるということのみを意味している。誰もが「ウェブ技術の使用法及びそのアクセシビリティ・サポート」という公開資料を作成することが可能である。資料作成者は、資料を作成し、コンテンツ制作者が参考資料として示すことのできる名前をつけてもよい。その資料が公開されている限り、コンテンツ制作者あるいは利用者などは、ニーズに合った使用法を容易に選択することが可能である。利用者やその他の者は、いずれかの時点で自分の環境又は言語に合致したウェブ技術を選んで、コンテンツを制作すべきウェブ技術を特定することができる。コンテンツ制作者には、精度と有用性において評価されている情報源を用いることを強く推奨する。そして、技術開発者には、その技術のアクセシビリティ・サポートに関する情報を提供することを強く推奨する。WCAGワーキンググループは、正確な情報を提供し、コンテンツ制作者と利用者双方にメリットのある文書のみが、長期的に市場の評価を得るものと考えている。

WCAG においては、公開された資料を用いたり、そのような資料にある技術の使用法のみを用いたりすることを要件にしていない。公開された資料は、適合において重要だが少々複雑な部分を、支援技術のサポートに関する専門家ではない（あるいは、単に主流のユーザーエージェント及び支援技術の進化を把握する時間がない）コンテンツ制作者にとってより容易にする手法としてのみ説明されている。

コンテンツ制作者や企業などは、アクセシビリティ・サポーテッドな技術の使用に関する資料を独自に作成して用いたいと考えるかもしれないし、それは WCAG に適合する上では認められている。一方、利用者、企業などは、用いた独自の資料あるいは公開資料から、その技術の使用法を特定してもよい。「附録 B ウェブコンテンツ技術の使用法のアクセシビリティ・サポートを文書化する」を参照のこと。

アクセシビリティ・サポートに関する記述

アクセシビリティ・サポートを明文化する適合宣言の方法の例には、次のようなものがある：

1. この適合宣言は、コンテンツの言語でのユーザーエージェント A、ユーザーエージェント B、ユーザーエージェント C、及び支援技術 X、支援技術 Y そして支援技術 Z によるコンテンツの検証に基づいた、アクセシビリティ・サポートの要件を満たしています。これは、それらの製品を用いて、WCAG 2.0 のレベル A の達成基準すべてを満たすことができたことを意味します。

2. この適合宣言は、Techniques for WCAG 2.0 に記述されている実装方法及びユーザーエージェント・ノートに基づいて、コンテンツの言語でのアクセシビリティ・サポートの要件を満たしています。また、（適合する上で依存した）技術のアクセシビリティ・サポート文書にも基づいており、「組織 XYZ によるアクセシビリティ・サポート文書」で参照可能です。

3. この適合宣言は、「WCAG 2.0 のための技術 Z のアクセシビリティ・サポーテッドな実装方法」で文書化されている技術 Z の使用法を基にして、コンテンツの言語でのアクセシビリティ・サポートの要件を満たしています。

4. この適合宣言は、技術 A のアクセシビリティ・ガイドライン及び技術 B のアクセシビリティ・ガイドラインにある使用法を基にして、コンテンツの言語でのアクセシビリティ・サポートの要件を満たしています。ユーザーエージェント及び支援技術のサポート情報は、それらのガイドラインに記述されている「製品 XYZ アクセシビリティ・サポート要件」で確認することができます。

「プログラムが解釈」を理解する

いくつもの達成基準で、コンテンツ（又は、コンテンツの特定の部分）が「プログラムが解釈」できることを要件としている。これは、コンテンツが、支援技術を含むユーザーエージェントがその情報にアクセスできるような方法で制作されていることを意味する。

ウェブコンテンツ技術（例えば、HTML、CSS、PDF、GIF、MPEG、Flash など）を用いて制作されたコンテンツが、様々なタイプの障害のある利用者にとってアクセシブルであるためには、用いられているウェブコンテンツ技術が、支援技術を含むユーザーエージェント及びその他のユーザーエージェントのアクセシビリティ機能と連携することが必要不可欠である。コンテンツを「プログラムが解釈」できることを要件としている達成基準に適合するためには、支援技術をサポートしているウェブコンテンツ技術を用いてコンテンツを実装する必要がある。

「プログラムが解釈」できるコンテンツは、（支援技術を含むユーザーエージェントによって、）個々の利用者が必要とする様々な感覚（例： 視覚、聴覚）のフォーマット又はプレゼンテーションのスタイルに変換することが可能である。既存の支援技術が変換できない場合には、その情報は「プログラムが解釈」できるとはいえない。

この用語を用いているのは、情報が支援技術（及び、アクセシビリティを支援するその他のユーザーエージェント）に対してアクセシブルでなければならない部分を、アクセシブルにするために具体的にどのような方法を用いるかという点に言及せずに、WCAG ワーキンググループがはっきりと特定できるようにするためである。技術が絶え間なく変化しているということを考えると、これは重要なことである。この用語によって、ガイドラインを満たすために、何を「プログラムが解釈」できるようにする必要があるのかをガイドライン中で特定できるようになる。そして、時間とともに更新可能な文書群（WCAG 2.0を満たす方法、WCAG 2.0解説書、及び、WCAG 2.0実装方法の文書）を別に用意することができて、ユーザーエージェント及び支援技術のサポート状況に基づき、いずれかの時点で目的通りに機能して、十分であると考えられる特定の実装方法を挙げることが可能になる。

「アクセシビリティ・サポーテッド」vs.「プログラムが解釈」

「アクセシビリティ・サポーテッド」は、ユーザーエージェント（支援技術を含む）によるウェブコンテンツ技術の特定の使い方に対するサポートと関係がある。ウェブコンテンツ技術のアクセシビリティ・サポーテッドな使い方は、支援技術及び主流なユーザーエージェント（ブラウザ及びプレーヤーなど）のアクセシビリティ機能と連携するものである。

「プログラムが解釈」は、ウェブコンテンツにある情報と関係がある。アクセシビリティ・サポーテッドなウェブコンテンツ技術が適切に用いられているならば、支援技術及びユーザーエージェントはコンテンツにある情報にアクセスする（すなわち、コンテンツにある情報をプログラムが解釈する）ことができて、その情報を利用者に提示することができる。

情報が支援技術を含むユーザーエージェントによって利用者に提示可能であるようにするために、この2つの概念は関連しているものである。コンテンツ制作者は、ウェブコンテンツ技術のアクセシビリティ・サポーテッドな使い方に依存しなければならない。そして、情報をプログラムが解釈できるようにするために、その使い方を適切に用いなければならない。そうすることで、情報は支援技術及びユーザーエージェントによって障害のある利用者に提示できるようになる。

適合している代替バージョンを理解する

適合要件 1 は、適合している代替バージョンがある限り、適合していないページを適合の範囲内に含めることを許容している。適合している代替バージョンは、次のように定義されている：

適合している代替バージョン

以下の事項を満たすバージョンのことを指す：

1. 指定されたレベルで適合しており、かつ

2. 同じ情報および機能のすべてを同一の自然言語で提供しており、かつ

3. 適合していないコンテンツと同時に更新されていて、かつ

4. 以下に挙げる事項のうち少なくとも一つを満たしていること：

   1. アクセシビリティ・サポーテッド メカニズムを用いて、適合していないウェブページから適合しているバージョンへ移動できる。もしくは、

   2. 適合しているバージョンからのみ適合していないバージョンへ移動できる。もしくは、

   3. 適合しているバージョンへ移動するメカニズムも提供している適合しているウェブページからのみ、適合していないバージョンへ移動できる。

注記 1： この定義においては、「･･･からのみ･･･へ移動できる」とは、条件付きのリダイレクトのような何らかのメカニズムがあり、利用者が特定のウェブページから来ないかぎり、利用者が適合していないウェブページに「たどり着く」（適合していないウェブページを読み込む）ことがない、ということを意味する。

注記 2： 代替バージョンは、元のウェブページと一対一で対応している必要はない（例えば、適合した代替バージョンは複数のウェブページであってもよい）。

注記 3： 複数の言語版がある場合、各言語版に対して、適合した代替バージョンを提供する必要がある。

注記 4： 様々な技術環境又は利用者層に対応するために、複数の代替バージョンを提供してもよい。この場合、各バージョンは可能なかぎり適合したものでなければならず、適合要件 1を満たすためには、そのうちの一つのバージョンが完全に適合したものでなければならない。

注記 5： 適合していないバージョンと同じように自由に利用可能であるかぎり、適合した代替バージョンは、適合宣言の対象のウェブページ群に含まれている必要はなく、元のウェブページと同じウェブサイト上で提供されている必要もない。

注記 6： 代替バージョンは、元のウェブページを補助して理解を高める補足的なコンテンツと混同されないようにすべきである。

注記 7： コンテンツ内で利用者が設定を行うことで適合したバージョンが作り出される仕組みは、その利用者の設定に用いられている手法がアクセシビリティ・サポーテッドであるかぎり、代替バージョンへの移動メカニズムとして条件を満たしているといえる。

これにより、適合宣言の範囲内にあるページ上のすべての情報及びすべての機能は、適合しているウェブページ上で利用可能になる。

なぜ代替バージョンを容認するのか？

なぜ WCAG では、適合宣言に含まれるウェブページの適合している代替バージョンを容認するのか？　言い換えれば、なぜ適合又は適合宣言の範囲内にあって、その適合レベルにある達成基準に適合していないページを含めるのか？

• 時には、ウェブページが、まだアクセシビリティ・サポーテッドではないウェブコンテンツ技術を用いることがある。新しいウェブコンテンツ技術が登場する際、支援技術によるサポートは遅れをとる、又はターゲットとする利用者だけが利用可能になる。そのため、コンテンツ制作者は、すべての利用者に対して新しい技術だけに依存してコンテンツを提供することはできないことがある。しかし、新しい技術を使用することには、その他の利点があるかもしれない。例えば、より良いパフォーマンス、広範囲の感覚モダリティで利用可能、など。代替バージョンの要件は、アクセシブルな代替バージョンをアクセシビリティ・サポーテッドなウェブコンテンツ技術で提供することによって、コンテンツ制作者がそのような新しい技術を用いたウェブページをウェブサイトに含めることができるようにするためのものである。十分にサポートされている新しいウェブコンテンツ技術を利用できる人は、その新しいバージョンの利点を享受する。将来のアクセシビリティ・サポートを見据えているコンテンツ制作者は、代替バージョンのページを提供することによって、今の時点でも達成基準に適合することが可能である。また、支援技術がサポートするようになった際のことを考えて、新しいウェブコンテンツ技術を用いるページでアクセシビリティ機能を組み込んでおくこともできる。

• 様々な理由から、ウェブページ上のコンテンツを修正できないこともある。例えば、

  • 法的又は歴史的な理由で、文書の見た目をそのままコピーしたものを含めることが重要な意味を持っていることがある。

  • そのウェブページはあるウェブサイト内にあるが、そのサイトの所有者には元のページにあるコンテンツを修正できる法的な権利がないかもしれない。

  • 企業は、過去に公開したものを削除又は部分的に修正するのが法的に不可能なことがある。

  • コンテンツ制作者が、他の部署、政府機関、又は企業から、文書を部分的にでも変更するための許可を得ていないかもしれない。

• 時には、ある障害に特別に対応するウェブページを制作することによって、その障害がある利用者にとっての最高の体験を提供することがある。そのような場合、すべての達成基準に適合することによって、ウェブページをすべての障害に対応させることは不可能又は非現実的かもしれない。完全に適合している「代替バージョン」のページがある限り、代替バージョンの要件はそのような特別なページを適合宣言の範囲内に含めることを容認している。

• アクセシビリティに取り組んでいるサイトの多くには、大量の古いウェブページがある。情報はアクセシブルなフォーマットで入手可能になってきているものの、そういったファイルを大量に削除するには、組織的な抵抗がかなり強かったり、手続き上の障壁があったりするものである。特に政府機関などのように、従来の印刷志向のプロセスを優先している組織もある。こういった組織はインターネットでの情報配信に適応し、アクセシブルなフォーマットの必要性も認識しているにもかかわらず、それでもなお紙の発想のままで、「第一の」バージョンとして紙印刷のために設計されたフォーマットにこだわっている（電子的にしか「発行」されたことのない文書に対してもである）。ワーキンググループは、こういったアプローチは今後廃止されていくべきだと考えるが、アクセシブルなバージョンがすぐに入手可能である限りは、禁止できるものではないと考えている。

達成基準に適合していないウェブページを容認する際の懸念事項としては、障害のある利用者がそういった適合していないウェブページに遭遇し、そのコンテンツを利用することができずに、「適合している代替バージョン」も見つけることができない恐れがあることが挙げられる。そのため、代替バージョンの要件で鍵となるのは、適合していないウェブページに遭遇した際に、そのウェブページから適合しているページ（代替バージョン）を見つけられるようにすることである。よって、代替ページを容認する適合要件は、利用者が複数の代替バージョンの中からアクセシブルなバージョンを見つけることができる方法を提供することも要求している。

注意してほしいのは、代替バージョンを提供することは、WCAG に適合するための最後の選択肢であって、望ましい適合方法はすべてのコンテンツをそのままアクセシブルにすることであるという点である。

適合している代替バージョンを提供するための実装方法

適合している代替バージョンを提供する上で最も重要なのは、適合していないバージョンから適合している代替バージョンを見つけるメカニズムを提供することである。ある特定の実装方法が特定のウェブコンテンツ又は状況において常に可能であるとは限らないため、これには数多くの様々な方法がある。例えば、コンテンツ制作者がサーバーを制御できる場合には、利用者が常に前もって選択できるかなり効果的な実装方法がいくつかある。しかし、多くの場合、コンテンツ制作者はウェブサーバー上のサービスを制御することはできない。そういう場合には、他の実装方法がある。適合していないページでリンクを提供するのも効果的な実装方法だが、すべての適合していないウェブコンテンツ技術がハイパーテキストリンクをサポートしているわけではない。

次に挙げるのは、今までに確認されてきた実装方法である。WCAG ワーキンググループでは、時間とともにその他の実装方法も考案されることを期待している。そして、支援技術を含むユーザーエージェントによってサポートされていることが実証されれば、それらのアプローチがここに追加されていくだろうと考えている。例えば、支援技術がアクセスできない新しいウェブコンテンツ技術の開発者は、代替バージョンへのリンクを利用者に自動的に提示する機能をそのウェブコンテンツ技術に組み込んでもよい。

「ウェブページ」を理解する

ウェブページの定義は、次の通りである：

ウェブページ

単一の URI から HTTP で得たリソース（埋め込まれていないリソース）と、 ユーザエージェントがこのリソースと一緒にレンダリングすることを意図したりレンダリングに用いたりするその他のリソース（埋め込まれているリソース）を合わせたもの。

注記 1： どのような「その他のリソース」（埋め込まれているリソース）も主たるリソース（埋め込まれていないリソース）と一緒にレンダリングされるであろうが、これらのリソースが同時にレンダリングされる必要があるわけではない。

注記 2： このガイドラインの適合範囲に含まれる対象となるウェブページは、「埋め込まれていない」リソースでなければならない。

事例 1： すべての埋め込まれている画像とメディアを含んだウェブリソース。

事例 2： Ajax を用いたウェブメールのプログラム。そのプログラムは http://example.com/mail に存在しており、受信箱、アドレス帳、そしてカレンダーがある。受信箱、アドレス帳やカレンダーを起動するリンク又はボタンがあるが、ウェブページ全体の URI は変わらないもの。

事例 3： カスタマイズ可能なポータルサイトで、利用者が様々なコンテンツのモジュール一式から表示させるコンテンツを選択できるようなもの。

事例 4： ブラウザで"http://shopping.example.com/" へ行くと、映画のようなインタラクティブなショッピング環境になる。そこでは、視覚的に店内を移動して、店内の棚から商品をドラッグして、目の前にある視覚的な買物カゴに商品を入れる。商品をクリックすると、同時に仕様書が浮き上がるように表示される。これは1ページだけのウェブサイトかもしれないし、 ウェブサイトの中のほんの1ページなのかもしれない。

WCAGでは、「ウェブページ」という言葉が、静的な HTML ページよりもずっと多くのものを含むものを指していることに注意することが重要である。このガイドラインで用いられている「ウェブページ」という用語によって、ガイドラインがより理解可能なものになる。しかし、この用語の意味は、ウェブコンテンツ技術の進化とともに拡大し、完全に 'ページのようなもの' ではないものが多い、広範囲に及ぶウェブコンテンツ技術を包含するようになってきている。バーチャルでインタラクティブなコミュニティ全体を提示することのできる「ページ」を包含しながら、ウェブ上に登場してますます増えている動的なウェブページも含んでいる。例えば、「ウェブページ」という用語には、単一の URI で提供される、実体験のようにインタラクティブな映画のような体験も含まれている。

「代替テキスト」を理解する

代替テキストとは、非テキストコンテンツを視覚的に認識できない利用者のために、その非テキストコンテンツの代わりに用いられるテキストのことである。非テキストコンテンツには、写真、図、アプレット、音声ファイルなどがある。例えば、見ることができない利用者は、写真又は図で提示されている情報を見ることができない。代替テキストはそのために提供されていて、利用者がその情報（代替テキスト）を音声に変換することができるようになる。将来は、情報をテキストで持っておくことで、その情報を手話、画像、又は、より平易なテキストに変換できるようになるかもしれない。

障害のある利用者が、このテキストを利用できるようにするためには、テキストは「プログラムが解釈」できなければならない。つまり、テキストは、障害のある利用者の使用している支援技術（及び、ブラウザのアクセシビリティ機能）が読むことができて、利用できるものでなければならない。

また、支援技術を使用している利用者が利用することのできない非テキストコンテンツに遭遇した際に、その代替テキストを見つけ出すことが可能でなければならない。そのためには、テキストがその非テキストコンテンツと「プログラムで関連付け」られていなければならない。つまり、利用者が（自分が使えない）非テキストコンテンツを見つけたら、利用者は自分の支援技術を用いて（自分が利用できる）代替テキストを見つけることができなければならない。