[HOME] [翻訳について] [W3C知的所有権FAQ] [ウェブ内容アクセス指針1.0概況報告書]

日本語翻訳版覚書： [W3C検証]

1. W3C [文書著作権（知的所有権）覚書] によって要求された通り、
   オリジナルURL・文書の位置付け・原著著作権覚書を記載しています。
2. この仕様書の正式版は、W3Cサイトの英語版です。
3. 翻訳版は、翻訳からくる間違いがあり得ます。

accessible:アクセシブル

（・・の手段で）接近［到達・入手・達成・入場・面会・照合・利用］可能な

要約

この指針で、障害のある人も ウェブの内容に接近（アクセス）できるようにする 方法を説明しています。この指針は、 ウェブ開発者（ページ制作者とサイト設計者）と 作成ツール開発者を対象としています。この指針の原則上の目標は、アクセス性を促進することです。しかしどのような 表示代行手段（例えば、デスクトップ=ブラウザ・音声ブラウザ・携帯電話・自動車用個人コンピュータなど）を使っていても、またどのような環境（例えば、騒音の中・暗すぎたり明るすぎる部屋・手動操作が要らない状況など）を強いられていても、これに従えば、 すべての利用者がウェブ内容を入手できます。また、これらの指針に従えば、ウェブ上の情報を素早く見つけだすこともできます。開発者が画像・ビデオなどを使ってはいけないと言っているのではなく、むしろ多くの人がよりアクセスしやすいマルチメディアをどのようにして作るのかを説明するものです。

これはアクセス性の原則と企画アイデアのための参考文書です。この文書で言及されている幾つかの戦略は、ウェブ国際化および移動アクセスに関わっています。しかしこの文書の焦点はアクセス性にあり、それ以外の W3C活動が関わる関連項目をすべて網羅するものではありません。より詳しいことについては、 W3C Mobile Access Activity home page や W3C Internationalization Activity home pageを参照下さい。

この文書は安定的であるべきだという意味で、変化の早い色々な技術のブラウザサポート状況を提供していません。そのかわり、 Web Accessibility Initiative (WAI) ウェブサイトが情報（ [WAI-UA-SUPPORT]を参照）を提供しています。

この文書には付録があり、話題や優先度からみた全 チェックポイントを組織的に記載しています。付録にあるチェックポイントは、当該文書の定義に連結しています。画像・マルチメディア・テーブル・フレーム・フォームそしてスクリプトといった話題が付録にあります。この付録は チェックポイント表もしくは チェックポイント一覧として 得られます。

この文書とは別の「ウェブ内容アクセス性指針1.0のための技術」（ ［技術］）で、当該文書で定義されているチェックポイントにどのように手段を与えるかが説明されています。技術文書では、各チェックポイントについてより詳細に言及し、 ハイパーテキストマーク付け言語（HTML）・ カスケーディング・スタイルシート（ CSS）・ 音声合成マルチメディア統合言語（ SMIL）・ 数学マーク付け言語（ MathML）での例を提供しています。 またこの技術文書は、文書検証とテスト用の技術やHTMLの要素と属性インデックス（技術はこれを使っています）を含むように企画されています。この技術文書は技術上の変化をあとづけて当該文書よりも頻回に更新する予定です。 注意：全てのブラウザが、この指針で述べられている機能をサポートしているとは限りません。特に、HTML 4.0もしくはCSS 1・CSS 2の新しい機能はサポートされていないかもしれません。

