【注意】 この文書は、W3Cが技術ノートとして公開している「Core Techniques for Web Content Accessibility Guidelines 1.0 (http://www.w3.org/TR/2000/NOTE-WCAG10-CORE-TECHS-20001106/)」を、ZSPCが個人的に翻訳したものです。この技術ノートの正式な基準となる文書は、あくまでW3Cのサイト内にある英語版であり、この文書には翻訳上の間違いや不適切な表現が含まれている可能性がありますのでご注意ください。
Copyright
©1999 - 2000 W3C® (MIT,
INRIA, Keio), All Rights
Reserved.
この文書のすべての原著作権は、W3C(マサチューセッツ工科大学・フランス国立情報処理自動化研究所・慶應義塾大学)が保有します。また、この文書には、W3Cの「免責事項」「商標」「文書利用許諾」「ソフトウェア使用許諾」で示される規定が適用されます。
この文書は、様々なテクノロジーに対して広く適用できるアクセシブルなコンテンツ制作の手法を解説したもので、「ウェブコンテンツ・アクセシビリティ・ガイドライン 1.0」([WCAG10]) に適合した文書を制作したいと考えるウェブコンテンツ制作者の手助けとなることを意図しています。ただし、この文書に書かれている手法は、「ウェブコンテンツ・アクセシビリティ・ガイドライン 1.0」に適合したウェブコンテンツを制作しようとする人の手助けになるとは思われますが、上記のガイドラインに適合することを保証するものではありませんし、適合させるための唯一の方法でもありません。
この文書は、アクセシブルなウェブコンテンツを制作するための一連の技術文書の中の一編です。関連する他の文書については、「ウェブコンテンツ・アクセシビリティ・ガイドライン1.0 技術書」[WCAG10-TECHS] を参照してください。
本版は、前の版にあったいくつかのリンク切れ部分を修正したものです。
この2000年11月6日版の文書は、ウェブコンテンツ・アクセシビリティ・ガイドライン・ワーキンググループ (WCAG WG) によって作成および是認された一連の技術ノートの中の一文書です。この技術ノートは、W3Cのメンバーによって検討や是認が行われた文書ではありません。これらの一連の文書は、１つのファイルから成る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勧告とその他の技術文書の一覧も用意されています。
該当するチェックポイント：
文書をデザインする場合、コンテンツ制作者はその文書をユーザーにどのように見せるのかを考える前に、まずその文書に必要とされる構造を明確にする必要があります。文書の構造とそのコンテンツをどのように表現するのかを区別することは、アクセシビリティや管理性、移植性を高めるなどの多くの利点を生み出します。
どれが構造でどれが表現かを識別することは、場合によっては難しいかもしれません。たとえば、多くのコンテンツ制作者は、水平線は構造的な仕切を表すものだと考えています。これについては、それが見えているユーザーにとってはその通りかもしれませんが、それが見えないユーザーやグラフィカルなブラウザを使っていないユーザーにとっては、ほとんど意味がないものかもしれません。例としてHTMLの場合で考えると、コンテンツ制作者は新しい節を示すためには HTML 4.01 [HTML4] の見出し要素(H1〜H6)を使用するべきです。これらは水平線のような視覚的またはそれ以外によるなんらかの合図や手掛かりによって補足されることはありますが、それらによって置き換えられることはありません。
逆の場合にも同様のことが言えます。コンテンツ制作者は、構造を表すための要素を、表現上の効果を与える目的で使用するべきではありません。たとえばHTMLの場合、あるブラウザではBLOCKQUOTE要素のテキストはインデントされますが、BLOCKQUOTE要素は引用部分を示すためのものであって、表現上の副作用を作るためのものではありません。インデントのために使用されたBLOCKQUOTE要素は、ユーザーやサーチロボット同様、その要素がブロック単位での引用部分をタグ付けするものだと当てにしているすべての人(ユーザーエージェント)を混乱させます。
XML文書の場合は、もともと表現を構造から分離させるようになっています。Norman Walsh氏は、その著書「A Guide to XML」[WALSH] の中で次のように書いています。
HTMLブラウザのプログラムは、多くの場合タグとその表示方法を固定している。最上位の見出しは、ブラウザによってH1タグとして認識され、決められた方法で表示される。一方で、XML文書には固定されたタグ・セットが存在しないため、このような方法では動作させることができない。XML文書の表現部分は、スタイルシートに依存する。
すぐできるテスト法：そのコンテンツが“構造を表すもの”か“表現を表すもの”かを判定するためには、その文書のアウトラインを作成してみてください。そこで示される階層の各ポイントは、構造が変わることを意味しています。この変化を示すためには構造を表すタグ付けをして、その変化を視覚的または音声的により明確にするためには表現を表すタグ付けをしてください。ここで、水平線は構造を表すものではなく表現を表すものであるため、アウトラインの中には現れないことに着目してください。注意：このテスト方法は、章、節、段落の構造を判定するためのものです。文章中の構造を判定するためには、省略語や自然言語の変更、定義、リストなどがないかどうか探してみてください。
該当するチェックポイント：
テキストは、スクリーンリーダーやその他の視覚以外で利用できるブラウザ、点字リーダーなどで利用できるため、ほぼすべてのユーザーに対してアクセシブルだと考えられます。テキストは、画面上に表示することも、拡大することも、字幕として映像に同期して表示させることもできます。テキスト以外の情報(画像・アプレット・音・マルチメディアなど)を含んだ文書を作成する場合は、できるかぎりその部分に同等の役割を果たすテキストをつけるようにしてください。
同等の役割を果たすテキストがつけてあると、それが元のコンテンツと本質的に(可能な範囲で)同じ機能を果たします。単純な内容の場合は、同等の役割を果たすテキストには、単にそのコンテンツの役割や意図を表す内容を記述すればいいかもしれませんが、複雑な内容(図やグラフなど)の場合は、内容を説明するような長めの情報をつける必要があるかもしれません。
同等の役割を果たすテキストは、ロゴ、写真、送信ボタン、アプレット、リスト項目の前につける丸などの画像、ASCIIアートのほか、イメージマップのすべてのリンク箇所やレイアウトのための透明画像にもつけなければなりません。
すぐできるテスト法：同等の役割を果たすテキストが実用的なものになっているかどうかを判定するための良い方法は、その文書を電話を通して読み上げる場合を想像してみることです。その画像のところまで来た時、それを相手に理解できるように伝えるためには、あなたならどう言いますか？
同等の役割を果たすテキストをどのように指定するのかは、その文書で使用している言語によって異なります。
たとえば、それは要素によっても異なりますが、HTMLでは属性(altまたはlongdesc)を利用して、または要素の内容(OBJECT要素)として同等の役割を果たすテキストを指定することができます。
QuickTimeのようなビデオフォーマットの場合は、それ自体に様々な音声や映像の代替トラックを含めることができます。SMIL ([SMIL]) の場合は、代替の音声や映像、テキストファイルなどをそれぞれ同期させることができます。
XMLのDTDを作成する場合は、説明が必要となる可能性のある要素に対して、説明と要素自体を結び付けるためのいくつかの手段を提供するようにしてください。
画像フォーマットの中には、画像自体の情報と共にデータファイルの中にテキスト情報も含めることができるものがあります。画像フォーマットが、そのようなテキストをサポート(例：Portable Network Graphics、[PNG] 参照)している場合には、コンテンツ制作者はそこにも同様に情報を入れておくことができます。
コンテンツ制作者は、以下に述べるような理由から、ウェブページやウェブサイトを設計する際に後方互換性を考慮する必要があります。
そのため、過去の技術にあわせて設計する場合は、次のような手法を使うことを検討してみてください。
該当するチェックポイント：
ほとんどのコンテンツはアクセシブルにすることが可能ですが、ページ全体またはその一部をアクセシブルにできない場合もあります。アクセシブルな代わりのページを作るための手法には、次のようなものがあります。
アクセシブルな代わりのページにリンクする手法には、次の２つがあります。
該当するチェックポイント：
すべてのユーザーが、マウスやその他のポインティング・デバイスを使用したグラフィカルな環境にあるわけではありません。ユーザーによっては、リンクをたどったりフォームの構成部品をアクティブにしたりするために、キーボードや代替キーボードのほか、音声入力などを利用しています。コンテンツ制作者は、ユーザーがポインティング・デバイスではない他の装置を使用して操作している場合もあることに留意してください。キーボードによる操作(もちろんマウスによる操作に加えて)に対応したページは、一般に他の入力装置を使用しているユーザーに対してもアクセシブルになります。しかも、キーボードによる操作に対応したページをデザインすることによって、たいていの場合は全体としてのデザインも良くなります。
キーボードでリンクやフォームの構成部品にアクセスできるようにするためには、以下のような方法があります。
いくつかの要素は、マークアップ言語からはそのインターフェイスをコントロールできないオブジェクト(たとえば、アプレットやマルチメディア・プレイヤーなど)を取り込みます。その場合で、もし取り込むオブジェクトの持つインターフェイスがアクセシブルでない場合は、コンテンツ制作者はアクセシブルなインターフェイスを持ち同じ役割を果たす代わりのものを用意しておくべきです。
該当するチェックポイント：
各ページの体裁を一貫した様式にしておくことは、ナビゲーションの仕組をよりわかりやすくするだけでなく、重要な内容を探すためにナビゲーション部分を読み(聞き)飛ばすことも簡単にできるようにします。このことは、学習や読むことに対して障害のある人に役立つだけでなく、すべてのユーザーに対して操作を容易にするということでもあります。内容が予想できることによって、サイトの中から情報を探し出せる確立が高くなり、また情報が無いようであれば立ち去ることもできます。
構造として各ページで同じ位置に表示されるものの例としては、以下のものがあげられます。
ナビゲーションの仕組は、ユーザーがサイト内を行き来できるような通路を作り出します。ナビゲーション・バーやサイトマップ、検索機能を提供することはすべて、ユーザーがそのサイト内で探している情報へたどり着ける可能性を高めます。もし、あなたのサイトがビジュアル中心で構成されている場合で、ユーザーが現在サイトの中のどこへ向かっているのかや、今どこにいるのかなどのマップを頭の中で構成できないようであれば、その構造は操作するのが難しいものとなっているのかもしれません。そのような場合は、コンテンツ制作者は、ナビゲーションの仕組を説明するようなものを提供するべきです。サイト内で迷子になった人にとっては、サイトの説明や案内だけが頼りとなりますので、それらをアクセシブルにしておくことは重要なことだと言えます。
検索機能を提供する場合、コンテンツ制作者は様々なレベルのスキルや好みを満足させるような検索の機構を用意しておくべきです。ほとんどの場合、検索をするためには検索対象としてのキーワードを入力する必要があります。もし、検索するために完璧なスペルの入力が求められるのであれば、スペルのわからないユーザーや、そのサイトで使われている言語がよくわからないユーザーは、検索を行うために悪戦苦闘することになります。検索エンジンには、できるだけスペル・チェッカーや推測される近い単語の表示、検索例による検索、類似する単語による検索などの機能を含めるようにした方がよいでしょう。
該当するチェックポイント：
以下の節では、ページやサイトの内容を理解できるようにするための手法について解説しています。
以下の文章の書き方に関する提言は、すべての人、特に読むことや認識することに障害のある人に対して、サイトの内容を読みやすくするためのものです。いくつかの解説書([HACKER]など)では、ここで紹介するものとそれ以外の文章の書き方について、より詳しく論じられています。
その文書が読みやすいかどうかを判定するためには、「Gunning-Fog reading measure」([SPOOL]で例とともに解説されており、そのアルゴリズムは[TECHHEAD]にてオンラインで確認できます)と呼ばれる測定方法を利用することも考慮してみてください。このアルゴリズムでは、一般的に内容が読みやすいものに対して低いスコアを出します。結果の例としては、聖書、シェークスピア、マーク・トウェイン、テレビガイドなどはすべて約6となり、タイム、ニュースウィーク、ウォールストリート・ジャーナルなどは平均11程度となります。
同等の役割を果たすマルチメディア表現(テキスト以外のもの)は、読むことが難しかったり、まったく読むことができない人にとって理解の助けとなります。ただし、マルチメディアで表現することによって、必ずしもテキストがわかりやすいものになるとは限らないことに注意してください。場合によっては、マルチメディアで表現することによって、かえって混乱を招くかもしれません。
テキストを補うマルチメディア表現の例としては、次のようなものがあげられます。
該当するチェックポイント：
ユーザーが自分に適切なコンテンツを選択する方法には、様々なものがあります。
該当するチェックポイント：
コンテンツ制作者は時々、ユーザーがページの更新を要求していなくても、更新したり移動するようなページを制作することがあります。そのようなページの自動的な更新によって、あるユーザーは非常に混乱させられることになります。したがって、制作者はそのような方法ではなく、要求に応じる次のような方法をとるべきです。
注意：チェックポイント7.4とチェックポイント7.5は、いずれも古いユーザーエージェントの引き起こす問題に対して書かれたものです。新しいユーザーエージェントは、自動的な更新を無効にして、その代わりとしてページの先頭に新しい情報へのリンクを付加するべきです。
「ウェブコンテンツ・アクセシビリティ・ガイドライン1.0 技術書」[WCAG10-TECHS] から非推奨とされる例を参照することができます。
該当するチェックポイント：
画面を明滅させたりピカッと光らせることは、光過敏性てんかんのユーザーの発作を誘発する可能性があります。したがって、コンテンツ制作者は画面を明滅させることは避けるべきです。１秒間に20回の閃光や(ストロボの光りのような)点滅をピークとする１秒間に4〜59回(ヘルツ)の範囲の明滅や閃光は、発作を引き起こします。
該当するチェックポイント：
複数の文書をひとまとめにしておくことで、オフラインで読むことが容易になります。文書間の関連をより強めるには、次のようにしてください。
この節では、ウェブ文書のアクセシビリティに関わる問題が解決されているかどうかをテストするための方法とテクニックについて解説します。ここで紹介するテストは、アクセスするための重要な問題に焦点を当てたもので、アクセシビリティに関する多数の障壁を取り除くために有益なものです。しかしながら、テストで想定している状況のいくつかは、ある種の障害によって生じる状態を反映させただけのものであり、障害を持つユーザーが直面する可能性のあるすべての状態をシミュレートするものではありません。そして実際には、あなたのページはあなたの期待するほど使いやすくないかもしれません。したがって、テストの方法のひとつとして、コンテンツ制作者が異なる障害を持つ人々がページやサイトをどのように使おうとするのかを実際に見て確認することが推奨されています。
もし、以下に述べるテストを完了し、それに応じてデザインを調整してもアクセシブルにならなかった場合は、アクセシブルな別のページを制作した方がよいと思われます。
注意：ここで紹介するテストで問題が見つからなかった場合でも、それは「Web Content Accessibility Guidelines 1.0」に適合することを保証するものではありません。
自動検証ソフトを使用すると、そのページの文法(HTML、CSS、XMLなど)を検証することができます。ソフトウェアは適確に書かれた文書はより簡単に処理できますので、文法を正確にすることは、多くのアクセシビリティ上の問題を取り除くための手助けとなります。また、自動検証ソフトによっては、文法に基づくアクセシビリティ上の問題について警告を出すこともできます（たとえば、アクセシビリティに関わる重要な属性やプロパティが含まれていない場合など）。しかし、文法が正確であることが、その文書がアクセシブルであることを保証するわけではないことに注意してください。たとえば、その言語の仕様書に従って画像に代替テキストをつけたとしても、そのテキストの内容に誤りがあったり不適当なものとなっている可能性があります。そのような理由で、自動検証ソフトによっては、ユーザーに質問をして、解析のためにユーザーの判断を伴う過程を通して処理を行うものもあります。自動検証ソフトの例としては、以下のようなものがあります。
自動検証ソフトは通常、解決すべき問題点を指摘し、場合によってはそれらを解決するための例を示します。それらは多くの場合、各問題点についてどのように修正すればいいのかを示唆してくれるわけではありませんし、インタラクティブに文書を修正できるようにもなっていません。WAI Evaluation and Repair Working Group ([WAI-ER]) は、問題点を指摘するだけでなく、それらをインタラクティブに解決するツール群を開発するための活動をしています。
ほとんどのユーザー・エージェント(ブラウザ)とオペレーティング・システムでは、その表示形態や音、動作などを変更するための設定が可能になっていることに留意してください。様々な種類のユーザー・エージェントを使用した異なるユーザーが、ウェブ上でまったく異なる体験をしています。したがって、以下のような様々な環境を想定したテストをすることが必要です。
スピーチ・シンセサイザでページの内容を聞いている人は、スペルの間違った単語を推測して読み上げたものに関しては、意味がわからないかもしれません。文法チェッカーは、ページ内のテキスト部分が正しいかどうかを確認する際に役立ちます。これは、その文書が母国語でない人や、その文書に書かれている言語を学んでいる人にとっても役立つことです。これらは結果として、ページの内容をより理解してもらえることにつながります。
注意：この文書を書いた時点では、すべてのユーザー・エージェントがウェブページのアクセシビリティを増加させる HTML4.01 [HTML4] の属性と要素をサポートしているわけではないようです。
ブラウザや他のユーザー・エージェントのアクセシビリティに関する機能のサポート状況については、W3Cのウェブサイト([WAI-UA-SUPPORT])を参照してください。
一般的に、HTMLを扱うユーザー・エージェントは、サポートしていない属性は無視し、サポートしていない要素の内容は表示するという点にご注意ください。
該当するチェックポイント：
「Web Content Accessibility Guidelines 1.0」では、アクセシビリティに関する問題が検討済であり、それによってアクセシビリティの機能が組み込まれているW3Cのテクノロジーを使用することを提案しています。W3Cのテクノロジーの最新版については、「W3C Technical Reports and Publications」を参照してください。
現時点でのW3Cのテクノロジーを簡単に紹介します。
該当するチェックポイント：
音声で表現されるものには、それと同等の役割を果たすテキスト情報であるテキスト・トランスクリプトをつける必要があります。このトランスクリプトが映像と同期しているものを字幕と言い、映像についている音声を聞くことのできない人によって利用されます。
いくつかのメディア形式(QuickTime 3.0やSMILなど)は、マルチメディア・クリップに対して字幕と映像に関する説明を追加できるようになっています。SAMIには、字幕を付けることができます。以下の例は、見ている人に何が起きているのかがわかるように、字幕には声の他に周囲で聞こえる音も入れるべきだということを示しています。
【例】
「E.T.」のあるシーンに対する字幕。電話のベルが３回鳴る。その後、声が聞こえる。
[電話が鳴る]
[鳴る]
[鳴る]
もしもし？
【例終了】
現在使用しているフォーマットが代替トラックをサポートしていない場合には、字幕や説明が付いたものとそうでないものの２つのムービーを用意しておくことで対応できます。SMILやSAMIのような技術を利用すると、字幕をつけるための同期ファイルを使用して、映像・音声のファイルとは別のテキストファイルを結び付けることができます。
また、使用する技術によっては、ユーザーが複数の字幕の中から自分のスキルに合ったものを選択することもできます。詳しくは SMIL1.0 ([SMIL]) の仕様書を参照してください。
サウンドに対する同等の役割を果たすものは、テキスト・トランスクリプトまたは説明へのリンクとして提供することもできます。その場合、トランスクリプトへのリンクは、ページの最初の部分など目立つところに配置するべきです。しかし、スクリプトによって自動的にサウンドをロードするような場合には、現在サウンドが再生されていることを示す表示も自動的に表示させ、サウンドに対する説明やトランスクリプトも提供するべきです。
注意：ユーザーの設定によっては、ブラウザは音声情報ではなく視覚的な情報をロードすることができるため、この手法に関しては様々な論議があります。しかし、上記の方法は現在のブラウザに対しても有効です。
詳細は[NCAM]を参照してください。
該当するチェックポイント：
映像トラックの音声による説明は、音声やビデオ中の会話を邪魔することのないような形で、キーとなる視覚的な要素をナレーションとして提供します。キーとなる視覚的な要素とは、動作、背景、ボディ・ランゲージ、グラフィックス、画面上の文字などのことを言います。音声による説明は、基本的には目の見えない人がビデオ上の動作や音以外の情報を知るために利用されます。
【例】
ここでは、コレイテッド・テキスト・トランスクリプトの例として「ライオンキング」の一場面([DVS]に掲載されています)を紹介します。解説者(Describer)は、映像トラックを声で説明しますが、その説明はトランスクリプトの中に取り込まれているという点に注意してください。
シンバ：それっ！
解説者：シンバは外へ駆け出して行き、両親が後に続きます。サラビはやさしく微笑みながら、シンバを父の方へ行くようにと促します。２頭は並んで座りながら、黄金に輝く日の出を見つめています。
ムファサ：見なさい、シンバ。太陽が輝かせているのは、私たちの王国だ。
シンバ：ほんとだ！
【例終了】
注意：たとえば、サイトの使い方を(録音された声で)説明する際の語り手の動作など、視覚的な情報として重要でないものに対しては、音声による説明をつける必要はありません。
ムービーの場合は、オリジナルの音声に同期した音声による説明を提供するようにしてください。マルチメディア・フォーマットに関するより詳しい情報については、「音声による情報」の節を参照してください。
コレイテッド・テキスト・トランスクリプトは、視覚と聴覚の両方に障害のある人のアクセスを可能にするものです。コレイテッド・テキスト・トランスクリプトを提供することによって、すべての人が音声や映像に含まれる情報に索引をつけたり内容を検索できるようにもなります。
コレイテッド・テキスト・トランスクリプトには、会話のほか、画面に映っているものの音、画面に映っていないものの音、音楽、笑い声、拍手喝采などの重要な音も含まれます。言い替えると、字幕に含まれるすべてのテキストだけでなく、音に関する説明のすべてを含むということになります。
W3Cによる各種仕様の最新版については、「W3C Technical Reports(http://www.w3.org/TR/)」を参照してください。
注意：以下に示す参照先は、読者の便宜をはかるために掲載されたものです。W3Cでは、以下の参照先の内容が常に現状に即しているかどうかについては保証できません。また、製品の紹介についても、それらの動作について保証するものではありません。
WAIのウェブサイトには、他の選択肢として考えられるウェブブラウザ(アクセシビリティを考慮してデザインされた他のユーザーエージェントと支援技術)の一覧が掲載されています。
