【注意】 この文書は、W3C/WAIが公開している「About Baseline and WCAG 2.0　ver. 1.0」（原文は英語）を、財団法人日本規格協会情報技術標準化研究センター 情報アクセシビリティ国際標準化に関する調査研究開発委員会ウェブアクセシビリティ国際規格調査研究部会が日本語に翻訳したものです。このワーキングドラフトの正式な文書は、あくまでW3Cのサイト内にある英語版であり、この文書には翻訳上の間違い、あるいは不適切な表現が含まれている可能性がありますのでご注意ください。また、リンク先が英語の場合、あるいはダミーのページである場合もあります。ご了承ください。

W3C logoWeb Accessibility Initiative (WAI) logo

WAI: Strategies, guidelines, resources to make the Web accessible to people with disabilities

ベースラインと WCAG 2.0 について

このページのコンテンツ

背景

World Wide Web は、Web Content Accessibility Guidelines (WCAG) 1.0 が1999年に勧告になって以来、見違えるほどに発達してきた。WCAG 1.0 は、Web のユーザーは主にHTMLを使用しているだろうと想定して書かれたものである。今日では、Web は1999年当時には不可能だったような様々な方法で使用されている。Web コミュニティは情報を広めてやりとりをするために新しくて独自の方法を見つけるので、多くの新しい Web 技術が出現しており、既存の技術はより広範囲に及んでいる。また、言語、経済格差、およびその他の要因から、世界のある地域では普及している技術も、他の地域では存在していなかったり、遅れていたりすることがある。

こういった現実をふまえて、WCAG ワーキンググループは、ガイドラインのバージョン 2.0 を形づくるには、異なる基盤を見つけ出さねばならないと考えた。今日のあらゆる技術にまたがって通用し、技術における劇的な転換や変化に耐えうるしっかりとした原則として、Web アクセシビリティを提示しなければならない。そして、WCAG 2.0 は、広範囲に及ぶ W3C 技術および W3Cでない技術に対応しなければならない。ポリシー策定者やサイト運営者には、国によって互換性のないガイドラインとならないように技術と文化の相違点を許容しながらも、アクセシブルな Web コンテンツを制作しようとするときにどんな成果物が必要なのかに関するガイダンスを提供する必要がある。

こういったニーズを解決するために、ワーキンググループは技術に依存しないガイドラインと達成基準を開発してきた。これらは、Web Content Accessibility Guidelines 2.0 という文書で提示されている。このガイドライン文書には、事例および WCAG 2.0 の達成基準を満たすのに十分なテクニックのリストを提供する、Understanding WCAG 2.0 という参考情報の文書が付随している。この2つのレイヤーによるアプローチにより、アクセシビリティの安定した基準を、技術の進歩および達成基準を満たす新しい方法の出現にあわせて更新可能な技術文書のサポートと併せ持つことが可能となる。/p>

このモデルでキーとなる要素は、ユーザーエージェントがサポートすると判断できる技術一式を定義できるかどうかである。支援技術を含むユーザーエージェントが全ての新しい技術を発表されたその日にサポートするものと想定するのは妥当ではない。（支援技術を含む）ユーザーエージェントで利用可能で動作すると想定しうる技術を定義する、何らかのメカニズムが必要である。しかしながら、ワーキンググループは、WCAG 1.0 が時代遅れになってしまったので、何らかの技術一式を選んで、それを WCAG 2.0 の中で定義すること（公然と、あるいは達成基準の定義を通じて）が新しいガイドラインをすぐに時代遅れにしてしまうことになると考えた。それは、将来において新しい技術を用いたアクセシブルである Web コンテンツが、新しい技術を用いているがゆえに適合を宣言できる可能性を狭めてしまうことにもなる。

このようにして何度となくこの問題を解決しようとした結果（技術一式を定義するために、User Agent Accessibility Guidelines (UAAG) 1.0 を用いようとしたことも含めて; 以下参照）、ワーキンググループは、この問題を解決できる唯一の手段は新しいコンセプトを導入することだという結論に至った。："ベースライン" である。

ベースラインとは何か？

WCAG 2.0 の中で用いられている "ベースライン" というのは、制作者がアクセシブルなユーザーエージェントによってサポートされ動作可能であると想定する技術の一式を指す。制作者は、Web コンテンツの全ての情報および機能が、たとえユーザーエージェントがそのベースラインにある技術だけをサポートしているときでも、WCAG 2.0 に適合するようにしなければならない。