「ウェブ内容アクセス性指針1.0」は、 ウェブアクセス性発案(Web Accessibility Initiative)から出版されているアクセス性指針シリーズの一つです。またこのシリーズには、表示代行手段アクセス性指針（ [WAI-USERAGENT]）と制作ツールアクセス性指針（ [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制作者は自分のページをよりよく制御でき、視力低下のある人にもアクセスしやすいページを制作することになり、またしばしばスタイルシートで分担することで全ての利用者にとってページ保存時間の短縮になります。

この指針ではアクセス上の問題を議論し、アクセスしやすい設計法を提案しています。設計は、障害のある利用者にとって問題がある典型的な一連の事柄に取り組みます（文字様式の例と同じで）。例えば、 最初の指針では、内容開発者が画像にアクセスしやすくする方法を説明しています。利用者によっては画像を見ることができないかもしれませんし、また別の利用者は画像をサポートしていないテキスト専用ブラウザを使っているかもしれません、一方画像サポートを切っている利用者もいるかもしれません（例えば、インターネット接続速度が遅いため）。この指針はアクセス性を改善する方法として画像を避けるようにと示唆しているのではありません。そうではなくて、画像に 相当するテキスト(text equivalent)を提供することがアクセスしやすくすると説明しているのです。

等価テキストは、どのようにして画像をアクセスしやすくするのでしょうか。「等価とテキスト」(text equivalent)という二つの言葉が重要です：

• 内容がテキストなら、音声・点字そして視覚的に表示されるテキストとして、利用者に表現できます。これら三つの機序はそれぞれ異なる感覚器官を使い−−音声合成は耳・点字は触覚そして視覚的に表示されたテキストは目に−−色々な感覚やその他の障害のあるグループも情報にアクセスできるようにします。
• 役に立つものにするには、テキストが画像と同じ機能や目的を伝達しなければなりません。例えば、宇宙から見られる地球の画像と同等のテキスト（text equivalent for a image）を考えてみましょう。画像の目的が主に飾りであるなら、 "宇宙から見た地球の写真"というテキストでメッセージの機能は満されるでしょう。 写真の目的が世界地理について必要な情報を表示することであれば、同じ機能のテキストはその情報を伝えなければなりません。写真が、地球についての情報のために、 画像 （例、そこのクリックによって）を選択する目的で利用者に語りかける場合は等価テキストは"地球に関する情報"となります。したがってテキストが、障害のある利用者に、画像がそれ以外の利用者のためにあるのと同等の機能もしくは目的を伝えるなら、その場合等価テキストであると言えます。

障害ある利用者の恩恵に加えて、等価テキストは全ての利用者がページを素早く見付け出すのを助けることに注意してください。というのは、検索ロボットはページを索引化する際そのテキストを使えるからです。

ウェブ内容開発者は画像やその他のマルチメディア内容と等価のテキストを提供しなければならませんが、利用者にその情報を提示するのは 表示代行手段（ 例えば、ブラウザや 画面読み取り ・点字表示 といった補助技術）の責任です。

テキスト（例えば、アイコン・録音済スピーチやビデオ）に 等価の非テキストによって、書かれたテキストにアクセスし難い人でも、文書にアクセスできるようになります。認識障害・学習障害・耳が聞こえない人などがそうです。またテキストに等価な非テキストは読めない人（子）にとって助けとなります。 音声記述は、視覚的な情報と等価な非テキストの例です。マルチメディア表現での視覚的な方法の音声記述は、視覚的な情報をみることができない人に恩恵をもたらします。

2.アクセスしやすい設計上の課題

この指針では二つの課題を提示します：適切な転換を確保することと文書を理解しやすく誘導しやすいものにすることです。

2.1 適切な転換の確保

これらの指針に従うことで、内容開発者は適切に転換するページを作成できます。 適切に転換するページは、 「はじめに」で記載した物理的・感覚的・認識的障害や仕事上の束縛や技術的な障害など如何なる拘束にもかかわらず、アクセスしやすさを維持できます。適切に転換するページを設計するには幾つかの鍵があります：

• 構造を表現から分離する（ 「内容・構造・表現」の違いを参照）。
• テキスト（ 等価テキストを含めて）。テキストは殆どすべての閲覧装置得られ殆ど全ての利用者にアクセスできる方法で表示されることができます。
• 利用者が見えないか聞こえないもしくは両者であっても作動する文書を作成しましょう。代替感覚系に適したやり方で、オーディオやビデオと同じ目的や機能を提供する情報を用意しましょう。このことは、目が見えない利用者がアクセスできるようにと全サイトの前もって録音した音声版を作成することではありません。目が見えない利用者は、ページ上の全てのテキスト情報を表示するために、 画面読み取りが使えます。
• 一種類の型の装置に依存しない文書を作成しましょう。ページは、マウスを使わない・小画面で画面解像度が低く白黒画面や画面使用しない・音声のみやテクスト出力などの利用者にも利用できるようにすべきです。

適切な転換という課題は、主に指針1から11で述べられます。

2.2 内容が分かり易く探し易く作成

内容開発者は内容が分かりやすく探しやすくすべきです。言葉を明確で簡潔にするのみならず、ページ内やページ間の誘導の分かりやすい機序を提供することも含まれます。ページの誘導道具や情報を提供すれば、アクセス性と有用性を最大にできます。画像マップ・対応するスクロール=バー・横並びの枠といった画像もしくはグラフィカルなデスクトップ・ブラウザ利用者をめざした案内画像といった視覚的な印を全ての利用者が使えるとはかぎりません。利用者も、ページの一部分だけ閲覧する場合、状況（文脈上）情報を見失います。というのも、一度にページの一言 （音声合成装置 や 点字画面）や一セクション（小画面や拡大画面）にアクセスしているからです。方向付け情報なくしては、利用者は非常に大きな表・リスト・メニューなどを理解できないかもしれません。

内容が分かりやすく探しやすく作成するという課題は、主に指針12で述べられます。

3. この指針の構成

この文書には、40の 指針もしくはアクセスしやすい設計の一般的な原理が述べられています。各指針には以下のものがあります：

• 指針番号
• 指針説明
• 指針誘導リンク。これらリンクによって次の指針（右向き矢印）、前の指針（左向き矢印）もしくは目次での当の指針の位置（上向き矢印）へ導きます。
• 指針の背景の意味とそれから利益を受ける利用者
• チェックポイント定義一覧

各指針の チェックポイント定義によって、典型的な内容開発上の事柄でその指針がどのように適用されるかを説明します。各チェックポイント定義には以下のものがあります：

• チェックポイント番号
• チェックポイント番号の説明
• チェックポイントの優先順位。優先度１のチェックポイントは、スタイルシートの使用中は強調されています。
• 選択できる情報的な注意点・理解のための例そして関連指針やチェックポイントとの相互参照
• チェックポイントの手段や例が言及されている 技術文書（ [TECHNIQUES]）のセクションへのリンク

各チェックポイントは、十分特異的であるように企画されているので、ページやサイトを閲覧する人によってチェックポイントが満足のいくものであると確認されるでしょう。

3.1 文書規約

以下の編集上の規約は、この文書を通して使われています：

• 要素名は、大文字です。
• 属性名は、引用符号で囲まれた小文字です。
• 定義へのリンクはスタイルシート使用中は強調されます。

4. 優先度

各チェックポイントには優先がレベルあり、チェックポイントのアクセス性に及ぼす影響力に基づいて作業班が割り当てています。

［優先度１］

内容開発者はこのチェックポイントを満たさ なければなりません（must）。そうしないと、文書内の情報にアクセスできないグループが出てきます。グループにとっては、このチェックポイントを満たすことが、ウェブ文書を利用できるためには基本的に必須なものです。

［優先度２］

内容開発者はこのチェックポイントを満たすべきです （should）。そうしないと、文書内の情報にアクセスし難いグループが出てきます。このチェックポイントを満たすことで、ウェブ文書にアクセスする際の意味ある障害を除くでしょう。

［優先度３］

内容開発者はこのチェックポイントに耳をかたむけるように しましょう（ may）。そうしないなら、一つ以上のグループが、文書の情報にアクセスするのに多少困難を感じます。このチェックポイントを満たすことで、ウェブ文書へのアクセスが改善されるでしょう。

チェックポイントによっては、ある状況の下では優先レベルが変わるように特定されています。

5. 適合性

このセクションで、この文書への三段階の適合度合を定義しています：

• 適合度合"A"： 優先度１のチェックポイントをすべて満たしている；
• 適合度合"ダブルA"： 優先度１と優先度２のチェックポイントをすべて満たしている；
• 適合度合"トリプルA"： 優先度１・優先度２そして優先度３のチェックポイントをすべて満たしている；

注意　適合度合はテキストで記載し、音声表示でも分かるようにするためです。

この文書への適合度要請は、以下の二つの様式の内の一つでなければなりません。

様式１：特定（Specify）：

• 指針タイトル：「ウェブ内容アクセス指針1.0」
• 指針URI：http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
• 満たしている適合度：　"A", "ダブルA", or "トリプルA".
• 要請がカバーする範囲（例、ページ・サイトもしくはサイトの定義された部分）

様式１の例：

このページは、http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505　から入手できるW3Cの「Web Content Accessibility Guidelines 1.0」（「ウェブ内容アクセス指針1.0」）の適合度ダブルAです。

様式２：適合性を要請している各ページに、W3Cが提供している三つのアイコンの一つを置き、そのアイコンを適切なW3Cの要請説明にリンクしておきます。アイコンについての情報とそれをページに挿入する方法は、 [WCAG-ICONS]から入手できます。

6. ウェブ内容アクセス指針

指針 1. 音声的・視覚的内容と等価の代替え提供

利用者に見せる場合、音響・視覚的な内容と本質的に同じ機能や目的を伝える内容の提供

画像・動画・音響・アプレットなどを使わない利用者もいますが、視覚・音響的な内容に 等価なテキストのあるページはやはり利用します。等価情報は視覚・音響的な内容と同じ目的に役立たなければなりません。したがって、表内容にリンクした上向き矢印の画像と等価のテキストは、「表内容へ行く」となります。ある場合には、等価テキストも画像内容の現われ方（例、込み入ったチャート・掲示板やダイアグラムの場合）もしくは音響内容の音（例、教育に使用されるサンプル音の場合）を記述しなければなりません。

この指針では、非テキスト内容（画像・録音済音響・ビデオ）の 等価テキストの提供の重要性を強調しています。等価テキストは、様々な技術を駆使している色々な障害のある人達にアクセスしやすい方法で表示される、と言うその包容力にあります。テキストは、音声合成装置や 点字表示に出力して読むことができ、またコンピューター上や印刷紙上で視覚的に表現（色々なサイズで）できます。合成装置による音声は、盲目の人や認識上の障害のある人・読み書きの困難な人・耳が遠い人にとって限界があります。点字は、耳が聞こえなくて眼が見えない人や同様に感覚障害が眼が見えないだけの人にとって絶対必要です。視覚的に表示されるテキストは、耳が遠い利用者にまたそれと同じくらい大部分のウェブ利用者に恩恵をもたらします。

テキストと等価の非テキスト（例、絵・ビデオや録音済音響）も利用者によっては、特に読めない（子供など）人や読むのが難しい人に、恩恵を与えます。映画や視覚的な表現において体言語（身振り）や視覚的な仕草などの視覚的動作は、それと同じ情報を伝えるには音響情報では十分でありません。この視覚的な情報の言葉による説明が提供されていないなら、この視覚的な内容を見ることができない人はそれを理解できません。

チェックポイント：

1.1　非テキスト要素すべてに等価テキストを提供しましよう（例、"alt"・"longdesc"を経たり、要素内容で）。 これには：画像・テキストの画像的な表現（シンボルもふくめて）・イメージ=マップ領域・動画（例、gifアニメーション）・アプレットやプログラム・ アスキー文字絵・フレーム・スクリプト・リストの印としての画像・字間空白・グラフィックなボタン・音響（利用者との相互作動が必要でないまた必要な演奏）・独立音響ファイル・ビデオ音響そしてビデオがあります。　 ［優先度１］

HTML 4.0の場合の例：

• IMG・INPUTやAPPLET要素で"alt"を使い、またOBJECT・APPLET要素の内容に等価のテキストを提供する。
• 込み入った内容（例、チャート）で、"alt"のテキストでは完全な等価テキストを提供できない場合、IMG・FRAME・OBJECT要素内のリンクの"longdesc"または 記述リンク（description link）を利用して補足的な記述を提供する。
• イメージ・マップには、AREAで"alt"属性とA要素でMAP要素を内容として利用する。

以下も参照　 チェックポイント9.1 と チェックポイント13.10。

技術：チェックポイント1.1向け

1.2　サーバー側イメージ・マップの各作動領域にテキストによる重複するリンクを提供する。　 ［優先度１］

以下も参照 チェックポイント1.5と チェックポイント9.1.

技術：チェックポイント1.2向け

1.3　表示代行手段が、視覚的なトラックの等価テキストを自動的に音声読み上げができるまでは、マルチメディア表現の視覚的トラックの重要な情報についての音響的な記述を提供しましょう。　 ［優先度１］

チェックポイント1.4を経るように音響トタックと 音響的な記述を同調します。 視覚的な情報と等価のテキストについての情報は、 チェックポイント1.1を参照。

技術：チェックポイント1.3向け

1.4　時間ベースのマルチメディア表現（例、映画や動画）には、等価の代替え（例、表題や視覚的なトラックの音響的な記述）を表現と同調させる。　［優先度１］

技術：チェックポイント1.4向け

1.5　表示代行手段が、クライアント側イメージマップ・リンクの等価テキストを表示するまでは、クライアント側イメージ・マップの各活動領域に重複するテキストでのリンクを提供する。　［優先度３］

チェックポイント1.2と チェックポイント9.1を参照

技術：チェックポイント1.5向け

指針2. 色だけに依存しない

色指定なしで閲覧した場合も、テキストや画像が分かりやすいように確保

情報を伝えるのに色彩だけを利用したら、ある種の色彩を区別できない人や色なしや非視覚的な表示画面を使っている人は、その情報を受け取れません。前景と後景の色があまりにも近くて同じ色合いになると、モノクロ画面での閲覧やある種の色盲の人が閲覧すると十分なコントラストが得られません。

チェックポイント：

2.1　色彩を伴う全ての情報は、色彩指定しなくても、例えば文脈やマーク付けから、入手できるよう確保。　［優先度１］

技術：チェックポイント2.1向け

2.2　前景と後景の色の組み合わせが、色彩欠損のある人が閲覧してもまた黒白画面でみても、十分なコントラストを発揮しているかを確認。 　 ［優先度２　画像で、優先度３　テキストで］

技術：チェックポイント2.2向け

指針3.　マーク付けとスタイルシートを使い且つ正しく使う

適切な構造要素で文書をマーク付けする。体裁用の要素・属性でなくスタイルシートで表現を制御。

不適切にマーク付けをする−仕様書にしたがってない−と、アクセスしやすさを妨害します。表現効果のマーク付けのためにマーク付けの誤用（例、レイアウトにテーブルや文字サイズ変更に見出しを使うこと）によって、特別なソフトウェアーを使っている利用者は、ページの組織化を理解することやそれを通して誘導することができなくなります。更に、構造を伝えるのに構造的なマーク付けでなく体裁的なマーク付けを使うと（例、HTML PRE要素で表のように見せるものを構築すること）、別の装置上でページをよく分かるように表示できなくなります（ 内容・構造・体裁の違いを参照）。

内容開発者は古いブラウザで意図した形式効果を達成する構成を使い（ないしは誤用し）たくなるかもしれません。これらを行うとアクセス性の問題を起こすことに気付かねばなりませんし、利用者が文書にアクセスできなくなることを正当化するほど形式効果が緊急なことかを考えなければなりません。

一歩の極端に、内容開発者は適切なマーク付けを犠牲にしてはいけません、というのもブラウザや補助的な技術はそれを正しく処理できないからです。例えば 古い画面読み取りが並んだテキストを正しく処理しなくても（ チェックポイント10.3を参照 ）、 表になった情報をマーク付けするのにHTMLでTABLE要素を使うのは適切です。TABLEを正しく使い、適切に転換する表（ 指針5）を作成すること で、ソフトウェアーが二次元格子としてでなく表を表示することができます。

チェックポイント：

3.1　適切なマーク付け言語が在れば、画像でなくマーク付けを使って情報を伝えます。　［優先度２］

例えば、MathMLを使って数学方程式をマーク付けし、そし て スタイルシートを使ってテキストを書式化しレイアウトを制御します。また、テキストの表現に画像を使うのを避け−代わりにテキストとスタイルシートを使います。 指針6と指針11を参照。

技術：チェックポイント3.1向け

3.2　公開されている正式な文法で検証する文書を作成する。 　［優先度２］

例えば、文書の初めに公開された DTD（例、the strict HTML 4.0 DTD）を参照する文書型宣言を入れます。

技術：チェックポイント3.2向け

3.3　レイアウトや体裁の制御にはスタイルシートを使います。　 ［優先度２］

例えば、文字様式を制御するのにHTML FONT要素でなく、CSSの"font"特有値を使います。

技術：チェックポイント3.3<向け

3.4　マーク付け言語の属性値やスタイルシートの特有値で絶対的な単位でなく相対的なものを使います。　［優先度２］

例えば、CSSで絶対的単位である'pt'や'cm'でなく、'em'やパーセント長を使います。絶対的単位を使う場合表示される内容が利用できるかを検証します（ 検証についてのセクションを参照）。

技術：チェックポイント3.4向け

3.5　文書構造を伝えるには見出し要素を使い、仕様書に従った使い方をします。　［優先度２］

例えば、HTMLでH2をH1の下位セクションを示すために使います。文字効果のためにみだしを使わないこと。

技術：チェックポイント3.5向け

3.6　リストとリスト項目を適切にマーク付けします。　 ［優先度２］

例えば、HTMLでOL・ULそしてDLリストを適切に入れ子します。

技術：チェックポイント3.6向け

3.7　引用のマーク付け。引用マーク付けを字下げといった書式効果のために使わない。　［優先度２］

例えば、HTMLでQやBLOCKQUOTE要素を使って、それぞれで短い引用と長い引用をマーク付けします。

技術：チェックポイント3.7向け

指針4.　自然言語の使用を明確に

省略もしくは外国テキストの発音や解釈を助けるマーク付けの使用

内容開発者は文書での自然言語をマーク付けしていると、音声合成装置や点字装置は自動的に新しい言語に入れ替わり、多言語使用の利用者がより文書にアクセスしやすくなります。内容開発者は、文書内容の支配的な 自然言語（natural language）が識別できるようにしておくべきです（マーク付けや HTTPヘッダーを通じて）。 内容開発者は省略語や頭文字の展開も提供しておくべきです。

補助技術を助けること以外にも、自然言語マーク付けをしておくと検索エンジンがキー・ワードを見つけ望み通りの文書を識別できるようになります。自然言語マーク付けは、全ての人（学習困難・認識障害また耳の聞こえない人を含めて）にとってウェブへのアクセス性を改善します。

省略語と自然言語変化が識別できないなら、機械発声や点字の場合解読できないかもしれません。

チェックポイント：

4.1　文書のテキストや 等価テキスト（例、表題）の自然言語の変化を明確に識別すること。　［優先度１］

例えば、HTMLで"lang"属性を使う。 XMLで"xml:lang"を使います。

技術：チェックポイント4.1向け

4.2　文書で最初に来る省略語や頭文字語の展開を特定しておく。　 ［優先度３］

例えば、HTMLでABBRやACRONYM要素の"title"属性を使う。文書の主要な場所で拡張展開を提供すれば、文書が利用しやすくなります。

技術：チェックポイント4.2

4.3　文書の基本の自然言語を識別できるようにしておく。　 ［優先度３］

例えば、HTMLでHTML要素の"lang"属性を設定。XMLで "xml:lang"を使用する。サーバー管理者は、HTTP内容交渉機構（HTTP content negotiation mechanisms）（ [RFC2068], section 14.13）を優先するようにサーバーを設定する。そうすれば、クライアントは参照された言語の文書を自動的に受け取ります。

技術：チェックポイント4.3向け

指針5.　適切に転換するテーブルの作成

アクセスできるブラウザやその他の表示代行手段によって転換されるのに必要なマーク付けをテーブルが持つようにする

テーブルは、真に 表情報（tabular information）（「データー表」、"data tables"）をマーク付けするのに使われるべきです。内容開発者は、ページをレイアウト（"layout tables"）への利用を避けるべきです。テーブルはどのように使っても、 画面読み取り利用者に、特別な問題を表現します（ チェックポイント10.3参照）。

表示代行手段のなかには、利用者がテーブル・セル・テーブル見出し・テーブル情報間を誘導することができるものもあります。適切にマーク付けされていないなら、テーブルは表示代行手段に適切な情報を提供しません（ 指針3も参照）。

以下のチェックポイントは、音響手段（例、画面読み取りや自動車ベース個人コンピューター）からテーブルにアクセスする人や同時にページの一部だけ閲覧する人（ 例、音声出力や点字画面を使っている目が見えなかったり視力の低下している利用者や小画面の装置の利用者など）に直接恩恵をもたらします。

チェックポイント：

5.1　テーダー表では、行と見出しを特定します。　 ［優先度１］

例えば、HTMLではTDでデーター・セルを特定し、THで見出しを特定します。

技術：チェックポイント5.1向け

5.2　二つ以上の論理的レベルの行もしくは列見出しを持っているデーター表では、データ・セル（部分）と見出しセル（部分）を関係づけるようにマーク付けを使います。　［優先度１］

例えば、HTMLでは行をグループ化するのにTHEAD・TFOOTそしてTBODYを、列をグループ化するのにCOLとCOLGROUPを、データ間のより複雑な関係を記述するには"axis"・"scope"そして"headers" 属性を使います。

技術：チェックポイント5.2向け

5.3　テーブルが直線化されても道理に適っていないなら、テーブル（表）をレイアウトに使用しない。そうでなくても、テーブルが道理に適っていないなら、等価の代替えを提供します（ 直線化版（linearized version）であるかもしれません）。　［優先度２］

Note. 表示代行手段が配列スタイルシート（style sheet positioning）をサポートしているなら、レイアウトのためにテーブルを利用すべきではありません。 チェックポイント3.3を参照

技術：チェックポイント5.3向け

5.4　テーブルをレイアウト用に利用するなら、視覚的な書式化目的のために如何なる構造的マーク付けも使わない。　 ［優先度２］

例えばHTMLで（テーブル見出しでない）セルの内容をセンタリングし太字にするためにTH要素を使わない。

技術：チェックポイント5.4向け

5.5　テーブル用の要約を提供する。　 ［優先度３］

例えば、HTMLでTABLE要素の"summary"属性を使う。

技術：チェックポイント5.5向け

5.6　見出しラベルの省略語を提供する。　 ［優先度３］

例えば、HTMLでTH要素に"abbr"属性を使う。

技術：チェックポイント5.6向け

チェックポイント10.3も参照.

指針6　新しい技術を特徴としているページは適切に転換することの確保

新しい技術がサポートされていないか切ってあってもページがアクセスしやすいようにしておく

内容開発者は既存の技術で起こる問題を解決する新技術を使うよう奨励されはしますが、古いブラウザやその機能を切っている人でもページが機能する方法を知っておくべきです。

チェックポイント：

6.1　スタイルシートがなくても読めるように文書を組織化します。例えば、HTML文書が関連するスタイルシートなしで表示される場合、その文書を読むことが可能であるべきです。　 ［優先度１］

内容が論理的に組織化されていれば、スタイルシートが切ってあったりサポートされていない場合でも意味ある順序で表示するでしょう。

技術：チェックポイント6.1向け

6.2　ダイナミックな内容と同じものが、ダイナミックな内容が変更されたら、更新できることを保証します。　 ［優先度１］

技術：チェックポイント6.2向け

6.3　スクリプト・アプレットもしくはその他のプログラム的な対象が切ってあってもページは利用できることを保証します。これができない場合は、代替えのアクセスできるページに等価の情報を提供します。　 ［優先度１］

例えば、スクリプトが切られたりサポートされていない場合スクリプトを引き金にするリンクが作動するようにします（例、リンク目標として"javascript:"を使用しない）。スクリプトなしではページを利用できるように作ることができないなら、NOSCRIPT要素で等価テキストを提供するか、クライアント側スクリプトでなくサーバー側スクリプトを使うか、 チェックポイント11.4のように代替えのアクセスできるページを提供する。 指針1を参照

技術：チェックポイント6.3向け

6.4　スクリプトやアプレットで、事象処理系は入力装置に依存していないことを保証します。　 ［優先度２］

装置独立性の定義を参照。

技術：チェックポイント6.4向け

6.5　ダイナミックな内容がアクセスできるかもしくは代替えの表現やページを提供していることを確認。　 ［優先度２］

例えば、HTMLで各framesetの終でNOFRAMESを使う。アプリケーションによっては、サーバー側スクリプトがクライアント側スクリプトよりアクセスしやすい。

技術：チェックポイント6.5向け

チェックポイント11.4も参照.

指針7.　時間間隔での内容変更を利用者が制御できることの確保

移動・点滅・スクロールや自動更新対象やページは、休止もしくは停止できるかを確認する

認識ないしは視覚障害のある人は、動きのあるテキストを素早く読めないかまたは全く読めません。動きは、認識障害のある人にとっては残りのページが読めないといった注意力散漫になる原因にもなります。 画面読み取りでは、動くテキストを読むことはできません。肉体的な障害のある人は、素早くまたは動く対象に応じて正確に動けないでしょう。

注意　 表示代行手段がが十分な制御機構機能を提供するまで、以下の全てのチェックポイントが内容開発者側の責任となります。

チェックポイント：

7.1　表示代行手段がちらつきの制御を利用者に可能になるまで、画面をちらつかせる原因となるものを避ける。　 ［優先度１］

注意　光反応性てんかんのある人は、一秒につき4から59の割合の発光で、明暗の早い変化（写真のストロボ光線のような）と同じく一秒につき20回のフラッシュが一番影響があり、ちらついたりフラッシュで発作が引き起こされます。

技術：チェックポイント7.1向け

7.2　表示代行手段で点滅の制御を利用者ができるようになるまで、内容を点滅させる結果になるものを避けます（例、切ったり入れたりといった一定の割合で表現を変化する）。　 ［優先度２］

技術：チェックポイント7.2向け

7.3　 表示代行手段で、利用者が移動を止めることができるまで、ページ内の動きを避ける。　 ［優先度２］

ページに動く内容がある場合利用者が動きや更新を中止できるようなスクリプトやアプレット機序を提供します。スクリプトとともにスタイルシートを使って動きを作ると、利用者が切たり上書きすることがより容易になります。 指針8も参照

技術：チェックポイント7.3向け

7.4　 表示代行手段がリフレッシュを止める機能を提供するまでは、周期的に自動変更するページを作成しない。　 ［優先度２］

例えば、HTMLで"HTTP-EQUIV=refresh"でページを自動変更しない、表示代行手段で利用者がこの機能をきることができるまでは。

技術：チェックポイント7.4向け

7.5　 表示代行手段が自動方向変更を停止する機能を提供するまでは、自動的にページを再方向化するマーク付けを使用しない。代わりに、ページを再方向化するようにサーバーを設定します。　 ［優先度２］

技術：チェックポイント7.5向け

注意　BLINKとMARQUEE要素は、どのW3C HTML仕様書でも定義されてなく、使用すべきではありません。 指針11も参照

指針8.　組み込まれたユーザー・インターフェースへの直接のアクセス性を確保

ユーザー・インターフェースは、アクセスしやすい設計の原則に従うことを確認します：装置独立性で機能へアクセス・キーボード操作性・自己発声など

組み込まれた対象がその「固有のインターフェース」を持っている場合インターフェース−ブラウザ自身へのインターフェースのように−は、アクセスしやすいものでなければなりません。組み込まれた対象のインターフェースがアクセスしやすくなってないなら、代替えのアクセスしやすい解決策が提供されなければなりません。

注意　アクッセスしやすいインターフェースについての情報については、表示代行手段アクセス指針（User Agent Accessibility Guidelines）（ [WAI-USERAGENT]）や制作道具アクセス指針（ Authoring Tool Accessibility Guidelines ）（ [WAI-AUTOOL]）を参照下さい。

チェックポイント：

8.1　スクリプトやアプレットといったプログラム要素を直接アクセスできるようにまた補助的な技術と両立できるようにします。［機能が 重要で外では表現できないなら 優先度１で、そうでないなら優先度２］

指針6も参照

技術：チェックポイント8.1向け

指針9. 装置に依存しない設計

色々な入力装置からページ要素の作動ができる機能を使う

装置に依存しないアクセスとは、利用者は好みの入力（出力）装置で表示代行手段や文書と接触します−マウス・キーボード・音声・先端ワンドその他。例えば、フォーム書式制御がマウスや別のポイント装置でだけ作動させられるなら、視力を使わないで音声入力やキーボードでそのページを利用したり、その他のポイントでない入力装置を使っている人はそのフォームを利用できません。

注意　リンクとして使われるイメージマップや画像に等価のテキストを提供すれば、ポイント装置でなくても利用者は相互に作用できるようになります。 指針１も参照

一般的には、キーボード交流も音声入力や入力行交流を通してアクセス可能です。

チェックポイント：

9.1　領域が入手できる地理上の形で定義できない場合を除き、サーバー側イメージマップでなくクライアント側イメージマップを提供します。　 ［優先度１］

チェックポイント1.1・ チェックポイント1.2・ チェックポイント1.5も 参照

技術：チェックポイント9.1向け

9.2　固有のインターフェースを持っている要素は装置に依存しない方法で操作できることを確認します。　 ［優先度２］

装置非依存性も参照

指針8も参照

技術：チェックポイント9.2向け

9.3　スクリプトでは、装置依存性の事象処理系でなく論理的事象処理系を特定します。　 ［優先度２］

技術：チェックポイント9.3向け

9.4　リンク・フォーム制御そしてオブジェクトを通じて論理的なタブ順位を作成する。　［優先度３］

例えば、HTMLで"tabindex"属性を経てタブ順位を特定し、論理的なページ設計を確保します。

技術：チェックポイント9.4向け

9.5　重要なリンク（ クライアント側イメージマップを含んで）・フォーム制御・フォーム制御群にキーボード・ショートカットを提供します。 　［優先度３］

例えば、HTMLで"accesskey"属性を介してショートカットを特定します。

技術：チェックポイント9.5向け

指針10.　暫定的な解決策を使う

協力技術や古いブラウザが正しく操作できないので、アクセス性の暫定的な解決を使います。

例えば、古いブラウザでは利用者は空の編集ボックスへ誘導できません。古い画面読み取りでは、連続したリンクのリストを一つのリンクとして読み上げます。これらの作動している要素は、したがって、アクセスすることが難しいか不可能です。また、現在の画面（窓）の変更や新しい窓の飛び出しは、これが起こっていることを見られない利用者をおおいに混乱させます。

注意　以下のチェックポイントは 表示代行手段（ 援助技術を含めた）がこれらの問題に取り組みます。これらのチェックポイントは暫定的（"interim"）と分類し、暫定的とは、ウェブ内容指針作業班は この文書が出される時点でウェブ・アクセス性上正しく必要なものと考えていると言う意味です。しかし一旦ウェブ技術が予想された機能や能力を組み入れるなら、作業班はこれらのチェックポイントが将来必要とは考えていません。

チェックポイント：

10.1　 表示代行手段で利用者が起こった窓を切ることができるようになるまで、飛び出しや別の窓を表わしたり、利用者に知らせないで現在の窓を変更しないように。　 ［優先度２］

例えば、HTMLでターゲットを新しい窓にするframeの使用を避ける。

技術：チェックポイント10.1向け

10.2　 表示代行手段がラベルとフォーム制御の協調が明確になるまで、暗黙に協調されたラベルのある全てのフォーム制御では、そのラベルが適切に位置付けされているかを確認。　 ［優先度２］

フォームのラベルは、同じ行で制御の直前（行当たり一つ以上の制御／ラベルが可能）に、または制御に先行する行（行当たりただ一つのラベルと制御）に来なければなりません。 チェックポイント12.4も参照

技術：チェックポイント10.2向け

10.3　 表示代行手段（支援技術も含めて）が横並びのテキストを正しく表示できるまでは、テキストを平行で単語の折り返しする列でテキストをレイアウトする全てのテーブルに、線状のテキスト代替え（現在のページにか他のページに）を提供する。　 ［優先度３］

Note. 線状化テーブル（linearized table）の定義を参照。このチェックポイントは、 横並びに表示されるテキストのブロックを処理できない 表示代行手段（ 画面読み取りといった）を使っている人に恩恵をもたらします； このチェックポイントは 表情報を表現するのにテーブルを使わないようにと内容開発者にといってるのではありません。

技術：チェックポイント10.3向け

10.4　 表示代行手段が空の制御を正しく処理するまでは、編集ボックスとテキスト領域に初期で置き代えられる文字符号を配置します。　 ［優先度３］

例えば、TEXTAREAとINPUTでこうしておきます。

技術：チェックポイント10.4向け

10.5　 表示代行手段（支援技術も含めて）がリンクにはっきりと合わすようになるまでは、隣接するリンクの間に非リンク・印刷できる文字符号（スペースで囲む）をいれます。　 ［優先度３］

技術：チェックポイント10.5向け

指針11.　W3Cの技術と指針を使う

W3Cの技術（仕様書にしたがって）を使い、アクセス指針に従う。W3Cの技術を使えないか、またはそうすることで適切に転換できない場合アクセスできる代替え内容版を提供する。

現在の指針は、幾つかの理由で、W3Cの技術（HTML・CSSなど）を推奨しました：

• W3Cの技術は、アクセス性機能が組み込まれています。
• W3C仕様書は、アクセス性問題を設計段階から考慮するということを確保するよう早くから論評しています。
• W3C仕様書は、公開され企業の合意をへて発展しています。

非W3C書式（例、 PDF・Shockwaveなど）は、プラッグインか独立アプリケーションでの閲覧が必要です。しばしばこれらの書式は、標準の 表示代行手段（支援技術も含めて）で閲覧や誘導ができません。 非W3Cと非標準機能（所有権のある要素・属性・特有値そして拡張機能）を避けると、色々なハード・ソフトウェアーを使っている人にアクセスしやすいページになります。アクセスできない技術（所有権があるなしにかかわらず）を使わなければならない場合等価のアクセスしやすいページを提供しなければなりません。

W3C技術を使っている場合でも、アクセス指針に従っていなければなりません。新技術を使う場合、適切に転換することを確認しておきます（ 指針6も参照）。

注意　文書（PDF・PostScript・ RTFなどから）をW3Cマーク付け言語（HTML・ XML）へ変換しても必ずしもアクセスしやすい文書を作成するとはかぎりません。このためには、変換処理後にアクセス性や利用性について各ページを検証します（ 検証についてのセクションを参照）。ページが容易に変換されないなら、元の表現が適切に変換されるまでそのページを修正するか、HTMLや平叙文版を提供します。

チェックポイント：

11.1　入手できて仕事に適しているならW3Cの技術を使用し、サポートされているなら最新版を使用するように。　 ［優先度２］

最新のW3C仕様書と表示代行手段のW3Cの技術サポートについての情報である [WAI-UA-SUPPORT]を何処で見つけるかという情報については 参考一覧を見てください。

技術：チェックポイント11.1向け

11.2　W3C技術のいずれ破棄される（deprecated）機能は避ける。　 ［優先度２］

例えば、HTMLで いずれ破棄されるFONT要素を使用しない；代わりにスタイルシートを使用する（例CSSの'font'プロパティ）。

技術：チェックポイント11.2向け

11.3　利用者は設定条件（プレファレンス）にそって文書を受け取るのでその情報を提供する（例、言語・内容型など）。　 ［優先度３］

注意可能な限り内容誘導を使う。

技術：チェックポイント11.3向け

11.4　 最大の努力をしても アクセスしやすいページを作成できない場合W3C技術を使い、アクセスしやすく、 等価の情報（また機能性）を持ち、アクセスしにくいもとのページと同じ頻度で更新する代替えページへのリンクを提供する。　 ［優先度１］

技術：チェックポイント11.4向け

注意　内容開発者は、他の解決に失敗する場合、代替えページにのみ頼るべきでなく、というのも一般的に「元の」ページに比べて更新することが少なくなるからです。日付の古いページはアクセスできないページと同じくらいフラストレーションになり、両者とも元のページにある情報は得られないのですから。 自動生成する代替えページはより頻回な更新になりますが、内容開発者はやはり十分な注意をもって、生成されたページは必ず納得のいくものになっているか、元のページと代替えページまたその両方のリンクを辿って利用者がサイトを誘導できるか、確認しなくてはなりません。代替えページに頼る前に、オリジナルなページの設計を再考しましょう；それをアクセスしやすくすることが、全ての利用者にとって改善に なるなのか。

指針12.　文脈（状況）と方向性情報の提供

文脈（状況）と方向性情報の提供して、複雑なページや要素について利用者の理解を助ける。

要素をグループ化し要素間の関係の文脈上の情報を提供することは、全ての利用者にとって役立ちます。ページの部分の間の複雑な関係は、認識障害や視力障害のある人にとっては解釈が困難かもしれません。

チェックポイント：

12.1　各フレームにタイトルを付け、フレーム識別や誘導を容易にする。 　［優先度１］

例えば、HTMLでFRAME要素の"title"属性を使う。

技術：チェックポイント12.1向け

12.2　フレームの目的やフレーム・タイトルだけでははっきりしないならフレームの相互関係を説明する。　 ［優先度２］

例えば、HTMLで"longdesc,"や 説明リンクを使う。

技術：チェックポイント12.2向け

12.3　自然で適切な所なら、大きな情報をより扱いやすいグループに分ける。　 ［優先度２］

例えば、HTMLでSELECT内のOPTION要素をグループ化するのにOPTGROUPを使う；フォーム制御をFIELDSETとLEGENDでグループ化；適切な所ではリストを入れ子にする；文書を構造化するのに見出しを使うなど。 指針3も参照.

技術：チェックポイント12.3向け

12.4　ラベルをはっきりとその制御を強調させる。　 ［優先度２］

例えば、HTMLでLABERLとその "for"属性を使う。

技術：チェックポイント12.4向け

指針13.　明確な誘導機序の提供

サイトで探しているものを見付けだしやすくするために、明確で一定した誘導機序を提供する−方向付け情報・誘導バー・サイト地図など−

明確で一定した 誘導機序は、認識障害や目が見えない人にとって重要で、そして全ての利用者にも恩恵をもたらします。

チェックポイント：

13.1　各リンクの目標を明確に識別します。　 ［優先度２］

リンク文は、文脈外で読んだとき分かるように十分意味あるものであるべきです−それ自身でも、一連のリンクの一部としても。リンク文もまた簡潔でなければなりません。

例えば、HTMLで、「ここをクリック」でなく「4.3版情報」と書きます。明確なリンク文以外にも、内容開発者は情報的なリンクのタイトルでリンクの目標をさらに明確にします（例、HTMLで"title"属性）。

技術：チェックポイント13.1向け

13.2　意味付け情報をページやサイトに加えるためにメタデータを提供します。　 ［優先度２］

例えば、文書の著者・内容の型などを示すために RDFを使います。

注意　HTML 表示代行手段によっては、HTML LIN要素と "rel"や"rev"属性によって記載された文書関連性から誘導道具を作り上げます（例、rel="next", rel="previous", rel="index"　など）。 チェックポイント13.5も参照

技術：チェックポイント13.2向け

13.3　サイトの全体的なレイアウトについての情報を提供します（例、サイト地図や目次）。　 ［優先度２］

サイトのレイアウト（配置）を説明する際、入手できるアクセス性機能を強調し説明します。

技術：チェックポイント13.3向け

13.4　一定の方法で誘導機序を提供する。　 ［優先度２］

技術：チェックポント13.4向け

13.5　誘導機序へのアクセスを強調し与えるために誘導バーを提供する。　 ［優先度３］

技術；チェックポイント13.5向け

13.6　関連付けられたリンクをグループ化し、そのグループを（表示代行手段のために）を識別し、 表示代行手段がそうできるまでは、グループを迂回する方法を提供する。　 ［優先度３］

技術：チェックポイント13.6向け

13.7　検索機能が提供されているなら、異なる熟練度と設定条件で検索タイプを違えることができるように。　 ［優先度３］

技術：チェックポイント13.7向け

13.8　見出し・パラグラフ・リストなどのはじめに区別する情報を置く。　 ［優先度３］

注意これは前読み込み（"front-loading"）としてよく参照され、特に音声合成装置といった連属性の装置で情報にアクセスする人を助けます。

技術：チェックポイント13.8向け

13.9　文書の集まりについての情報を提供する（例、多数のページを含む文書）。　 ［優先度３］

例えば、HTMLで文書の集まりをLINK要素と"rel"・"rev"属性で特定する。集まりを作成する別の方法は、アーカイブ（例、zip・tar・gzip・ stuffitなど）を作り上げることです。

注意　オフライン処理で得られるパフォーマンス改善は低速度で閲覧するという障害をもった人にとっては閲覧が非常に安くなります。

技術：チェックポイント13.9向け

13.10　多行のASCIIアートを飛び超える手段を提供する。　 ［優先度３］

チェックポイント1.1と 用語のアスキー文字アートの例を参照。

技術：チェックポイント13.10向け

指針14.　文書は明晰で簡潔であること

文書は明晰で簡潔であること、これでより容易に理解できるから

一定のページレイアウト・見やすい画像そして言葉がわかりやすいことで、全ての利用者が恩恵を受けます。特に、認識障害や読むことが困難な人を助けます。（しかし、目が見えない人や視力低下の人もしくは画像が見られない・画像選択をしてない人に、画像には等価のテキストをつけましょう。 指針1も参照）

明晰で簡潔な言葉を使うことは、効果的な交流を促進します。書かれた情報へのアクセスは、認識や学習が困難な人にはむずかしいものになることがあります。明晰で簡潔な言葉は、第一言語が自分の言葉と違う人（手話で主に交流している人も含めて）に恩恵をもたらします。

チェックポイント：

14.1　サイト内容には明晰で簡潔な言葉を使う。　 ［優先度１］

技術：チェックポイント14.1向け

14.2　画像や音響表現にテキストを補足し、ページの把握を容易にする。　 ［優先度３］

指針1も参照

技術：チェックポイント14.2向け

14.3　ページ間で一定の表現様式にする。　 ［優先度３］

技術：チェックポイント14.3向け

付録A.　--　検証

自動道具や人の批評でアクセス性を検証しましょう。自動的な方法は一般的に早く便利ですが、アクセス上の問題全てを識別することはできません。人による批評は言葉や誘導の容易さを確認する助けになります。

開発の早い段階から検証することです。アクセス上の問題が早い段階で分かったら、修正やそれを避けるのが容易になります。

以下は、幾つかの重要な検証方法で、より詳しくは 技術文書の検証セクションで言及します。

1. 自動的なアクセス性道具やブラウザ検証道具を利用します。しかしソフトウェアー道具は、アクセス性全てにアクセスしないことに注意してください。例えば、リンク文の意味や 等価テキストの適切性などで す。
2. 構文の検証（例、HTMLやXMLなどの）
3. スタイルシートの検証（例、 CSS)）
4. テキスト専用ブラウザやエミュレーターを使って見る。
5. マルティプル（多目的な）グラフィックなブラウザを使ってみる：
   • 音響と画像読み込み
   • 画像は読み込まない
   • 音響を読み込まない
   • マウスを使わない
   • フレーム・スクリプト・スタイルシートやアプレットを読み込まない
