適合を理解する

すべての WCAG 2.0 の達成基準は、客観的にコンテンツがその基準を満たしているかどうかを判断できるように、テスト可能な基準として記述されている。達成基準のテストでは、自動的なテストと人間による判断を組み合わせる必要がある。様々な種類の障害のある人がどのようにウェブを利用しているのかを理解している人が、コンテンツをテストすべきである。

ここでいうテストやテスト可能というのは、機能面のテストのことを指している。つまり、コンテンツが想定していた通りに機能することを確認するということである。あるいは、ここでは、達成基準を満たしていることを確認するといってもよい。コンテンツがすべての達成基準を満たしていたとしても、それでも様々な障害のある利用者がそのコンテンツを使うことができるとは限らない。そのため、必要とされる機能面のテストに加えて、ユーザビリティテストを実施することも推奨している。ユーザビリティテスティングは、その用途に応じて、利用者がコンテンツをどれだけうまく使えるかを判断することを目的としている。ユーザビリティテストを実施する際には、テスト参加者に障害のある利用者を含めることを推奨する。

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

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

注記

ある達成基準について、適用対象となるコンテンツを含まないコンテンツにおいては、その達成基準は満たされているということを意味する。

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

適合要件を理解する

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

適合要件 1 を理解する

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

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

また、「適合している代替版」を提供する達成方法を紹介している適合している代替版を理解するも参照のこと。

適合要件 2 を理解する

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

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

注記

適合要件 5 により、たとえページの一部分でアクセシビリティ サポーテッドではないウェブコンテンツ技術を用いていたとしても、それがページの残りの部分の利用を妨げず、すべての情報及び機能がそのページ又はそのページから移動できる別ページのどこかで提供されている限り、ページ全体が適合できる。

適合していないコンテンツを含めることが可能である。適合要件 5 を理解するを参照のこと。

適合要件 3 を理解する

この要件では、プロセス全体が適合していない場合、そのプロセスの一部であるウェブページは適合しているとはみなされないことを述べている。例えば、ショッピングサイトでは、支払あるいはショッピング及び購入プロセスの一部であるその他のサイトの機能が適合していなかったとしたら、そのショッピングサイトは適合していることにならないということである。

適合要件 4 を理解する

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

適合要件 5 を理解する

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

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

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

あるウェブページが "ZAP" というインタラクティブなグラフィックの新技術を組み込んでいたとする。ZAP はアクセシビリティ サポーテッドではあるが、ZAP を用いて提示されている情報が、HTML のページでも提示されている。そのため、ZAP には依存していないことになる。その場合、このページは適合要件 1 を満たしている。しかし、もし利用者が ZAP のコンテンツを Tab キーで移動しようとして、フォーカスが ZAP のオブジェクトの中に入るとそこから抜け出せなくなる。一度中に入ると、利用者はフォーカスを外に出すことができなくなってしまう。そうすると、キーボード利用者は、ページの残り半分を利用することができない。また、ZAP のコンテンツは、様々な速度で明るく閃光を放ち続けていて、静止しない。それにより、注意力欠如 (発達障害) のある利用者は気が散ってしまい、光感受性発作疾患のある利用者は発作を起こしてしまう可能性がある。適合要件 5 は、適合しているページ上でこういった状況が起こらないようにするためのものである。

適合宣言を理解する

適合する上では、適合宣言をすることは必須ではない。しかし、宣言する場合は、適合宣言に必要なすべての情報を提供しなければならない。この情報を提供する方法はいくつか存在する。

Schema.org は、ウェブページ内に開示メタデータを含めるためのそのような選択肢の1つを提供する。記述的なアクセシビリティプロパティの集合は、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) のように、プログラムによる報告のフォーマットもある。報告のフォーマットが形式化されて、そのサポートが進めば、ここに追記される予定である。

事例

適合宣言の必須要素の例

2009 年 3 月 23 日時点で、http://www.wondercall.example.comにあるサーバー上で利用可能なすべてのコンテンツは、http://www.w3.org/TR/2008/REC-WCAG20-20081211/にある WCAG 2.0 にレベル A で適合しています。Level A conformance.

  • この適合宣言において依存している、アクセシビリティ サポーテッドなコンテンツ技術の文書化された一式は、http://ISA.example.gov/AsCTsets/AS2-2008にある ISA- AsCTset#1-2008 の一部である。

(正規表現を用いて) 2009 年 8 月 12 日時点で、http://www.example.com/(marketing|sales|contact)/* は、http://www.w3.org/TR/2008/REC-WCAG20-20081211/にある WCAG 2.0 にレベル AA で適合しています。

  • このコンテンツが「依存」している技術: XHTML 1.0 Transitional、CSS 2.0、及び JavaScript 1.2。

