contents

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

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


W3C

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

1999年5月5日 W3C勧告

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

概要

このガイドラインでは、どのようにすればウェブコンテンツが障害のある人にとってアクセシブルになるのかを説明しています。対象としては、すべてのウェブコンテンツ制作者(ページ制作者とサイト設計者)とオーサリングツールの開発者を想定しています。そして、このガイドラインの第一の目的は、ウェブのアクセシビリティを促進させることです。一方、このガイドラインに従うことは、ウェブコンテンツをすべてのユーザーが、どんなユーザーエージェント(たとえば、デスクトップパソコン上のブラウザ、音声ブラウザ、携帯電話、モバイル機器など)を利用していても、どのような環境(騒がしい場所、明るすぎる場所、暗すぎる場所、手を使えない状況)のもとでも利用可能にするということでもあります。また、このガイドラインに従えば、ユーザーがウェブ上からより速く情報を探し出せるようにもなります。このガイドラインは、コンテンツ制作者に画像や映像などを使わないことを奨めるものではありません。そのようなマルチメディアコンテンツを、多くのユーザーにとって、よりアクセシブルにするための制作方法を説明するものです。

この文書は、アクセシビリティのための原則と設計に関する考え方の参考文書です。この文書内で論じられている方法の中には、ウェブの国際化やモバイル・アクセスに触れている部分もあります。しかし、この文書はアクセシビリティを中心に説明していますので、他のW3Cアクティビティに関連する内容については、すべてを説明しているわけではありません。詳細は、W3C Mobile Access Activity ホームページW3C Internationalization Activity ホームページを参照してください。

この文書では、その内容を永続的なものとするために、頻繁に更新される種々のテクノロジーに対する各ブラウザのサポート状況は提供しません。ただし、Web Accessibility Initiative (WAI) のサイト内には、そのような情報を提供しているページ([WAI-UA-SUPPORT]参照)があります。

この文書には、すべてのチェックポイントを優先度と項目別にまとめた付録がついています。付録の各チェックポイントは、この文書内の該当部分にリンクされています。項目としては、画像・マルチメディア・テーブル・フレーム・フォーム・スクリプトに分類されています。付録には、表形式のチェックポイント一覧リスト形式のチェックポイント一覧の2つの形式があります。

「ウェブコンテンツ・アクセシビリティ・ガイドライン1.0 技術書」 ([TECHNIQUES])と題する別の文書では、この文書で定義されているチェックポイントを満たすための方法について説明しています。その中では、各チェックポイントについてより詳しく解説されており、HTMLCSSSMILMathMLなどのサンプルも掲載されています。また、その中には文書が正しいかどうか確認する方法やテストする方法、HTMLの要素と属性別の一覧(どの方法でどれを使うか)も含まれています。上記の文書は、技術の進歩に応じて更新していく予定ですので、この文書と比較すると頻繁に更新されることになるでしょう。 【注】必ずしもすべてのブラウザやマルチメディア関連ツールが、ガイドラインに書かれている内容をサポートしているとは限りません。特にHTML4.0やCSS1、CSS2の新しい仕様については、サポートされていない可能性があります。

「ウェブコンテンツ・アクセシビリティ・ガイドライン 1.0」は、Web Accessibility Initiative によって公布されているアクセシビリティ・ガイドラインのシリーズの中の一部です。そのシリーズの中には、User Agent Accessibility Guidelines ([WAI-USERAGENT]) や Authoring Tool Accessibility Guidelines ([WAI-AUTOOLS]) もあります。

この文書の位置付け

この文書は、W3Cのメンバーとその他の方々によって検討され、その管理者によってW3C勧告として是認されたものです。したがって、この文書は最終的に完成したものであり、参照資料として利用したり、規準となる参考資料として引用することが認められています。勧告文書を制作するに当たってのW3Cの役割は、仕様に対しての注意を引いて、それを広く普及させることです。それによって、ウェブの機能性と普遍性を向上させることになります。

この仕様書は、英語版が唯一の正式な基準文書となっていますが、他の言語への翻訳版については以下を参照してください。
http://www.w3.org/WAI/GL/WAI-WEBCONTENT-TRANSLATIONS

この文書の正誤表は以下にあります。
http://www.w3.org/WAI/GL/WAI-WEBCONTENT-ERRATA
この文書内に誤りを発見された場合は、wai-wcag-editor@w3.org までご連絡ください。

他のW3C勧告文書と技術文書の一覧については、http://www.w3.org/TR を参照してください。

この文書は、W3Cの Web Accessibility Initiative の活動の一環として制作されたものです。Web Content Guidelines Working Group の目的については、Working Group charter に記載されています。

付録として、チェックポイント一覧が表形式リスト形式で用意されています。


1. はじめに

ウェブページ・デザインに関連するアクセシビリティについてよく知らない方は、多くのユーザーがあなたとは非常に異なった状況のもとで操作している可能性があるということを考えてみてください。

コンテンツ制作者は、ページデザインをする場合に上記の個々の状況を考慮する必要があります。しかし、考慮すべき様々な状況がある一方で、それぞれのアクセシブルなデザインのための方法は、同時に複数の状況に対して有効となる場合が多く、結果としてウェブ利用者全体にも利益をもたらします。たとえば、フォントのスタイルを指定する場合に、FONT要素を使用せずにスタイルシートを利用すると、HTML制作者は同時に複数の文書に渡っての制御をすることが可能になりますし、視力の低下している人達に対してよりアクセシブルになります。そして、各ページでスタイルシートを共有することは、すべてのユーザーのダウンロード時間の短縮にもつながります。

このガイドラインは、アクセシビリティについて説明し、アクセシブルなデザインのためのソリューションも提供します。それらは、上記のフォントスタイルの例のように、ある障害を持つ人々にとって問題となるような典型的な例をあげて説明しています。たとえば、1つめのガイドラインでは、コンテンツ制作者がどのようにすれば画像をアクセシブルにすることができるかということを説明しています。あるユーザーは、画像を見ることができないかもしれません。また、あるユーザーは、画像を表示できないテキストベースのブラウザを使用しているかもしれません。また、あるユーザーは、インターネットの接続速度が遅いなどの理由で、画像表示をオフにしているかもしれません。このガイドラインは、アクセシビリティを向上させるために画像を使わないように奨めているわけではなく、画像と同等の役割を果たすテキストを提供することでアクセシブルになるということを説明しています。

画像と「同等の役割を果たすテキスト」を提供することで、なぜその画像がアクセシブルになるのでしょうか? この点に関しては「テキスト」であることと「同等の役割を果たす」ということの二点が重要な意味を持っています。

同等の役割を果たすテキストは、障害を持つユーザーにとっての利益となるばかりでなく、必要なページをより速く検索できるようになるという点で、すべてのユーザーの役にも立ちます(サーチロボットがページを索引化する場合に、そのテキストを利用できるようになるため)。

ウェブコンテンツ制作者が、画像やマルチメディア・コンテンツに対して「同等の役割を果たすテキスト」を付けなければならないと同時に、 ユーザーエージェント(ブラウザやスクリーンリーダー点字ディスプレイなどの支援技術)には、その情報をユーザーに提供する責任があります。

「テキストと同等の役割を果たすテキスト以外のもの(アイコン・音声・手話の映像など)」は、テキストをうまく認識できない人達(認知障害・学習障害・耳が聞こえない人など)に対して、その文章をアクセシブルにします。また、子供などの文字を読むことができないユーザーにとっても有用です。たとえば、目に見える情報と同等の役割を果たすテキスト以外のものの例としては「音声による説明」があります。マルチメディア・コンテンツのビジュアルな部分に対する音声による説明は、視覚的な情報を得ることができない人々に対して有益な情報となります。

2. アクセシブルなデザインのための課題

このガイドラインには、「確実にうまく変換されるようにする」「内容を理解できて操作可能なものにする」という2つの大きな課題があります。

2.1 確実にうまく変換されるようにする

このガイドラインに従うことによって、コンテンツ制作者は適切に変換されるページを制作することが可能になります。適切に変換されるページは、「はじめに」にも書いたように様々な制約があるにもかかわらず、身体や感覚(知覚)や認識の障害、仕事上の制約、テクノロジー上の障壁も含めて、結局アクセシブルになります。次に、適切に変換されるページをデザインするためのカギとなる部分を紹介します。

「確実にうまく変換されるようにする」という課題については、基本的にガイドラインの1〜11で説明されています。

2.2 内容を理解できて操作可能なものにする

コンテンツ制作者は、その内容を「理解できて操作可能なもの」にするべきです。これは、単純明快な言葉を使用するということだけでなく、1つのページ内や各ページ間を行き来できるように、理解できる構造も提供するということです。ページ中にナビゲーションのためのツールと位置情報を提供することで、アクセシビリティと使い勝手は最高に良くなります。必ずしもすべてのユーザーが「イメージマップ」「スクロールバー」「フレーム」「デスクトップパソコン上のグラフィカルなブラウザを使用している目の見えるユーザーを対象としたグラフィクス」のような視覚的な手がかりを利用できるわけではありません。また、ページの一部分しか見られない状態の時、ユーザーは前後関係がわからなくなります。その問題は、スピーチシンセサイザや点字ディスプレイを使用していて一度に一語ずつしかアクセスできない場合や、小さい画面を使用している場合、画面を拡大表示にしている場合などで一度に一部分しか見ることができない場合などに起こります。また、位置情報が無い場合、ユーザーは極端に大きなテーブルやリスト、メニューなどを理解できない可能性があります。

