アクセシビリティとは？/ ディック
[ 483] ウェブコンテンツ・アクセシビリティ・ガイドライン 1.0
[引用サイト] http://www.zspc.com/documents/wcag10/
|
この文書のすべての原著作権は、W3C(マサチューセッツ工科大学・フランス国立情報処理自動化研究所・慶應義塾大学)が保有します。また、この文書には、W3Cの「免責事項」「商標」「文書利用許諾」「ソフトウェア使用許諾」で示される規定が適用されます。 このガイドラインでは、どのようにすればウェブコンテンツが障害のある人にとってアクセシブルになるのかを説明しています。対象としては、すべてのウェブコンテンツ制作者(ページ制作者とサイト設計者)とオーサリングツールの開発者を想定しています。そして、このガイドラインの第一の目的は、ウェブのアクセシビリティを促進させることです。一方、このガイドラインに従うことは、ウェブコンテンツをすべてのユーザーが、どんなユーザーエージェント（たとえば、デスクトップパソコン上のブラウザ、音声ブラウザ、携帯電話、モバイル機器など）を利用していても、どのような環境（騒がしい場所、明るすぎる場所、暗すぎる場所、手を使えない状況）のもとでも利用可能にするということでもあります。また、このガイドラインに従えば、ユーザーがウェブ上からより速く情報を探し出せるようにもなります。このガイドラインは、コンテンツ制作者に画像や映像などを使わないことを奨めるものではありません。そのようなマルチメディアコンテンツを、多くのユーザーにとって、よりアクセシブルにするための制作方法を説明するものです。 この文書には、すべてのチェックポイントを優先度と項目別にまとめた付録がついています。付録の各チェックポイントは、この文書内の該当部分にリンクされています。項目としては、画像・マルチメディア・テーブル・フレーム・フォーム・スクリプトに分類されています。付録には、表形式のチェックポイント一覧とリスト形式のチェックポイント一覧の２つの形式があります。 「ウェブコンテンツ・アクセシビリティ・ガイドライン1.0 技術書」 ([TECHNIQUES])と題する別の文書では、この文書で定義されているチェックポイントを満たすための方法について説明しています。その中では、各チェックポイントについてより詳しく解説されており、HTML・CSS・SMIL・MathMLなどのサンプルも掲載されています。また、その中には文書が正しいかどうか確認する方法やテストする方法、HTMLの要素と属性別の一覧（どの方法でどれを使うか）も含まれています。上記の文書は、技術の進歩に応じて更新していく予定ですので、この文書と比較すると頻繁に更新されることになるでしょう。 この文書は、W3Cのメンバーとその他の方々によって検討され、その管理者によってW3C勧告として是認されたものです。したがって、この文書は最終的に完成したものであり、参照資料として利用したり、規準となる参考資料として引用することが認められています。勧告文書を制作するに当たってのW3Cの役割は、仕様に対しての注意を引いて、それを広く普及させることです。それによって、ウェブの機能性と普遍性を向上させることになります。 この仕様書は、英語版が唯一の正式な基準文書となっていますが、他の言語への翻訳版については以下を参照してください。 ウェブページ・デザインに関連するアクセシビリティについてよく知らない方は、多くのユーザーがあなたとは非常に異なった状況のもとで操作している可能性があるということを考えてみてください。 あるユーザーは、「見ることができない」「聞くことができない」「動くことができない」または「ある種類の情報を簡単に、あるいはまったく処理できない」かもしれません。 あるユーザーは、「キーボードやマウスがない」または「キーボードやマウスを使うことができない」かもしれません。 あるユーザーは、「テキストしか表示できない環境」「小さな画面を使用」「インターネットに低速でしか接続できない環境」で操作しているかもしれません。 あるユーザーは、その文書が書かれている言語を「容易に話したり理解することができない」かもしれません。 あるユーザーは、「見たり聞いたりできない状況」または「手が使えない状況」にあるかもしれません（車を運転している場合や、騒がしい環境などの場合）。 コンテンツ制作者は、ページデザインをする場合に上記の個々の状況を考慮する必要があります。しかし、考慮すべき様々な状況がある一方で、それぞれのアクセシブルなデザインのための方法は、同時に複数の状況に対して有効となる場合が多く、結果としてウェブ利用者全体にも利益をもたらします。たとえば、フォントのスタイルを指定する場合に、FONT要素を使用せずにスタイルシートを利用すると、HTML制作者は同時に複数の文書に渡っての制御をすることが可能になりますし、視力の低下している人達に対してよりアクセシブルになります。そして、各ページでスタイルシートを共有することは、すべてのユーザーのダウンロード時間の短縮にもつながります。 このガイドラインは、アクセシビリティについて説明し、アクセシブルなデザインのためのソリューションも提供します。それらは、上記のフォントスタイルの例のように、ある障害を持つ人々にとって問題となるような典型的な例をあげて説明しています。たとえば、１つめのガイドラインでは、コンテンツ制作者がどのようにすれば画像をアクセシブルにすることができるかということを説明しています。あるユーザーは、画像を見ることができないかもしれません。また、あるユーザーは、画像を表示できないテキストベースのブラウザを使用しているかもしれません。また、あるユーザーは、インターネットの接続速度が遅いなどの理由で、画像表示をオフにしているかもしれません。このガイドラインは、アクセシビリティを向上させるために画像を使わないように奨めているわけではなく、画像と同等の役割を果たすテキストを提供することでアクセシブルになるということを説明しています。 画像と「同等の役割を果たすテキスト」を提供することで、なぜその画像がアクセシブルになるのでしょうか？ この点に関しては「テキスト」であることと「同等の役割を果たす」ということの二点が重要な意味を持っています。 テキストによるコンテンツは、コンピュータに読み上げさせること、点字で表現すること、目で見ることができます。つまり、テキストを使用することで、これら三種類の方法を用いてそれぞれ異なる感覚（聴覚・触覚・視覚）で利用できるようになるため、様々なタイプの感覚障害のあるユーザーに対して情報をアクセシブルな状態にすることができるというわけです。 テキストを有益なものにするためには、テキストは画像と同じ役割や効果を持っていなければなりません。例として、「宇宙から見た地球の写真」の画像に対する「同等の役割を果たすテキスト」を考えてみましょう。もし、その画像を装飾のために使用しているのであれば、「宇宙から見た地球の写真」というテキストで必要な役割を果たします。もし、その画像の役割が地理的な特定の情報を示すためのものであれば、「同等の役割を果たすテキスト」はその情報を文章で表現したものにするべきです。もし、その画像の役割が、それをクリックすることなどによって、ユーザーに地球に関する情報を引き出させるものであれば、「同等の役割を果たすテキスト」は「地球に関する情報」となるでしょう。このように、もしそのテキストが障害のあるユーザーに対して、画像が他のユーザーに伝えるのと同じ役割や効果を提供できていれば、それを「同等の役割を果たすテキスト」と言うことができます。 同等の役割を果たすテキストは、障害を持つユーザーにとっての利益となるばかりでなく、必要なページをより速く検索できるようになるという点で、すべてのユーザーの役にも立ちます（サーチロボットがページを索引化する場合に、そのテキストを利用できるようになるため）。 ウェブコンテンツ制作者が、画像やマルチメディア・コンテンツに対して「同等の役割を果たすテキスト」を付けなければならないと同時に、 ユーザーエージェント（ブラウザやスクリーンリーダー、点字ディスプレイなどの支援技術）には、その情報をユーザーに提供する責任があります。 「テキストと同等の役割を果たすテキスト以外のもの（アイコン・音声・手話の映像など）」は、テキストをうまく認識できない人達（認知障害・学習障害・耳が聞こえない人など）に対して、その文章をアクセシブルにします。また、子供などの文字を読むことができないユーザーにとっても有用です。たとえば、目に見える情報と同等の役割を果たすテキスト以外のものの例としては「音声による説明」があります。マルチメディア・コンテンツのビジュアルな部分に対する音声による説明は、視覚的な情報を得ることができない人々に対して有益な情報となります。 このガイドラインには、「確実にうまく変換されるようにする」「内容を理解できて操作可能なものにする」という２つの大きな課題があります。 このガイドラインに従うことによって、コンテンツ制作者は適切に変換されるページを制作することが可能になります。適切に変換されるページは、「はじめに」にも書いたように様々な制約があるにもかかわらず、身体や感覚(知覚)や認識の障害、仕事上の制約、テクノロジー上の障壁も含めて、結局アクセシブルになります。次に、適切に変換されるページをデザインするためのカギとなる部分を紹介します。 テキストによる情報を提供する（同等の役割を果たすテキストを含む）。テキストは、ほとんどすべてのブラウジング環境で表現できますし、ほとんどすべてのユーザーが利用できます。 たとえユーザーが見ることや聞くことができなくても利用できるページを制作してください。代わりに使用される感覚（聴覚・触覚・視覚など）に合った方法で、音声や映像の代わりとなる同じ効果や役割を持った情報を提供してください。これは、目が見えないユーザーに対してアクセシブルにするために、あらかじめサイト全体の内容を読み上げたものを録音した音声版を制作しないさいという意味ではありません。目の見えないユーザーは、ページのテキスト情報を得るためにスクリーンリーダーを使うことができます。 １つの種類のハードウェアに依存しない文書を作ってください。ページは、マウスが無い状態や、小さい画面、低解像度の画面、白黒の画面、画面なし、音声のみ、テキストのみなどの環境でも利用できるようにするべきです。 「確実にうまく変換されるようにする」という課題については、基本的にガイドラインの1〜11で説明されています。 コンテンツ制作者は、その内容を「理解できて操作可能なもの」にするべきです。これは、単純明快な言葉を使用するということだけでなく、１つのページ内や各ページ間を行き来できるように、理解できる構造も提供するということです。ページ中にナビゲーションのためのツールと位置情報を提供することで、アクセシビリティと使い勝手は最高に良くなります。必ずしもすべてのユーザーが「イメージマップ」「スクロールバー」「フレーム」「デスクトップパソコン上のグラフィカルなブラウザを使用している目の見えるユーザーを対象としたグラフィクス」のような視覚的な手がかりを利用できるわけではありません。また、ページの一部分しか見られない状態の時、ユーザーは前後関係がわからなくなります。その問題は、スピーチシンセサイザや点字ディスプレイを使用していて一度に一語ずつしかアクセスできない場合や、小さい画面を使用している場合、画面を拡大表示にしている場合などで一度に一部分しか見ることができない場合などに起こります。また、位置情報が無い場合、ユーザーは極端に大きなテーブルやリスト、メニューなどを理解できない可能性があります。 「内容を理解できて操作可能なものにする」という課題については、基本的にガイドラインの12〜14で説明されています。 この文書には、14のガイドラインもしくはアクセシブルなデザインのための一般的な原則が含まれています。それぞれのガイドラインには、以下のものが含まれています。 ナビゲーション・リンク − 次のガイドラインへ（右矢印）・前のガイドラインへ（左矢印）・目次内のこのガイドラインの位置へ（上矢印）の３つのリンクがあります。 各ガイドラインのチェックポイントでは、ガイドラインが一般的なコンテンツ制作の過程でどのように適用されるかを説明します。それぞれのチェックポイントには、以下のものが含まれています。 チェックポイントの優先順位 − 優先度１のチェックポイントは、スタイルシートを適用している場合には強調されて表示されます。 選択可能な適用方法などの解説・具体的な使用例・関連するガイドラインやチェックポイントへのクロスリファレンス 各チェックポイントは、各ページやサイト全体がチェックポイントを満たしているかどうか確認する場合に、考えられる様々な状況に対応できるように十分配慮されています。 各チェックポイントには、ワーキンググループによって割り当てられた、チェックポイントのアクセシビリティに与える影響に基づく優先度があります。 ウェブコンテンツ制作者は、このチェックポイントを満たさなければなりません。そうしないと、その文書の情報にアクセスできない人達が出てきます。このチェックポイントを満たすことは、ある特定の人々がウェブ文書を利用できるようにするために基本的に要求されることです。 ウェブコンテンツ制作者は、このチェックポイントを満たすべきです。そうしないと、その文書の情報にアクセスするのが難しい人達が出てきます。このチェックポイントを満たすことは、ウェブ文書にアクセスする上での重要な障害を取り除くことになります。 ウェブコンテンツ制作者は、このチェックポイントに取り組むことが望まれます。そうしないと、その文書の情報にアクセスするのが多少難しい人達が出てきます。このチェックポイントを満たすことは、ウェブ文書へのアクセス性を向上させます。 いくつかのチェックポイントは、特定の状況下において優先度が変わるものもあります（その場合は、その旨示されています）。 その情報がユーザーに与えられた時に、聞くための内容や見るための内容と本質的に同じ効果や役割を伝える内容を提供する。 画像や映像、音、アプレットなどに関しては直接利用することができない人もいますが、それらに対して同等の役割を果たす情報も含まれていれば、そのページを利用することが可能になります。この場合、同等の役割を果たす情報は、見るための内容や聞くための内容と同じ効果を持っていなければなりません。したがって、たとえば目次にリンクしている「上向きの矢印の画像」に対する同等の役割を果たすテキストの場合は、「目次へ」のようになります。場合によっては、同等の役割を果たす代わりのものは、見るための内容そのままの姿や聞くための内容の音そのものを表現すべき時もあります。（例：複雑な図、広告、図形や教育のために利用される音声のサンプルなど） このガイドラインでは、テキスト以外の内容（画像や、音声、映像）に付けるべき同等の役割を果たすテキストの重要性を強く訴えています。同等の役割を果たすテキストを使用する利点は、様々なテクノロジーを使っている様々な障害を持つ方々に対してそれぞれアクセシブルで利用可能であるという、その受容力にあります。テキストは、スピーチシンセサイザや点字ディスプレイに対して容易に出力可能ですし、画面や紙上に様々なサイズで表示させることも可能です。スピーチシンセサイザによって合成された音声は、目のよく見えない方々や多くの読むことが困難な（認知障害、学習障害、聾唖などの）方々にとって重要なものです。また、点字は目の見えない方々はもちろん、目と耳の両方が不自由な方々にとって欠くことのできないものです。文字として表示されるテキストは、多くのユーザーに利用されると同時に、耳の不自由な方々にも役立っています。 テキストと同等の役割を果たすテキスト以外のもの（画像、映像、音声）を提供することも、一部のユーザー（特に子供などの文字を読めないユーザーや読むことが困難なユーザー）にとっては有益なことです。映像その他の視覚的な表現をする場合、身振りや仕草などの動作は、それを示すためのじゅうぶんな意味を持つ音声を伴っていないこともあります。もし、その動作を表す言葉による説明がなければ、それを見ることができない人にはその内容は理解できないものとなるでしょう。 サーバーサイドのイメージマップを使用する場合には、各領域に対するものと同じテキストによるリンクも付けるようにする。[優先度1] ユーザーエージェントが、映像と同等の役割を果たすテキストを自動的に読み上げることができるようになるまでは、マルチメディア的な表現をする場合の映像トラックの重要な情報を示す部分に対して、音声による説明もつけるようにする。[優先度1] チェックポイント1.4で示すように、音声による説明は音声トラックと同期するようにしてください。視覚的な情報に対する同等の役割を果たすテキストに関しては、チェックポイント1.1を参照してください。 時間の流れを伴うマルチメディア表現をするもの（ムービーやアニメーションなど）を使用する場合には、同等の役割を果たす代わりのもの（字幕、映像トラックの音声による説明など）がそれに同期するようにする。[優先度1] ユーザーエージェントが、クライアントサイド・イメージマップのリンクに対する同等の役割を果たすテキストを表示できるようになるまでは、反応する各領域と同じリンク先のテキストによるリンクも提供する。[優先度3] ある情報を伝えるために色だけを利用している場合、特定の色を識別できない人やモノクロの画面を使用している人、ビジュアルな表示のできないディスプレイを使用している人などは、情報を受け取ることができなくなります。また、前景色と背景色の色相が非常に近いような場合、モノクロモニタで見ている人や色の識別が難しい人などに対して、十分なコントラストを与えることができません。 色によって表現されている全ての情報は、その色を再現できない環境でも得られるようにしておく（たとえば、前後関係やタグ付けなどによって）。[優先度1] 前景色と背景色の組み合わせは、色の識別が困難な人やモノクロ画面を使用している人などに対しても十分なコントラストを与えるようなものにする。 文書は、適切な構造を表す要素でタグ付けし、見栄えなどの表示方法を制御するためには、表示を制御するための要素や属性を使用せずに、スタイルシートを利用する。 タグ付けを正しく行わない（仕様に従わない）ことは、アクセシビリティの妨げになります。表示上の効果として間違ったタグ付けを行うこと（レイアウトのためにテーブルを利用することや、フォントサイズを変えるために見出しを利用すること）は、特別なソフトウェアを利用しているユーザーにとって、ページの構成を理解することやサイト内を行き来することを難しくしています。さらに、本来構造を示すべき部分に対して、構造を表すタグ付けではなく表示を制御するためのタグ付けをすること（たとえば、HTMLのPRE要素を使って表のように見せることなど）は、様々な装置でページの内容をわかりやすく表現することを難しくします。（内容と構造および表現方法の違いの説明を参照） コンテンツ制作者は、古いブラウザ上でも望んだ通りに表示されるような（タグ付けを正しく行わない）組み立て方をしたくなるかもしれません。しかし、そのような慣行はアクセシビリティ上の問題を引き起こすということに気付かなければなりませんし、表示上の効果というものが特定のユーザーに対してアクセシブルではない文書を作成する理由となるほど重要なものであるかどうかも考える必要があります。 逆に、コンテンツ制作者は、いく種類かのブラウザや支援技術が正しく処理できないからと言って、本来適切であるタグ付けを犠牲にしてしまうべきではありません。たとえば、古いバージョンのスクリーンリーダーがそれらのテキストを正しく取り扱うことができない（チェックポイント10.3 参照）とはいえ、HTMLで表形式の情報をタグ付けするためにTABLE要素を使うことは適切なことだと言えます。TABLE要素を正しく使用し、確実にうまく変換されるような（ガイドライン5 参照）テーブルを作成することによって、ソフトウェアが単に整列されただけのデータではなくテーブルを表現することが可能になります。 3.1 ある情報を表すための適切なマークアップ言語がある場合には、画像を使わずにそのマークアップ言語を使用する(タグ付けによって情報の意味を伝えるため)。[優先度2] たとえば、数学の方程式をタグ付けする場合は、MathMLを使用してください。そして、テキストのフォーマットやレイアウトの制御に関しては、スタイルシートを使用してください。もちろん、文字を表すために画像を使うことは避けて（テキストとスタイルシートを使用して）ください。 3.4 マークアップ言語の属性の値やスタイルシートのプロパティの値には、絶対的な大きさを表す単位ではなく、相対的な大きさを表す単位を使用する。[優先度2] たとえば、HTMLの場合では、H2要素はH1要素の１つ下の階層の見出しを示すために使用されます。見出しをフォントのサイズなどを変更する目的で使用してはいけません。 3.7 引用文には引用を表す要素のタグを付ける。引用部分を示すべきタグを、インデントなどのレイアウト目的で使用しない。[優先度2] コンテンツ制作者が文書中で自然言語が変わることをタグ付けで示していれば、スピーチシンセサイザや点字関連装置は自動的にその言語に切り替えることができます。このことは、マルチリンガルなユーザーに対して、文書をよりアクセシブルにすることになります。また、コンテンツ制作者は、文書の内容中で基本となる自然言語を（タグ付けやHTTPヘッダを使用して）示すべきです。さらに、コンテンツ制作者は、略語や頭字語に対してそれらの意味（省略していない状態のテキスト）も提供するようにしてください。 自然言語を示すタグ付けをしておくことは、支援技術に対して役立つだけでなく、サーチエンジンがキーワードを検索したり指定した言語を見分けることを可能にします。また、自然言語を示すタグ付けをしておくことは、学習障害・認知障害・聴覚障害・聾唖の方々を含むすべての人々に対して、読みやすさを向上させます。 略語や自然言語の変更が示されていない場合、読み上げ装置や点字出力されたものでは内容が判読できないものとなる可能性があります。 4.1 文書中の文章や同等の役割を果たすテキストの自然言語が変わる部分では、それを明示する。[優先度1] 4.2 文書中の略語や頭字語に対しては、その言葉が最初に出てくるところで正式名称(省略していない状態の言葉)を示す。[優先度3] テーブルがアクセシブルなブラウザやユーザーエージェントによってうまく変換されるために必要なタグ付けを正しく行う。 テーブルは、表形式の情報(データをあらわすための表)をタグ付けするために正当に使用されるべきです。コンテンツ制作者は、ページをレイアウトするためにテーブルを使用すること(レイアウト・テーブル)を避けるべきです。本来の目的以外の様々な使い方をされたテーブルは、スクリーンリーダーを使用しているユーザーに対して深刻な問題を引き起こしています。（チェックポイント10.3 参照） ユーザーエージェントの中には、テーブルのセル間を行き来できたり、ヘッダや他のセルの情報にアクセスできるものもあります。しかし、もし正しくタグ付けされていなければ、テーブルは適切な情報を提供できなくなってしまいます。（参考：ガイドライン3） 以下に示すチェックポイントを実践することは、音声によってアクセスしているユーザー(スクリーンリーダーやモバイルパソコンの利用者)や、一度にページ内の限られた範囲しか見る(聞く)ことのできないユーザー(音声出力や点字ディスプレイを利用しているユーザーや小さな画面で見ているユーザーなど)に対して役に立ちます。 5.2 データをあらわすための表が縦列や横列に対して複数の対応するヘッダを持っている場合には、データセルとヘッダセルを関連付けるためのマーク付けをする。[優先度1] 5.3 テーブルを線形化して意味が通る場合を除いて、テーブルをレイアウトのために使用しない。テーブルを線形化して意味が通らない場合は、同じ役割を果たす代わりのもの(それは 線形化して意味の通るテーブルでもよい)を提供すること。[優先度2] ユーザーエージェントがスタイルシートによる位置指定をサポートしているので、テーブルをレイアウトのために使用すべきではありません。参考： チェックポイント3.3 5.4 レイアウトのためにテーブルを使用する場合、表示を制御する目的で構造を表すためのタグを使用しない。[優先度2] たとえばHTMLの場合、テーブルのヘッダでもないのに、センタリングしたり太字で表示したいからといってTH要素を使ってはいけません。 コンテンツ制作者が、既存の技術に対する問題を解決するために新しい技術を使うことは推奨されるべきことではありますが、それは古いブラウザやその機能をオフにした状態のブラウザでもそのページを機能させる方法を知った上で行うべきです。 6.1 スタイルシートなしでも読めるように、構造のしっかりとした文書を作る。たとえば、そのHTML文書に指定してあるスタイルシートが無い状態でも、その文書を読むことが可能でなければならない。[優先度1] 内容が論理的にしっかりと構造化されていれば、スタイルシートがオフの状態やサポートされていない場合でも、意味を持った状態で表示されます。 6.2 動的な内容に対する同等の役割を果たすものは、その変化に伴って更新されるようにする。[優先度1] 6.3 スクリプトやアプレット、その他のプログラムが動作しないように設定されていたりサポートされていない場合でも、そのページが利用できるようにする。もし、それができないのであれば、アクセシブルな別のページを作成して同等の役割を果たす情報を提供する。[優先度1] たとえば、スクリプトによって機能するリンクは、スクリプトがオフにされていたりサポートされていなくても利用できるようにしてください（リンク先として「javascript:〜」と指定してはいけません）。もし、スクリプトなしでも利用できるようにすることが不可能であれば、NOSCRIPT要素で同等の役割を果たすテキストを提供する、またはクライアントサイドではなくサーバーサイドのスクリプトを使用する、またはチェックポイント11.4 にあるように別のアクセシブルなページを提供するなどしてください。参考：ガイドライン1 6.4 スクリプトとアプレットを使用する場合は、イベントハンドラが入力装置に依存しないようにする。[優先度2] 6.5 動的な内容については、それ自体をアクセシブルなものにするか、代わりの表現方法またはページを提供するようにする。[優先度2] 移動、点滅、スクロール、自動的に更新されるオブジェクトやページは、一時的にまたは完全に停止させることができるようにする。 認識や視覚に関する障害のある方々の中には、すばやく動く文字をうまく（または、まったく）読めない人もいます。また、文字を動かすと、認知障害のある人は気が散ってしまい、それ以上読めなくなってしまうこともあります。スクリーンリーダーは、動いている文字を読み上げることはできません。身体に障害のある方々は、動くオブジェクトに合わせてすばやく正確に動くことができないかもしれません。 【注】ユーザーエージェントがそれを制御するための適切な制御機能を提供するまでの間は、コンテンツ制作者の責任において以下のすべてのチェックポイントを満たすようにしてください。 ユーザーエージェントで画面の明滅(フリッカー)に関する設定が可能になるまでは、画面を明滅させることを避ける。[優先度1] 光過敏性てんかんのある人は、特に１秒間に20回の点滅をピークとする１秒間に４〜59回(Hz)の点滅や（ストロボの光りのような）暗いものから明るいものへの急激な変化に対し、その明滅やフラッシュがきっかけとなって発作を引き起こすことがあります。 ユーザーエージェントで点滅(blink)に関する設定が可能になるまでは、内容を点滅させることは避ける（つまり、規則的に表示されたり消えたりというような表現は別の表現に変更する）。[優先度2] ユーザーエージェントで移動する内容を止めることができるようになるまでは、ページ内で内容を移動させることを避ける。[優先度2] ページ内に移動する内容を含んでいる場合は、スクリプトやアプレット内にその動きや更新を止められるような機能を付けてください。内容を移動させるためのスクリプトにスタイルシートを使用することで、より簡単にその効果をオフにしたり変更することができるようになります。 ユーザーエージェントでページの自動的な更新を止めることができるようになるまでは、定期的に自動更新するようなページは作らない。[優先度2] ユーザーエージェントでページの自動的な移動を止めることができるようになるまでは、自動的に他のページに移動するようなタグ付けはしない。そのような場合は、代わりにサーバー側で自動的に移動させるようにする。[優先度2] ガイドライン8. ページ中に組み込まれたもののユーザーインターフェイスは、それ自体がアクセシブルなものにする ユーザーインターフェイスは、アクセシブルなデザインの原則に従ったものにする（機能の実現方法を装置に依存しないものにする、キーボードで操作可能にする、音声によるガイドをつけるなど）。 ページ中に組み込まれたオブジェクトが「独自のインターフェイス」を持っている場合、そのインターフェイスは（ブラウザ自身のインターフェイス同様に）アクセシブルなものでなければなりません。もし、組み込まれたオブジェクトのインターフェイスをアクセシブルにできない場合は、必ず代わりのアクセシブルな解決手段を提供してください。 8.1 スクリプトやアプレットなどのプログラムによる要素は、それ自身をアクセシブルにするか、支援技術で利用可能なものにする。[もしその機能が重要であり他の部分でそれが表現されていない場合は優先度1、そうでなければ優先度2] 装置に依存しないアクセスとは、ユーザーが選択した入力(出力)装置（マウス、キーボード、音声、ヘッドワンドなど）を使ってユーザーエージェントや文書を操作できることを言います。もし、たとえばフォームの操作がマウスなどのポインティングデバイスのみで操作可能な場合は、そのページが見えない状態で利用している人、音声入力を利用している人、キーボードで操作している人、その他ポインティングデバイス以外の入力装置を利用している人はフォームを使えないことになります。 【注】リンクとして使用されている画像やイメージマップに対して同等の役割を果たすテキストを付けると、ポインティングデバイスが無くてもそれらを操作することが可能になります。参考：ガイドライン1 一般的に、キーボードによる操作が可能なページは、音声入力やコマンドライン入力の場合でもアクセシブルです。 9.1 領域が定義できないような形状の場合を除き、サーバーサイドのイメージマップではなく、クライアントサイドのイメージマップを使用する。[優先度1] 9.2 それ自身にインターフェイスを持つ要素は、装置に依存しないで操作できるようにする。[優先度2] 9.3 スクリプトを使用する場合は、装置に依存するイベントハンドラではなく、論理イベントハンドラを指定する。[優先度2] 9.5 重要なリンク(クライアントサイド・イメージマップのリンクも含む)、フォームの構成部品とそのグループには、キーボード・ショートカットを付ける。[優先度3] 支援技術や古いブラウザを使った場合でも正しく操作できるように、暫定的なアクセシビリティの解決策をとる。 たとえば、古いブラウザの中には編集可能なボックス（TEXTAREAとINPUT要素）が空の状態では入力できないものがあります。また、古いスクリーンリーダーの中には、連続した複数のリンクを一つのリンクとして読み上げてしまうものもあります。そのような状態ではアクセスすることが難しいか、まったくアクセスできない状態になります。同様に現在のウインドウを変更することや、新しいウインドウを開くことは、それを目で確認することができないユーザーを混乱させます。 【注】以下のチェックポイントは、ユーザーエージェント（支援技術も含む）がそれらを実現（修正）するまでの間にするべきことです。これらのチェックポイントは「暫定的な」と表現されていますが、それはウェブコンテンツ・アクセシビリティ・ガイドラインのワーキンググループが、それらがこの文書が出版された時点ではウェブのアクセシビリティにとって必要で正当なことだと考えた結果です。しかし、ワーキンググループでは、それらが将来的にも必要なものだとは考えていません。 ユーザーエージェントで新しいウインドウを開かない設定ができるようになるまでは、ユーザーに知らせることなしに新しいウインドウを開いたり現在のウインドウを変更しないようにする。[優先度2] たとえばHTMLの場合、新しいウインドウをターゲットとするようなフレームを使用しないようにしてください。 ユーザーエージェントがフォームの構成部品とそのラベルを明確に対応づけられるようになるまでは、対応するラベルのあるすべての構成部品に対して、ラベルは適切な位置に配置する。[優先度2] 複数行の入力フィールド、一行の入力フィールド、または一つの組となった構成部品(チェックボックスなど)に対するラベルは、同じ行の直前の位置(１つの構成部品または一組の構成部品しかない場合)に配置するか、直前の行に配置しなければなりません。 10.3 支援技術も含むユーザーエージェントが、段組みのような形式のテキストを正しく表現できるようになるまでは、文章を段組形式で表示させるすべてのテーブルに対して、段組していない状態の同等の役割を果たすテキストを提供する。（それは、同一ページ内に配置しても、他のページに配置してもよい。）[優先度3] 線形化されたテーブルも参照してください。このチェックポイントは、段組形式で表現された文章を正しく扱うことができないユーザーエージェント(たとえば一部のスクリーンリーダーなど)を使用しているユーザーのためのものです。このチェックポイントは、コンテンツ制作者に対して「表形式の情報を表すためにテーブルを使用する」ことを否定するものではありません。 10.4 ユーザーエージェントが、空のテキストフィールドを正しく扱えるようになるまでは、デフォルトの文字を入れておくようにする。[優先度3] 10.5 ユーザーエージェント(支援技術も含む)が、隣り合うリンク部分をそれぞれ別のリンクとして明確に表現できるようになるまでは、隣り合うリンクの間に(両端をスペースで囲った)リンクしていない印刷可能な文字を入れる。[優先度3] W3Cのテクノロジー（仕様）とガイドラインに従う。W3Cのテクノロジーを利用できない部分や、うまく変換できなかったものに対しては、アクセシブルな代わりのバージョンを提供する。 W3Cの仕様は、設計段階においてアクセシビリティに関する点が考慮されるように初期の段階からレビューされています。 W3Cで定めたもの以外の多くの形式（PDFやShockwaveなど）を使用する場合には、プラグインやスタンドアロン・アプリケーションなどが必要となります。時には、これらの形式は標準的なユーザーエージェント（支援技術も含む）で利用することができない場合もあります。W3Cで定めたもの以外のものや標準的でないもの（特定の企業などが独自に定めた要素・属性・プロパティ・機能拡張など）を使わないことによって、ウェブページを様々なハードウェアやソフトウェアを利用しているさらに多くの人々に対してよりアクセシブルなものにすることができます。どうしてもアクセシブルでない技術（それが特定の企業独自のものであってもなくても）を使わなければならない場合は、必ずアクセシブルな同等の役割を果たす別のページを用意するようにしてください。 W3Cのテクノロジーを使っている場合でも、アクセシビリティ・ガイドラインに従う必要があります。新しい技術を使用する場合は、それがうまく変換されるようにしてください。 (参考：ガイドライン6) 11.3 ユーザーが自分の設定(言語やコンテント・タイプなど)に従った文書を受け取ることができるような情報を提供する。[優先度3] 11.4 もし、最大限に努力してもアクセシブルなページを作れなかった場合、W3Cのテクノロジーを利用したアクセシブルな、しかも同等の情報(役割)を持つ別のページを作成してそこへリンクする。そして、そのページはアクセシブルではないページ(元のページ)と同じ頻度で更新するようにする。[優先度1] コンテンツ制作者は、他のどの方法でもうまくいかない場合にのみ、最後の手段として別ページを作成するようにしてください。その理由は、別ページは一般的に元のページと比べると更新されることが少ないからです。更新されていないということは、元の内容を知ることができないという点で、アクセシブルでないページと同じことになります。別ページを自動生成できる場合は更新頻度も上がるかもしれませんが、それにしてもそのページの内容が意味のあるものになっているかどうか、リンクが間違っていないかどうかなど慎重に確認しなければなりません。最後の手段として別ページを作成する前に、元のページの設計について再考してみてください。元のページをアクセシブルにすることは、ほとんどすべてのユーザーがそのページを利用できるようになるということです。 内容を分類して、それらの関係を示す情報を提供することは、すべてのユーザーにとって役に立ちます。ページ内の各部分間の複雑な関係は、認知障害や目の不自由な方々にとって理解するのが難しいかもしれません。 12.2 フレームのタイトルだけでは明確にならない場合は、フレームの目的とそれぞれの関連性について説明をつける。[優先度2] 12.3 複数のまとまりによって構成される大きな情報は、より扱いやすくなるように自然で適切な単位でグループ分けをする。[優先度2] 探している情報がすぐに見つけだせるように、明確で一貫したナビゲーションのための仕組（位置情報、ナビゲーション・バー、サイトマップなど）を提供する。 明確で一貫したナビゲーションのための仕組は、認知障害や目の見えない方々にとっては重要なものであると同時に、すべてのユーザーにとって役に立ちます。 リンクしている部分の言葉は、その部分を読んだだけでも十分意味のわかるものにするべきです（リンクが１つの時でも、複数のリンクが並んでいる場合でも）。また、リンクしている部分の言葉は簡潔なものにしてください。 13.5 ナビゲーションのための仕組が目立ってアクセスしやすくなるように、ナビゲーション・バーをつける。[優先度3] 13.6 関連した複数のリンクが並んでいる部分は、ユーザーエージェントがその部分を読み飛ばすことができるように、１つのグループにして、かつ識別できるようにしておく（【訳注】スピーチシンセサイザなどを利用している場合に、毎回それをすべて聞かなくても済むようにするためなどの理由による）。ユーザーエージェントがそのようにできるようになるまでは、その部分を読み飛ばすことができるような仕組を提供する。[優先度3] 13.7 検索機能がある場合は、ユーザーのスキルと好みに合わせて異なるタイプの検索ができるようにする。[優先度3] これは「フロント・ローディング（【訳注】前読み。最初から最後まで続けて読んでいては時間がかかるため、段落などの始めだけを読んでいき必要な情報のある部分を探し出すような場合に行う）」をする場合によく利用されています。特にスピーチシンセサイザなどのように情報に順番にアクセスしていく装置を利用している人にとって役立ちます。 オフラインで利用できるということは、障害があってゆっくりとしか閲覧できないような場合に接続コストを安くすることになります。 一貫したページレイアウト、すぐに意味のわかるグラフィックス、わかりやすい文章。これらはすべてのユーザーにとって、そして特に認知障害や読むことが難しい人達にとって有益なものです。（しかし、目の見えない人やよく見えない人、画像を見ることができない状況の人や表示しない設定をしている人のために、同等の役割を果たすテキストをつけるようにしましょう。参考：ガイドライン1） 明瞭で簡潔な言葉を使用することで、情報がより伝わりやすくなります。文字で書かれた情報を読み取るのは、認知障害や学習障害の方々にとって難しいことかもしれません。また、明瞭で簡潔な文章にするということは、それが自分の一番得意とする言語でない場合や、主に手話を利用している方などにとっても役立ちます。 14.2 グラフィックスや音声がページの理解を助けると思われる部分には、それらを付けてテキストを補足する。[優先度3] 自動検証ツールを利用したり他の人に批評してもらうなどして、アクセシビリティに関する確認をしてください。ツールを利用して行う方法は、一般的に早くて便利ですが、すべての項目について確認できるわけではありません。文章の明瞭さやナビゲーションの容易さなどについては、他の人に批評してもらうことによって確認してください。 制作過程の早い段階から確認作業を開始するようにしてください。早期に発見されたアクセシビリティの問題点は、後から行うよりも簡単に解決したり避けたりすることができます。 以下に、いくつかの重要な確認方法を示します。より詳しい内容については、技術書の確認の項を参照してください。 自動的にアクセシビリティやブラウザへの対応をチェックをするツールを利用する。ただし、そのようなソフトウェアによるツールでは、すべての項目について確認できるわけではないことに注意すること。リンクしている部分の言葉は意味のあるものになっているか、同等の役割を果たすテキストの内容は適切かどうかなどは、ツールでは確認できない。 文章のスペルチェックと文法チェックを行う。スピーチシンセサイザによってページの内容を聞いている人は、スペルの間違った単語は理解できない可能性がある。文法的な間違いをなくすることは、内容を理解しやすいものにする。 文書の明快さと平易さについてレビューを行う。ワープロの機能による読みやすさの判定は、明快さと平易さの指標となる。さらに良い方法は、経験のある編集者に内容の明快さについてレビューしてもらうことである。編集者は言葉やアイコンの使い方によって起きる微妙な文化的問題を発見して、文書の有用性を高めてくれる場合もある。 障害者の方に文書のレビューを依頼する。その方が熟練者でも初心者でも、アクセシビリティや使いやすさに関する問題点や、それを操作することの難しさについての価値のあるフィードバックを得ることができる。 障害のある方々が日常生活を行うことができるように特別にデザインされたソフトウェアまたはハードウェア。支援技術には、車椅子や読み上げ機のほか、物をつかむための装置なども含まれます。ウェブ・アクセシビリティの範囲で利用されるソフトウェアによる支援技術としては、スクリーンリーダーや拡大表示用ソフトウェア、スピーチシンセサイザ、グラフィカルなデスクトップのブラウザで利用可能な音声入力ソフトウェアなどがあります。ハードウェアによる支援技術としては、代替キーボードやその他のポインティングデバイスなどがあります。 点字ディスプレイ（一般に「ダイナミック点字ディスプレイ」とも呼ばれている）とは、コンピュータなどの電子機器で突起または凹みを表現するものです。結果は点字の行として表され、それは次々と変化させることができます。現在のダイナミック点字ディスプレイは１つの文字を表すものから80文字を表すものまでありますが、一般的には１行につき12〜20文字のものが使用されています。 非推奨の要素や属性とは、新しい構文によって旧式となってしまったもののことを言います。これらはHTMLの将来のバージョンでは使用されなくなる可能性があります。技術書の中のHTML要素と属性のインデックスでは、HTML4.0の中のどの要素と属性が非推奨なのかを示しています。 制作者は非推奨の要素や属性を使わないようにするべきです。ただし、ユーザーエージェントは、後方互換性を保つためにサポートを続けるべきです。 ユーザーは自分の選択や必要性に応じた入出力装置を使用して、ユーザーエージェントを操作可能でなければなりません。入力装置にはポインティングデバイス（マウスなど）、キーボード、点字装置、ヘッドワンド（頭部に棒などの補装具を装着するもの）、マイクロフォンなどがあります。また、出力装置としては、モニタ、スピーチシンセサイザ、点字装置などがあります。 「装置に依存しないことをサポートする」ということは、ユーザーエージェントがすべての入出力装置をサポートしなければならないという意味ではないことに注意してください。ユーザーエージェントは、サポートしている装置に対して、十分な入出力のための機構を提供するべきです。たとえば、ユーザーエージェントがキーボードとマウスによる入力をサポートしている場合、ユーザーがキーボードとマウスのどちらを利用していてもすべての機能を利用できるようにするべきです。 例として文書の見出しについて考えてみます。見出しの内容は、その見出しが言わんとするそのものです（例：帆船）。HTMLでは、見出しはたとえばH2要素などによってタグ付けされる構造要素です。そして、最終的な見出しの表現方法としては、マージンをとった太字のブロックテキストや、中央揃えされたテキスト、音声スタイルの指定されたタイトルなどがあります。 DHTMLとは、HTMLやスタイルシート、ドキュメント・オブジェクト・モデル [DOM1] 、スクリプトなどのスタンダードな技術を合成させたものに対するマーケティング上の用語です。したがって、W3Cの仕様としてDHTMLを正式に定義したものはありません。ほとんどのガイドラインは、DHTMLを使用したアプリケーションに対して適用できると思われますが、次にあげるガイドラインではスクリプトとスタイルシートに関連する問題について述べられています。ガイドライン1、ガイドライン3、ガイドライン6、ガイドライン7、ガイドライン9 この文書では「要素」という言葉を、厳密なSGMLでの意味（要素は構文上の構造を表す）と、より一般的な内容のタイプ（映像や音声など）や論理的な構造（見出しやリストなど）の両方の意味で使用しています。二つめの意味によって、主にHTMLに対して作成されたガイドラインが他のマークアップ言語にも容易に適用できるようになっています。 二つの内容がユーザーに対して本質的に同じ役割や効果を提供できている時、それらの内容は「同等の役割を持っている」ことになります。この文書の方針では、同等の役割を果たすためには、もとの内容が障害のない人に対して提供する内容と本質的に同じ役割を、障害のある人にも提供しなければなりません（少なくともその障害の状態と利用可能なテクノロジーによって可能な範囲において）。たとえば「満月」というテキストは、満月の画像と同じ情報をユーザーに提供します。同等の情報にとって重要なことは、同じ役割を果たすということです。もし、その画像がリンクの一部で、しかも画像の意味を理解することがリンク先を推測する上で重要な意味を持っている場合、同等の役割を果たすものも同様にリンク先を連想させる情報をユーザーに与えなければなりません。アクセシブルではない内容に対して同等の役割を果たす情報を提供することは、その文書を障害者にとってアクセシブルにするために制作者が行うべき基本的な方法の一つです。 同じ役割を果たすことの一つとして、その内容がどのようなものか（その内容がどのように見えるか、または聞こえるか）を説明するのもよい方法です。たとえば、複雑な図表が表す情報をユーザーに理解してもらうために、制作者はその図表の視覚的な情報についても説明するべきです。 テキストによる内容は、ユーザーに対して音声合成や点字のほか、普通に表示される文字としても表現できるので、このガイドラインでは画像や音声の情報に対して必ず同等の役割を果たすテキストをつけるよう要求しています。したがって、同等の役割を果たすテキストには、本質的なすべての内容を書くようにしなければなりません。同等の役割を果たすテキスト以外のもの（視覚的な表現を音声で表したもの、手話による映像など）も、目の見えない人や認知障害、学習障害、耳が聞こえない人などの視覚的な情報や表示されたテキストから情報を得ることができない人に対してアクセシビリティを向上させます。 テキスト・トランスクリプトとは、音声情報と同等の役割を果たすテキストのことで、そこには話された内容のほかに効果音などの音も表現します。字幕とは、ビデオなどの映像と音が同期するもののオーディオトラックに対するテキスト・トランスクリプトのことです。字幕は一般的に映像の上にスーパーインポーズされて表示されます。そして、それは耳の聞こえない人や耳の遠い人、騒がしくて音が聞き取れない状況にいる人などに役立ちます。コレイテッド・テキスト・トランスクリプトとは、字幕に映像の情報のテキストによる説明（ビデオトラックの動作や仕草、映像、場面の変更など）も加えたものです。これらの同等の役割を果たすテキストは、耳や目の不自由な人やそのままではムービーを楽しめない人に対して、それをアクセシブルなものにします。また、同等の役割を果たすテキストをつけることによって、その情報をサーチエンジンが利用できるようになります。 同等の役割を果たすテキスト以外のものの一例として、その表現のキーとなる視覚的な要素を音声で表現するということがあげられます。その場合の表現方法としては、実際の声を録音したものと音声合成による方法があります。音声による表現は、オーディオトラックに同期させて、通常はオーディオトラックの自然な合間に発声されます。音声での表現には、動作や仕草、映像、場面の変更などの情報が含まれます。 イメージマップとは、画像をそれに関連してアクションを起こす特定の領域に分けたものです。アクティブな領域をクリックすると、なんらかのアクションを引き起こします。 ユーザーがクライアントサイド・イメージマップのアクティブな領域をクリックした時、ユーザーエージェントはどの領域がクリックされたのかを計算して、そのリンクに関連付けられたリンク先へと移動します。サーバーサイド・イメージマップのアクティブな領域をクリックすると、クリックした座標がサーバーに送られた後になんらかのアクションを起こします。 コンテンツ制作者は、イメージマップの領域に関連付けられたリンクと同じリンクを装置に依存しない表現で提供することで、クライアントサイド・イメージマップをアクセシブルにすることができます。また、クライアントサイド・イメージマップを使用することで、ユーザーエージェントはポインタがアクティブな領域にあるかどうかをユーザーに即座にフィードバックすることが可能になります。 もし、その情報が文書を理解するために重要であることがわかっているのであれば、文書中のその情報は重要なものであると言えます。 セルの内容を連続する段落の１つとして(たとえばページの下方向に)次々とつなげていくような、テーブルを表現する場合の処理方法を線形化と言います。この場合、その内容は文書のソース中でセルが定義されているのと同じ順序で表現されます。したがって、セルは定義されている順序で読んだ場合でも意味が通るようにしておくべきです。また、線形化されても意味が通るようにするためには、セルの中に構造を表す要素(段落、見出し、リストなど)を入れるようにしてください。 ナビゲーションのための仕組とは、ユーザーがページやサイト内の情報をたどっていくための様々な手段のことを言います。典型的な仕組としては、次のようなものがあります。 PDAは、小さくてポータブルなコンピュータです。ほとんどのPDAは、カレンダーや住所録、電子メールなどの個人情報を取り扱うために利用されています。一般的に小さな画面のついた手に乗るサイズの装置で、様々な入力源に対応しています。 見やすくするために、画面を部分的に拡大して表示するソフトウェア。拡大表示用ソフトウェアは、基本的に視力の弱い人に利用されます。 画面上に表示されている内容を音声で読み上げるソフトウェア。スクリーンリーダーは、基本的には目の見えない人によって利用されます。一般的にスクリーンリーダーは、画面上に表示されたテキスト情報は読み上げられますが、ペイント系の画像になった文字情報などは読み上げることはできません。 スタイルシートとは、文書の表現方法の指定に特化した構文の集合体です。スタイルシートには、その内容を制作した人が指定したもの、ユーザーが指定したもの、ユーザーエージェントに備わっているものの３種類があります。CSS([CSS2])では、それらの相互作用を「カスケード」と呼んでいます。 表現方法のマーク付けとは、HTMLのB要素やI要素などのように、構造ではなくスタイルを表すものです。STRONG要素とEM要素については、それが特定のフォントスタイルに結び付いていないことから、表現要素とは考えられていません。 データ同士（テキスト、数字、画像など）の関係を論理的に表現するためにテーブルが使用されている時、その情報は「表形式の情報」と呼ばれます。そして、そのテーブルは「データ・テーブル」と呼ばれます。テーブルによって表現された関係は、視覚的に（２次元で）表現されることの他に音声（各セルをヘッダー情報と共に読み上げる場合もある）その他の形式で表現される場合もあります。 ほとんどのチェックポイントでは、コンテンツ制作者はそのページやサイト全体に対して、アクセシビリティを確保するよう求められています。しかし、ユーザーエージェント（支援技術も含む）側で対応する必要のある点も多くあります。この文書を公布した時点では、必ずしもすべてのユーザーエージェントや支援技術が、ユーザーが必要とするアクセシビリティ上の操作手段を提供しているわけではありません（例としては、点滅するコンテンツを止める手段がない、スクリーンリーダーによってはテーブルをうまく扱うことができないなど）。「ユーザーエージェントが 〜 できるようになるまで」というように書かれているチェックポイントでは、コンテンツ制作者はアクセシビリティを確保するために、ほとんどのユーザーエージェントがそれらを実現するまでの間、さらなるサポートをするよう求められます。 ウェブコンテンツにアクセスするためのソフトウェア。これには、デスクトップのグラフィカルなブラウザや音声ブラウザ、携帯電話、マルチメディアプレイヤー、プラグインなどのほか、スクリーンリーダーや拡大表示用ソフトウェア、音声認識ソフトウェアなどのようにブラウザと共に動作するソフトウエアの支援技術も含まれます。 |
ディックのサイトです。