ベースラインは、政府機関、クライアント、組織、制作者、あるいはこれらの組合せにより設定される。制作者が WCAG 2.0 への適合を主張する際には、その主張をするのに用いているベースラインを特定しなければならない。その主張において、もしユーザーエージェントがベースラインに挙げられている技術をサポートできているならば、コンテンツはその適合レベルにおいて WCAG 2.0 の要件を満たしているということを主張することになる。実際には、制作者はベースラインにある技術の幾つか（サブセット）だけを利用している、ということもあるだろう。

ベースラインにない技術が用いられることもありうるが、その Web コンテンツの全ての情報および機能は、ベースラインにない技術全てがオンでもオフでも、適合していなければならない。ユーザーの中には、ベースラインにない技術をサポートしているブラウザを使用していないユーザーもいるかもしれないが、使用しているユーザーもいることが考えられるので、両方の条件が必要となる。

ベースラインの事例（および、それらが意味すること）

事例 1 ベースライン: HTML 4.01 Transitional、 .GIF、 ならびに .JPEG

このベースラインを用いた適合は、全てのコンテンツがこれらの技術をサポートしている全てのユーザーエージェントに対して（制作者が主張するレベルにおいて）WCAG 2.0 に適合しているということを意味する。

このベースラインには、今日最も広く用いられている画像フォーマットである .GIF と .JPEG の画像に加えて、HTML 4.01 がある。この極めて限定されたベースラインは、その対象ユーザーにどのユーザーエージェントが入手可能であるかについて、少ししか、あるいはほとんど分からないようなときに、とても広範囲のユーザーを対象にしたコンテンツに対しては適切かもしれない。このベースラインを用いる制作者は、適合するためにはこの3つの技術だけを利用することになるだろう。そして制作者は、『Understanding WCAG 2.0』 にある "十分である" と説明されている HTML 4.01 のテクニックを用いるだろう（制作者は、『Understanding WCAG 2.0』に "参考" （オプション）として挙げられている追加の HTML テクニックも用いて、ユーザー・エクスペリエンスをさらに向上することもできる）。

事例 2 ベースライン: HTML 4.01、CSS、GIF、JPEG、ならびに JavaScript

そのサイトで頻繁にアクセスされるセクションへナビゲートするための "クイック・リンク" のリストを提供している Web サイトのシナリオを考えてみよう。達成基準 3.2.2 は、Web ユニットでそのふるまいを説明するインストラクションが該当するコントロールの前にないかぎり、あらゆるフォームのコントロールあるいはフィールドの設定が変わることで状況の変化を引き起こしてはならないことを要求している。JavaScript がベースラインに挙げられているので、適合したコンテンツを制作するには、『Understanding WCAG 2.0』で "十分である" として挙げられているスクリプトのテクニックを利用することができる。そして、JavaScript がオフになっているときに機能する代替コンテンツを提供する必要はない。達成基準 3.2.2 のケースにおいては、このことは "選択された要素に応じてコンテンツを隠したり見せたりする" というスクリプトのテクニックを、全般的なテクニックである "状況の変化を起こすサブミット・ボタンを提供する" とともに用いれば十分であるということを意味する。

事例 3 ベースライン: HTML 4.01、CSS、GIF、JPEG、MOV、AVI、MP3、RM、RT

この事例では、マルチメディア技術がベースラインに含まれている。そのため、キャプションと音声ガイドのついたムービーが、レベル 1 での適合には十分である、ということになる。前述の事例 1 および事例 2 にあるベースラインの下では適合を主張する Web ユニットには当てはまるものの、このベースラインでは全ての情報を他のアクセシブルなフォーマットで提供する必要はない。

上記事例の注意点

Javascript

事例 2 には、ベースラインに Javascript がある。そのため、言及された Javascript のテクニックがその達成基準を満たすには十分である。しかしながら、JavaScript は事例 1 では挙げられていないため、これと同じスクリプトのテクニックを用いることは事例 1 のベースラインでは十分ではない。その代わりに、HTML テクニックの "HTMLでサブミット・ボタンを提供する" を全般的なテクニックである "状況の変化を起こすサブミット・ボタンを提供する" とあわせて用いることで十分となる。JavaScript は他の目的でもその Web ユニットで用いられるかもしれないが、JavaScriptに依存しないアクセシブルな代替コンテンツが必要とされる。