「内容を理解できて操作可能なものにする」という課題については、基本的にガイドラインの12〜14で説明されています。

3. ガイドラインの構成

この文書には、14のガイドラインもしくはアクセシブルなデザインのための一般的な原則が含まれています。それぞれのガイドラインには、以下のものが含まれています。

各ガイドラインのチェックポイントでは、ガイドラインが一般的なコンテンツ制作の過程でどのように適用されるかを説明します。それぞれのチェックポイントには、以下のものが含まれています。

各チェックポイントは、各ページやサイト全体がチェックポイントを満たしているかどうか確認する場合に、考えられる様々な状況に対応できるように十分配慮されています。

3.1 文書の規約

この文書全体を通して、以下の編集上の規約が適用さています。

4. 優先度

各チェックポイントには、ワーキンググループによって割り当てられた、チェックポイントのアクセシビリティに与える影響に基づく優先度があります。

[優先度1]
ウェブコンテンツ制作者は、このチェックポイントを満たさなければなりません。そうしないと、その文書の情報にアクセスできない人達が出てきます。このチェックポイントを満たすことは、ある特定の人々がウェブ文書を利用できるようにするために基本的に要求されることです。
[優先度2]
ウェブコンテンツ制作者は、このチェックポイントを満たすべきです。そうしないと、その文書の情報にアクセスするのが難しい人達が出てきます。このチェックポイントを満たすことは、ウェブ文書にアクセスする上での重要な障害を取り除くことになります。
[優先度3]
ウェブコンテンツ制作者は、このチェックポイントに取り組むことが望まれます。そうしないと、その文書の情報にアクセスするのが多少難しい人達が出てきます。このチェックポイントを満たすことは、ウェブ文書へのアクセス性を向上させます。

いくつかのチェックポイントは、特定の状況下において優先度が変わるものもあります(その場合は、その旨示されています)。

5. 適合度

ここでは、この文書への3段階の適合度を規定します。

【注】適合度は、音声によって読み上げられた場合でもわかる(正しく発音される)ように、単語で表記します。(例:AAAではなく、Triple-Aのように)

この文書に適合していることを示すには、以下の2つの様式のうち、いずれかを使用しなければなりません。

様式1:次の事柄を示してください。

様式1の例:

このページは、W3Cの「Web Content Accessibility Guidelines 1.0」(http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505)に「Double-A」のレベルで適合しています。

様式2: 各ページに、適合していることを示すW3Cが提供する3つのアイコンのうちの1つを配置してください。そして、そのアイコンからW3Cの説明のあるページにリンクしてください。アイコンとその配置方法に関する情報については、[WCAG-ICONS]を参照してください。


6. ウェブコンテンツ・アクセシビリティ・ガイドライン

ガイドライン1. 聞くための内容や見るための内容には、同等の役割を果たす代わりのものを提供する

Next guideline: 2 Previous guideline: 14 Go to contents

その情報がユーザーに与えられた時に、聞くための内容や見るための内容と本質的に同じ効果や役割を伝える内容を提供する。

画像や映像、音、アプレットなどに関しては直接利用することができない人もいますが、それらに対して同等の役割を果たす情報も含まれていれば、そのページを利用することが可能になります。この場合、同等の役割を果たす情報は、見るための内容や聞くための内容と同じ効果を持っていなければなりません。したがって、たとえば目次にリンクしている「上向きの矢印の画像」に対する同等の役割を果たすテキストの場合は、「目次へ」のようになります。場合によっては、同等の役割を果たす代わりのものは、見るための内容そのままの姿や聞くための内容の音そのものを表現すべき時もあります。(例:複雑な図、広告、図形や教育のために利用される音声のサンプルなど)

このガイドラインでは、テキスト以外の内容(画像や、音声、映像)に付けるべき同等の役割を果たすテキストの重要性を強く訴えています。同等の役割を果たすテキストを使用する利点は、様々なテクノロジーを使っている様々な障害を持つ方々に対してそれぞれアクセシブルで利用可能であるという、その受容力にあります。テキストは、スピーチシンセサイザや点字ディスプレイに対して容易に出力可能ですし、画面や紙上に様々なサイズで表示させることも可能です。スピーチシンセサイザによって合成された音声は、目のよく見えない方々や多くの読むことが困難な(認知障害、学習障害、聾唖などの)方々にとって重要なものです。また、点字は目の見えない方々はもちろん、目と耳の両方が不自由な方々にとって欠くことのできないものです。文字として表示されるテキストは、多くのユーザーに利用されると同時に、耳の不自由な方々にも役立っています。

テキストと同等の役割を果たすテキスト以外のもの(画像、映像、音声)を提供することも、一部のユーザー(特に子供などの文字を読めないユーザーや読むことが困難なユーザー)にとっては有益なことです。映像その他の視覚的な表現をする場合、身振りや仕草などの動作は、それを示すためのじゅうぶんな意味を持つ音声を伴っていないこともあります。もし、その動作を表す言葉による説明がなければ、それを見ることができない人にはその内容は理解できないものとなるでしょう。

チェックポイント:

1.1 テキスト以外の要素には、必ず同等の役割を果たすテキストをつける(alt属性やlongdesc属性、または要素の内容として)。テキスト以外の要素とは、次のようなものを指す。画像、グラフィカルな表現をしたもの(記号も含む)、イメージマップの領域、GIFアニメなどのアニメーション、アプレットなどのプログラムによるオブジェクト、ASCIIアート、フレーム、スクリプト、リスト項目の前につける画像、スペーサー、画像によるボタン、音(ユーザーが制御可能であるかどうかにかかわらず)、音声ファイル、映像の音声、映像。[優先度1]
たとえば、HTMLの場合は次のようにしてください。
  • IMG・INPUT・APPLET要素の場合は「alt」属性を利用して、OBJECT・APPLET要素の場合には要素の内容として同等の役割を果たすテキストを入れるようにしてください。
  • 「alt」属性に記述する文章だけでは完全に書き切れない複雑な内容(図表など)を表す場合には、IMGやFRAME要素の場合は「longdesc」属性を、OBJECT要素の場合は要素内容にリンクを、それ以外の場合には説明文へのリンクをつけるなどしてください。
  • イメージマップを使用する場合は、AREA要素の「alt」属性を利用するか、MAP要素内の内容としてA要素(+補足説明)を使用してください。

参考: チェックポイント9.1チェックポイント13.10

チェックポイント1.1の技術書の解説
1.2  サーバーサイドのイメージマップを使用する場合には、各領域に対するものと同じテキストによるリンクも付けるようにする。[優先度1]
参考: チェックポイント1.5チェックポイント9.1
チェックポイント1.2の技術書の解説
1.3  ユーザーエージェントが、映像と同等の役割を果たすテキストを自動的に読み上げることができるようになるまでは、マルチメディア的な表現をする場合の映像トラックの重要な情報を示す部分に対して、音声による説明もつけるようにする。[優先度1]
チェックポイント1.4で示すように、音声による説明は音声トラックと同期するようにしてください。視覚的な情報に対する同等の役割を果たすテキストに関しては、チェックポイント1.1を参照してください。
チェックポイント1.3の技術書の解説
1.4  時間の流れを伴うマルチメディア表現をするもの(ムービーやアニメーションなど)を使用する場合には、同等の役割を果たす代わりのもの(字幕、映像トラックの音声による説明など)がそれに同期するようにする。[優先度1]
チェックポイント1.4の技術書の解説
1.5  ユーザーエージェントが、クライアントサイド・イメージマップのリンクに対する同等の役割を果たすテキストを表示できるようになるまでは、反応する各領域と同じリンク先のテキストによるリンクも提供する。[優先度3]
参考: チェックポイント1.2チェックポイント9.1
チェックポイント1.5の技術書の解説

ガイドライン2. 色だけに依存しない

Next guideline: 3 Previous guideline: 1 Go to contents

色を再現できない環境で表示しても、テキストやグラフィックスが理解できるようにする

ある情報を伝えるために色だけを利用している場合、特定の色を識別できない人やモノクロの画面を使用している人、ビジュアルな表示のできないディスプレイを使用している人などは、情報を受け取ることができなくなります。また、前景色と背景色の色相が非常に近いような場合、モノクロモニタで見ている人や色の識別が難しい人などに対して、十分なコントラストを与えることができません。

チェックポイント:

2.1  色によって表現されている全ての情報は、その色を再現できない環境でも得られるようにしておく(たとえば、前後関係やタグ付けなどによって)。[優先度1]
チェックポイント2.1の技術書の解説
2.2  前景色と背景色の組み合わせは、色の識別が困難な人やモノクロ画面を使用している人などに対しても十分なコントラストを与えるようなものにする。 [対画像:優先度2 、対テキスト:優先度3]
チェックポイント2.2の技術書の解説

ガイドライン3. 正しくタグ付けし、適切にスタイルシートを使う

Next guideline: 4 Previous guideline: 2 Go to contents

文書は、適切な構造を表す要素でタグ付けし、見栄えなどの表示方法を制御するためには、表示を制御するための要素や属性を使用せずに、スタイルシートを利用する。