6. 新旧幾つかのブラウザを使ってみる
7. 発声ブラウザ・画面読み取り・拡大ソフトウェアー・小画面などを使ってみる。
8. スペルや文法チェッカーを使う。音声合成装置はスペル間違いのある単語を合成装置がいいと推定して判読することができます。文法問題を取り除くことは把握しやすくなります。
9. 明晰性と簡潔性について文書を吟味する。ある種のワードプロセッサーが生成する読み易さの値は、明晰性と簡潔性の指標として利用できます。しかしよりいいのは、書かれた内容が明晰であるかを経験ある編集者に批評してもらうことです。編集者は、言葉やアイコン使用でおこりえる潜在的に影響される文化問題を識別して文書の利用性を改善することもできます。
10. 文書を批評するのに障害のある人に見てもらう。障害があって熟練した人と未熟な人は、アクセス上や利用上の問題やその困難度合について価値ある意見を提供してくれます。

付録B.　--　用語

アクセス（容易）性（Accessible）

障害がある人が使った場合、内容にアクセスしやす。

アプレット（Applet）

ウェブページに挿入されるプログラム

支援技術

日常活動を行うに当たって困難がある人を支援するように特別に設計されたソフトやハードウェアー。支援技術として、車椅子・読み取り器・掌握のための装置などがあります。ウェブアクセス性の領域でよくみるソフトウェアー支援技術には、グラフィカルなデスクトップブラウザ（他の 表示代行手段のうち）と協調した画面読み取り・画面拡大・音声合成装置・音声入力ソフトウェアーがあります。ハードウェアー支援技術には、代替えのキーボードやポンター装置があります。

