WCAG 2.0 への適合を理解する

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

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

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

適合要件を理解する

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

適合要件 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. 技術のアクセシビリティ サポーテッドな使用方法だけ: 達成基準を満たすために、用いる技術のアクセシビリティ サポーテッドな使用方法だけに依存している。アクセシビリティ サポーテッドではない方法で提供されている情報又は機能は、アクセシビリティ サポーテッドな方法でも利用できる (Understanding accessibility support を参照)。

この適合要件は、後述のアクセシビリティ サポートを理解するで説明されている。

適合要件 5 を理解する

5. 非干渉: 技術がアクセシビリティ サポーテッドではない方法で用いられている場合、又は適合しない方法で用いられている場合、利用者がウェブページの他の部分へアクセスすることを妨げていない。加えて、全体としてウェブページは、以下のそれぞれの条件の下で適合要件を満たしていること:

1. 依存していない技術がユーザエージェントで有効になっているとき

2. 依存していない技術がユーザエージェントで無効になっているとき、及び

3. 依存していない技術がユーザエージェントでサポートされていないとき

さらに、適合するために依存していないコンテンツも含めて、ページ上のすべてのコンテンツには以下の達成基準が適用される。なぜならば、これらを満たしていないことにより、ページの利用を妨げる可能性があるためである。

• 1.4.2 - 音声制御、

• 2.1.2 - キーボードトラップなし、

• 2.3.1 - 3回の閃光、又は閾値以下、及び

• 2.2.2 - 一時停止、停止、非表示

この要件は、基本的に、すべての情報がアクセシビリティ サポーテッドであるウェブコンテンツ技術を用いても利用可能である限り、なおかつ、アクセシビリティ サポーテッドではないコンテンツが妨げとなっていない限り、アクセシビリティ サポーテッドではないウェブコンテンツ技術を用いることができるということを述べている。

すべての情報がアクセシビリティ サポーテッドであるウェブコンテンツ技術を用いた適合する方法でも利用可能で、なおかつ、アクセシビリティ サポーテッドではないコンテンツが妨げとなっていない限り、アクセシビリティ サポーテッドではないウェブコンテンツ技術を適合していない方法で用いることができる。

特にページ利用の妨げとなる問題に対処する四つの達成基準がある。これら四つの達成基準は、注記に示されている。各達成基準の注記では、アクセシビリティ サポーテッドではないウェブコンテンツ技術を用いて制作したコンテンツを含むすべてのコンテンツが、これらの達成基準を満たさなければならないことを示している。

適合宣言を理解する

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

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

第三者によるコンテンツに伴う部分的な適合宣言

第三者によるコンテンツの実装を、制作者が用いる判断をする場合、WCAG の要件を満たしたものを選択するべきである。ページ上のすべてのコンテンツ (第三者によるコンテンツを含む) が WCAG のすべての達成基準を満たすのであれば、そのページは WCAG に適合していると言える。しかし、制作者の制御が及ばない正当な理由のみによってページが WCAG に適合できない場合は、制作者は部分適合を宣言することができる。ただしこれは不適合であることの声明であり、ページ上の一部のコンテンツにアクセスできない利用者がいるかもしれないことを認識することが重要である。

コンテンツに対して制作者の制御が及ばない理由のひとつは、そのコンテンツが第三者 (ブログ、ポータル、ニュースサイト) によって供給されるからである。また、ウェブページに第三者製のライブラリやプラグイン、ウィジェットが含まれる場合もある。

ウェブページ制作者の承認なく変更される可能性があるコンテンツはすべて監視し、適合していたページが突然不適合に陥ることのないようにすること。監視したり第三者によるコンテンツを修正することが不可能な場合は、そのページの不適合箇所を利用者に明示する必要がある。当該箇所以外が WCAG に適合するウェブページであれば、そのページは部分適合宣言の資格を持つ。

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

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

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

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

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

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

適合宣言の例

適合宣言のための達成方法

適合レベルを理解する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   • ウェブ技術は、企業内で配備される特定のユーザエージェント及び支援技術によってのみサポートされていればよいこともある。(これらのユーザエージェント及び支援技術は、古いバージョンである場合もあれば、最新バージョンである場合もある。)

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

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

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

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

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

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

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

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

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

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

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

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

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

アクセシビリティ サポーテッド (accessibility supported)

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

あるウェブコンテンツ技術 (あるいは、ある技術の機能) の使用方法がアクセシビリティ サポーテッドであると認められるためには、そのウェブコンテンツ技術 (あるいは、機能) について、次の 1. と 2. の両方が満たされていなければならない:

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

   かつ

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

   1. その技術が (HTML や CSS のように)、広く配布されているアクセシビリティ サポーテッドなユーザエージェントに標準でサポートされている。

      又は、

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

      又は、

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

      又は、

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

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

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

注記 1: WCAG Working Group ならびに W3C は、あるウェブ技術のある特定の使用方法がアクセシビリティ サポーテッドであると分類するために、そのウェブ技術の特定の使用方法に対して、どの支援技術によるどれだけのサポートが必要なのかを定めない (Level of Assistive Technology Support Needed for "Accessibility Support"を参照)。

注記 2: そのウェブ技術に依存しておらず、適合要件 4: 技術のアクセシビリティ サポーテッドな使用方法だけ及び適合要件 5: 非干渉を含む適合要件をウェブページ全体が満たしている場合は、そのウェブ技術をアクセシビリティ サポーテッドではない方法で用いることができる。

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

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

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

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

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

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

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

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

適合している代替版を理解する

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

適合している代替版 (conforming alternate version)

以下の事項を満たす版のことを指す:

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

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

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

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

   1. アクセシビリティ サポーテッドな メカニズムを用いて、 不適合ページから適合版へ到達できる。もしくは、

   2. 不適合版に到達できるのは、適合版からのみである。

   3. 不適合版に到達できるのは、適合版に到達するメカニズムも提供している適合ページからのみである。

注記 1: この定義において、「到達できるのは……からのみ」とは、利用者が適合版から来ていない限り、不適合ページに「到達する」 (読み込む) のを防ぐ条件付きリダイレクトのような何らかのメカニズムがある、ということを意味する。

注記 2: 代替版は、元のページと一対一で対応している必要はない (例えば、適合している代替版は複数のページであってもよい)。

注記 3: 複数の言語版が利用できる場合、各言語版に対して、適合している代替版を提供する必要がある。

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

注記 5: 不適合版と同じように自由に利用可能であるかぎり、適合している代替版は、適合宣言の範囲に含まれている必要はなく、同一のウェブサイト上で提供されている必要もない。

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

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

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

なぜ代替版を容認するのか？

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

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

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

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

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

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

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

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

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

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

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

適合している代替版を提供するための達成方法

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

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

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

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

ウェブページ (Web page)

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

注記 1: どのような「その他のリソース」も主たるリソースと一緒にレンダリングされるであろうが、これらのリソースが同時にレンダリングされるとは限らない。

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

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

事例 2: Asynchronous JavaScript and XML (AJAX) を用いたウェブメールのプログラム。そのプログラム全体は http://example.com/mail に存在しているが、受信箱、アドレス帳、カレンダーがある。リンクまたはボタンがあり、それを押すと受信箱、アドレス帳やカレンダーを表示するが、ページの URI は全体を通して変わらない。

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

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

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

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

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

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

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