ここにベースラインというコンセプトがどのように機能するかを垣間見ることができる。ユーザーの（支援技術を含む）ユーザーエージェント全てが JavaScript をサポートしているだろうと想定するのが無難な環境においては、事例 2 のベースラインを用いる（そして、JavaScript を使用する）のが妥当だといえるだろう。もし、ユーザーの（支援技術を含む）ユーザーエージェントが JavaScript をサポートしていると考えられないのであれば、事例 1 のベースラインが唯一妥当なものとなる（JavaScriptを使用することはできるが、それに依存しない）。 このように、JavaScript は使用可能だが、JavaScript をオフにしているか、動作しない状態でも、全ての情報および機能がアクセシブルである必要がある。

マルチメディア

事例 1 および事例 2 のベースラインには、オーディオやビデオのようなマルチメディア技術が含まれていない。その Web ユニットにマルチメディアを含めることはできるだろうか？　答えは、イエスだ。しかし、オーディオやビデオのフォーマットはこれらの事例のベースラインにはないので、この技術を情報および機能を提供する唯一の手段として利用することはできない。もし Web ページが（事例 1 あるいは事例 2 のベースラインの下で）マルチメディアを使用するのであれば、全ての情報および機能をベースラインにある技術 "のみ" を用いて入手可能にした、そのコンテンツのアクセシブルなバージョンが必要となる。マルチメディアのコンテンツがアップデートされたときは、必ずその代替バージョンもアップデートされなければならない。例えば、この代替バージョンは、（そのマルチメディアにぴったり合致する）マルチメディアのテキストによる脚本であるかもしれない。

ベースラインの指定は、ブラウザの指定ではない

ベースラインは、"この Web コンテンツは IE 6.0 で利用するのが最適です" というような記述とは違う。これはベースラインとしては無効な記述である。ベースラインは、ブラウザあるいはユーザーエージェントを特定できるものではない。技術の一式である。そこには、微妙だが重要な差異がある。ベースラインに挙げられる技術のタイプとしては、これらに限定されないが、以下のようなものがある。

これらは、コンテンツを制作する、あるいはユーザーエージェントによりユーザーに入手可能とするために用いられる技術の種類である。ベースラインというのは、上記の種類に属する特定の技術のリストになる。

ユーザーエージェントではなく、技術を特定するのが重要である理由の一つは、ユーザーを特定のユーザーエージェントのみに限定するのは、あるユーザーに対して克服することのできないアクセシビリティ上の問題をもたらすからである。おそらく、そのコンテンツがクローズドな環境で使われるためのものでないかぎり、前もってそういった問題の全てを知ることはほとんど不可能である。

ベースラインは対象ユーザーの能力に関するものではない

また、ベースラインの記述は、そのコンテンツを利用するのに、どのような身体的、感覚的あるいは認知的な能力が必要とされるかについて記述するものではない。あくまで技術を特定する記述であって、そのコンテンツが主張されたレベルでアクセシブルであるために、ユーザーエージェントがサポートしていなければならない技術が何なのかに関するものである。

Web コンテンツを制作する誰もが想定しなければならないことの一つに、ターゲットにしているユーザーの中には障害のあるユーザーがいる、ということがある。あらゆるユーザー層を構成する中には、障害のあるユーザーがいると考えるべきである。つまり、ターゲットとするユーザー層から障害のあるユーザーを除外することはできないということである。

適合宣言におけるベースラインの使用

WCAG 2.0 への適合を宣言する際には、開発者は、もしユーザーエージェントが記述されたベースラインにある技術をサポートしていれば、その Web コンテンツの全ての情報および機能が WCAG 2.0 にそのレベルで適合していることを宣言することになる。

繰り返しになるが、さまざまな組織や政府により用いられるベースラインは、新しい技術的な進歩に対応していくために変化しうる。WCAG 2.0 の意図するところは、原則およびガイドラインによる機能的なアウトプットが、技術およびベースラインには依存しないものなので、原則やガイドラインが技術の進歩していく中でも不変なままであることである。

誰がベースラインを設定するのか？

ベースラインは、個々の制作者、組織（企業、非政府組織あるいは非営利組織などを含む）、あるいは行政体により設定されうる。