タグ付けを正しく行わない(仕様に従わない)ことは、アクセシビリティの妨げになります。表示上の効果として間違ったタグ付けを行うこと(レイアウトのためにテーブルを利用することや、フォントサイズを変えるために見出しを利用すること)は、特別なソフトウェアを利用しているユーザーにとって、ページの構成を理解することやサイト内を行き来することを難しくしています。さらに、本来構造を示すべき部分に対して、構造を表すタグ付けではなく表示を制御するためのタグ付けをすること(たとえば、HTMLのPRE要素を使って表のように見せることなど)は、様々な装置でページの内容をわかりやすく表現することを難しくします。(内容と構造および表現方法の違いの説明を参照)

コンテンツ制作者は、古いブラウザ上でも望んだ通りに表示されるような(タグ付けを正しく行わない)組み立て方をしたくなるかもしれません。しかし、そのような慣行はアクセシビリティ上の問題を引き起こすということに気付かなければなりませんし、表示上の効果というものが特定のユーザーに対してアクセシブルではない文書を作成する理由となるほど重要なものであるかどうかも考える必要があります。

逆に、コンテンツ制作者は、いく種類かのブラウザや支援技術が正しく処理できないからと言って、本来適切であるタグ付けを犠牲にしてしまうべきではありません。たとえば、古いバージョンのスクリーンリーダーがそれらのテキストを正しく取り扱うことができない(チェックポイント10.3 参照)とはいえ、HTMLで表形式の情報をタグ付けするためにTABLE要素を使うことは適切なことだと言えます。TABLE要素を正しく使用し、確実にうまく変換されるような(ガイドライン5 参照)テーブルを作成することによって、ソフトウェアが単に整列されただけのデータではなくテーブルを表現することが可能になります。

チェックポイント:

3.1 ある情報を表すための適切なマークアップ言語がある場合には、画像を使わずにそのマークアップ言語を使用する(タグ付けによって情報の意味を伝えるため)。[優先度2]
たとえば、数学の方程式をタグ付けする場合は、MathMLを使用してください。そして、テキストのフォーマットやレイアウトの制御に関しては、スタイルシートを使用してください。もちろん、文字を表すために画像を使うことは避けて(テキストとスタイルシートを使用して)ください。 参考: ガイドライン6ガイドライン11.
チェックポイント3.1の技術書の解説
3.2 一般に公開されている公式な文法に従った文書を作成する。[優先度2]
たとえば、公開されているDTD(HTML4.0 StrictDTDなど)を参照している文書の最初には、文書型宣言を入れてください。
チェックポイント3.2の技術書の解説
3.3 レイアウトや表現方法などを制御するにはスタイルシートを使う。[優先度2]
たとえば、フォントのスタイルを制御するためには、HTMLのFONT要素ではなく、CSSの「font」プロパティを使用してください。
チェックポイント3.3の技術書の解説
3.4 マークアップ言語の属性の値やスタイルシートのプロパティの値には、絶対的な大きさを表す単位ではなく、相対的な大きさを表す単位を使用する。[優先度2]
たとえば、CSSの場合では、絶対的な大きさを表す単位である「pt」や「cm」を使用せずに、「em」や「%」を使用してください。もし絶対的な大きさを表す単位を使用する場合には、表示される内容が利用可能なものになっているかどうか検証してください。(確認方法を参照)
チェックポイント3.4の技術書の解説
3.5 見出しを表す要素は、あくまで文書の構造を表すために使用し、かつ仕様に準じた使い方をする。[優先度2]
たとえば、HTMLの場合では、H2要素はH1要素の1つ下の階層の見出しを示すために使用されます。見出しをフォントのサイズなどを変更する目的で使用してはいけません。
チェックポイント3.5の技術書の解説
3.6 リストやリストの各項目は正しくタグ付けする。[優先度2]
たとえば、HTMLの場合には、OLやUL、DLなどのリストを正しく入れ子にするようにしてください。
チェックポイント3.6の技術書の解説
3.7 引用文には引用を表す要素のタグを付ける。引用部分を示すべきタグを、インデントなどのレイアウト目的で使用しない。[優先度2]
たとえば、HTMLの場合では、Q要素とBLOCKQUOTE要素はそれぞれ「短い引用文」と「長い引用文」に対して使用してください。
チェックポイント3.7の技術書の解説

ガイドライン4. 自然言語の取り扱い方に関する情報を明確に示す

Next guideline: 5 Previous guideline: 3 Go to contents

発音の仕方や、略語や外国語の意味が容易にわかるようなタグ付けをする。

コンテンツ制作者が文書中で自然言語が変わることをタグ付けで示していれば、スピーチシンセサイザや点字関連装置は自動的にその言語に切り替えることができます。このことは、マルチリンガルなユーザーに対して、文書をよりアクセシブルにすることになります。また、コンテンツ制作者は、文書の内容中で基本となる自然言語を(タグ付けやHTTPヘッダを使用して)示すべきです。さらに、コンテンツ制作者は、略語や頭字語に対してそれらの意味(省略していない状態のテキスト)も提供するようにしてください。

自然言語を示すタグ付けをしておくことは、支援技術に対して役立つだけでなく、サーチエンジンがキーワードを検索したり指定した言語を見分けることを可能にします。また、自然言語を示すタグ付けをしておくことは、学習障害・認知障害・聴覚障害・聾唖の方々を含むすべての人々に対して、読みやすさを向上させます。

略語や自然言語の変更が示されていない場合、読み上げ装置や点字出力されたものでは内容が判読できないものとなる可能性があります。

チェックポイント:

4.1 文書中の文章や同等の役割を果たすテキストの自然言語が変わる部分では、それを明示する。[優先度1]
たとえば、HTMLでは「lang」属性を、XMLでは「xml:lang」を使用してください。
チェックポイント4.1の技術書の解説
4.2 文書中の略語や頭字語に対しては、その言葉が最初に出てくるところで正式名称(省略していない状態の言葉)を示す。[優先度3]
たとえば、HTMLではABBR要素とACRONYM要素の「title」属性を使用してください。また、省略していない状態のテキストを本文中に組み込んでおくことも文書の有用性を高めることにつながります。
チェックポイント4.2の技術書の解説
4.3 文書の基本となる自然言語を示す。[優先度3]
たとえば、HTMLの場合はHTML要素に対して「lang」属性を、XMLの場合は「xml:lang」を指定するようにしてください。サーバー管理者はHTTPのコンテント・ネゴシエーション機能([RFC2068], section 14.13)を利用して、クライアントが自動的にあらかじめ指定してある言語の文書を受け取れるように設定しておくべきです。
チェックポイント4.3の技術書の解説

ガイドライン5. うまく変換されるテーブルを作る

Next guideline: 6 Previous guideline: 4 Go to contents

テーブルがアクセシブルなブラウザやユーザーエージェントによってうまく変換されるために必要なタグ付けを正しく行う。

テーブルは、表形式の情報(データをあらわすための表)をタグ付けするために正当に使用されるべきです。コンテンツ制作者は、ページをレイアウトするためにテーブルを使用すること(レイアウト・テーブル)を避けるべきです。本来の目的以外の様々な使い方をされたテーブルは、スクリーンリーダーを使用しているユーザーに対して深刻な問題を引き起こしています。(チェックポイント10.3 参照)