(ブール論理を用いて) 2009 年 1 月 6 日時点で、(http://example.com/archive/又は http://example.com/publications/archive/を除く) http://example.com/は、http://www.w3.org/TR/2008/REC-WCAG20-20081211/にある WCAG 2.0 にレベル AA で適合しています。

  • この適合宣言において依存している、アクセシビリティ サポーテッドなコンテンツ技術の文書化された一式には、http://ISA.example.gov/AsCTsets/AS2-2008にある ISA- AsCTset#1-2008 の XHTML 1.0 及び SMIL があります。

任意要素を含めた適合宣言の例

2009 年 5 月 5 日時点で、「G7: イントロダクション」のページ (http://telcor.example.com/nav/G7/intro.html)は、http://www.w3.org/TR/2008/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。

2009 年 6 月 21 日時点で、http://example.com/nav及び http://example.com/docsという URI で始まるすべてのコンテンツは、http://www.w3.org/TR/2008/REC-WCAG20-20081211/にある WCAG 2.0 にレベル AAA で適合しています。

  • この適合宣言において依存している、アクセシビリティ サポーテッドなコンテンツ技術の文書化された一式は、http://smithreports.example.com/AsCTsets/AS2-2008にある SMITH- AsCTset#2-2008 です。
  • このコンテンツが「依存」している技術: XHTML 1.0 (Strict)、CSS2、JavaScript 1.2、JPEG、PNG。
  • このコンテンツを検証したユーザエージェント (支援技術を含む) は、http://example.com/docs/WCAG20/test/technologies.htmlで確認することができます。

2009 年 3 月 23 日時点で、http://www.wondercall.example.comにあるサーバー上で利用可能なすべてのコンテンツは、http://www.w3.org/TR/2008/REC-WCAG20-20081211/にある WCAG 2.0 にレベル A で適合しています。

  • このコンテンツが「依存」している技術: HTML 4.01。
  • このコンテンツが「使用しているが依存はしていない」技術: CSS2 及び gif。
  • このコンテンツは、次のユーザエージェント及び支援技術を用いて検証しました: Windows Vista 上の Firefox 1.5 及びスクリーンリーダー X 4.0、Windows XP SP2 上の Firefox 1.5 及びスクリーンリーダー X 3.5、Windows 2000 SP4 上の IE 6.0 及びスクリーンリーダー Y 5.0、Windows 2000 SP4 上の IE 6.0 及びスクリーンリーダー Z 2.0、Windows XP SP2 上の Firefox 1.5 及びスクリーンリーダー X 4.0、OS X 10.44 上の Safari 2.0

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

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

  • ダブリンコアの要素を用いて WCAG 2.0 への適合宣言を示す (リンク追加予定)

適合レベルを理解する

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

  1. すべての達成基準は、すべての利用者が直面する可能性があるユーザビリティ問題という側面以上に、障害のある利用者にとって重要なアクセス上の問題でなければならない。言い換えれば、アクセシビリティの問題として考慮されるためには (そして、このようなアクセシビリティ ガイドラインでカバーされるためには)、アクセス上の問題は、障害のない利用者に対して引き起こされる問題よりも、障害のある利用者に対して割合から言ってより重大な問題を引き起こすものでなければならない。
  2. すべての達成基準は、テスト可能でなければならない。このことは重要である。なぜなら、テスト可能でなければ、あるページが達成基準に適合しているのか、もしくは適合していないのかを判断することができなくなるからである。達成基準が満たされているかどうかを高い信頼水準で判断することが可能である限り、その達成基準は、機械と人間の評価を組み合わせることによってテストすることができる。

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

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

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

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

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

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

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

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

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

    • ウェブ技術は、企業内で配備される特定のユーザエージェント及び支援技術によってのみサポートされていればよいこともある。(これらのユーザエージェント及び支援技術は、古いバージョンである場合もあれば、最新バージョンである場合もある。)
    • 一般に公開されているウェブコンテンツは、古いバージョンを含む、より広範囲のユーザエージェント及び支援技術で利用可能である必要がある。
  2. ウェブ技術のアクセシビリティサポートは、言語 (及び方言) により異なる。

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

    • 新しい技術が既存の支援技術全てによってサポート可能でないことは明らかであり、その技術をすべての支援技術によってサポートされるように求めることは不可能である。
  4. 一つの古い支援技術によるサポートだけでは、通常は十分とはいえない。

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

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

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

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

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

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

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

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

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

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

コンテンツ制作者や企業などは、アクセシビリティ サポーテッドな技術の使用に関する資料を独自に作成して用いたいと考えるかもしれないし、それは WCAG に適合する上では認められている。一方、利用者、企業などは、用いた独自の資料あるいは公開資料から、その技術の使用法を特定してもよい。See .

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

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

  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)

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

適合している代替版に依存するコンテンツ制作者は、適合している代替版が利用可能であることをエンドユーザに知らせなければならない。これは、リンクテキストで明確に特定される、よりアクセシブルな版へのリンクを提供することで実現できる。あるいは、代替版をよりアクセシブルにする特定の方法 (「ハイコントラスト版」など) だけでなく、そのよりアクセシブルな版にアクセスする方法も文書化した説明書へのリンクを提供してもよい。

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

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

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

    • 法的又は歴史的な理由で、文書の見た目をそのままコピーしたものを含めることが重要な意味を持っていることがある。
    • そのウェブページはあるウェブサイト内にあるが、そのサイトの所有者には元のページにあるコンテンツを修正できる法的な権利がないかもしれない。
    • 企業は、過去に公開したものを削除又は部分的に修正するのが法的に不可能なことがある。
    • コンテンツ制作者が、他の部署、政府機関、又は企業から、文書を部分的にでも変更するための許可を得ていないかもしれない。
  • 時には、ある障害に特別に対応するウェブページを制作することによって、その障害がある利用者にとっての最高の体験を提供することがある。そのような場合、すべての達成基準に適合することによって、ウェブページをすべての障害に対応させることは不可能又は非現実的かもしれない。完全に適合している「代替版」のページがある限り、代替版の要件はそのような特別なページを適合宣言の範囲内に含めることを容認している。
  • アクセシビリティに取り組んでいるサイトの多くには、大量の古いウェブページがある。情報はアクセシブルなフォーマットで入手可能になってきているものの、そういったファイルを大量に削除するには、組織的な抵抗がかなり強かったり、手続き上の障壁があったりするものである。特に政府機関などのように、従来の印刷志向のプロセスを優先している組織もある。こういった組織はインターネットでの情報配信に適応し、アクセシブルなフォーマットの必要性も認識しているにもかかわらず、それでもなお紙の発想のままで、「第一の」バージョンとして紙印刷のために設計されたフォーマットにこだわっている (電子的にしか「発行」されたことのない文書に対してもである)。ワーキンググループは、こういったアプローチは今後廃止されていくべきだと考えるが、アクセシブルなバージョンがすぐに入手可能である限りは、禁止できるものではないと考えている。

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

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

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

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

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

ウェブページの適合している代替版を提供する適合要件を満たすことができる達成方法

この節にある番号付きの各項目は、WCAG ワーキンググループがこの達成基準を満たすのに十分であると判断する達成方法、又は複数の達成方法の組み合わせを表している。しかしながら、必ずしもこれらの達成方法を用いる必要はない。他の達成方法の利用については、具体的にはその他の達成方法のセクションを参照のこと。

  1. G136: 不適合なウェブページの先頭に、適合している代替版を指すリンクを提供する
  2. G190: 適合している代替版へのリンクを、不適合のオブジェクトに隣接して、又は関連付けて提供する
  3. C29: 適合している代替版を提供するために、スタイルスイッチャーを使用する
  4. SCR38: プログレッシブエンハンスメントで設計されたウェブページに対して、適合している代替版を作成する
  5. SVR2: 適合しているコンテンツからのみ、適合していないコンテンツにアクセスできるように、.htaccess を使用する
  6. SVR3: 適合しているコンテンツからのみ、適合していないコンテンツにアクセスできるように、HTTP リファラを使用する
  7. SVR4: 適合している代替版の表示に関する設定を利用者が行えるようにする

ワーキンググループが確認したよくある適合要件を満たしていない事例

ウェブページの適合している代替版を提供する適合要件でさらに対応が望まれる達成方法 (参考)

  • 適合しているバージョンと不適合のバージョンのバージョン間の相互リンクを提供する (リンク追加予定)
  • 不適合のコンテンツが検索結果に表示されないようにする (リンク追加予定)
  • コンテンツネゴシエーションを利用する (リンク追加予定)
  • その技術がオフになっている、又はサポートされていないとき、アクセシビリティ サポーテッドではない技術に依存したコンテンツを表示しない。(future link)
  • メタデータを用いて、適合していないページの URI から適合している代替版を発見できるようにする (リンク追加予定)

適合している代替版の事例

  • 複数のバージョンのサイトがあるイントラネット

    ある大企業が、イントラネットのサイト上で新しいウェブコンテンツ技術を使うことによって、異なる技術をベースにしている様々な拠点、及び広範囲に及ぶユーザエージェント及び支援技術を使用している個々の従業員のニーズに対処しづらくなるかもしれないという懸念を抱いていた。この懸念を解消するために、その企業は、使用するウェブコンテンツ技術のアクセシビリティ サポーテッドな使用法を限定して、すべてのレベル A 達成基準に適合している代替版のコンテンツを制作した。二つのバージョンは相互にリンクされている。

  • 後方互換性を維持している情報サイト

    ある情報サイトは、広範囲に及ぶ話題を網羅していて、利用者が自分の探しているトピックをすぐに見つけ出すことができるようにしたいと考えている。そうするために、そのサイトは、人気のある二つのユーザエージェントの最新バージョンでのみサポートされているインタラクティブなメニューシステムを実装した。その特定のユーザエージェントを使用していない利用者もそのサイトを有効に利用できるようにするため、最新の技術をサポートしていないユーザエージェントには、そのインタラクティブなメニューシステムに依存しないナビゲーションのメカニズムを提供している。

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

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

ウェブページ (Web page)

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

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

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

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

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