アスキーIIアート（作品）

アスキーII作品は、画像を作成するために組み合わされたテキスト文字や記号を参照します。例えば ";-)"は、笑った感情をさします。以下のアスキー作品は、開眼時と閉眼時での発行頻度と光発作との関係を示しています［ アスキーII作品を飛び越すもしくは 表の説明を参照］：

 
  %   __ __ __ __ __ __ __ __ __ __ __ __ __ __   
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
      Flash frequency (Hertz)

制作道具（Authoring tool）

HTMLエディター・文書変換道具・ウェブ内容をデーターベースから生成する道具は、すべて制作道具です。アクセスしやすい道具の開発についての情報は、「制作道具アクセス指針」（ [WAI-AUTOOLS])）を参照下さい。

後方互換性

言語やプログラムなどの古いバージョンでも作動する設計

点字（Braille）

点字では、目が見えない人が指先で読むために、異なる高さの六つの点を使って文字や数字を表現します。次は、"Accessible"の点字です：

点字画面は、普通「ダイナミック点字表示」をさし、電子的な装置通常コンピュータからの指令のままにドット・パターンを上げたり下げたりします。その結果、つぎつぎと変化する点字の行になります。現在のダイナミック点字表示の大きさは、一セル（6ないし8ドット）から80セルのはばがあり、大部分は一行につき12と20の間です。