ユーザーエージェントの中には、テーブルのセル間を行き来できたり、ヘッダや他のセルの情報にアクセスできるものもあります。しかし、もし正しくタグ付けされていなければ、テーブルは適切な情報を提供できなくなってしまいます。(参考:ガイドライン3

以下に示すチェックポイントを実践することは、音声によってアクセスしているユーザー(スクリーンリーダーやモバイルパソコンの利用者)や、一度にページ内の限られた範囲しか見る(聞く)ことのできないユーザー(音声出力や点字ディスプレイを利用しているユーザーや小さな画面で見ているユーザーなど)に対して役に立ちます。

チェックポイント:

5.1 データをあらわすための表では、表のヘッダを明確に示す。[優先度1]
たとえば、HTMLの場合はデータセルを示すためにはTD要素を使用し、ヘッダを示すためにはTH要素を使用してください。
チェックポイント5.1の技術書の解説
5.2 データをあらわすための表が縦列や横列に対して複数の対応するヘッダを持っている場合には、データセルとヘッダセルを関連付けるためのマーク付けをする。[優先度1]
たとえばHTMLの場合では、横列を分類するためにTHEAD・TFOOT・TBODYの各要素を、縦列を分類するためにはCOLとCOLGROUP要素を使用してください。また、データ間のさらに複雑な関係を示すには「axis」「scope」「headers」の各属性を使用してください。
チェックポイント5.2の技術書の解説
5.3 テーブルを線形化して意味が通る場合を除いて、テーブルをレイアウトのために使用しない。テーブルを線形化して意味が通らない場合は、同じ役割を果たす代わりのもの(それは 線形化して意味の通るテーブルでもよい)を提供すること。[優先度2]
【注】 すでに ユーザーエージェントがスタイルシートによる位置指定をサポートしているので、テーブルをレイアウトのために使用すべきではありません。参考: チェックポイント3.3
チェックポイント5.3の技術書の解説
5.4 レイアウトのためにテーブルを使用する場合、表示を制御する目的で構造を表すためのタグを使用しない。[優先度2]
たとえばHTMLの場合、テーブルのヘッダでもないのに、センタリングしたり太字で表示したいからといってTH要素を使ってはいけません。
チェックポイント5.4の技術書の解説
5.5 テーブルには要約をつける。[優先度3]
たとえば、HTMLの場合はTABLE要素の「summary」属性を使用してください。
チェックポイント5.5の技術書の解説
5.6 ヘッダのラベルとして、ヘッダの内容を短く表現したものをつける。[優先度3]
たとえば、HTMLの場合はTH要素の「abbr」属性を使用してください。
チェックポイント5.6の技術書の解説

参考:チェックポイント10.3

ガイドライン6. 新しい技術を利用したページは、うまく変換されるようにしておく

Next guideline: 7 Previous guideline: 5 Go to contents

新しい技術をサポートしていなかったり、その機能をオフにした状態でもアクセシブルであるようにする。

コンテンツ制作者が、既存の技術に対する問題を解決するために新しい技術を使うことは推奨されるべきことではありますが、それは古いブラウザやその機能をオフにした状態のブラウザでもそのページを機能させる方法を知った上で行うべきです。

チェックポイント:

6.1 スタイルシートなしでも読めるように、構造のしっかりとした文書を作る。たとえば、そのHTML文書に指定してあるスタイルシートが無い状態でも、その文書を読むことが可能でなければならない。[優先度1]
内容が論理的にしっかりと構造化されていれば、スタイルシートがオフの状態やサポートされていない場合でも、意味を持った状態で表示されます。
チェックポイント6.1の技術書の解説
6.2 動的な内容に対する同等の役割を果たすものは、その変化に伴って更新されるようにする。[優先度1]
チェックポイント6.2の技術書の解説
6.3 スクリプトやアプレット、その他のプログラムが動作しないように設定されていたりサポートされていない場合でも、そのページが利用できるようにする。もし、それができないのであれば、アクセシブルな別のページを作成して同等の役割を果たす情報を提供する。[優先度1]
たとえば、スクリプトによって機能するリンクは、スクリプトがオフにされていたりサポートされていなくても利用できるようにしてください(リンク先として「javascript:〜」と指定してはいけません)。もし、スクリプトなしでも利用できるようにすることが不可能であれば、NOSCRIPT要素で同等の役割を果たすテキストを提供する、またはクライアントサイドではなくサーバーサイドのスクリプトを使用する、またはチェックポイント11.4 にあるように別のアクセシブルなページを提供するなどしてください。参考:ガイドライン1
チェックポイント6.3の技術書の解説
6.4 スクリプトとアプレットを使用する場合は、イベントハンドラが入力装置に依存しないようにする。[優先度2]
装置に依存しないこと」の定義を参照。
チェックポイント6.4の技術書の解説
6.5 動的な内容については、それ自体をアクセシブルなものにするか、代わりの表現方法またはページを提供するようにする。[優先度2]
たとえば、HTMLの場合、FRAMESET要素の最後にNOFRAMES要素を含めるようにします。アプリケーションによっては、クライアントサイドのスクリプトよりも、サーバーサイドのスクリプトの方がよりアクセシブルな場合があります。
チェックポイント6.5の技術書の解説

参考:チェックポイント11.4

ガイドライン7. 時間とともに変化する内容については、ユーザーが制御できるようにする

Next guideline: 8 Previous guideline: 6 Go to contents

移動、点滅、スクロール、自動的に更新されるオブジェクトやページは、一時的にまたは完全に停止させることができるようにする。

認識や視覚に関する障害のある方々の中には、すばやく動く文字をうまく(または、まったく)読めない人もいます。また、文字を動かすと、認知障害のある人は気が散ってしまい、それ以上読めなくなってしまうこともあります。スクリーンリーダーは、動いている文字を読み上げることはできません。身体に障害のある方々は、動くオブジェクトに合わせてすばやく正確に動くことができないかもしれません。

【注】ユーザーエージェントがそれを制御するための適切な制御機能を提供するまでの間は、コンテンツ制作者の責任において以下のすべてのチェックポイントを満たすようにしてください。

チェックポイント:

7.1  ユーザーエージェントで画面の明滅(フリッカー)に関する設定が可能になるまでは、画面を明滅させることを避ける。[優先度1]
【注】 光過敏性てんかんのある人は、特に1秒間に20回の点滅をピークとする1秒間に4〜59回(Hz)の点滅や(ストロボの光りのような)暗いものから明るいものへの急激な変化に対し、その明滅やフラッシュがきっかけとなって発作を引き起こすことがあります。
チェックポイント7.1の技術書の解説
7.2  ユーザーエージェントで点滅(blink)に関する設定が可能になるまでは、内容を点滅させることは避ける(つまり、規則的に表示されたり消えたりというような表現は別の表現に変更する)。[優先度2]
チェックポイント7.2の技術書の解説
7.3  ユーザーエージェントで移動する内容を止めることができるようになるまでは、ページ内で内容を移動させることを避ける。[優先度2]
ページ内に移動する内容を含んでいる場合は、スクリプトやアプレット内にその動きや更新を止められるような機能を付けてください。内容を移動させるためのスクリプトにスタイルシートを使用することで、より簡単にその効果をオフにしたり変更することができるようになります。 参考:ガイドライン8.
チェックポイント7.3の技術書の解説
7.4  ユーザーエージェントでページの自動的な更新を止めることができるようになるまでは、定期的に自動更新するようなページは作らない。[優先度2]
たとえば、HTMLの場合、ユーザーエージェントでページの自動的な更新を止めることができるようになるまでは、「HTTP-EQUIV=refresh」を使ってページ内容を自動的に更新させることは避けてください。
チェックポイント7.4の技術書の解説
7.5  ユーザーエージェントでページの自動的な移動を止めることができるようになるまでは、自動的に他のページに移動するようなタグ付けはしない。そのような場合は、代わりにサーバー側で自動的に移動させるようにする。[優先度2]
チェックポイント7.5の技術書の解説

【注】BLINK要素とMARQUEE要素は、W3CのどのHTMLの仕様にも定義されていないものです。コンテンツ制作者は、それらを使用すべきではありません。参考:ガイドライン11

ガイドライン8. ページ中に組み込まれたもののユーザーインターフェイスは、それ自体がアクセシブルなものにする

Next guideline: 9 Previous guideline: 7 Go to contents

ユーザーインターフェイスは、アクセシブルなデザインの原則に従ったものにする(機能の実現方法を装置に依存しないものにする、キーボードで操作可能にする、音声によるガイドをつけるなど)。

ページ中に組み込まれたオブジェクトが「独自のインターフェイス」を持っている場合、そのインターフェイスは(ブラウザ自身のインターフェイス同様に)アクセシブルなものでなければなりません。もし、組み込まれたオブジェクトのインターフェイスをアクセシブルにできない場合は、必ず代わりのアクセシブルな解決手段を提供してください。

【注】アクセシブルなインターフェイスについての情報に関しては、User Agent Accessibility Guidelines ([WAI-USERAGENT]) と Authoring Tool Accessibility Guidelines ([WAI-AUTOOL])を参照してください。

チェックポイント:

8.1 スクリプトやアプレットなどのプログラムによる要素は、それ自身をアクセシブルにするか、支援技術で利用可能なものにする。[もしその機能が重要であり他の部分でそれが表現されていない場合は優先度1、そうでなければ優先度2]
参考:ガイドライン6
チェックポイント8.1の技術書の解説

ガイドライン9. 装置に依存しないように設計する

Next guideline: 10 Previous guideline: 8 Go to contents

様々な入力装置からページの内容を操作できるような機能を使う。

装置に依存しないアクセスとは、ユーザーが選択した入力(出力)装置(マウス、キーボード、音声、ヘッドワンドなど)を使ってユーザーエージェントや文書を操作できることを言います。もし、たとえばフォームの操作がマウスなどのポインティングデバイスのみで操作可能な場合は、そのページが見えない状態で利用している人、音声入力を利用している人、キーボードで操作している人、その他ポインティングデバイス以外の入力装置を利用している人はフォームを使えないことになります。

【注】リンクとして使用されている画像やイメージマップに対して同等の役割を果たすテキストを付けると、ポインティングデバイスが無くてもそれらを操作することが可能になります。参考:ガイドライン1

一般的に、キーボードによる操作が可能なページは、音声入力やコマンドライン入力の場合でもアクセシブルです。

チェックポイント:

9.1 領域が定義できないような形状の場合を除き、サーバーサイドのイメージマップではなく、クライアントサイドのイメージマップを使用する。[優先度1]
参考: チェックポイント1.1チェックポイント1.2、 and チェックポイント1.5
チェックポイント9.1の技術書の解説
9.2 それ自身にインターフェイスを持つ要素は、装置に依存しないで操作できるようにする。[優先度2]
装置に依存しないこと」の定義を参照。
参考:ガイドライン8.
チェックポイント9.2の技術書の解説
9.3 スクリプトを使用する場合は、装置に依存するイベントハンドラではなく、論理イベントハンドラを指定する。[優先度2]
チェックポイント9.3の技術書の解説
9.4 リンクとフォームの構成部品、オブジェクトの全体を通しての論理的なTab移動順を設定しておく。[優先度3]
たとえば、HTMLの場合は「tabindex」属性を使用してTabキーによる移動の順序を指定するか、または論理的なページデザインをするようにしてください。
チェックポイント9.4の技術書の解説
9.5 重要なリンク(クライアントサイド・イメージマップのリンクも含む)、フォームの構成部品とそのグループには、キーボード・ショートカットを付ける。[優先度3]
たとえば、HTMLの場合は「accesskey」属性を使用してショートカットを指定してください。
チェックポイント9.5の技術書の解説

ガイドライン10. 暫定的な解決策をとる

Next guideline: 11 Previous guideline: 9 Go to contents

支援技術や古いブラウザを使った場合でも正しく操作できるように、暫定的なアクセシビリティの解決策をとる。

たとえば、古いブラウザの中には編集可能なボックス(TEXTAREAとINPUT要素)が空の状態では入力できないものがあります。また、古いスクリーンリーダーの中には、連続した複数のリンクを一つのリンクとして読み上げてしまうものもあります。そのような状態ではアクセスすることが難しいか、まったくアクセスできない状態になります。同様に現在のウインドウを変更することや、新しいウインドウを開くことは、それを目で確認することができないユーザーを混乱させます。

【注】以下のチェックポイントは、ユーザーエージェント支援技術も含む)がそれらを実現(修正)するまでの間にするべきことです。これらのチェックポイントは「暫定的な」と表現されていますが、それはウェブコンテンツ・アクセシビリティ・ガイドラインのワーキンググループが、それらがこの文書が出版された時点ではウェブのアクセシビリティにとって必要で正当なことだと考えた結果です。しかし、ワーキンググループでは、それらが将来的にも必要なものだとは考えていません。