1999年の WCAG 1.0 のガイドラインではベースラインについて何の言及もなかったが、そのガイドラインに用いられた暗黙のベースラインが存在していた。端的に言えば、WCAG 1.0 は HTML および幾つかのグラフィックおよびメディアの技術をベースラインとして想定していたのである。この点において、ベースラインは想定されていたし、その仕様書に "組み込まれていた" のである。WCAG 1.0 は HTML を念頭において書かれていたので、ベースラインはガイドライン自体により設定されていたし、含まれていたことになる。このことによる制約が、WCAG 2.0 を必要とするキーとなる要因ともなっていた。

WCAG 2.0 のガイドラインでは、いかなる特定のベースラインも想定されていない。その代わりに、ベースラインは WCAG 2.0 文書から離れたところで設定されるものと想定されている。

WAI がベースラインを設定するガイダンスを提供することはあるかもしれないが、WCAG 2.0 の "これがベースライン" というものや "一つのベースライン" というものを設定することはない。先に説明した事例のベースラインは、どのようにベースラインというコンセプトが機能するかを示して説明するという目的のためだけに提供されたものである。WCAG ワーキンググループ、WAI、あるいは W3C が推薦するベースラインを意味するものではない。

もし WCAG がベースラインを設定しないのであれば、サイトがアクセシブルであることをどのように確認できるのか？

完全にアクセシブルだといえるサイトあるいはコンテンツは存在しない。

WCAG 2.0 にあるレベルで適合しているというのは、そのコンテンツに対して記述されたベースラインにある、その技術をサポートしうるユーザーエージェントを使用しているユーザーにとってのアクセシビリティのレベルを示している。

もし開発者が妥当なベースラインを用いていないのであれば、その時点および可能ならさまざまなタイプのコンテンツに対して妥当なベースラインを設定するのは、企業、顧客あるいは監督官庁に委ねられる（例えば、World Wide Web 上で得られる公的な情報 vs 特定の組織内のイントラネットの組織内ユーザーにのみ利用可能なコンテンツ）。

開発者がベースラインを選択するのに役立つものには何があるか？

『Understanding WCAG 2.0』という参考情報の文書に、各達成基準を満たす方法に関する情報がある。その『Understanding WCAG 2.0』では、達成基準に関する重要な情報を提供しており、重要な用語の定義（規定の用語集でも入手可能）、達成基準の意図の説明、およびよくある失敗例とあわせて十分なテクニックおよびオプションのテクニックのリストがある。また、『Understanding WCAG 2.0』は、その達成基準が誰のためになるのかも示しており、そして事例とその達成基準のためのより詳細な情報を提供する関連リソースも挙げている。 該当するものには、個々のテクニック文書に "ユーザーエージェントおよび支援技術のサポートメモ" というタイトルのセクションがあり、支援技術によるさまざまなテクニックあるいは技術のサポートに関する情報を提供している。

W3C-WAI はまた、組織がその環境において最大限のアクセシビリティを保証するベースラインを選択するのを手助けするために "ポリシー策定者のためのガイド" を準備するかもしれない。そして、さまざまな言語およびさまざまな地域でどんなユーザーエージェントのサポートが得られるかについて説明するリソースがあってもよいかもしれない。

他にどんな開発者向けの支援が得られるのか？

W3C 技術

WCAG は、さまざまな W3C 技術に対して技術特有のテクニック文書を提供するだろう。『Understanding WCAG 2.0』がガイドラインの各達成基準を満たすのに十分な方法を挙げている箇所では、そのテクニック文書が十分なテクニックおよび参考テクニックの両方に関して、事例、ソースコード、およびテストの手順も含めた詳細を提供するだろう。

非 W3C 技術

W3C は、W3C により開発されていない技術に対してガイダンス文書を作成できる立場にはない。しかしながら、W3C は同様の資料を作成すべく、開発ベンダー企業と協業しているところである。

多くの大手である非 W3C 技術の提供者は、その技術の利用者がWCAG 2.0 の達成基準を満たすのを手助けするアクセシビリティのテクニックを開発している最中である。W3C 技術の場合と同様に、適合を主張するためには、そういった技術を使用しているあらゆるコンテンツが WCAG 2.0 のレベル 1 達成基準の全てを満たさなければならない。