内容開発者

ウェブ・ページを作成するもしくはウェブ・サイトを設計する人

旧式になる（Deprecated）

旧式になる要素や属性とは、新しい構成では時代遅れにされるものです。旧式になる要素は、HTMLの将来のバージョンでは破棄されるかもしれません。 技術文書でのHTML要素と属性の索引（原文）［翻訳版］は、どの要素と属性がHTML 4.0で旧式にされているかを示しています。

制作者は、旧式になる要素や属性の使用を避けるべきです。表示代行手段は、互換性という立場からサポートを続けるべきです。

装置非依存性（独立性）

利用者は、表示代行手段（そしてそれが文書を表示する）と、自分の選択や必要にそってサポートされている入力と出力装置を使って相互に働きかけなければなりません。入力装置には、ポイント装置・キーボード・点字装置・先端バンド・マイクロフォン・その他があります。出力装置には、モニター・音声合成装置や点字装置があります。

「装置非依存性のサポート」は、表示代行手段が全ての入出力装置をサポートしなければならないことを意味するのではないことに注意してください。表示代行手段は、サポートされている装置に有り余るほどの入出力機構を提供すべきです。例えば表示代行手段がキーボードとマウス入力をサポートしているなら、表示代行手段はキーボードとマウスのどちらをも使う全ての機能と相互い作用できなければなりません。

