contents

【注意】 この文書は、W3Cが技術ノートとして公開している「Core Techniques for Web Content Accessibility Guidelines 1.0 (http://www.w3.org/TR/2000/NOTE-WCAG10-CORE-TECHS-20001106/)」を、ZSPCが個人的に翻訳したものです。この技術ノートの正式な基準となる文書は、あくまでW3Cのサイト内にある英語版であり、この文書には翻訳上の間違いや不適切な表現が含まれている可能性がありますのでご注意ください。

[ZSPCホーム] [ZSPC資料集]


W3C

ウェブコンテンツ・アクセシビリティ・ガイドライン1.0 基本技術書

2000年11月6日 W3C技術ノート

本版オリジナル:
http://www.w3.org/TR/2000/NOTE-WCAG10-CORE-TECHS-20001106/
( プレーンテキスト形式PostScript形式PDF形式HTML形式tar/gzip圧縮HTML形式ZIP圧縮 )
最新版オリジナル:
http://www.w3.org/TR/WCAG10-CORE-TECHS/
直前版オリジナル:
http://www.w3.org/TR/2000/NOTE-WCAG10-CORE-TECHS-20000920/
オリジナル版編集者:
Wendy Chisholm, W3C;
Gregg Vanderheiden, Trace R & D Center University of Wisconsin -- Madison;
Ian Jacobs, W3C

概要

この文書は、様々なテクノロジーに対して広く適用できるアクセシブルなコンテンツ制作の手法を解説したもので、「ウェブコンテンツ・アクセシビリティ・ガイドライン 1.0」([WCAG10]) に適合した文書を制作したいと考えるウェブコンテンツ制作者の手助けとなることを意図しています。ただし、この文書に書かれている手法は、「ウェブコンテンツ・アクセシビリティ・ガイドライン 1.0」に適合したウェブコンテンツを制作しようとする人の手助けになるとは思われますが、上記のガイドラインに適合することを保証するものではありませんし、適合させるための唯一の方法でもありません。

この文書は、アクセシブルなウェブコンテンツを制作するための一連の技術文書の中の一編です。関連する他の文書については、「ウェブコンテンツ・アクセシビリティ・ガイドライン1.0 技術書」[WCAG10-TECHS] を参照してください。

この文書の位置付け

本版は、前の版にあったいくつかのリンク切れ部分を修正したものです。

この2000年11月6日版の文書は、ウェブコンテンツ・アクセシビリティ・ガイドライン・ワーキンググループ (WCAG WG) によって作成および是認された一連の技術ノートの中の一文書です。この技術ノートは、W3Cのメンバーによって検討や是認が行われた文書ではありません。これらの一連の文書は、1つのファイルから成る1999年5月5日版のW3C技術ノート「ウェブコンテンツ・アクセシビリティ・ガイドライン1.0 技術書」に置き換わるものです。初期の文書で項目として分けられていた部分は、本版ではそれぞれ個別に発展させたテクノロジー別の文書に分割されました。テクノロジー別のより小さな文書に分けられたことによって、特定のテクノロジーに焦点を絞って利用することもできます。

「ウェブコンテンツ・アクセシビリティ・ガイドライン 1.0」の勧告 [WCAG10] に書かれている内容は永続的なものですが、この姉妹編である一連の文書は、テクノロジーの変化やコンテンツ制作者によって発見されるアクセシブルなウェブデザインのためのより効果的な手法などに応じて発展させていく予定です。

この一連の文書には、更新履歴のほか未解決の問題および解決済の問題の一覧も用意されています。文書に対するコメントや現在抱えている問題に対する解決策などがありましたら、ぜひお寄せください。ワーキンググループ宛のこの文書に関するコメントは、「w3c-wai-gl@w3.org」までお送りください。公開されたアーカイブも用意されています。

この文書は、英語版が唯一の正式な基準文書となっていますが、他の言語への翻訳版もあります。

この文書で見つかった誤りの一覧については「ウェブコンテンツ・アクセシビリティ・ガイドライン正誤表」を参照してください。また、この文書内で誤りを発見された場合は、「wai-wcag-editor@w3.org」まで、ぜひご連絡ください。

World Wide Web Consortium (W3C) の Web Accessibility Initiative (WAI) では、様々なウェブアクセシビリティに関する資料や情報を提供しています。WAI アクセシビリティ・ガイドラインは、「WAI Technical Activity」の活動の一環として作成されたものです。 WCAGワーキング・グループの目的については、「the charter」に記載されています。

現在のW3C勧告とその他の技術文書の一覧も用意されています。


1 構造 vs. 表現

該当するチェックポイント:

文書をデザインする場合、コンテンツ制作者はその文書をユーザーにどのように見せるのかを考える前に、まずその文書に必要とされる構造を明確にする必要があります。文書の構造とそのコンテンツをどのように表現するのかを区別することは、アクセシビリティや管理性、移植性を高めるなどの多くの利点を生み出します。

どれが構造でどれが表現かを識別することは、場合によっては難しいかもしれません。たとえば、多くのコンテンツ制作者は、水平線は構造的な仕切を表すものだと考えています。これについては、それが見えているユーザーにとってはその通りかもしれませんが、それが見えないユーザーやグラフィカルなブラウザを使っていないユーザーにとっては、ほとんど意味がないものかもしれません。例としてHTMLの場合で考えると、コンテンツ制作者は新しい節を示すためには HTML 4.01 [HTML4] の見出し要素(H1〜H6)を使用するべきです。これらは水平線のような視覚的またはそれ以外によるなんらかの合図や手掛かりによって補足されることはありますが、それらによって置き換えられることはありません。

逆の場合にも同様のことが言えます。コンテンツ制作者は、構造を表すための要素を、表現上の効果を与える目的で使用するべきではありません。たとえばHTMLの場合、あるブラウザではBLOCKQUOTE要素のテキストはインデントされますが、BLOCKQUOTE要素は引用部分を示すためのものであって、表現上の副作用を作るためのものではありません。インデントのために使用されたBLOCKQUOTE要素は、ユーザーやサーチロボット同様、その要素がブロック単位での引用部分をタグ付けするものだと当てにしているすべての人(ユーザーエージェント)を混乱させます。

XML文書の場合は、もともと表現を構造から分離させるようになっています。Norman Walsh氏は、その著書「A Guide to XML」[WALSH] の中で次のように書いています。

HTMLブラウザのプログラムは、多くの場合タグとその表示方法を固定している。最上位の見出しは、ブラウザによってH1タグとして認識され、決められた方法で表示される。一方で、XML文書には固定されたタグ・セットが存在しないため、このような方法では動作させることができない。XML文書の表現部分は、スタイルシートに依存する。

すぐできるテスト法:そのコンテンツが“構造を表すもの”か“表現を表すもの”かを判定するためには、その文書のアウトラインを作成してみてください。そこで示される階層の各ポイントは、構造が変わることを意味しています。この変化を示すためには構造を表すタグ付けをして、その変化を視覚的または音声的により明確にするためには表現を表すタグ付けをしてください。ここで、水平線は構造を表すものではなく表現を表すものであるため、アウトラインの中には現れないことに着目してください。注意:このテスト方法は、章、節、段落の構造を判定するためのものです。文章中の構造を判定するためには、省略語や自然言語の変更、定義、リストなどがないかどうか探してみてください。

2 同等の役割を果たすテキスト

該当するチェックポイント:

テキストは、スクリーンリーダーやその他の視覚以外で利用できるブラウザ、点字リーダーなどで利用できるため、ほぼすべてのユーザーに対してアクセシブルだと考えられます。テキストは、画面上に表示することも、拡大することも、字幕として映像に同期して表示させることもできます。テキスト以外の情報(画像・アプレット・音・マルチメディアなど)を含んだ文書を作成する場合は、できるかぎりその部分に同等の役割を果たすテキストをつけるようにしてください。

同等の役割を果たすテキストがつけてあると、それが元のコンテンツと本質的に(可能な範囲で)同じ機能を果たします。単純な内容の場合は、同等の役割を果たすテキストには、単にそのコンテンツの役割や意図を表す内容を記述すればいいかもしれませんが、複雑な内容(図やグラフなど)の場合は、内容を説明するような長めの情報をつける必要があるかもしれません。

同等の役割を果たすテキストは、ロゴ、写真、送信ボタン、アプレット、リスト項目の前につける丸などの画像、ASCIIアートのほか、イメージマップのすべてのリンク箇所やレイアウトのための透明画像にもつけなければなりません。

すぐできるテスト法:同等の役割を果たすテキストが実用的なものになっているかどうかを判定するための良い方法は、その文書を電話を通して読み上げる場合を想像してみることです。その画像のところまで来た時、それを相手に理解できるように伝えるためには、あなたならどう言いますか?

2.1 技術的な方法の概要

同等の役割を果たすテキストをどのように指定するのかは、その文書で使用している言語によって異なります。

たとえば、それは要素によっても異なりますが、HTMLでは属性(altまたはlongdesc)を利用して、または要素の内容(OBJECT要素)として同等の役割を果たすテキストを指定することができます。

QuickTimeのようなビデオフォーマットの場合は、それ自体に様々な音声や映像の代替トラックを含めることができます。SMIL ([SMIL]) の場合は、代替の音声や映像、テキストファイルなどをそれぞれ同期させることができます。

XMLのDTDを作成する場合は、説明が必要となる可能性のある要素に対して、説明と要素自体を結び付けるためのいくつかの手段を提供するようにしてください。

画像フォーマットの中には、画像自体の情報と共にデータファイルの中にテキスト情報も含めることができるものがあります。画像フォーマットが、そのようなテキストをサポート(例:Portable Network Graphics、[PNG] 参照)している場合には、コンテンツ制作者はそこにも同様に情報を入れておくことができます。

2.2 後方互換性

コンテンツ制作者は、以下に述べるような理由から、ウェブページやウェブサイトを設計する際に後方互換性を考慮する必要があります。

そのため、過去の技術にあわせて設計する場合は、次のような手法を使うことを検討してみてください。

3 代わりのページ

該当するチェックポイント:

ほとんどのコンテンツはアクセシブルにすることが可能ですが、ページ全体またはその一部をアクセシブルにできない場合もあります。アクセシブルな代わりのページを作るための手法には、次のようなものがあります。

  1. ユーザーが、アクセシブルではないページと同等の情報を持ったアクセシブルな別のページに行けるようにする。しかも、そのページはアクセシブルではないページと同じ頻度で更新するようにする。
  2. 静的な代わりのページを用意するのではなく、要求に応じてアクセシブルなページをサーバーサイドのスクリプトで自動生成するようにする。
  3. フレームおよびスクリプトの例文を参照。
  4. その情報を得ることができる位置にアクセシブルな状態で、電話番号、FAX番号、電子メールアドレス、住所などを掲載しておく。その際、できれば24時間対応であることが望ましい。

アクセシブルな代わりのページにリンクする手法には、次の2つがあります。

  1. ユーザーが元のページと代わりのページの間を行き来できるように、両方のページの最上部にリンクをつけておく。たとえば、グラフィカルなページの最上部にはテキストのみのページへのリンクを、テキストのみのページの最上部には元となるグラフィカルなページへのリンクをつけるなど。この場合のリンクは、ユーザーがタブ移動した場合のページ最上部での最初のリンクとなるようにする。
  2. 代わりの文書を示すためにメタ情報を使用する。この場合、ブラウザはユーザーが使用しているブラウザの種類やその設定に基づいて、代わりのページを自動的に読み込むべきだと考えられる。

該当するチェックポイント:

すべてのユーザーが、マウスやその他のポインティング・デバイスを使用したグラフィカルな環境にあるわけではありません。ユーザーによっては、リンクをたどったりフォームの構成部品をアクティブにしたりするために、キーボードや代替キーボードのほか、音声入力などを利用しています。コンテンツ制作者は、ユーザーがポインティング・デバイスではない他の装置を使用して操作している場合もあることに留意してください。キーボードによる操作(もちろんマウスによる操作に加えて)に対応したページは、一般に他の入力装置を使用しているユーザーに対してもアクセシブルになります。しかも、キーボードによる操作に対応したページをデザインすることによって、たいていの場合は全体としてのデザインも良くなります。

キーボードでリンクやフォームの構成部品にアクセスできるようにするためには、以下のような方法があります。

イメージマップのリンク
クライアントサイド・イメージマップの各領域に対しては、同等の役割を果たすテキストをつける。サーバーサイド・イメージマップに対しては、テキストによるリンクも添えるようにする。例文についてはイメージマップの節を参照。
キーボード・ショートカット
ユーザーが押すキーの組合せによってページ上のリンクやフォームの構成部品に移動できるように、キーボード・ショートカットをつける。注意:キーボード・ショートカット(特にショートカットを利用するために使われるキー)は、オペレーティング・システムによって、その取り扱い方が異なる場合がある。Windowsマシンでは、多くの場合「alt」キーと「ctrl」キーが使用されるが、Macintoshでは「アップル」または「クローバー」キー(【訳注】コマンドキー)が使用される。例文については、キーボードによるリンクへのアクセスキーボードによるフォームへのアクセスの節を参照。
Tabキーによる移動の順序
Tab移動順は、リンクからリンクへ、またはフォームの構成部品から別の構成部品へと移動する際の(論理的な)順序を表す。(通常はTabキーを押すことによって行われるためTab移動順と呼ばれる)。例文については、キーボードによるフォームへのアクセスの節を参照。

3.1 組み込まれたもののインターフェイスに対する装置に依存しない操作性

いくつかの要素は、マークアップ言語からはそのインターフェイスをコントロールできないオブジェクト(たとえば、アプレットやマルチメディア・プレイヤーなど)を取り込みます。その場合で、もし取り込むオブジェクトの持つインターフェイスがアクセシブルでない場合は、コンテンツ制作者はアクセシブルなインターフェイスを持ち同じ役割を果たす代わりのものを用意しておくべきです。

4 ナビゲーション

該当するチェックポイント:

各ページの体裁を一貫した様式にしておくことは、ナビゲーションの仕組をよりわかりやすくするだけでなく、重要な内容を探すためにナビゲーション部分を読み(聞き)飛ばすことも簡単にできるようにします。このことは、学習や読むことに対して障害のある人に役立つだけでなく、すべてのユーザーに対して操作を容易にするということでもあります。内容が予想できることによって、サイトの中から情報を探し出せる確立が高くなり、また情報が無いようであれば立ち去ることもできます。

構造として各ページで同じ位置に表示されるものの例としては、以下のものがあげられます。

  1. ナビゲーション・バー
  2. ページの本来の内容
  3. 広告

ナビゲーションの仕組は、ユーザーがサイト内を行き来できるような通路を作り出します。ナビゲーション・バーやサイトマップ、検索機能を提供することはすべて、ユーザーがそのサイト内で探している情報へたどり着ける可能性を高めます。もし、あなたのサイトがビジュアル中心で構成されている場合で、ユーザーが現在サイトの中のどこへ向かっているのかや、今どこにいるのかなどのマップを頭の中で構成できないようであれば、その構造は操作するのが難しいものとなっているのかもしれません。そのような場合は、コンテンツ制作者は、ナビゲーションの仕組を説明するようなものを提供するべきです。サイト内で迷子になった人にとっては、サイトの説明や案内だけが頼りとなりますので、それらをアクセシブルにしておくことは重要なことだと言えます。

検索機能を提供する場合、コンテンツ制作者は様々なレベルのスキルや好みを満足させるような検索の機構を用意しておくべきです。ほとんどの場合、検索をするためには検索対象としてのキーワードを入力する必要があります。もし、検索するために完璧なスペルの入力が求められるのであれば、スペルのわからないユーザーや、そのサイトで使われている言語がよくわからないユーザーは、検索を行うために悪戦苦闘することになります。検索エンジンには、できるだけスペル・チェッカーや推測される近い単語の表示、検索例による検索、類似する単語による検索などの機能を含めるようにした方がよいでしょう。

5 内容の理解

該当するチェックポイント:

以下の節では、ページやサイトの内容を理解できるようにするための手法について解説しています。

5.1 文章の書き方

以下の文章の書き方に関する提言は、すべての人、特に読むことや認識することに障害のある人に対して、サイトの内容を読みやすくするためのものです。いくつかの解説書([HACKER]など)では、ここで紹介するものとそれ以外の文章の書き方について、より詳しく論じられています。

  1. 見出しとリンク部分の言葉は、明瞭で的確なものとなるように努める。これには、リンクしている部分の言葉には、簡潔で、文章の前後関係を見なくても意味がとれる、または連続した一連のリンクの中にあっても意味がわかるものを使うということも含まれる(一部のユーザーは、リンクからリンクへと直接移動して、リンク部分の言葉だけを聞いて内容を確かめるため)。また、見出しは、ユーザーが情報を得るために文章を詳しく読まなくても、ざっと見ただけですぐにわかるような有益なものにする。
  2. 文章や段落の主題は、最初に書くようにする(これは、フロント・ローディングと呼ばれている)。そのようにしておくことで、文章を目で拾い読みする人に限らず、スピーチ・シンセサイザを利用している人にも役立つようになる。音声によって拾い読み(聞き)するということは、ユーザーが見出しから見出しへ、または段落から段落へと飛ばしながら、それが自分の求めている情報であるかどうかを判断するために十分な言葉(見出し、段落、リンク部分など)だけを聞いていくということである。もし、段落の要点が後半以降に書かれていると、音声で聞いているユーザーは、自分の欲しい情報を見つけるために文書のほとんどを読まなければならなくなる。何を探しているかや主題についてどれだけ詳しいかはユーザーによって異なるので、検索機能があるとより早く目的の内容を見つけ出すことができる。
  3. 各段落には、ひとつの主題しか入れない。
  4. 文書中でそれが定義されていない限り、スラングや一部の人にしか通じない言葉、一般の言葉を特別な意味で使うことは避ける。
  5. より一般に使用されている言葉を使用する。たとえば、「commence」ではなく「begin」を、「endeavor」ではなく「try」を使う。
  6. 受動態ではなく、能動態を使う。
  7. 複雑な文章構造にしない。

その文書が読みやすいかどうかを判定するためには、「Gunning-Fog reading measure」([SPOOL]で例とともに解説されており、そのアルゴリズムは[TECHHEAD]にてオンラインで確認できます)と呼ばれる測定方法を利用することも考慮してみてください。このアルゴリズムでは、一般的に内容が読みやすいものに対して低いスコアを出します。結果の例としては、聖書、シェークスピア、マーク・トウェイン、テレビガイドなどはすべて約6となり、タイム、ニュースウィーク、ウォールストリート・ジャーナルなどは平均11程度となります。

5.2 同等の役割を果たすマルチメディア表現

同等の役割を果たすマルチメディア表現(テキスト以外のもの)は、読むことが難しかったり、まったく読むことができない人にとって理解の助けとなります。ただし、マルチメディアで表現することによって、必ずしもテキストがわかりやすいものになるとは限らないことに注意してください。場合によっては、マルチメディアで表現することによって、かえって混乱を招くかもしれません。

テキストを補うマルチメディア表現の例としては、次のようなものがあげられます。

  1. 複雑なデータを図表で表現したもの。例としては、過去の会計年度の売上高の推移を表したものなど。
  2. テキストを手話のムービーで表現したもの。手話は話言葉とは非常に異なるものであり、アメリカの手話ができる人はアメリカ英語の文章が読めるとは限らない。
  3. あらかじめ録音されている音楽・朗読・効果音は、音を聞くことはできるが読むことのできないユーザーにとって役立つものである。テキストは音声合成によって読み上げさせることもできるが、録音された声の変化は音声合成には無い情報も伝達できる。

6 コンテント・ネゴシエーション

該当するチェックポイント:

ユーザーが自分に適切なコンテンツを選択する方法には、様々なものがあります。

  1. 翻訳版などの他のバージョンへのリンクをつける。たとえば「この文書のフランス語版を参照」のようなリンクを作成して、フランス語版へリンクさせる。
  2. タグ付け(HTMLの場合は「type」や「hreflang」を使用)によってコンテント・タイプや言語を示す。
  3. クライアントの要求に合わせたコンテンツを配信できるように、コンテント・ネゴシエーションを使用する。たとえば、フランス語を要求しているクライアントには、フランス語版のドキュメントを配信する。

7 自動的なページの更新

該当するチェックポイント:

コンテンツ制作者は時々、ユーザーがページの更新を要求していなくても、更新したり移動するようなページを制作することがあります。そのようなページの自動的な更新によって、あるユーザーは非常に混乱させられることになります。したがって、制作者はそのような方法ではなく、要求に応じる次のような方法をとるべきです。

  1. サーバーが適切なHTTPステータス・コード(301)を使うように設定する。HTTPヘッダを利用することは、インターネットのトラフィックとダウンロード時間を減らし、HTML以外の文書にも適用でき、HEADリクエストだけを要求するユーザーエージェント(リンク・チェッカーなど)によっても利用されるという点で、より良い方法だと言える。しかも、30Xタイプのステータス・コードは、META要素による自動更新では与えることのできない「永久に移動」や「一時的に移動」などの情報を提供することもできる。
  2. 新しいページへの通常のリンクを含んだ、自動的な更新や移動をしないページに変更する。

注意:チェックポイント7.4チェックポイント7.5は、いずれも古いユーザーエージェントの引き起こす問題に対して書かれたものです。新しいユーザーエージェントは、自動的な更新を無効にして、その代わりとしてページの先頭に新しい情報へのリンクを付加するべきです。

「ウェブコンテンツ・アクセシビリティ・ガイドライン1.0 技術書」[WCAG10-TECHS] から非推奨とされる例を参照することができます。

8 画面の明滅(フリッカー)

該当するチェックポイント:

画面を明滅させたりピカッと光らせることは、光過敏性てんかんのユーザーの発作を誘発する可能性があります。したがって、コンテンツ制作者は画面を明滅させることは避けるべきです。1秒間に20回の閃光や(ストロボの光りのような)点滅をピークとする1秒間に4〜59回(ヘルツ)の範囲の明滅や閃光は、発作を引き起こします。

9 ひとまとめの文書

該当するチェックポイント:

複数の文書をひとまとめにしておくことで、オフラインで読むことが容易になります。文書間の関連をより強めるには、次のようにしてください。

10 検証

この節では、ウェブ文書のアクセシビリティに関わる問題が解決されているかどうかをテストするための方法とテクニックについて解説します。ここで紹介するテストは、アクセスするための重要な問題に焦点を当てたもので、アクセシビリティに関する多数の障壁を取り除くために有益なものです。しかしながら、テストで想定している状況のいくつかは、ある種の障害によって生じる状態を反映させただけのものであり、障害を持つユーザーが直面する可能性のあるすべての状態をシミュレートするものではありません。そして実際には、あなたのページはあなたの期待するほど使いやすくないかもしれません。したがって、テストの方法のひとつとして、コンテンツ制作者が異なる障害を持つ人々がページやサイトをどのように使おうとするのかを実際に見て確認することが推奨されています。

もし、以下に述べるテストを完了し、それに応じてデザインを調整してもアクセシブルにならなかった場合は、アクセシブルな別のページを制作した方がよいと思われます。

注意:ここで紹介するテストで問題が見つからなかった場合でも、それは「Web Content Accessibility Guidelines 1.0」に適合することを保証するものではありません。

10.1 自動検証ソフト

自動検証ソフトを使用すると、そのページの文法(HTML、CSS、XMLなど)を検証することができます。ソフトウェアは適確に書かれた文書はより簡単に処理できますので、文法を正確にすることは、多くのアクセシビリティ上の問題を取り除くための手助けとなります。また、自動検証ソフトによっては、文法に基づくアクセシビリティ上の問題について警告を出すこともできます(たとえば、アクセシビリティに関わる重要な属性やプロパティが含まれていない場合など)。しかし、文法が正確であることが、その文書がアクセシブルであることを保証するわけではないことに注意してください。たとえば、その言語の仕様書に従って画像に代替テキストをつけたとしても、そのテキストの内容に誤りがあったり不適当なものとなっている可能性があります。そのような理由で、自動検証ソフトによっては、ユーザーに質問をして、解析のためにユーザーの判断を伴う過程を通して処理を行うものもあります。自動検証ソフトの例としては、以下のようなものがあります。

  1. Bobby([BOBBY]参照)のような、自動的にアクセシビリティの検証を行うツール
  2. W3C HTML Validation Service ( [HTMLVAL]参照)のような、HTML検証サービス
  3. W3C CSS Validation Service ([CSSVAL]参照)のような、スタイルシート検証サービス

10.2 リペアツール

自動検証ソフトは通常、解決すべき問題点を指摘し、場合によってはそれらを解決するための例を示します。それらは多くの場合、各問題点についてどのように修正すればいいのかを示唆してくれるわけではありませんし、インタラクティブに文書を修正できるようにもなっていません。WAI Evaluation and Repair Working Group ([WAI-ER]) は、問題点を指摘するだけでなく、それらをインタラクティブに解決するツール群を開発するための活動をしています。

10.3 ユーザー環境の想定

ほとんどのユーザー・エージェント(ブラウザ)とオペレーティング・システムでは、その表示形態や音、動作などを変更するための設定が可能になっていることに留意してください。様々な種類のユーザー・エージェントを使用した異なるユーザーが、ウェブ上でまったく異なる体験をしています。したがって、以下のような様々な環境を想定したテストをすることが必要です。

  1. Lynx ([LYNX]) のようなテキスト・ブラウザ、または Lynx Viewer ([LYNXVIEW]) や Lynx-me ([LYNXME]) などのようなLynxエミュレータを使用したテストを行う
  2. 以下のような設定で、複数のグラフィック・ブラウザを使ってみる
    • 音と画像をロードする
    • 画像をロードしない
    • 音をロードしない
    • マウスを使わない
    • フレーム、スクリプト、スタイルシート、アプレットをロードしない
  3. 古いブラウザと新しいブラウザを何種類か使ってみる。注意:オペレーティング・システムやブラウザによっては、同じマシンに複数のブラウザをインストールできないようになっている。また、古いブラウザをインストールすることも難しい場合がある。
  4. 音声読上ブラウザ([PWWEBSPEAK][HOMEPAGEREADER]など)やスクリーン・リーダー([JAWS] [WINVISION]など)、拡大表示用ソフトウェア、小さなディスプレイ、ソフト・キーボード、代替キーボードなどのような他のツールを使ってみる。注意:もし、ウェブサイトがこれらの製品のうちの1つで使いやすいものであっても、それは他の製品でも使いやすいことを保証するわけではありません。ウェブにアクセスするために使用される支援技術のより詳細な一覧については([ALTBROWSERS])を参照してください。

10.4 スペルチェックと文法チェック

スピーチ・シンセサイザでページの内容を聞いている人は、スペルの間違った単語を推測して読み上げたものに関しては、意味がわからないかもしれません。文法チェッカーは、ページ内のテキスト部分が正しいかどうかを確認する際に役立ちます。これは、その文書が母国語でない人や、その文書に書かれている言語を学んでいる人にとっても役立つことです。これらは結果として、ページの内容をより理解してもらえることにつながります。

11 ブラウザのサポート状況

注意:この文書を書いた時点では、すべてのユーザー・エージェントがウェブページのアクセシビリティを増加させる HTML4.01 [HTML4] の属性と要素をサポートしているわけではないようです。

ブラウザや他のユーザー・エージェントのアクセシビリティに関する機能のサポート状況については、W3Cのウェブサイト([WAI-UA-SUPPORT])を参照してください。

一般的に、HTMLを扱うユーザー・エージェントは、サポートしていない属性は無視し、サポートしていない要素の内容は表示するという点にご注意ください。

12 アクセシビリティに関して検討済のテクノロジー

該当するチェックポイント:

「Web Content Accessibility Guidelines 1.0」では、アクセシビリティに関する問題が検討済であり、それによってアクセシビリティの機能が組み込まれているW3Cのテクノロジーを使用することを提案しています。W3Cのテクノロジーの最新版については、「W3C Technical Reports and Publications」を参照してください。

現時点でのW3Cのテクノロジーを簡単に紹介します。

13 オーディオとビデオ

14 音声による情報

該当するチェックポイント:

音声で表現されるものには、それと同等の役割を果たすテキスト情報であるテキスト・トランスクリプトをつける必要があります。このトランスクリプトが映像と同期しているものを字幕と言い、映像についている音声を聞くことのできない人によって利用されます。

いくつかのメディア形式(QuickTime 3.0やSMILなど)は、マルチメディア・クリップに対して字幕と映像に関する説明を追加できるようになっています。SAMIには、字幕を付けることができます。以下の例は、見ている人に何が起きているのかがわかるように、字幕には声の他に周囲で聞こえる音も入れるべきだということを示しています。

【例】

「E.T.」のあるシーンに対する字幕。電話のベルが3回鳴る。その後、声が聞こえる。

[電話が鳴る]

[鳴る]

[鳴る]

もしもし?

【例終了】

現在使用しているフォーマットが代替トラックをサポートしていない場合には、字幕や説明が付いたものとそうでないものの2つのムービーを用意しておくことで対応できます。SMILやSAMIのような技術を利用すると、字幕をつけるための同期ファイルを使用して、映像・音声のファイルとは別のテキストファイルを結び付けることができます。

また、使用する技術によっては、ユーザーが複数の字幕の中から自分のスキルに合ったものを選択することもできます。詳しくは SMIL1.0 ([SMIL]) の仕様書を参照してください。

サウンドに対する同等の役割を果たすものは、テキスト・トランスクリプトまたは説明へのリンクとして提供することもできます。その場合、トランスクリプトへのリンクは、ページの最初の部分など目立つところに配置するべきです。しかし、スクリプトによって自動的にサウンドをロードするような場合には、現在サウンドが再生されていることを示す表示も自動的に表示させ、サウンドに対する説明やトランスクリプトも提供するべきです。

注意:ユーザーの設定によっては、ブラウザは音声情報ではなく視覚的な情報をロードすることができるため、この手法に関しては様々な論議があります。しかし、上記の方法は現在のブラウザに対しても有効です。

詳細は[NCAM]を参照してください。

15 視覚的な情報とその動作

該当するチェックポイント:

映像トラックの音声による説明は、音声やビデオ中の会話を邪魔することのないような形で、キーとなる視覚的な要素をナレーションとして提供します。キーとなる視覚的な要素とは、動作、背景、ボディ・ランゲージ、グラフィックス、画面上の文字などのことを言います。音声による説明は、基本的には目の見えない人がビデオ上の動作や音以外の情報を知るために利用されます。

【例】

ここでは、コレイテッド・テキスト・トランスクリプトの例として「ライオンキング」の一場面([DVS]に掲載されています)を紹介します。解説者(Describer)は、映像トラックを声で説明しますが、その説明はトランスクリプトの中に取り込まれているという点に注意してください。

シンバ:それっ!

解説者:シンバは外へ駆け出して行き、両親が後に続きます。サラビはやさしく微笑みながら、シンバを父の方へ行くようにと促します。2頭は並んで座りながら、黄金に輝く日の出を見つめています。

ムファサ:見なさい、シンバ。太陽が輝かせているのは、私たちの王国だ。

シンバ:ほんとだ!

【例終了】

注意:たとえば、サイトの使い方を(録音された声で)説明する際の語り手の動作など、視覚的な情報として重要でないものに対しては、音声による説明をつける必要はありません。

ムービーの場合は、オリジナルの音声に同期した音声による説明を提供するようにしてください。マルチメディア・フォーマットに関するより詳しい情報については、「音声による情報」の節を参照してください。

16 コレイテッド・テキスト・トランスクリプト

コレイテッド・テキスト・トランスクリプトは、視覚と聴覚の両方に障害のある人のアクセスを可能にするものです。コレイテッド・テキスト・トランスクリプトを提供することによって、すべての人が音声や映像に含まれる情報に索引をつけたり内容を検索できるようにもなります。

コレイテッド・テキスト・トランスクリプトには、会話のほか、画面に映っているものの音、画面に映っていないものの音、音楽、笑い声、拍手喝采などの重要な音も含まれます。言い替えると、字幕に含まれるすべてのテキストだけでなく、音に関する説明のすべてを含むということになります。


17 参考文献

W3Cによる各種仕様の最新版については、「W3C Technical Reports(http://www.w3.org/TR/)」を参照してください。

[HTML4]
"HTML 4.01 Recommendation", D. Raggett, A. Le Hors, and I. Jacobs, eds., 24 December 1999. This HTML 4.01 Recommendation is http://www.w3.org/TR/1999/REC-html401-19991224/.
[PNG]
"PNG (Portable Network Graphics) Specification", T. Boutell, ed., T. Lane, contributing ed., 1 October 1996. The latest version of PNG 1.0 is available at http://www.w3.org/TR/REC-png.
[SMIL]
"Synchronized Multimedia Integration Language (SMIL) 1.0 Specification", P. Hoschka, ed., 15 June 1998. This SMIL 1.0 Recommendation is http://www.w3.org/TR/1998/REC-smil-19980615/. The latest version of SMIL 1.0 is available at http://www.w3.org/TR/REC-smil.
[WCAG10]
"Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, and I. Jacobs, eds., 5 May 1999. This WCAG 1.0 Recommendation is http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/.
[WCAG10-TECHS]
"Techniques for Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, I. Jacobs, eds. This document explains how to implement the checkpoints defined in "Web Content Accessibility Guidelines 1.0". The latest draft of the techniques is available at http://www.w3.org/TR/WCAG10-TECHS/.

18 資料集

注意:以下に示す参照先は、読者の便宜をはかるために掲載されたものです。W3Cでは、以下の参照先の内容が常に現状に即しているかどうかについては保証できません。また、製品の紹介についても、それらの動作について保証するものではありません。

18.1 他のガイドライン

[HACKER]
Hacker, Diana. (1993). A Pocket Style Manual. St. Martin's Press, Inc. 175 Fifth Avenue, New York, NY 10010.
[SPOOL]
Spool, J.M., Sconlong, T., Schroeder, W., Snyder, C., DeAngelo, T. (1997). Web Site Usability: A Designer's Guide User Interface Engineering, 800 Turnpike St, Suite 101, North Andover, MA 01845.
[UWSAG]
"The Unified Web Site Accessibility Guidelines", G. Vanderheiden, W. Chisholm, eds. The Unified Web Site Guidelines were compiled by the Trace R & D Center at the University of Wisconsin under funding from the National Institute on Disability and Rehabilitation Research (NIDRR),  U.S. Dept. of Education.
[WALSH]
Walsh, Norman. (1997). "A Guide to XML." In "XML: Principles, Tools, and Techniques." Dan Connolly, Ed. O'Reilly & Associates, 101 Morris St, Sebastopol, CA 95472. pp 97-107.

18.2 ユーザーエージェントと他のツール

WAIのウェブサイトには、他の選択肢として考えられるウェブブラウザ(アクセシビリティを考慮してデザインされた他のユーザーエージェントと支援技術)の一覧が掲載されています。

[ALTBROWSERS]
"Alternative Web Browsing". This page documents known support by user agents (including assistive technologies) of some accessibility features listed in this document. The page is available at http://www.w3.org/WAI/References/Browsing.
[BOBBY]
Bobby is an automatic accessibility validation tool developed by Cast.
[CSSVAL]
The W3C CSS Validation Service.
[HOMEPAGEREADER]
IBM's Home Page Reader.
[HTMLVAL]
The W3C HTML Validation Service.
[JAWS]
Henter-Joyce's Jaws screen reader.
[LYNX]
Lynx is a text-only browser.
[LYNXME]
Lynx-me is a Lynx emulator.
[LYNXVIEW]
Lynx Viewer is a Lynx emulator.
[PWWEBSPEAK]
The Productivity Works' pwWebSpeak.
[WAI-UA-SUPPORT]
User Agent Support for Accessibility
[WINVISION]
Artic's WinVision.

18.3 アクセシビリティ関連

[DVS]
DVS Descriptive Video Services.
[NCAM]
The National Center for Accessible Media includes information about captioning and audio description on the Web.
[TECHHEAD]
Tech Head provides some information about the Fog index described in [SPOOL].
[WAI-ER]
The WAI Evaluation and Repair Working Group

19 謝辞

Web Content Guidelines Working Group Co-Chairs:
Jason White, University of Melbourne
Gregg Vanderheiden, Trace Research and Development
W3C Team contact:
Wendy Chisholm
We wish to thank the following people who have contributed their time and valuable comments to shaping these guidelines:
Harvey Bingham, Kevin Carey, Chetz Colwell, Neal Ewers, Geoff Freed, Al Gilman, Larry Goldberg, Jon Gunderson, Eric Hansen, Phill Jenkins, Leonard Kasday, George Kerscher, Marja-Riitta Koivunen, Josh Krieger, Chuck Letourneau, Scott Luebking, William Loughborough, Murray Maloney, Charles McCathieNevile, MegaZone (Livingston Enterprises), Masafumi Nakane, Mark Novak, Charles Oppermann, Mike Paciello, David Pawson, Michael Pieper, Greg Rosmaita, Liam Quinn, Dave Raggett, T.V. Raman, Robert Savellis, Jutta Treviranus, Steve Tyler, and Jaap van Lelieveld

Level Triple-A conformance icon, W3C-WAI Web Content Accessibility Guidelines 1.0