チェックポイント:

10.1  ユーザーエージェントで新しいウインドウを開かない設定ができるようになるまでは、ユーザーに知らせることなしに新しいウインドウを開いたり現在のウインドウを変更しないようにする。[優先度2]
たとえばHTMLの場合、新しいウインドウをターゲットとするようなフレームを使用しないようにしてください。
チェックポイント10.1の技術書の解説
10.2  ユーザーエージェントがフォームの構成部品とそのラベルを明確に対応づけられるようになるまでは、対応するラベルのあるすべての構成部品に対して、ラベルは適切な位置に配置する。[優先度2]
複数行の入力フィールド、一行の入力フィールド、または一つの組となった構成部品(チェックボックスなど)に対するラベルは、同じ行の直前の位置(1つの構成部品または一組の構成部品しかない場合)に配置するか、直前の行に配置しなければなりません。 参考:チェックポイント12.4
チェックポイント10.2の技術書の解説
10.3 支援技術も含むユーザーエージェントが、段組みのような形式のテキストを正しく表現できるようになるまでは、文章を段組形式で表示させるすべてのテーブルに対して、段組していない状態の同等の役割を果たすテキストを提供する。(それは、同一ページ内に配置しても、他のページに配置してもよい。)[優先度3]
【注】 線形化されたテーブルも参照してください。このチェックポイントは、段組形式で表現された文章を正しく扱うことができないユーザーエージェント(たとえば一部のスクリーンリーダーなど)を使用しているユーザーのためのものです。このチェックポイントは、コンテンツ制作者に対して「表形式の情報を表すためにテーブルを使用する」ことを否定するものではありません。
チェックポイント10.3の技術書の解説
10.4 ユーザーエージェントが、空のテキストフィールドを正しく扱えるようになるまでは、デフォルトの文字を入れておくようにする。[優先度3]
たとえばHTMLの場合は、TEXTAREA要素とINPUT要素にデフォルトの文字を入れるようにしてください。
チェックポイント10.4の技術書の解説
10.5 ユーザーエージェント(支援技術も含む)が、隣り合うリンク部分をそれぞれ別のリンクとして明確に表現できるようになるまでは、隣り合うリンクの間に(両端をスペースで囲った)リンクしていない印刷可能な文字を入れる。[優先度3]
チェックポイント10.5の技術書の解説

ガイドライン11. W3Cのテクノロジーとガイドラインを使用する

Next guideline: 12 Previous guideline: 10 Go to contents

W3Cのテクノロジー(仕様)とガイドラインに従う。W3Cのテクノロジーを利用できない部分や、うまく変換できなかったものに対しては、アクセシブルな代わりのバージョンを提供する。

このガイドラインでは、いくつかの理由によってW3Cのテクノロジー(HTMLやCSSなど)を推奨しています。

W3Cで定めたもの以外の多くの形式(PDFやShockwaveなど)を使用する場合には、プラグインやスタンドアロン・アプリケーションなどが必要となります。時には、これらの形式は標準的なユーザーエージェント支援技術も含む)で利用することができない場合もあります。W3Cで定めたもの以外のものや標準的でないもの(特定の企業などが独自に定めた要素・属性・プロパティ・機能拡張など)を使わないことによって、ウェブページを様々なハードウェアやソフトウェアを利用しているさらに多くの人々に対してよりアクセシブルなものにすることができます。どうしてもアクセシブルでない技術(それが特定の企業独自のものであってもなくても)を使わなければならない場合は、必ずアクセシブルな同等の役割を果たす別のページを用意するようにしてください。

W3Cのテクノロジーを使っている場合でも、アクセシビリティ・ガイドラインに従う必要があります。新しい技術を使用する場合は、それがうまく変換されるようにしてください。 (参考:ガイドライン6)

【注】PDFやPostScript、RTFなどの文書から、W3Cのマークアップ言語(HTML・XML)へとコンバートする場合、必ずしもそれがアクセシブルな文書になるとは限りません。したがって、コンバート後には各ページのアクセシビリティや使いやすさなどを確認するようにしてください(付録 A. 確認方法を参照)。もし、簡単にはうまくコンバートできない場合は、そのページが適切にコンバートされるまで何度も修正するか、HTMLまたはプレーンテキスト版を用意するようにしてください。

チェックポイント:

11.1 その目的に合っていて利用可能な場合にはW3Cのテクノロジーを利用する。しかも、サポートされていれば最新版を使用する。[優先度2]
W3Cの最新の仕様を見たい場合は、仕様書一覧を参照してください。また、各ユーザーエージェントのW3Cテクノロジーのサポート状況については、[WAI-UA-SUPPORT]を参照してください。
チェックポイント11.1の技術書の解説
11.2 W3Cのテクノロジーのうち、非推奨となっているものは使用しない。[優先度2]
たとえばHTMLの場合では、FONT要素は非推奨となっています。この場合、FONT要素は使用せずにスタイルシート(CSSの場合は「font」プロパティ)を利用するようにしてください。
チェックポイント11.2の技術書の解説
11.3 ユーザーが自分の設定(言語やコンテント・タイプなど)に従った文書を受け取ることができるような情報を提供する。[優先度3]
【注】 可能であれば、コンテント・ネゴシエーション機能を利用してください。
チェックポイント11.3の技術書の解説
11.4 もし、最大限に努力してもアクセシブルなページを作れなかった場合、W3Cのテクノロジーを利用したアクセシブルな、しかも同等の情報(役割)を持つ別のページを作成してそこへリンクする。そして、そのページはアクセシブルではないページ(元のページ)と同じ頻度で更新するようにする。[優先度1]
チェックポイント11.4の技術書の解説

【注】 コンテンツ制作者は、他のどの方法でもうまくいかない場合にのみ、最後の手段として別ページを作成するようにしてください。その理由は、別ページは一般的に元のページと比べると更新されることが少ないからです。更新されていないということは、元の内容を知ることができないという点で、アクセシブルでないページと同じことになります。別ページを自動生成できる場合は更新頻度も上がるかもしれませんが、それにしてもそのページの内容が意味のあるものになっているかどうか、リンクが間違っていないかどうかなど慎重に確認しなければなりません。最後の手段として別ページを作成する前に、元のページの設計について再考してみてください。元のページをアクセシブルにすることは、ほとんどすべてのユーザーがそのページを利用できるようになるということです。

ガイドライン12. 前後関係や位置を表す情報を提供する

Next guideline: 13 Previous guideline: 11 Go to contents

複雑な内容やページ構成でもユーザーが理解できるように、前後関係や位置を表す情報を提供する。

内容を分類して、それらの関係を示す情報を提供することは、すべてのユーザーにとって役に立ちます。ページ内の各部分間の複雑な関係は、認知障害や目の不自由な方々にとって理解するのが難しいかもしれません。

チェックポイント:

12.1 フレームの特定や操作を容易にするために、各フレームにはタイトルをつける。[優先度1]
たとえばHTMLの場合は、FRAME要素には「title」属性をつけるようにしてください。
チェックポイント12.1の技術書の解説
12.2 フレームのタイトルだけでは明確にならない場合は、フレームの目的とそれぞれの関連性について説明をつける。[優先度2]
たとえばHTMLの場合は、「longdesc」属性をつけるか、説明へのリンクをつけてください。
チェックポイント12.2の技術書の解説
12.3 複数のまとまりによって構成される大きな情報は、より扱いやすくなるように自然で適切な単位でグループ分けをする。[優先度2]
たとえばHTMLの場合、SELECT要素内のOPTION要素であればOPTGROUP要素を利用して、フォームの構成部品であればFIELDSET要素とLEGEND要素を利用して、リストであれば適切な位置で入れ子にして、構造的には見出しを使用するなどしてグループ分けしてください。 参考:ガイドライン3.
チェックポイント12.3の技術書の解説
12.4 ラベルをフォームの構成部品に明確に関連付ける。[優先度2]
たとえばHTMLの場合は、LABEL要素とその「for」属性を使用してください。
チェックポイント12.4の技術書の解説

ガイドライン13.  はっきりとわかるナビゲーションのための仕組を提供する

Next guideline: 14 Previous guideline: 12 Go to contents

