WAIアクセシビリティガイドライン:ページ制作


W3CWD-WAI-PAGEAUTH-19980918

WAIアクセシビリティガイドライン:ページ制作

W3Cワーキングドラフト - 1998年9月18日

このバージョン(原文):
http://www.w3.org/TR/1998/WD-WAI-PAGEAUTH-19980918
最新のバージョン:
http://www.w3.org/TR/WD-WAI-PAGEAUTH
以前のバージョン:
http://www.w3.org/TR/1998/WD-WAI-PAGEAUTH-0414
http://www.w3.org/TR/1998/WD-WAI-PAGEAUTH-0203
関連文書:
Table Version of the Guidelines
Techniques
編集者:
Gregg Vanderheiden <gv@trace.wisc.edu>
Wendy Chisholm <chisholm@trace.wisc.edu>
Ian Jacobs <ij@w3.org>

著作権  ©  1998 W3C(マサチューセッツ工科大学フランス国立情報処理自動化研究所慶應義塾大学. すべての権利が留保されている。

概要

この文書は、ページを、障害のある人々にとってよりアクセス性が高く、またその他のユーザ、新しいページ閲覧技術(モバイル、音声)や、インデックスロボットといったような電子的エージェントにとってより便利なものにするためにページ制作者が従うべきガイドラインの一覧です。HTMLで書かれた文書を生成するツール(オーサリングツール、ファイル変換パッケージその他の製品)は、これらのガイドラインに従った文書を制作者が生み出すことを容易にするべきです。この文書は Web Accessibility Initiative によって公開されている一連のアクセシビリティ文書の一部です。

アクセシビリティは最低限のページ設計を意味するのではありません。考え抜かれたページ設計を意味します。これらのガイドラインは、制作者、特にマルチメディアコンテンツを使っている制作者が、それらのエレメントによって提供されるコンテンツや機能がすべてのユーザに利用可能であることを確保するための手続の輪郭を描きます。一般的に制作者は、マルチメディアの利用を思いとどまらされるべきなのではなく、公開する素材が可能な限り最も広い観客聴衆にとりアクセス可能であることを確保する方法でマルチメディアを利用するべきです。

この文書の位置づけ

これは、W3C会員およびその他の利害関係者による検討のためのW3Cワーキングドラフトです。この文書はワーキングドラフトであり、何時にても他の文書により更新され、置換され、あるいは廃止される場合があります。W3Cワーキングドラフトを参照資料として用いたり「進行中の作業」以外のものとして引用することは不適切です。これは進行中の作業であって、W3Cや WAI-GL ワーキンググループのメンバーによる裏書や合意を意味するものではありません。

この文書は、W3C WAI Activity の一部として生み出されているものであり、アクセシビリティの高いウェブページを制作するための勧告提案の草稿として意図されています。WAI-GL ワーキンググループの目標は、私達の憲章の中で論じられています。

コメント

この文書についての詳細なコメントは w3c-wai-gl@w3.org までお送りください。WAI制作者ガイドラインについての公開のコメントもこのメーリングリストに送ることができます。

目次

格付け、分類
A. さまざまなユーザや技術、状況にわたってページが素直に変身することを保証しましょう
B. 複雑なページやエレメントには文脈情報や方向性情報をつけましょう
C. よい設計慣習に従って可用性を最大化しましょう
付録 A: テストの方法
付録 B: 定義集
付録 C: 優先度別ガイドライン索引
付録 D: 優先度別テクニック索引

格付け、分類

[優先度1]
制作者はこのガイドラインに従わなければならず、さもなくば1つまたはそれ以上のグループのユーザはその文書の中の情報にアクセスすることが不可能であると知ることになります。このガイドラインを実装することは、いくつかのグループがウェブ文書を利用できるようにするための基本的な必須の要請です。
[優先度2]
制作者はこのガイドラインに従うべきであり、さもなくば1つまたはそれ以上のグループのユーザはその文書の中の情報にアクセスすることが困難であると知ることになります。このガイドラインを実装することは、ウェブ文書へのアクセスを著しく向上させるでしょう。
[優先度3]
制作者は、1つまたはそれ以上のグループのユーザが文書の中の情報にアクセスしやすくするために、このガイドラインに従ってもかまいません。このガイドラインを実装することは、ウェブ文書へのアクセスを向上させるでしょう。

各ガイドラインおよび各テクニックは、列挙されている優先度をもっています。ガイドラインの優先度は、そのガイドラインによって特定される問題を扱うことの重要性を指しています。テクニックの優先度は、このガイドラインに関してどのテクニックが最もアクセシビリティを向上させるかを指しています。たとえば、優先度1のガイドラインには、アクセシビリティを提供するために実行されなければならない優先度1のテクニックがあったり、問題の処理を助けるために実行されてもよい優先度3のテクニックがあるかもしれません。


A. 素直な変身

さまざまなユーザやテクニックや状況にまたがってページが素直に変身することを確認しましょう。

「素直に変身する」とは、ユーザや技術的および状況的制約にかかわらずページが利用可能でありつづけるという意味です。ユーザの中には、ページを完全に利用するためには制作者によって指定された機能(フォントサイズや色の組み合わせなど)を「オフにする」必要のあるユーザもいます。たとえば、弱視者だとテキスト全部を36ポイントのフォントで表示する必要があるかもしれません。そうすると制作者指定のフォントサイズを基礎としたフォーマットが崩壊することになります。

素直に変身する文書を制作するために、制作者は次のことをするべきです。

  1. ページ上のすべての情報が、完全に視覚的に受領されてもよく、完全に聴覚的手段を通じて受領されてもよく、全情報がテキストでも利用可能であることを保証する。
  2. サイト上の内容(言っていること)やその内容を構造化するために選択した方法(それをどのように組織するか)を、内容や構造がどのように表現されるか(どのように「見て」もらいたいか)から常に分離する。
  3. マウスなしのデバイスや、小さい低解像度画面や白黒画面のデバイス、音声またはテキスト出力のみのデバイス、スクリーンなしのデバイスなどを含むさまざまなタイプのハードウェア上でページが操作可能であろうことを確認する。

ガイドライン A.1 ~ A.12 は、これらの問題を扱うものです。

A.1. すべての画像、アプレット、イメージマップに代替テキストをつけましょう。[優先度1]

これには送信ボタンや、リストのブリット、イメージマップ内部のリンクの全部として使われている画像、ページをレイアウトするために使われている不可視的画像も含まれます。代替テキストは画像やアプレット、イメージマップの視覚的外観を説明するものではありません。むしろ、装飾的であるか情報的であるか、あるいはレイアウト目的であるかを問わず、画像やアプレット、イメージマップが果たす機能を表わすために使われるものです。もし代替テキストがつけられていなければ、目の見えないユーザや弱視のユーザ、グラフィックを見ることができず、または見ないよう選択しているユーザは、そのページ上の視覚的部品の目的がわからないことになります。「アスキーアート」(画像を形作るキャラクタ)には代替テキストが許されませんから、この目的のためには特別にマークアップされなければなりません。

テクニック:

  1. すべての画像 (IMG) に代替テキストをつける("alt" アトリビュート経由)。[優先度1]
    注意. これにはイメージマップやスペーサーリストのブリットリンクとして使われている画像が含まれる。
  2. すべてのアプレット (APPLET) に代替テキスト("alt" アトリビュート経由)と注釈とをつける。[優先度1]
  3. すべてのイメージマップリンク (AREA) について
  4. サーバ側イメージマップを使わなければならない場合には、イメージマップ内のそれぞれのホットスポットに代わるテキストリンクをつける。[優先度1]
  5. すべてのグラフィカルボタン (INPUT type="image") について
    1. 代替テキストをつける("alt" アトリビュート経由)。[優先度1]
    2. イメージマップを使ってフォームの中にボタンのセットを作らない。代わりに(代替テキストをつけられ)別々に分かれたボタンや画像を使う。[優先度2]
  6. 画像と代替テキストとでアスキーアートを置き換える。[優先度1~2。情報の重要性による(例. 重要な地図)]
    注意. (重要な)アスキーアートの説明文が長くなる場合には、代替テキストに加えて説明文をつけましょう(A.2 を見ること)。
  7. 画像やアプレット、スクリプトをページに組み込むために OBJECT が使われている場合には、OBJECT が受領できないときに情報を伝達するための数多くの方法のうちのどれかを使う(例. "title" を用いたり OBJECT アトリビュートの本体の内部に情報を記述する)。[優先度1]

A.2. 重要なグラフィックスやスクリプト、アプレットが代替テキストを通じて、または文書の内容の中で充分に説明されていない場合には説明文をつけましょう。[優先度1]

さもなくば、目が見えない人々や、一部の弱視者グラフィックやスクリプト、アプレットを見ないように選択しているユーザやスクリプトやアプレットをサポートしていないブラウザのユーザにとって、グラフィック的に表現されている重要な情報(地図、ビルボード、解説図)が受領不能ということになります。

テクニック:

  1. 重要な情報を伝達するグラフィックすべてに長文解説 をつける。そのためには
  2. 画像やアプレット、スクリプトをページに組み込むために OBJECT が使われており、それが重要な情報を表現している場合には、OBJECT が受領できないときに情報の長文解説をつけるための数多くの方法のうちのどれかを使う。[優先度1]

A.3. すべての音声情報には同等のテキスト(テキスト表記)をつけましょう。[優先度1]

音声が視覚的表現(ムービー、アニメーション)と結び付けられている場合には、テキスト的な等価物を視覚的表現と同期させましょう。さもなくば、耳が聞こえないユーザや難聴のユーザ、音声を聞くことができず、あるいは聞かないよう選択しているユーザが、会話や効果音や音楽などを通じて表現されている情報を受領できません。

テクニック:

  1. スタンドアローンのオーディオファイルには、話されたり歌われたりしているすべての言葉とすべての重要なサウンドとのテキスト表記をつける。[優先度1]
  2. ビデオと結びつけられた音声には、ビデオと同期した(会話や音声の)テキスト表記をつける(例. 字幕)。[優先度1]
  3. 音声が自動的に再生されるときには視覚的な通知やテキスト表記を提供する。[優先度1~2. 音声の重要性による]

A.4. 動きのある視覚的情報(ムービー、アニメーションなど)には音声形式とテキスト形式の双方で言葉による説明をつけましょう。[優先度1]

視覚的表現が聴覚的表現と結びつけられている場合(例. ムービー)には、オーディオ版の解説を既存の聴覚的表現と同期させテキスト版の説明文を主オーディオトラックのテキスト表記(字幕)と対照させましょう。さもなくば、聴覚的手段を通じてでは(会話や効果音など)同様に表現できない情報をアクションやボディランゲージその他の視覚的キューが表現している場合には、そのページを見ることができないユーザが情報を受領できないことになります。対照されたテキスト版はムービーを再生しないデバイスや耳が聞こえず目が見えない人々による情報へのアクセスを可能にします。

テクニック:

  1. アニメーションgif画像のような短いアニメーションには、必要ならば代替テキスト(A.1 を見ること)や長文解説(A.2 を見ること)をつける。[優先度1]
  2. ムービーには、オリジナルのオーディオと同期した聴覚的解説 をつける。[優先度1]
  3. 主オーディオトラックのテキスト表記(字幕)と対照されたテキスト版の聴覚的解説 をつける。[優先度2]

A.5. 色なしで見たときにテキストやグラフィックスが受領可能、理解可能であることを確かめましょう。[優先度1]

そうでなくて、もし色が情報を伝達するために使われていれば、一定の色を識別できないユーザ(および非カラーまたは非視覚的表示装置を用いているデバイスのユーザ)は、その情報を受け取れないことになります。
前景色と背景色とがあまり同一色調に近いと、モノクロディスプレイを使って見られたり異なる型の色覚障害を有する人々に見られたりするときに充分なコントラストがつけられない場合があります。

テクニック:

  1. マークアップやテキストからも情報が明確であるのでない限り色を使って情報を伝達しない。[優先度1]
  2. 色盲の人が見たり白黒スクリーン上で見たりするときに充分なコントラストを提供する色の組み合わせを前景色と背景色との間で使う。[優先度1]

A.6. 構造は構造エレメントで示し、表現は表現エレメントやスタイルシートで制御しましょう。[優先度2]

構造的エレメントやアトリビュートが表現効果を作り出すために使われていると、ユーザが構造を通じたナビゲーションをできるようにするユーザエージェントがそれを適切にできないことにな。そうした慣習は、他のメディアやデバイスの上でページをレンダリングすることも困難にします。たとえば、テキストが実際にトップレベルの見出しでない限り、大きな太い文字を作り出すために H1 を使ってはいけません。

テクニック:

  1. 見出しを適切にネストする (H1 - H6). [優先度2]
  2. リスト構造やリスト項目を適切にエンコードする (UL, OL, DL, LI). [優先度2]
  3. 引用は Q エレメントや BLOCKQUOTE エレメントでマークアップする。字下げなどのフォーマット効果のためにこれらのエレメントを使わない。[優先度2]
  4. 利用されている大部分のブラウザがきちんとサポートするようになれば直ちに、レイアウトや表現を制御するためには、可能な限りどこででもスタイルシートを使う(A.9 を見ること)。それまでの間は単純なテーブル(レイアウトを制御するため)や代替テキストつきのビットマップテキスト(特殊なテキスト効果のため)を使ってもよいが、そのページ上の情報がアクセス可能であることを確保するために必要であれば代替ページを使うこと(C.1 を見ること)。[優先度2]
  5. 絶対的サイズ指定や位置指定(例. ピクセルやポイント)よりも相対的サイズ指定や位置指定(例. 百分率)を使う。[優先度2]

A.7. 移動したり、点滅、スクロール、自動更新するオブジェクトやページを停止させたり凍結してもよいことを確かめましょう。[優先度1]

これは特にテキストを含むオブジェクトにとって重要であり、即時リダイレクションには適用されません認識的制約視覚障害のある人々は、高速で移動するテキストを充分にはあるいは全く読むことができません。移動はまた、認識障害のある人々にとってページの残りの部分を読めなくするような混乱も生じ得ます。スクリーンリーダーは移動するテキストを読むことができません。身体的障害のある人々は、移動するオブジェクトと相互作用するため充分にすばやくあるいは正確に動作することができない場合もあります。光過敏性てんかんのある人々は、毎秒20回を感受性のピークとして毎秒4~59回(ヘルツ)の範囲のフリッカーや閃光が引き金となる発作を起こす場合があります。

テクニック:

  1. 可能であれば移動は避けるべきであるが、もし使わなければならない場合はユーザがアプレットやスクリプトの動きや更新を凍結できるようにする機構をつけるか、スタイルシートやスクリプトを使って動きを作り出す(A.10 を見ること)。[優先度2]
  2. 自動リロードページやタイミング応答ページには、リンクが選択されてしまった後にしか(ユーザエージェントがこの能力を自身に提供するまでの間)リフレッシュしないページのセカンドコピーをつける。[優先度1]
  3. フリッカーを起こすスクリーンの点滅や更新を避ける。[優先度1]

注1. BLINK や MARQUEE はどのW3C HTML仕様書にも定義されていませんから、使うべきではありません。C.1 を見ること

注2. アニメーションgifを論じている A.4.1 も見ること

A.8. 省略されたテキストや外国語のテキストを発音したり解釈するために必要な補充的情報をつけましょう。[優先度2]

同じページ上で複数の言語の間の変更が特定されず、略語や頭字語の展開が提供されていない場合には、音声化されたり点字化されたときに解読不能な場合がある。

テクニック:

  1. "lang" アトリビュートを使って明確にテキスト言語の変更を特定する。[優先度2]
  2. 略語や頭字語には ABBR または ACRONYM に "title" アトリビュートをつけて展開を指定する。[優先度2]

A.9. 新しいW3C機能(技術)を使っているページが、その機能がサポートされていなかったりオフにされていれる場合にアクセス可能な形式に素直に変身するであろうことを確認しましょう。[優先度1]

完全には後方互換的でない最近の機能には、フレームやスクリプト、スタイルシート、アプレットが含まれます。HTMLの各リリースは新しい言語機能を組み込んでいます。たとえば、HTML 4.0 はページにスタイルシートを添付したりスクリプトやアプレットを埋め込む能力を追加しました。古いブラウザは新しい機能を無視しますし、新しい機能を利用しないようにブラウザを設定しているユーザもいます。新しい機能が素直に変身しないときには、これらのユーザには真っ白なページ以外に何も見えなかったり、利用不能なページしか見えないことがよくあります。たとえば、画像をフレームのソースに("src" アトリビュート経由で)指定すると、その画像に代替テキスト(A.1 を見ること)を添付する単純な方法はありません。

テクニック:

  1. フレーム:
    1. フレームを含んでいるページにはバックアップページをつける(例. NOFRAME を使うことにより)。[優先度1]
    2. 各フレームのソースがHTMLファイルであることを確認する。[優先度1]
  2. 決定的な情報や機能を表現するスクリプトには代替的な同等の表現または機構を提供する(例. NOSCRIPT を使うことにより)。[優先度1]
  3. スタイルシートを使うページについては、スタイルシートなしでも適切に読めるように各ページの内容が整理され、構造化されていることを確認する。[優先度1]
  4. アプレット: (OBJECT または APPLET を使って埋め込まれる)
    1. 最低でも
    2. 可能ならばアプレット以外のフォーマットで代替的機能や表現を提供する。たとえば録画された物理実験の(Java で書かれた)MPEGムービーや、gif画像として保存されたアニメーションのひとこまなど。[優先度2]


C.1.2 も見ること - 代替ページ.

A.10. それ自身のユーザインターフェイスを含んでいるエレメントにはアクセシビリティが組み込まれるべきです。[優先度2]

それ自身のインターフェイスをもつオブジェクトのアクセシビリティは、ユーザエージェントのアクセシビリティから独立しています。したがって、アクセシビリティがオブジェクトに組み込まれるか、代替手段が提供されなければなりません(A.11.4 を見ること)。

テクニック:

  1. 可能な限りどこでもアプレットを直接アクセス可能にする (A.9.4 も見ること)。[情報または機能が重要であり他のどこにも表示されていないならば優先度1。それ以外では優先度2]

A.11. ポインティングデバイス以外の入力デバイス経由で(例. キーボードや音声などを経由して)ページ要素を活性化できるようにする機能を使いましょう。[優先度1]

視覚を使わず、あるいは音声入力やキーボード(あるいはマウスなどのポインティングデバイス以外の入力デバイス。例. 点字ディスプレイ)でページを使っているユーザの中には、操作にポインティングデバイスが要求されるとページのナビゲーションに困難な思いをすることになる者もいます。ページがキーボード経由で利用可能であれば、会話入力やコマンドラインインターフェイス経由でも操作可能である可能性がさらに高くなります。これらのユーザにとって、代替方法が提供されない限りイメージマップへのアクセスは不可能です。

テクニック:

  1. イメージマップには、リンクのための代替テキストをつける(A.1 も見ること)。[優先度1]
  2. できれば、自前のインターフェイスを有するエレメントすべてがキーボードで操作可能であることを確認する(A.11 も見ること)。[優先度2]
  3. リンクやフォーム制御、オブジェクトを一貫して論理的なタブ順序を("tabindex" アトリビュート経由または論理的なページ設計を通して)制作する。[優先度3]
  4. リンク(クライアント側イメージマップの中にあるものを含む)やフォーム制御、フォーム制御のグループに("accesskey" アトリビュート経由で)キーボードショートカットをつける。[優先度3]

A.12. 当面のアクセシビリティ解決策を使って、補助的技術や古いブラウザが正しく動作するようにしましょう。[優先度2]

古いブラウザは、編集ボックスやテキスト領域、連続的リンク一覧が許されず、ユーザがそれらにアクセスすることを困難または不可能にします。グラフィカル環境で操作をしていないユーザは、警告なしに新しいウィンドウへ転送されると方向を見失うことになります。

テクニック:

ほとんどのユーザがこれらの問題を処理する新しい技術を確保できるまでの間、

  1. 編集ボックスやテキスト領域の中にデフォルトの場所確保用キャラクタを組み込む。[優先度3]
  2. 連続して発生するリンクの間に非リンクの印字可能キャラクタ(スペースで囲まれた)を組み込む。[優先度3]
  3. ユーザがその発生に気づいているのでない限り、新しいウィンドウを開いたり、アクティブウィンドウを変更したり、ポップアップウィンドウを使わない。[優先度2]
  4. すべてのラベルつきフォーム制御について、ラベルが ことを確認する。
  5. ユーザエージェントやスクリーンリーダーが並んで表示されているテキストを処理できるようになるまでの間、ワードラップされた平行な段組みにテキストをレイアウトするすべてのテーブルには直線的な同等のテキストが(現在ページ上またはその他のページ上に)必須である。[優先度2]

B. 文脈、方向づけ

複雑なページやエレメントについては、文脈情報や方向性情報を提供しましょう。

文脈情報や方向性情報を提供するとは、ユーザがページやテーブルやフレーム、フォームによって表現されている「概観図」の理解を得ることを助けるための追加的な情報を提供することを意味します。ユーザが一度に1単語ずつ(音声合成装置や点字ディスプレイ)または1節ずつ(小さいディスプレイや拡大ディスプレイ)ページにアクセスしているために、ページの一部分だけしか見られないという制約を受けるのはよくあることです。

文脈情報や方向性情報を提供する文書を制作するために、制作者は以下のことをするべきです。

  1. 情報を構造化したりグループ化する。
  2. 構造やグループを明確にラベルづけする。

ガイドライン B.1 ~ B.3 はこの問題を扱います。

B.1. フレームには、フレームの目的やフレームが互いにどのように関連しているかを知るために充分な情報を提供しましょう。[優先度1]

目の見えないユーザや弱視のユーザは、スクリーンに「トンネルビジョン」でアクセスし、ページを理解するための概観を得られないことがよくあります。またフレーム間の複雑な関係も、認識障害のある人々にとって利用困難である場合があります。

テクニック:

  1. ユーザが名前でフレームを追跡できるようにフレームにタイトルをつける(FRAME の "title" アトリビュート経由)。[優先度1]
  2. "longdesc" を(必要な場所で)使って(タイトルで与えられるよりも)より完全な説明文をフレームに直接に結びつける。"longdesc" が広くサポートされるまではDリンクや不可視的Dリンクも使う。[優先度2]

B.2. 制御や選択、ラベルを意味論的単位にグループ化しましょう。[優先度2]

これは制御間の関係についての文脈的情報を提供するものであり、すべてのユーザに有益です。

テクニック:

  1. フォーム制御をグループ化する(FIELDSET や LEGEND エレメントを使う)。[優先度2(ラジオボタン、チェックボックスについて)~3(その他の制御について)]
  2. それらの制御にラベルをつける(LABEL とその "for" アトリビュートを使う)。[優先度2]
  3. 長い選択リストには階層構造を作成する(OPTGROUP を用いる)。[優先度2]

B.3. (レイアウト目的で使われていない)テーブルが、必要なマークアップを有し、アクセス可能なブラウザその他のユーザエージェントによって適切に再構築され表示されることを確認する。[優先度1]

多数のユーザエージェントはテーブルを再構築して表示します。適切なマークアップを欠けば、テーブルは再構築されるときに意味をなさないことになります。またテーブルはスクリーンリーダーのユーザに特別な問題を課します。

これらのガイドラインは、音声的手段を通じてテーブルにアクセスし(例. 音声入力および出力で操作する自動車PC)、または一度にページの一部分しか見えない(例. 会話または点字ディスプレイを使っている全盲または弱視のユーザ、その他小さいディスプレイのデバイスのユーザなど)ユーザに利益をもたらします。

テクニック:

  1. テーブルのまとめをつける(TABLE の "summary" アトリビュート経由で)。[優先度3]
  2. 行や列の見出しを特定する(TD, TH). [優先度2]
  3. テーブルが行や列で示されているのを越えた構造的部分を有するところでは、構造的部分を特定するために適切なマークアップ(THEAD, TFOOT, COLGROUP, "axis" アトリビュート、"scope" アトリビュートなど)を使う。[優先度2]
  4. ヘッダラベルに略語表記をつける(TH の "abbr" アトリビュート経由で)。[優先度3]

B.4. 可能な限りどこでも「よい」リンク文を作成しましょう。[優先度2]

「よい」リンク文とは

ものです。

「聴覚的ユーザ」、すなわち目が見えずまたはものを見るのに困難がある人々やディスプレイが小さかったりなかったりするデバイスを使っている人々は、目ですばやくページをスキャンすることができず、リンク一覧を使ってページの概要をつかんだりリンクをすばやく発見したりすることがよくあります。リンクが充分に説明的でなくて文脈を離れて読んだときに意味をなさず、あるいは一意的でないならば、聴覚的ユーザは各リンクを特定するために立ち止まってその周囲のテキストを読まなければなりません。

可能な限りどこでも

  1. 2つ以上のリンクが同じテキスト文を共有していれば、それらすべてのリンクが同じリソースを指し示しているべきである。[優先度2]
  2. 「ここをクリックしてください」といったようなそれ自身では意味のない文を避ける。[優先度2]
  3. 文全体を含むリンク文を作成することを避ける。[優先度2]

C. よい習慣

以下のよい設計習慣に従って可用性を最大化しましょう。

よい設計とはアクセス性の高い設計であり、逆もまた真です。たとえば、よりアクセス性の高いページへつながる習慣は、ページを、すべてのユーザによって利用可能であるだけでなく、インデックスエンジンにとってもアクセス性の高いものにします。よい設計習慣に含まれるものには、一貫性、一般性、単純性、再利用、検証があります。

C.1. W3C仕様書で定義された技術だけを使い、それをアクセス可能な方法で使いましょう。それができない場所ではアクセス可能な代替ページを提供しましょう。[優先度1]

情報をエンコードするために使われている多数の非HTML技術(例. PDF、Shockwave、その他の非W3Cデータフォーマット)は、標準的なウェブアクセスツールを使って見たり操作したりできないページを作り出すことが多いプラグインやスタンドアローンアプリケーションを必須とします。また、素直に変身しない方法でW3C技術が使われる場合もあります(例. 視覚的コンポーネントが複雑すぎたり、補助的技術やユーザエージェント(ブラウザ)が特定の機能を欠いているため)。非標準的機能(特定のブラウザ型でしかサポートされていないエレメントやアトリビュートやプロパティなど)を避け、すべての技術が素直に変身することを保証することにより、あなたのページは、より広範囲のハードウェアやソフトウェアを使っているより多数の人々にとってアクセス可能になるでしょう。

注. すべてのPDFページが、PDFトランスレータを通じて処理された後でアクセス可能であったり可読的であるとは限りません。変換プロセスの後で可読性を各ページについて個別的にテストしましょう。もしページが自動的に変身しないならば、そのPDF表現が一般的に利用可能なコンバータを通じて適切にコンバートされるまでそのページを改訂するか、HTMLまたはプレインテキストの等価物を用意してポストしましょう。

  1. W3C技術が使われる場合は
    1. 可能である限りいつでも最新のW3C仕様を使う。[優先度2]
    2. 可能である限りいつでも廃止されたエレメントを避ける。[優先度2]
  2. もし最善の努力を尽くしても非W3C技術やアクセス不能な方法でW3C技術を使うことを避けられないならば、このような代替ページへのリンクを提供しなければならない。 [優先度1]
    注. (代替ページがオリジナルのページと同じソースから自動的に生成されるのでない限り)代替ページをオリジナルページの完全な内容をもたせて最新のものに保つことは困難ですから、代替ページを提供するのは、オリジナルページを アクセス可能にするためにこの文書で概観されたその他の適切な技術のすべてを試した後にするべきです。
    代替ページ制作のガイドラインと方法

C.2. ウェブサイト内部の操作を促進する機構を提供しましょう。[優先度3]

よい設計を通じて、人が探しているものを簡単に見つけることができ、サイトを一貫して簡単にナビゲートできる機械を増加させましょう。ページ間で一貫性のあるページレイアウトや明快なナビゲーション構造は、認識障害のある人々だけでなくサイトを訪問したすべての人にとって役に立つでしょう。

重要な情報を見つけるまでに読者がなすべきふるい分けの量を減少させるため、見出しや段落、リストの始めに識別用の情報を置きましょう。これは一般に「フロントローディング」と呼ばれ、特にシリアル的に情報にアクセスしている人々にとって助けになります。

  1. ページ間で一貫性のある表現スタイルを制作する。[優先度3]
  2. 明快で一貫性のあるナビゲーション構造を使う。[優先度3]
  3. ナビゲーション構造に簡単にアクセスできるようナビゲーションバーを提供する。[優先度3]
  4. サイトの全体的なレイアウト、使われているアクセス機能やその使い方についての説明文をつける。[優先度3]
  5. サイトマップを提供する。[優先度3]
  6. 異なる技能水準や好みに応じた異なるタイプの検索を提供する。[優先度3]
  7. 見出しや段落、リストのなどの最初に識別用の情報を提供する。[優先度3]

C.3. 一連の分割ページとして存在している文書についてはダウンロード可能な単一ファイルを作成しましょう。[優先度3]

これは文書をオフラインで読んでいる人々の助けとなります。現在、単一ファイルを作成するためにはアーカイブや圧縮プログラムが必要です。近い将来、ユーザエージェントは、ばらばらのページをメタ情報に基づいて丁合できることでしょう。

  1. どれが文書の最初のページであるかを示したり、どのページが現在のページに続くかを示す(例. LINK を使う)。[優先度3]
  2. 文書を構成する全ページのバンドル版を作成する。[優先度3]

付録 A: テストの方法

ページを検証したりアクセシビリティを査定するには、自動化されたツールや手動のテスト、その他のサービスを利用します。

さまざまな型のブラウザや、現在のブラウザの旧バージョン、ブラウザをエミュレートするサービスを用いてサイトをテストすることは重要です。さまざまなブラウザやその他のサービスでサイトをテストすることは、人々が扱う問題のいくつかの直接の経験を得ることを可能にするでしょう。テストの結果に基づいて設計を調整することは、広範囲のユーザや技術によってサイトが利用可能であることの蓋然性を高めるでしょう。

  1. 自動化されたアクセシビリティ検証ツールやブラウザ検証ツールを使う。
  2. W3C HTML検証サービスを使う。http://validator.w3.org/ で利用できる。
  3. W3C CSS検証サービスを使う。http://jigsaw.w3.org/css-validator/ で利用できる。
  4. テキスト専用ブラウザまたはエミュレータを使う。
  5. 複数のグラフィックブラウザを 使う。
  6. 自動音声化ブラウザや、スクリーンリーダ、拡大ソフトウェア、小さいディスプレイなどを用いてサイトをテストすることも助けになる場合がある。

付録 B: 定義集

アプレット (applet)
ウェブページの中へ挿入されたプログラム。
アスキーアート (ASCII art)
アスキーアートとは、テキストキャラクタや記号を組み合わせて画像を作り出したものをいいます。たとえば ";-)" はスマイリー(顔文字)ですし、以下の絵は牛を表現しています。
          (__)             
          (oo)   
   /-------\/          
  / |     ||
 *  ||----||             
    ^^    ^^       
後方互換的な (backwards compatible)
より早い時期のバージョンの言語やプログラムなどで動作するように設計されているもの。
[ブライユ式]点字 (braille)
点字は、異なるパターンで浮き上がった点6つを使って、目の見えない人々が指先で読む文字や数字を表現します。動的点字は、ドットパターンが電気的に上げ下げされるディスプレイの利用を伴います。
Accessible 点字で表わした "Accessible" という単語。
画像 (image)
グラフィカルな表現。
イメージマップ (image map)
複数の区域に分割されている画像。区域をクリックするとアクションが発生します。
重要な (important)
その詳しい理解が文書の全体的理解に必要であれば、それは重要である。
即時リダイレクション (instant redirection)
ページが読み込まれますが、一時滞在文書のメタ情報のせいで直ちに他の文書によって置き換えられます。
ページ制作者 (page author)
ウェブページを作り出している人々。
画面拡大器 (screen magnifier)
画面をより簡単に見ることができるよう画面の一部分を拡大するソフトウェアプログラム。主に視力の弱い人によって使われます。
スクリーンリーダー (screen reader)
ユーザに対して声を出して画面の内容を読み上げるソフトウェアプログラム。主に目の見えない人によって使われます。大抵は画面に印字されるが描画されるのではないテキストだけしか読むことができません。

付録 C: 優先度別ガイドライン

優先度1
  1. A.1. すべての画像やアプレット、イメージマップに代替テキストをつけましょう
  2. A.2. 重要なグラフィックスやスクリプト、アプレットが代替テキストを通じて、または文書の内容の中で充分に説明されていない場合には、それらに説明文をつける
  3. A.3. すべての音声情報に同等のテキスト(テキスト表記)をつけましょう
  4. A.4. 動きのある視覚的情報(ムービー、アニメーションなど)には音声形式とテキスト形式の両方で言葉による説明をつけましょう
  5. A.5. 色なしで見たときにテキストやグラフィックスが受領可能、理解可能であることを確かめましょう
  6. A.7. 移動したり、点滅、スクロール、自動更新するオブジェクトやページを停止させたり凍結してもよいことを保証しましょう
  7. A.9. 新しいW3C機能(技術)を使っているページが、その機能がサポートされていなかったりオフにされている場合にアクセス可能な形式に素直に変身するであろうことを確認しましょう
  8. A.11. ポインティングデバイス以外の入力デバイス経由で(例. キーボードや音声などを経由して)ページ要素を活性化できるようにする機能を使いましょう
  9. B.1. フレームにはフレームの目的や相互関係を知るために充分な情報をつけましょう
  10. B.3. (レイアウト目的で使われていない)テーブルが、必要なマークアップを有し、アクセス可能なブラウザやその他のユーザエージェントによって適切に再構築されて表現されることを確認しましょう
  11. C.1. W3C仕様書に定義されている技術だけを使い、それをアクセス可能な方法で使いましょう。それができない場所ではアクセス可能な代替ページを提供しましょう。
優先度2
  1. A.6. 構造は構造エレメントで示し、表現は表現エレメントやスタイルシートで制御しましょう
  2. A.8. 省略表記や外国語テキストを発音したり解釈するために必要な補充的情報をつけましょう
  3. A.10. 独自のユーザインターフェイスを含んでいる要素にアクセシビリティを組み込むべきです
  4. A.12. 当面のアクセシビリティ解決策を使って、補助的技術や古いブラウザが正しく動作するようにしましょう
  5. B.2. 制御や選択、ラベルを意味論的単位にグループ化しましょう
  6. B.4. 可能であればどこでも「よい」リンク文を制作しましょう
優先度3
  1. C.2. サイト内部のナビゲーションを促進する可能にする機構を提供しましょう
  2. C.3. 一連の分離したページとして存在している文書についてはダウンロード可能な単一ファイルを作成しましょう

付録 D: 優先度別テクニック

優先度1
  1. A.1.1. すべての画像 (IMG)に代替テキストをつける("alt" アトリビュート経由)。注. これにはイメージマップやスペーサーリストのブリットリンクとして使われている画像が含まれる。
  2. A.1.2. すべてのアプレット (APPLET) に代替テキスト("alt" アトリビュート経由)と注釈とをつける。
  3. A.1.3. すべてのイメージマップリンク (AREA) について
  4. A.1.4. サーバ側イメージマップを使わなければならない場合にはイメージマップ内の各ホットスポットに代わるテキストリンクをつける。
  5. A.1.5. すべてのグラフィカルボタン (INPUT type="image") に代替テキスト("alt" アトリビュート経由)をつける。
  6. A.1.6. 画像と代替テキストとでアスキーアートを置き換える [優先度1~2. 情報の重要性に依存する(例. 重要な地図)]
  7. A.1.7. 画像やアプレット、スクリプトをページに組み込むために OBJECT が使われている場合には、OBJECT エレメントの本体内部といったような OBJECT が受領できない場合に情報を伝達するための数多くの方法のうちのどれかを使う(例. "title" を用いたり OBJECT アトリビュートの本体の内部に情報を記述する)。[優先度1]
  8. A.2.1. 重要な情報を伝達するグラフィックすべてに長文解説をつける。そのためには
    • "longdesc" を使う。
    • 大半のブラウザが "longdesc" をサポートするまでの間、Dリンク(または不可視的Dリンク)も使う。
  9. A.2.2. 画像やアプレット、スクリプトをページに組み込むために OBJECT が使われており、それが重要な情報を表示している場合には、OBJECT が受領できないときに情報を伝達するための数多くの方法のうちのどれかを使う。
  10. A.3.1. スタンドアローンのオーディオファイルに、話されたり歌われたりしているすべての言葉とすべての重要なサウンドとのテキスト表記をつける。
  11. A.3.2. ビデオと結びつけられた音声には、ビデオと同期した(会話や音声の)テキスト表記をつける(例. 字幕)。
  12. A.3.3. 音声が自動的に再生されるときには視覚的な通知やテキスト表記を提供する。[優先度1~2. 音声の重要性による]
  13. A.4.1. アニメーションgif画像のような短いアニメーションには、必要ならば代替テキスト(A.1 を見ること)や長文解説(A.2 を見ること)をつける。
  14. A.4.2. ムービーには、オリジナルのオーディオと同期した聴覚的説明をつける。
  15. A.5.1. マークアップやテキストからも情報が明確であるのでない限り色を使って情報を伝達しない
  16. A.5.2. 色盲の人が見たり白黒スクリーン上で見たりするときに充分なコントラストを提供する色の組み合わせを前景色と背景色との間で使う。
  17. A.7.2. 自動リロードページやタイミング応答ページには、(ユーザエージェントがこの能力を自身に提供するまでの間)リンクが選択されてしまった後にしかリフレッシュしないページのセカンドコピーをつける。
  18. A.7.3. フリッカーを起こすスクリーンの点滅や更新を避ける
  19. A.9.1. フレームを含むページにはバックアップページをつける(例. NOFRAME を使って)。
  20. A.9.2. 重大な情報や機能を表現するスクリプトには代替的な等価的表現物または機構をつける(例. NOSCRIPT を使うことにより)。
  21. A.9.3. スタイルシートを使うページについては、スタイルシートなしでも適切に読めるように各ページの内容が整理されたり構造化されていることを確認する。
  22. A.9.4. アプレット(OBJECT または APPLET を使って埋め込まれる)。最低でも
  23. A.11.1. イメージマップにはリンクの代替テキストをつける(A.1 をみること)。
  24. B.1.1. ユーザが名前でフレームを追跡できるようにフレームにタイトルをつける(FRAME の "title" アトリビュート経由)。
  25. C.1.2. もし最善を尽くしても非W3C技術やアクセス不能な方法でW3C技術を使うことを避けられないならば、次のような代替ページへのリンクを提供しなければならない。
    • W3C技術を使い、
    • アクセス可能で、
    • 同等の情報を有し、
    • アクセス不能な(オリジナルの)ページと同じ頻度で更新される。

    代替ページ制作のためのガイドラインと手法

優先度2
  1. A.1.5. イメージマップを使ってフォームの中にボタンのセットを作らない。代わりに(代替テキストがつけられた)別々に分かれたボタンや画像を使う
  2. A.4.3. 主オーディオトラックのテキスト表記(字幕)と対照されたテキスト版の聴覚的記述をつける。
  3. A.6.1. 見出しを適切にネストする (H1 - H6)。
  4. A.6.2. リスト構造やリスト項目を適切にエンコードする (UL, OL, DL, LI)。
  5. A.6.3. 引用は Q エレメントや BLOCKQUOTE エレメントでマークアップする。字下げなどのフォーマット効果のためにこれらのエレメントを使わない。
  6. A.6.4. 利用されている大多数のブラウザがスタイルシートをきちんとサポートするようになれば直ちに、レイアウトや表現を制御するためには、可能な限りどこででもスタイルシートを使う(A.9 を見ること)。それまでの間は単純なテーブル(レイアウトを制御するため)や代替テキストつきのビットマップテキスト(特殊なテキスト効果のため)を使ってもよいが、そのページ上の情報がアクセス可能であることを確保するために必要であれば代替ページを使うこと(C.1 を見ること)。
  7. A.6.5. 絶対的サイズ指定や位置指定(例. ピクセルやポイント)よりも相対的サイズ指定や位置指定(例. 百分率)を使う。
  8. A.7.1. 可能であるときは移動は避けるべきであるが、もし使わなければならない場合はユーザがアプレットやスクリプトの動きや更新を凍結できるようにする機構をつけるするか、スタイルシートやスクリプトを使って動きを作り出す(A.10 も見ること)。
  9. A.8.1. "lang" アトリビュートを使って明確にテキストの言語の変更を特定する
  10. A.8.2. 略語や頭字語には ABBR または ACRONYM に "title" アトリビュートをつけて展開を指定する。
  11. A.9.4.2. アプレットには、可能ならばアプレット以外のフォーマットで代替的機能や表現を提供する。たとえば、録画された物理実験の(Java で書かれた)MPEGムービーやgif画像として保存されているアニメーションのひとこまなど。
  12. A.10.1. 可能な限りどこでもアプレットを直接にアクセス可能にする。(A.9.4 も見ること)。
  13. A.12.3. ユーザがその発生に気づいているのでない限り、新しいウィンドウを開いたり、アクティブウィンドウを変更したり、ポップアップウィンドウを使わない
  14. A.12.4. すべてのラベルつきフォーム制御について、ラベルが かのいずれかであることを確認する。
  15. A.12.5. ユーザエージェントやスクリーンリーダーが並んで表示されているテキストを処理できるようになるまでの間、ワードラップされた平行の段組みにテキストをレイアウトするすべてのテーブルには、直線的な同等のテキストが(現在ページ上またはその他ページ上に)必須である。
  16. B.1.2. "longdesc" を(必要な場所で)使って(タイトルで与えられるよりも)完全な説明文をフレームに直接に結びつける。"longdesc" が広くサポートされるまではDリンクまたは不可視的Dリンクも使う。
  17. B.2.1. フォーム制御をグループ化する(FIELDSET や LEGEND エレメントを使う)。[優先度2(ラジオボタンやチェックボックスについて)~3(その他の制御について)]
  18. B.2.2. その制御にラベルを結びつける(LABEL とその "for" アトリビュートを使う)。
  19. B.2.3. 長い選択リストには階層構造を作成する(OPTGROUP を用いる)。
  20. B.3.2. 行や列の見出しを特定する (TD, TH).
  21. B.3.3. テーブルが行や列に示されているのを越えた構造的部分を有するところでは、構造的部分を特定するために適切なマークアップ(THEAD, TFOOT, TBODY, COLGROUP, "axis", "scope" アトリビュートなど)を使う。
  22. B.4. 可能な限りどこでも
    1. 2つ以上のリンクが同じテキスト文を共有していれば、それらのリンクすべてが同じリソースを指しているべきである
    2. 「ここをクリックしてください」といったようなそれ自体では意味のない文を避ける
    3. 文全体を含むリンク文を制作することを避ける。
  23. C.1.1.1. 可能である限りいつでも最新のW3C仕様を使う。
  24. C.1.1.2. 可能である限りいつでも廃止されたエレメントを避ける。
優先度3
  1. A.11.3. リンクやフォーム制御、オブジェクトを一貫して("tabindex" アトリビュート経由または論理的ページ設計を通して)論理的なタブ順序を作成する。
  2. A.11.4. リンク(クライアント側イメージマップの中にあるものを含む)やフォーム制御、フォーム制御のグループにキーボードショートカットをつける("accesskey" アトリビュート経由)。
  3. A.12.1. 編集ボックスやテキスト領域の中にデフォルトの場所確保キャラクタを組み込む。
  4. A.12.2. 連続的に発生するリンクの間に非リンクの印字可能キャラクタ(スペースで囲まれたもの)を組み込む。
  5. B.3.1. テーブルのまとめをつける(TABLE の "summary" アトリビュート経由で)。
  6. B.3.4. ヘッダラベルに略語表記をつける(TH の "abbr" アトリビュート経由で)。
  7. C.2.1. ページ間で一貫性のある表現スタイルを制作する。
  8. C.2.2. 明快で一貫性のあるナビゲーション構造を使う。
  9. C.2.3. ナビゲーション構造に簡単にアクセスできるようナビゲーションバーを提供する。
  10. C.2.4. サイトの全般的なレイアウト、使われているアクセス機能やその使い方についての説明文をつける
  11. C.2.5. サイトマップを提供する。
  12. C.2.6. 異なる技能水準や好みに応じた異なる型の検索を提供する。
  13. C.2.7. 見出しや段落、リストなどの最初に識別用の情報を置く。
  14. C.3.1. どれが文書の最初のページであるかを示したり、現在のページに続くページを示す(例。LINK を使う)。
  15. C.3.2. 文書を構成する全ページのバンドル版を作成する

どら猫本舗 (webmaster@doraneko.org)