独自のテクニック文書のない非 W3C 技術の場合には、達成基準で説明されている機能的なアウトプットを用いて、そのコンテンツを WCAG 2.0 の3つの適合レベルと照らし合わせて評価することが可能である。

なぜ UAAG がベースラインとして用いられなかったのか？

User Agent Accessibility Guidelines 1.0 (UAAG) は、ベースラインを選択する利害関係者に対して役に立つ方向性を示してくれるだろう。ワーキンググループでは、UAAG を WCAG 2.0 のベースラインとして用いることを真剣に考慮した。事実、ワーキンググループは一時はそうすることを試みようともした。しかしながら、注意深く検討し、多くの努力とリサーチを重ねた結果、UAAG は以下に挙げるものを含む多くの理由から、WCAGの現実的なベースラインにはならないだろうという結論に達したのである。

注記: UAAG 1.0 は以上のような理由から WCAG 2.0 のベースラインにはならないが、ベースラインに含めることを検討している技術がアクセシブルなユーザーエージェントによりサポートされているかどうかを判断しようとするときには、UAAG はユーザーエージェントのアクセシビリティを評価する上で有用である。UAAG 1.0 に適合しているユーザーエージェントはまた、WCAG 2.0 に適合している Web コンテンツをよりよくサポートするだろう。

まとめ

今日の技術的な環境は、WCAG 1.0 が勧告となった 1999年当時のそれとは非常に異なる。私たちは、Web 上での実効的な技術革新、コミュニケーション、コマースを促進しながら、この新しい環境において障害のあるユーザーに力を与えるような方法で、こうした新しい現実に対応していく必要がある。ベースラインのコンセプトは、このチャレンジへの回答の一つでもある。また、過去数年間にわたって、WCAG 1.0 の実装状況をウォッチしてきた経験を反映させたものでもある。ワーキンググループでは、ご意見、ご提案を求めており、皆さんのアドバイスの提供を歓迎している。

ベースラインと適合に関連する補足情報

適合の記述におけるベースラインの使用

適合宣言には以下のような主張が含まれる。

適合宣言に必須の構成要素：