探している情報がすぐに見つけだせるように、明確で一貫したナビゲーションのための仕組(位置情報、ナビゲーション・バー、サイトマップなど)を提供する。

明確で一貫したナビゲーションのための仕組は、認知障害や目の見えない方々にとっては重要なものであると同時に、すべてのユーザーにとって役に立ちます。

チェックポイント:

13.1 各リンク部分は、その行き先が明確にわかるようにする。[優先度2]
リンクしている部分の言葉は、その部分を読んだだけでも十分意味のわかるものにするべきです(リンクが1つの時でも、複数のリンクが並んでいる場合でも)。また、リンクしている部分の言葉は簡潔なものにしてください。
たとえばHTMLの場合、「ここをクリック」ではなく「バージョン4.3について」などのようにしてください。さらに、リンクにタイトル(HTMLでは「title」属性)をつけることによって、リンク先をより明確に示すこともできます。
チェックポイント13.1の技術書の解説
13.2 そのページやサイト全体に関する情報を加えるためにメタデータを提供する。[優先度2]
たとえば、文書の制作者や内容のタイプなどを示すためには、RDF ([RDF])を使用してください。
【注】 ユーザーエージェントの中には、HTMLのLINK要素とその「rel」属性または「rev」属性(rel="next"、rel="previous"、rel="index"など)で記述された文書間の関係からナビゲーション・ツールを構築するものもあります。参考:チェックポイント13.5
チェックポイント13.2の技術書の解説
13.3 サイトの全体的な構成に関する情報(たとえば、サイトマップや目次など)を提供する。[優先度2]
その際、利用可能なアクセシビリティ関連機能を目立つようにして説明してください。
チェックポイント13.3の技術書の解説
13.4 ナビゲーションの仕組は、一貫したものを提供する。[優先度2]
チェックポイント13.4の技術書の解説
13.5 ナビゲーションのための仕組が目立ってアクセスしやすくなるように、ナビゲーション・バーをつける。[優先度3]
チェックポイント13.5の技術書の解説
13.6 関連した複数のリンクが並んでいる部分は、ユーザーエージェントがその部分を読み飛ばすことができるように、1つのグループにして、かつ識別できるようにしておく(【訳注】スピーチシンセサイザなどを利用している場合に、毎回それをすべて聞かなくても済むようにするためなどの理由による)。ユーザーエージェントがそのようにできるようになるまでは、その部分を読み飛ばすことができるような仕組を提供する。[優先度3]
チェックポイント13.6の技術書の解説
13.7 検索機能がある場合は、ユーザーのスキルと好みに合わせて異なるタイプの検索ができるようにする。[優先度3]
チェックポイント13.7の技術書の解説
13.8 見出しや段落、リストなどの始めの言葉は、他の部分と区別できるようなものにする。[優先度3]
【注】 これは「フロント・ローディング(【訳注】前読み。最初から最後まで続けて読んでいては時間がかかるため、段落などの始めだけを読んでいき必要な情報のある部分を探し出すような場合に行う)」をする場合によく利用されています。特にスピーチシンセサイザなどのように情報に順番にアクセスしていく装置を利用している人にとって役立ちます。
チェックポイント13.8の技術書の解説
13.9 文書が複数ページから成る場合は、それらを集めるための情報を提供する。[優先度3]
たとえばHTMLの場合は、LINK要素とその「rel」属性や「rev」属性を指定してください。文書を集めるための他の方法として、複数のページを圧縮(zip・tar・gzip・stuffitなど)して一つのファイルとして用意おくことも有用です。
【注】 オフラインで利用できるということは、障害があってゆっくりとしか閲覧できないような場合に接続コストを安くすることになります。
チェックポイント13.9の技術書の解説
13.10 複数行に渡るASCIIアートは、読み飛ばすことができるようにする。[優先度3]
チェックポイント1.1付録のASCIIアートの例を参照してください。
チェックポイント13.10の技術書の解説

ガイドライン14.  文書は明瞭で簡潔なものにする

Next guideline: 1 Previous guideline: 13 Go to contents

文書は、より簡単に理解しやすいように明瞭で簡潔なものにする。