文書内容・構造そして表現（体裁）

文書の内容は、自然言語・画像・音響・映画・動画などを通して利用者に言いたいことを照会します。文書の構造は、どのように論理的に組織化（章・導入と目次など）されているということです。 文書構造を特定する 要素（例、HTMLのP・STRONG・BLOCKQUOTE）は、 構造要素と言われます。文書の表現（体裁）は、文書がどのように表示されるかということです（印刷物として・二次元グラフィカルな表現として・テキスト専用表現として・合成された音声として・点字としてなど）。文書表現（体裁）を特定する 要素（例、B・ FONT・CENTER）は、 表現（体裁）要素と言われます。

例として文書見出しを考えてみましょう。見出しの内容は見出しが言うものです（例、"Sailboats"）。HTMLで見出しは、例えばH2要素でマーク付けされた構造要素です。最終的に見出しの表現（体裁）は、周辺が太字体の文字で、中央化され、ある種の音声様式（音声文字のように）で発声されるタイトルなどに

ダイナミックHTML(DHTML)

DHTMLは、HTMLにある標準、 スタイルシート・ 文書対象模型（Document Object Model） [DOM1]・ スクリプト、の混合物に適用された市場用語です。しかしDHTMLを公式に定義したW3C仕様書は一つもありません。指針の多くはDHTMLを使ったアプリケーションにも適用されますが、しかし以下の指針はスクリプトやスタイルシートに関連する問題に的を絞っています： 指針1 指針3・ 指針6・ 指針7そして 指針9