適合宣言は必須ではない。しかしながら、もしあなたが適合宣言をしたいのであれば、その適合宣言には以下に挙げる主張を含まなければならない:

  1. 宣言の日付
  2. ガイドラインのタイトル/バージョン: "Web Content Accessibility Guidelines 2.0"
  3. ガイドラインのURI: http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD/
  4. 満たした適合レベル: (レベル A、AA あるいは AAA)
  5. 適合宣言をするのに用いたベースライン (ベースライン技術を適合宣言の中で列挙できる、あるいは、もしそのベースラインがどこかで公開されているのであれば、その適合宣言はそのベースラインを引用して、それを示すURIを提供することができる）
  6. 宣言の範囲 (1つのURI、URIのリスト、あるいはregular expressionにより定義されたURI一式)

適合宣言に任意の構成要素:

  1. 宣言がなされたコンテンツを制作するのに "依存した" 特定の技術のリスト
    • これには、マークアップ言語、プログラミング言語、スタイルシート、データ・フォーマット、およびマAPIなどを含む技術
    • "依存した" というのは、その技術が動作しない、あるいはサポートされていない場合には、そのコンテンツがWCAG 2.0を宣言したレベルで満たしていないことを意味する。
    • "依存した" 技術の一式は、ベースラインの妥当なサブセットでなければならない。
  2. "用いているが依存してはいない" 特定の技術のリスト
    • もし、ある技術が "用いている" が "依存してはいない"のであれば、その技術が動作するとき、およびオフだったりサポートされていなかったりするときのどちらであっても、そのコンテンツは宣言した適合レベルでWCAG 2.0を満たしていると言えるだろう。
  3. そのコンテンツをテストしたユーザーエージェントのリスト。これには支援技術を含めるべきである。
  4. 想定するユーザーあるいはターゲットユーザーに関する情報。これには、言語、地理的情報、あるいはその他の想定ユーザーに関連のある情報を含めることができる。ターゲットユーザーの情報には、障害、あるいは肉体的、感覚的または認知に関する要件に関連することを指定してはならない。

適合宣言の事例

事例 1

2005年3月23日、http://www.wondercall.example.com は、W3CのWCAG 2.0にレベルAで適合しています。この宣言のベースラインは、XHTML 1.0です。このコンテンツが "依存している" 仕様は、HTML 4.01です。このコンテンツが"用いているが依存してはいない" 仕様は、CSS2 および gifです。このコンテンツは以下に挙げるユーザーエージェントおよび支援技術にてテストしました： Windows 2000 SP4上のFirefox 1.5/Jaws 7.0、Windows XP SP 2上のFirefox 1.5/Jaws 7.0、Windows 2000 SP4上のIE 6.0/Jaws 4.51、Windows 2000 SP4上のIE 6.0/Jaws 7.0、Windows XP SP2上のFirefox 1.5/Jaws 7.0、OS X 10.4上のSafari 2.0。

事例 2

2006年5月5日、"G7: An Introduction" http://telcor.example.com/nav/G7/intro.html は、W3CのWCAG 2.0にレベルAAで適合しています。以下に挙げる達成基準についても追加で満たしています： 1.1.2、1.2.5、および 1.4.3。この宣言のベースラインは、UDBaseline#1-2006（http://UDLabs.org/Baseline#1- 2006.html）です。このコンテンツが "依存している" 仕様は、XHTML 1.0 (Strict)ならびに Real Videoです。このコンテンツが"用いているが依存してはいない"仕様は、JavaScript 1.2、CSS2です。

事例 3

2007年6月21日、http://example.com/nav と http://example.com/docs は、W3CのWCAG 2.0にレベルAAAで適合しています。ベースラインは、ISA-Baseline#2-2007（http: //ISA.example.gov/Baselines/BL2-2007）です。このコンテンツが "依存している" 仕様は、XHTML 1.0 (Strict)、CSS2、JavaScript 1.2、jpeg、pngです。このコンテンツがテストを行った技術は、http: //example.com/docs/WCAG20/test/technologies.html を参照ください。

Vertical and Horizontal Scoping in Conformance Statements

質問

"ユーザーが情報およびファイルを投稿できるセクションを除いて、コンテンツを WCAG 2.0 に適合させることはできますか？　ユーザーが適合しているコンテンツを投稿する確信を持てるとはかぎりません。どうしたらよいでしょうか？"

回答

適合は、Web コンテンツのガイドラインに適合することが保証できないあらゆるセクションに対して宣言することはできない。これが起こりうるよくある状況の一つは、組織がそのサイトに何が投稿されるかについて完全にコントロールできないパブリック・フォーラムなどだろう。

このような状況および似たような状況に対処するために、WCAG 2.0 には範囲を限定するという考え方がある。適合宣言は、サイトの特定のセクションを範囲外とすることが可能である。これは、"vertical scoping"（URI あるいは URI の範囲でサイトの一部を除外すること）といって、許容されている。WCAG 2.0 への適合は、サイトの特定の部分および/あるいはそのサイトの特定の部分を除いたサイト全体に対して宣言することが可能でである。

"Horizontal scoping"（Web ユニット内の特定の技術を範囲外とすること）は認められていない。組織は、「私たちのコンテンツは、WCAG 2.0 にレベル A で適合しています。ただし、全てのナビゲーションメニューは除く。」、あるいは「私たちのコンテンツは、全てのマルチメディアおよびアニメーションを除いて、適合しています。」というような言い方はできない。これは、さまざまな Web ユニットの一部を範囲外とすることであり、WCAG 2.0 の適合宣言として有効でもなければ容認可能でもない。レベル A あるいはレベル AA で適合宣言している部分である、あらゆる Web ユニットあるいは Web ユニットの一式は、そのレベルでの達成基準の全てを満たさなければならない。レベル AAA に適合するあらゆる Web ユニットは、レベル 1 およびレベル 2 の全ての達成基準に加えて、該当するレベル 3 達成基準のうち少なくとも50％を満たさなくてはならない。

ベースラインを設定する People and Places の事例

ただし、ベースラインは、ユーザーエージェントに関しては指定されないが、そのユーザーエージェント（支援技術）によりサポートされていて動作するWebコンテンツ技術に関して指定されるものである。

ベースライン選択における導入ガイド

ベースライン技術を選択することは、ベースラインを定義する時点で、想定するどんな技術が対象ユーザーのユーザーエージェントでサポートされているかに基づいて判断することである。ベースラインに関する決定を下すときには、以下の要素を考慮すべきである。

イントラネット

もし使用されるユーザーエージェントがコントロール可能で、そのユーザーエージェントをアクセシブルにする支援技術が分かっているようなクローズドな環境（イントラネット）ならば、そのユーザーエージェントの性能に合わせたベースラインを設定することが可能である。ユーザーエージェント（および、ユーザーエージェントと支援技術の組合せ）に関する質問には、以下のようなものがある。

  1. そのユーザーエージェントは、考慮されている各技術について、UAAG の要件をどこまで満たしているのか？　この情報源になるのは、そのユーザーエージェントの UAAG に対する適合の記述だろう。UAAG ワーキンググループはまた、幾つかのユーザーエージェントに関する情報のドラフトを UAAG Working Group Web site で挙げている。
  2. そのユーザーエージェントがサポートしている技術は何ですか？　例えば、どのバージョンの HTML、XHTML、CSS、PDF、Flash ですか？ （この情報は、ユーザーエージェントのベンダーが提供すべきである。）
  3. 支援技術製品のどのバージョンがそのユーザーエージェントで動作するのか？　そして、どの技術がその支援技術でサポートされているのか？　例えば、JavaScriptをサポートしているのか？　（この情報は、支援技術ベンダーが提供すべきである。また、ベースラインに検討されている技術のテクニック文書にある、ユーザーエージェントおよび支援技術サポートのセクションも参照のこと。）

注記: どの支援技術が社内で使用されるかについて想定をするときは、十分注意をしなければならない。

インターネット

ほとんどの Web コンテンツは、World Wide Web 上で公開されるためにデザインされている。このコンテンツの場合は、ユーザーが使用するであろうプラットフォームあるいはユーザーエージェントを知るのは不可能である。数多くある OS のどれか一つの上で動作している多くのユーザーエージェントのどれか一つかもしれない。時にはサービスパックにより差異が生じることもありえる。そのため、インターネットをテーマにしたときには、ブラウザではなく、技術の点から見ることが重要である。

以下に、考慮すべきいくつかの質問がある。

  1. 検討している各技術に対するユーザーエージェントが入手可能なのは、どのプラットフォームおよび OS なのか？　Winndows、Mac、Unix？　Windows XP、Windows 2000、Windows ME、Windows 98、Windows 95なのか。OS のサービスパックはユーザーエージェントのアクセシビリティに影響を与えるのか？
  2. 候補に挙がっている技術はそれぞれ、（もし存在するなら）対象ユーザーが用いる全ての言語のユーザーエージェントでサポートされているのか？　そのコンテンツの言語で入手可能なのか？
  3. 候補に挙がっている技術はそれぞれ、対象ユーザーが使用しているユーザーエージェントの最新バージョンでサポートされているのか？　ユーザーは、ユーザーエージェントの新しいバージョンにアップデートしないのが常であり、すぐにアップデートしないかもしれない。
  4. 候補に挙がっている技術はそれぞれ、とても高価なユーザーエージェントのみでサポートされているのか？　もしそのコストが対象ユーザーにとって購入できないほど高額だったとしたら、そのコンテンツは事実上利用できないだろう。
  5. もし、あるユーザーエージェントによる、ある技術のサポートが、プラグインのようなオプションのソフトウェアに依存していたら、ユーザーがそのプラグインを入手するのはどの程度困難なのか？　もしそれを使おうとしたならば、そのソフトウェアを自動的にインストールすように促されるのか？　そのプラグインのアクセシブルなバージョンは、通常ダウンロードされたり、リンクされていたりするものと違うのか？　そのプラグインのアクセシブルなバージョンへのリンクをコンテンツの一部として提供する必要があるのか？
  6. その技術には、オープンな標準規格あるいは公開された仕様があるか？

アクセシブルな Web コンテンツのための適切なベースラインは、ユーザーがその Web コンテンツをレンダリングするのにアクセシブルなユーザーエージェントを持つようにする保守的な選択をすることになるだろう。しかしながら、他の技術が、ベースラインにある技術だけをサポートしているユーザーエージェントがコンテンツをアクセシブルにレンダリングできるような方法で用いられているかぎり、このことはその技術を使用することを禁じるものではない。

用語集

WCAG 2.0 にある用語集を http://www.w3.org/TR/WCAG20 で参照のこと。