一貫したページレイアウト、すぐに意味のわかるグラフィックス、わかりやすい文章。これらはすべてのユーザーにとって、そして特に認知障害や読むことが難しい人達にとって有益なものです。(しかし、目の見えない人やよく見えない人、画像を見ることができない状況の人や表示しない設定をしている人のために、同等の役割を果たすテキストをつけるようにしましょう。参考:ガイドライン1

明瞭で簡潔な言葉を使用することで、情報がより伝わりやすくなります。文字で書かれた情報を読み取るのは、認知障害や学習障害の方々にとって難しいことかもしれません。また、明瞭で簡潔な文章にするということは、それが自分の一番得意とする言語でない場合や、主に手話を利用している方などにとっても役立ちます。

チェックポイント:

14.1 そのサイトの内容に合わせて、最も明瞭で簡潔な文章にする。[優先度1]
チェックポイント14.1の技術書の解説
14.2 グラフィックスや音声がページの理解を助けると思われる部分には、それらを付けてテキストを補足する。[優先度3]
参考:ガイドライン1.
チェックポイント14.2の技術書の解説
14.3 全体を通して一貫したスタイルの表現方法をとるようにする。[優先度3]
チェックポイント14.3の技術書の解説

付録 A. -- 確認方法

自動検証ツールを利用したり他の人に批評してもらうなどして、アクセシビリティに関する確認をしてください。ツールを利用して行う方法は、一般的に早くて便利ですが、すべての項目について確認できるわけではありません。文章の明瞭さやナビゲーションの容易さなどについては、他の人に批評してもらうことによって確認してください。

制作過程の早い段階から確認作業を開始するようにしてください。早期に発見されたアクセシビリティの問題点は、後から行うよりも簡単に解決したり避けたりすることができます。

以下に、いくつかの重要な確認方法を示します。より詳しい内容については、技術書の確認の項を参照してください。

  1. 自動的にアクセシビリティやブラウザへの対応をチェックをするツールを利用する。ただし、そのようなソフトウェアによるツールでは、すべての項目について確認できるわけではないことに注意すること。リンクしている部分の言葉は意味のあるものになっているか、同等の役割を果たすテキストの内容は適切かどうかなどは、ツールでは確認できない。
  2. HTMLやXMLなどの文法の確認する。
  3. CSSなどのスタイルシートの確認する。
  4. テキストブラウザまたはそのエミュレータで確認する。
  5. グラフィックブラウザを以下のように設定して確認する。
    • 音を出してグラフィックを表示する
    • グラフィックを表示しない
    • 音を出さない
    • マウスを使わない
    • フレーム・スクリプト・スタイルシート・アプレットのすべてがオフ
  6. 複数種類のブラウザの新旧バージョンで確認する。
  7. 音声ブラウザ、スクリーンリーダー、拡大表示用ソフトウェア、小さなディスプレイなどで確認する。
  8. 文章のスペルチェックと文法チェックを行う。スピーチシンセサイザによってページの内容を聞いている人は、スペルの間違った単語は理解できない可能性がある。文法的な間違いをなくすることは、内容を理解しやすいものにする。
  9. 文書の明快さと平易さについてレビューを行う。ワープロの機能による読みやすさの判定は、明快さと平易さの指標となる。さらに良い方法は、経験のある編集者に内容の明快さについてレビューしてもらうことである。編集者は言葉やアイコンの使い方によって起きる微妙な文化的問題を発見して、文書の有用性を高めてくれる場合もある。
  10. 障害者の方に文書のレビューを依頼する。その方が熟練者でも初心者でも、アクセシビリティや使いやすさに関する問題点や、それを操作することの難しさについての価値のあるフィードバックを得ることができる。

付録 B. -- 用語解説

アクセシブル
ある障害を持っている人がその内容を利用することができた時、その内容はアクセシブルだと言えます。
アプレット
ウェブページに組み込まれたプログラム。
支援技術
障害のある方々が日常生活を行うことができるように特別にデザインされたソフトウェアまたはハードウェア。支援技術には、車椅子や読み上げ機のほか、物をつかむための装置なども含まれます。ウェブ・アクセシビリティの範囲で利用されるソフトウェアによる支援技術としては、スクリーンリーダーや拡大表示用ソフトウェア、スピーチシンセサイザ、グラフィカルなデスクトップのブラウザで利用可能な音声入力ソフトウェアなどがあります。ハードウェアによる支援技術としては、代替キーボードやその他のポインティングデバイスなどがあります。
ASCIIアート
ASCIIアートとは、絵を表すために組み合わされた文字や記号を指します。たとえば ";-)" は、ニコニコしている様子を表しています。以下に示したASCIIアートによる図表は、患者が目を開けている状態と閉じている状態での光りの点滅の頻度と光過敏による発作の関係を表したものです。[ ASCIIアートの図表を読み飛ばす | 図表の説明を参照する ]
 
  %   __ __ __ __ __ __ __ __ __ __ __ __ __ __   
100 |             *                             |
 90 |                *  *                       |
 80 |          *           *                    |
 70 |             @           *                 |
 60 |          @                 *              |
 50 |       *        @              *           |
 40 |                   @              *        |
 30 |    *  @              @  @           *     |
 20 |                                           |
 10 |    @                       @  @  @  @     |
      0  5 10 15 20 25 30 35 40 45 50 55 60 65 70
      光りの点滅の頻度 (Hz)
オーサリングツール
HTMLエディタや文書変換ツール、データベースからウェブコンテンツを生成するツールなどは、すべてオーサリングツールです。アクセシブルなツールの開発に関する情報については、「Authoring Tool Accessibility Guidelines」([WAI-AUTOOLS])を参照してください。
後方互換
古いバージョンの言語やプログラムなどでも動作するように設計すること。
点字
目の見えない人が指先で読むことができるように、異なるパターンの六つの突起で文字や数字を表したもの。たとえば「Accessible」は、点字で次のように表されます。
Accessible
点字ディスプレイ(一般に「ダイナミック点字ディスプレイ」とも呼ばれている)とは、コンピュータなどの電子機器で突起または凹みを表現するものです。結果は点字の行として表され、それは次々と変化させることができます。現在のダイナミック点字ディスプレイは1つの文字を表すものから80文字を表すものまでありますが、一般的には1行につき12〜20文字のものが使用されています。
コンテンツ制作者
ウェブページを制作する人やウェブサイトを設計する人。
非推奨
非推奨の要素や属性とは、新しい構文によって旧式となってしまったもののことを言います。これらはHTMLの将来のバージョンでは使用されなくなる可能性があります。技術書の中のHTML要素と属性のインデックスでは、HTML4.0の中のどの要素と属性が非推奨なのかを示しています。
制作者は非推奨の要素や属性を使わないようにするべきです。ただし、ユーザーエージェントは、後方互換性を保つためにサポートを続けるべきです。
装置に依存しないこと
ユーザーは自分の選択や必要性に応じた入出力装置を使用して、ユーザーエージェントを操作可能でなければなりません。入力装置にはポインティングデバイス(マウスなど)、キーボード、点字装置、ヘッドワンド(頭部に棒などの補装具を装着するもの)、マイクロフォンなどがあります。また、出力装置としては、モニタ、スピーチシンセサイザ、点字装置などがあります。
「装置に依存しないことをサポートする」ということは、ユーザーエージェントがすべての入出力装置をサポートしなければならないという意味ではないことに注意してください。ユーザーエージェントは、サポートしている装置に対して、十分な入出力のための機構を提供するべきです。たとえば、ユーザーエージェントがキーボードとマウスによる入力をサポートしている場合、ユーザーがキーボードとマウスのどちらを利用していてもすべての機能を利用できるようにするべきです。
文書の内容と構造および表現方法
文書の内容とは、人が話したり書いたりする言語や画像、音声、映像、アニメーションなどを通して、直接ユーザーに伝える内容そのものを指します。文書の構造とは、それがどのように論理的に系統立てられているかを指します。例としては、各章に別れているとか、「はじめに」や「目次」などがついているなどです。HTMLのP(段落)、STRONG(強調)、BLOCKQUOTE(引用) などの要素 は文書の構造を表すので、構造要素(structural element)と呼ばれています。文書の表現方法とは、その文書をどのように表現するかを指します。例としては、印刷する、2次元のグラフィックで表現する、文字のみで表示する、音声で表現する、点字で表すなどです。HTMLのB(太字)、FONT(フォント関連の指定)、CENTER(中央揃え)などの要素は、文書の表現方法を表すので表現要素(presentation element)と呼ばれています。
例として文書の見出しについて考えてみます。見出しの内容は、その見出しが言わんとするそのものです(例:帆船)。HTMLでは、見出しはたとえばH2要素などによってタグ付けされる構造要素です。そして、最終的な見出しの表現方法としては、マージンをとった太字のブロックテキストや、中央揃えされたテキスト、音声スタイルの指定されたタイトルなどがあります。
Dynamic HTML (DHTML)
DHTMLとは、HTMLやスタイルシート、ドキュメント・オブジェクト・モデル [DOM1] 、スクリプトなどのスタンダードな技術を合成させたものに対するマーケティング上の用語です。したがって、W3Cの仕様としてDHTMLを正式に定義したものはありません。ほとんどのガイドラインは、DHTMLを使用したアプリケーションに対して適用できると思われますが、次にあげるガイドラインではスクリプトとスタイルシートに関連する問題について述べられています。ガイドライン1ガイドライン3ガイドライン6ガイドライン7ガイドライン9
要素
この文書では「要素」という言葉を、厳密なSGMLでの意味(要素は構文上の構造を表す)と、より一般的な内容のタイプ(映像や音声など)や論理的な構造(見出しやリストなど)の両方の意味で使用しています。二つめの意味によって、主にHTMLに対して作成されたガイドラインが他のマークアップ言語にも容易に適用できるようになっています。
SGMLの要素の中には、それ自体が表示されるもの(例:HTMLではP、LI、TABLE要素など)と、他の内容と置き換わるもの(例:IMG要素など)、処理に影響するもの(例:STYLEとSCRIPT)があることに注意してください。文書の一部としてテキストを発生させるような要素は、テキスト要素と呼ばれています。
同等の役割を果たす
二つの内容がユーザーに対して本質的に同じ役割や効果を提供できている時、それらの内容は「同等の役割を持っている」ことになります。この文書の方針では、同等の役割を果たすためには、もとの内容が障害のない人に対して提供する内容と本質的に同じ役割を、障害のある人にも提供しなければなりません(少なくともその障害の状態と利用可能なテクノロジーによって可能な範囲において)。たとえば「満月」というテキストは、満月の画像と同じ情報をユーザーに提供します。同等の情報にとって重要なことは、同じ役割を果たすということです。もし、その画像がリンクの一部で、しかも画像の意味を理解することがリンク先を推測する上で重要な意味を持っている場合、同等の役割を果たすものも同様にリンク先を連想させる情報をユーザーに与えなければなりません。アクセシブルではない内容に対して同等の役割を果たす情報を提供することは、その文書を障害者にとってアクセシブルにするために制作者が行うべき基本的な方法の一つです。
同じ役割を果たすことの一つとして、その内容がどのようなものか(その内容がどのように見えるか、または聞こえるか)を説明するのもよい方法です。たとえば、複雑な図表が表す情報をユーザーに理解してもらうために、制作者はその図表の視覚的な情報についても説明するべきです。
テキストによる内容は、ユーザーに対して音声合成や点字のほか、普通に表示される文字としても表現できるので、このガイドラインでは画像や音声の情報に対して必ず同等の役割を果たすテキストをつけるよう要求しています。したがって、同等の役割を果たすテキストには、本質的なすべての内容を書くようにしなければなりません。同等の役割を果たすテキスト以外のもの(視覚的な表現を音声で表したもの、手話による映像など)も、目の見えない人や認知障害、学習障害、耳が聞こえない人などの視覚的な情報や表示されたテキストから情報を得ることができない人に対してアクセシビリティを向上させます。
同等の役割を果たす情報を提供する方法としては、属性(例:HTMLとSMILでは「alt」属性のテキストの値)として、要素の内容(例:HTMLのOBJECT要素の内容)として、文書内の文章として、リンク先の文章(例:HTMLの「longdesc」属性で示されるリンク、説明へのリンク)としてなど様々な方法があります。この場合、同等の役割を果たすものの複雑さにもよりますが、複数のテクニックを併用する必要があります(例:省略語と同等の役割を果たすものに対して「alt」を使うことは慣れたユーザーに役立ち、「longdesc」で示すリンク先で詳しく説明することは初めてのユーザーに役立ちます)。同等の役割を果たす情報をいつどのようにして提供するのかということに関する詳細は、技術書で解説されています。 ([TECHNIQUES]).
テキスト・トランスクリプトとは、音声情報と同等の役割を果たすテキストのことで、そこには話された内容のほかに効果音などの音も表現します。字幕とは、ビデオなどの映像と音が同期するもののオーディオトラックに対するテキスト・トランスクリプトのことです。字幕は一般的に映像の上にスーパーインポーズされて表示されます。そして、それは耳の聞こえない人や耳の遠い人、騒がしくて音が聞き取れない状況にいる人などに役立ちます。コレイテッド・テキスト・トランスクリプトとは、字幕に映像の情報のテキストによる説明(ビデオトラックの動作や仕草、映像、場面の変更など)も加えたものです。これらの同等の役割を果たすテキストは、耳や目の不自由な人やそのままではムービーを楽しめない人に対して、それをアクセシブルなものにします。また、同等の役割を果たすテキストをつけることによって、その情報をサーチエンジンが利用できるようになります。
同等の役割を果たすテキスト以外のものの一例として、その表現のキーとなる視覚的な要素を音声で表現するということがあげられます。その場合の表現方法としては、実際の声を録音したものと音声合成による方法があります。音声による表現は、オーディオトラックに同期させて、通常はオーディオトラックの自然な合間に発声されます。音声での表現には、動作や仕草、映像、場面の変更などの情報が含まれます。
画像
グラフィカルな表現をしたもの。
イメージマップ
イメージマップとは、画像をそれに関連してアクションを起こす特定の領域に分けたものです。アクティブな領域をクリックすると、なんらかのアクションを引き起こします。
ユーザーがクライアントサイド・イメージマップのアクティブな領域をクリックした時、ユーザーエージェントはどの領域がクリックされたのかを計算して、そのリンクに関連付けられたリンク先へと移動します。サーバーサイド・イメージマップのアクティブな領域をクリックすると、クリックした座標がサーバーに送られた後になんらかのアクションを起こします。
コンテンツ制作者は、イメージマップの領域に関連付けられたリンクと同じリンクを装置に依存しない表現で提供することで、クライアントサイド・イメージマップをアクセシブルにすることができます。また、クライアントサイド・イメージマップを使用することで、ユーザーエージェントはポインタがアクティブな領域にあるかどうかをユーザーに即座にフィードバックすることが可能になります。
重要
もし、その情報が文書を理解するために重要であることがわかっているのであれば、文書中のその情報は重要なものであると言えます。
線形化されたテーブル
セルの内容を連続する段落の1つとして(たとえばページの下方向に)次々とつなげていくような、テーブルを表現する場合の処理方法を線形化と言います。この場合、その内容は文書のソース中でセルが定義されているのと同じ順序で表現されます。したがって、セルは定義されている順序で読んだ場合でも意味が通るようにしておくべきです。また、線形化されても意味が通るようにするためには、セルの中に構造を表す要素(段落、見出し、リストなど)を入れるようにしてください。
リンクテキスト
リンクの内容として表現されるテキスト。
自然言語
フランス語、日本語、手話、点字などのように、話したり書いたり身振りなどによって表現される言語。内容の自然言語は、HTMLでは「lang」属性で([HTML40], section 8.1)、XMLでは「xml:lang」属性で([XML], section 2.12)示されます。
ナビゲーションのための仕組
ナビゲーションのための仕組とは、ユーザーがページやサイト内の情報をたどっていくための様々な手段のことを言います。典型的な仕組としては、次のようなものがあります。
ナビゲーション・バー
ナビゲーション・バーとは、文書またはサイトの中で最も重要な部分へのリンクを集めたものです。
サイトマップ
サイトマップとは、ページやサイトの全体的な構成を提供するものです。
目次
目次とは、一般的に文書中の最も重要なセクションを一覧形式のリンクにしたものです。
PDA (Personal Digital Assistant)
PDAは、小さくてポータブルなコンピュータです。ほとんどのPDAは、カレンダーや住所録、電子メールなどの個人情報を取り扱うために利用されています。一般的に小さな画面のついた手に乗るサイズの装置で、様々な入力源に対応しています。
拡大表示用ソフトウェア
見やすくするために、画面を部分的に拡大して表示するソフトウェア。拡大表示用ソフトウェアは、基本的に視力の弱い人に利用されます。
スクリーンリーダー
画面上に表示されている内容を音声で読み上げるソフトウェア。スクリーンリーダーは、基本的には目の見えない人によって利用されます。一般的にスクリーンリーダーは、画面上に表示されたテキスト情報は読み上げられますが、ペイント系の画像になった文字情報などは読み上げることはできません。
スタイルシート
スタイルシートとは、文書の表現方法の指定に特化した構文の集合体です。スタイルシートには、その内容を制作した人が指定したもの、ユーザーが指定したもの、ユーザーエージェントに備わっているものの3種類があります。CSS([CSS2])では、それらの相互作用を「カスケード」と呼んでいます。
表現方法のマーク付けとは、HTMLのB要素やI要素などのように、構造ではなくスタイルを表すものです。STRONG要素とEM要素については、それが特定のフォントスタイルに結び付いていないことから、表現要素とは考えられていません。
表形式の情報
データ同士(テキスト、数字、画像など)の関係を論理的に表現するためにテーブルが使用されている時、その情報は「表形式の情報」と呼ばれます。そして、そのテーブルは「データ・テーブル」と呼ばれます。テーブルによって表現された関係は、視覚的に(2次元で)表現されることの他に音声(各セルをヘッダー情報と共に読み上げる場合もある)その他の形式で表現される場合もあります。
ユーザーエージェントで 〜 できるようになるまで
ほとんどのチェックポイントでは、コンテンツ制作者はそのページやサイト全体に対して、アクセシビリティを確保するよう求められています。しかし、ユーザーエージェント支援技術も含む)側で対応する必要のある点も多くあります。この文書を公布した時点では、必ずしもすべてのユーザーエージェントや支援技術が、ユーザーが必要とするアクセシビリティ上の操作手段を提供しているわけではありません(例としては、点滅するコンテンツを止める手段がない、スクリーンリーダーによってはテーブルをうまく扱うことができないなど)。「ユーザーエージェントが 〜 できるようになるまで」というように書かれているチェックポイントでは、コンテンツ制作者はアクセシビリティを確保するために、ほとんどのユーザーエージェントがそれらを実現するまでの間、さらなるサポートをするよう求められます。
【注】 W3CのWAI ウェブサイト([WAI-UA-SUPPORT]参照)では、ユーザーエージェントのアクセシビリティ関連機能のサポートに関する情報を提供しています。コンテンツ制作者は定期的に参照するようにしてください。
ユーザーエージェント
ウェブコンテンツにアクセスするためのソフトウェア。これには、デスクトップのグラフィカルなブラウザや音声ブラウザ、携帯電話、マルチメディアプレイヤー、プラグインなどのほか、スクリーンリーダーや拡大表示用ソフトウェア、音声認識ソフトウェアなどのようにブラウザと共に動作するソフトウエアの支援技術も含まれます。