要素

この文書では、「要素」という用語を厳密なSGMLの意味（要素は構文的な構造である）と、より一般的に内容のタイプ（ビデオ・音響といった）や論理的な構造（見出し・リスト）を意味するに使われます。二番目の意味はHTMLで生じた指針は容易にその他のマーク付け言語にも適用できることを強調しておきます。

ある種の（SGML）要素は表示される内容を持っており（例、HTMLでP・LIやTABLE要素）とあるものは外部内容に置き代えられ（例、IMG）、またあるものは処理過程に影響する（例、スタイルシートやスクリプト・エンジン）ものがあることに注意して下さい。テキスト文字を文書の部分にさせる要素は、 テキスト要素と言われます。

等価

両者が表現上本質的に同じ機能もしくは目的を利用者に実現する場合、内容は他の内容と等価です。文書の文脈上等価であることで、障害がない人にとって元の内容が果たすのと本質的に同じ機能を障害ある人（少なくとも、実現可能な、一定の障害の性質と技術の現状の限りにおいて）にも実現します。 例えば"The Full Moon"と言うテキストは、利用者に表現される時満月の画像と同じ情報を伝えます。等価情報は、 同じ機能を果たすことに的を絞っていることに注意してください。画像がリンクの一部で画像を理解することはリンク目標を推測する上で重要なら、等価もリンク目標の考え方を利用者に与えなければなりません。アクセスできない内容の情報を提供することは、制作者が障害のある人でも文書にアクセスできるようにする基本的な方法の一つです。

内容と同じ機能を実現することの一部として、等価はその内容の説明を含んでいることもあります。例えば複雑なチャート（表）によって伝えられる情報を利用者が理解するために、制作者はチャートについての視覚的な情報を記述すべきです。

テキストは合成音声・点字・視覚的な表示テキストとして利用者に表現されえるので、指針は画像や音響情報での 等価テキストの必要性を説いています。だから等価テキストは、必要な内容全てを伝えるように書かなければなりません。 等価の非テキスト（例、視覚的な表現用の音響的な記述・記載された物語の等価として、手話を使った物語を語る人のビデオなど）も、視覚的な情報もしくは書かれたテキストにアクセスできない人、目が見えない・認識障害がある・学習障害がある・耳が聞こえない人もふくめて、のアクセス性を改善します。

等価情報は幾つもの方法で提供できます。それには、属性（例、HTMLとSGMLの"alt"属性でのテキスト）を通してたり、文書内容の一部（例、HTMlのOBJECT）としてであったり、文書の散文の一部としてであったり、リンク先の文書（例、HTMLで"longdesc"属性や 記述リンクで設計されたもの）を経たりして、提供できます。 等価が複雑な場合、技術との組み合わせが必要になります（例、省略語に等価で普通の読み手に利用しやすい"alt"、更により完全な情報へのリンクでのはじめての読み手に利用しやすい"longdesc"）。 等価情報をどのようにまた何時提供するのかについての詳細は、技術文書 （［技術］）にあります。

テキスト化（text transcript）は、発声や音響効果と言った非発声音も含めて、音響情報の等価テキストです。 表題（caption）は、ビデオ表現上で、ビデオ・オーディオと同調している、音響のテキスト化です。表題は耳が聞こえない人やオーディオを聞きたくない人（例、混雑した室内で）に恩恵をもたらし、一般的にはビデオ上に重ね合せて視覚的に表示されます。 組み合わせテキスト化（collated text transcript）は、表題をビデオ情報（動き・体言語=身振り・グラフィックそしてビデオの場面変化の記述）に結合（組み合わせ）します。これら等価テキストによって、耳が聞こえない−目が見えない人や映画・動画が見られない人にもアクセスできる表現が可能です。これはまた、情報を検索エンジンに入手できるようにもします。

等価非テキストの例の一つに、表現上の鍵になる視覚的な要素の 音響説明があります。この説明は、前もって録音された人の声か合成された声（録音されたものか進行中に生成されたもの）です。音響説明は、表現上の音響軌道で、普通は音響軌道上の自然な合間に合成されます。音響説明には、動作・体言語=身振り・グラフィックそして場面変化などがあります。

画像

グラフィックな表現

イメージマップ

活動を伴った領域に分けられた画像。活動領域をクリックすると、作動します。

利用者がクライアント側の活動領域をクリックすると、表示代行手段はクリックされた領域で計算し、続いてその領域に伴われたリンクをたどります。 サーバー側イメージマップの活動領域を利用者がクリックすると、クリック地点の座標をサーバーに送り、次いで活動を実行します。

内容開発者は、イメージマップの領域と協調する同じリンクの装置非依存性のアクセスを提供してクライアント側イメージマップをアクセスしやすく作成できます。

重要（Important）

文書内の情報が、情報画文書の理解に必要で欠かすことができないなら、重要です。

線状化された表=テーブル

セル=箱の内容が一つながりのパラグラフになっているテーブル（例、ページの保存）。パラグラフは、文書ソースでセルが定義された順序で並びます。セルは、順番に読む際道理に適っていなくてはなりませんし、 構造要素（パラグラフ・見出し・リストなど）を含んでいるべきで、それ故に線形化されてもページが道理に適ってたものになります。

リンク文

表示されるリンクのテキスト内容

自然言語（Natural Language）

フランス語・日本語・米語といった話され書かれる言葉もしくは体言語（身振り・手話）。内容の自然言語は、HTMLで"lang"属性で（ [HTML40]、章8.1)）、XMLでは"xml:lang"（ [XML]、章2.12）で示唆されます。

誘導機構

誘導機構は、利用者がページやサイトを進むことができる手段です。典型的な機構には以下のものがあります：

誘導バー

誘導バーが文書やサイトの最も重要な部分のリンク集である。

サイト地図

サイト地図はページやサイトの組織全体の閲覧を提供する。

目次（tables of contents）

目次は、リストと文書の最も重要なセクションを全般的にリスト（そして そこへ リンク）する。

個人用ジギタル支援（Personal Digital Assistant=PDA）

PDAは、小型で携帯コンピュータ装置です。 大部分のPDAは、カレンダー・連絡・電子メールといった個人データーを伝えるのに使われます。PDAは、一般的に色々なソースからの入力可能な小画面の手のひらサイズの装置です。

画面拡大記

画面の一部を拡大するソフトウェアー・プログラムで、見やすくなります。画面拡大は、低視力の人が主に使用します。

画面読み取り

画面内容を利用者に声をだして読むソフトウェアー・プログラム。画面読み取りは、主に目が見えない人が使います。画面読み取りは、通常画面に印刷され描かれたものではないテキストのみを読みます。

スタイルシート

スタイルシートは、文書の表現（体裁）を特定する一組の声明です。スタイルシートは、三つ異なる源があります：内容提供者が書くもの、利用者が作成するもの、表示代行手段に組み込まれているものです。 CSS （[CSS2]）で、内容提供者と利用者と表示代行手段スタイルシートの相互作用は、 カスケード（cascade）といわれます。

表現マーク付けは、HTMLでのBやI要素のように様式の（構造を作るのでなく）効果を成し遂げるマーク付けです。STRONGやEM要素は、特別な文字スタイルとは独立な情報を伝えるので、表現マーク付けとは考えられていないことに注意してください。

表形式情報（Tabular information）

表はデーター、テキスト・画像など、間の論理的な関係を表現するのに使われ、その情報は「表形式情報」と言われ、その表は「データー表」と言われます。表で表現される関係は、視覚的に（普通は二次元格子に）、音声的に（しばしば、見出し情報のあるセルを先行して）、またその他の形式で表示されます。

表示代行手段が・・・・迄

大部分のチェックポイントで内容開発者は、自分のページやサイトのアクセス性を確認するために質問されています。しかし、 表示代行手段（ 支援技術も含めた）によってより適切に合ったアクセス性要求があります。 この文書の出版以後も、表示代行手段や支援技術全てが、利用者が要求するアクセス性制御を提供していません（例、表示代行手段のなかには利用者が点滅内容を切り替えることができませんし、画面読み取りのなかには表をうまく処理できないかもしれません）。「表示代行手段が・・・・迄」という句のあるチェックポイントは、多数の人が容易に入手できる殆どの表示代行手段が必要なアクセス性機能を持つ迄、開発者が追加的なアクセス性サポートを提供するよう求めています。

Note.W3C WAI Webサイト （[WAI-UA-SUPPORT]を参照）は、アクセス性機能のサポートの表示代行手段情報を提供しています。内容開発者はこのページを更新された情報を定期的に見るようにすすめます。

表示代行手段（ユーザー・エイジェント）

ウェブ内容にアクセスするソフトウェアーで、デスクトップのグラフィカルなブラウザ・テキスト=ブラウザ・プラッグインそして、画面読み取り・画面拡大・発声認識ソフトウェアーといったブラウザと結合して使用される、ある種の支援技術を含みます。

謝辞

Web Content Guidelines Working Group Co-Chairs:

Chuck Letourneau, Starling Access Services

Gregg Vanderheiden, Trace Research and Development

W3Cティームとの連絡：

Judy Brewerと Daniel Dardailler

この指針を作り上げるために時間と価値あるコメントで寄与していただいた以下の方々に感謝致します：

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

この文書のオリジナル候補は、Trace R & D Center at the University of Wisconsinによって変換された"The Unified Web Site Accessibility Guidelines" （ [UWSAG]）を元にしています。その文書には、さらなる寄与者の一覧があります。

参照資料

いかなるW3C仕様書の最新版については、 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
［ 翻訳版］

[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

［ホーム］