謝辞

Web Content Guidelines Working Group Co-Chairs:
Chuck Letourneau, Starling Access Services
Gregg Vanderheiden, Trace Research and Development
W3C Team contacts:
Judy Brewer and Daniel Dardailler
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, 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, Jaap van Lelieveld, and Jason White

The original draft of this document is based on "The Unified Web Site Accessibility Guidelines" ([UWSAG]) compiled by the Trace R & D Center at the University of Wisconsin. That document includes a list of additional contributors.

参考文献

W3Cによる各種仕様の最新版については、「W3C Technical Reports」を参照してください。

[CSS1]
"CSS, level 1 Recommendation", B. Bos, H. Wium Lie, eds., 17 December 1996, revised 11 January 1999. The CSS1 Recommendation is: http://www.w3.org/TR/1999/REC-CSS1-19990111.
The latest version of CSS1 is available at: http://www.w3.org/TR/REC-CSS1.
[CSS2]
"CSS, level 2 Recommendation", B. Bos, H. Wium Lie, C. Lilley, and I. Jacobs, eds., 12 May 1998. The CSS2 Recommendation is: http://www.w3.org/TR/1998/REC-CSS2-19980512.
The latest version of CSS2 is available at: http://www.w3.org/TR/REC-CSS2.
[DOM1]
"Document Object Model (DOM) Level 1 Specification", V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, and L. Wood, eds., 1 October 1998. The DOM Level 1 Recommendation is: http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001.
The latest version of DOM Level 1 is available at: http://www.w3.org/TR/REC-DOM-Level-1
[HTML40]
"HTML 4.0 Recommendation", D. Raggett, A. Le Hors, and I. Jacobs, eds., 17 December 1997, revised 24 April 1998. The HTML 4.0 Recommendation is: http://www.w3.org/TR/1998/REC-html40-19980424.
The latest version of HTML 4.0 is available at: http://www.w3.org/TR/REC-html40.
[HTML32]
"HTML 3.2 Recommendation", D. Raggett, ed., 14 January 1997. The latest version of HTML 3.2 is available at: http://www.w3.org/TR/REC-html32.
[MATHML]
"Mathematical Markup Language", P. Ion and R. Miner, eds., 7 April 1998. The MathML 1.0 Recommendation is: http://www.w3.org/TR/1998/REC-MathML-19980407.
The latest version of MathML 1.0 is available at: http://www.w3.org/TRREC-MathML.
[PNG]
"PNG (Portable Network Graphics) Specification", T. Boutell, ed., T. Lane, contributing ed., 1 October 1996. The latest version of PNG 1.0 is: http://www.w3.org/TR/REC-png.
[RDF]
"Resource Description Framework (RDF) Model and Syntax Specification", O. Lassila, R. Swick, eds., 22 February 1999. The RDF Recommendation is: http://www.w3.org/TR/1999/REC-rdf-syntax-19990222.
The latest version of RDF 1.0 is available at: http://www.w3.org/TR/REC-rdf-syntax
[RFC2068]
"HTTP Version 1.1", R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen, and T. Berners-Lee, January 1997.
[SMIL]
"Synchronized Multimedia Integration Language (SMIL) 1.0 Specification", P. Hoschka, ed., 15 June 1998. The 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
[TECHNIQUES]
"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/WAI-WEBCONTENT-TECHS/
[WAI-AUTOOLS]
"Authoring Tool Accessibility Guidelines", J. Treviranus, J. Richards, I. Jacobs, C. McCathieNevile, eds. The latest Working Draft of these guidelines for designing accessible authoring tools is available at: http://www.w3.org/TR/WAI-AUTOOLS/
[WAI-UA-SUPPORT]
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/Resources/WAI-UA-Support
[WAI-USERAGENT]
"User Agent Accessibility Guidelines", J. Gunderson and I. Jacobs, eds. The latest Working Draft of these guidelines for designing accessible user agents is available at: http://www.w3.org/TR/WAI-USERAGENT/
[WCAG-ICONS]
Information about conformance icons for this document and how to use them is available at http://www.w3.org/WAI/WCAG1-Conformance.html
[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. This document is available at: http://www.tracecenter.org/docs/html_guidelines/version8.htm
[XML]
"Extensible Markup Language (XML) 1.0.", T. Bray, J. Paoli, C.M. Sperberg-McQueen, eds., 10 February 1998. The XML 1.0 Recommendation is: http://www.w3.org/TR/1998/REC-xml-19980210.
The latest version of XML 1.0 is available at: http://www.w3.org/TR/REC-xml

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