Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0 を適当に解釈して適当に書いたものです。翻訳ではありません。独自の解釈によって原文と全く違う表現になっていたり原文にはありもしない注釈が加えられています。あたりまえですが W3C や WAI 公認のリソースではありません。
img要素に適切な alt 属性がないと画像が表示できない環境で読まれるべきものが読めなかったり、余計なもの([INLINE]という文字列とか)が読めてしまったりすることがあります。適切な alt 属性が指定されているかどうか確認します。area要素にも alt 属性が必須です。
他にも、object, iframeなどが再現できない環境があります。これらは alt属性ではなく、要素の中身に代替テキストを書きます。frameset要素には適切な内容の noframes要素を用意します。間違っても「フレームに対応していないブラウザの奴は帰れ」などと書かないようにしましょう。各フレームへのリンクを配するのが一般的です。
たとえば「項目名が赤になっているものは入力必須です」などと書いてあったとしましょう。色が再現できない環境だと、どれが「赤」なのか分からず、必須項目とそうでない項目が見分けられません。
情報は色に依存せずに伝わるようにしておきます。
文中で言語が変わったとき、それが明示されていないと、音声読み上げの環境でうまく読み上げできないことがあります。たとえば、英語の文章の中にフランス語が引用されていると、フランス語の単語を英語の発音で読んでしまうおそれがあります。
当然ですがスタイルシートオフでも問題なく読めなくてはいけません。スタイルシートがオフだとリンクがフレームの外にはみ出してクリックできない、などというページが実際にあります。そういったことのないようにします。
いわゆるロールオーバー効果によって画像が別のものに変化する、という仕組みは割と良くあると思います。その画像がたとえば文字で、それがまったく別の文字に変化するものだとしましょう。
変化後の文字は画像が表示できない環境でも読めるでしょうか？
スクリプトを工夫するなどして、変化後にも代替テキストが読めるようにします。難しいかもしれませんが。
勝手に文字がチカチカしたり動いたりすると読みにくいものです。ユーザをいらだたせるのはもちろんのこと、視力(動体視力？)の弱い人にはまったく読めないかもしれません。
どうしても点滅させたい場合は、ユーザの操作で初めて点滅を開始するようにしたり、ユーザの操作で点滅を停止できるようにします。
たとえば、アンカーに使う言葉が明快でなければユーザは混乱する可能性があります。特にアンカー部分だけを抽出して利用している場合もあるので、文脈に依存する表現、たとえば「ここをクリック」は避けて、代わりに「サイトツアー」などの分かりやすい語を使います。
また、各段落に適切な見出しをつける、俗語・業界用語の使用を避けるなど、文章自体に配慮すると、文章はより多くの人にとって読みやすいものになります。
画像が表示できない環境では、サーバ側イメージマップは利用できません。area要素の alt属性に相当するような代替手段もありません。そのため、サーバ側イメージマップを使っているなら、a要素によるリンクも別途用意しておく必要があります。
繰り返しになりますが、画像が表示できない環境ではサーバ側イメージマップは利用できません。ですから極力サーバ側イメージマップは避け、代わりにクライアント側のイメージマップを使うようにします。
サーバ側イメージマップを使うのは、クライアント側イメージマップでは表現できないものを表現したい場合のみとします。
HTML4.01 のクライアント側イメージマップで表現できるのは円、四角、多角形のみなので、複雑な形状を表現するにはサーバ側イメージマップを使わざるを得ないかもしれません。その場合は前述のように代替となるリンクを用意します。
見出しセルは th要素、データセルは td要素ときちんと使い分けして、scope 属性や colgroup, thead, tfoot などを駆使して構造をはっきりさせます。
ひとつのデータが二つも三つものカテゴリに属していて、一つのデータセルにいくつもの見出しセルが関連付けられるような複雑な表は、音声読み上げの環境で表現するのに難儀します。axis や headers 属性をうまくつかってその関連をマーク付けしてあると、うまく表現できることがあります。
frame要素に title属性をつけて、それぞれのフレームにタイトルをつけます。こうすることで、音声読み上げの環境などで利用する際に各フレームが識別しやすくなります。
JavaScript や JavaApplet, 各種プラグインなどが利用できない環境でも問題なく利用できるようにします。
どうしても無理な場合は、それらの技術を使わないで同等の情報を記した別ページを用意して、そちらに誘導します。
今のところ、ムービー内に現れる字幕などのテキストを読み上げる技術は確立していません。重要な情報は音声でも得られるようにすると、視覚に障碍のある人がアクセスしやすくなります。
たとえば、ナレーションが画面とずれないようにします。
どうしてもアクセシブルなページを作れない場合は、同じ情報や機能を持った別ページを用意し、そこに誘導します。
文字色と背景色が近い色だと、文字が背景に溶け込んで読みにくくなります。色数の少ない環境では近似色は同色になってしまいますし、赤と緑など、特定の色の見分けがつきにくい人もいます。そういった環境にも考慮して十分なコントラストを持たせましょう。
テキストならば、色指定をオフにすることで強引に読むこともできますが、画像の場合はそうも行きませんので、よりいっそう注意が必要です。
たとえば複雑な数式を表すのに、数式全体をひとつの画像にするよりも、MathML を使って表現した方が良いでしょう。
……という話なのですが、本当に MathML でどうにかなるのかは疑問です。
たとえば HTML4.01 の Strict DTD に従うとか、なにか公開されたものに従って文書を作りましょう。きちんと文書型宣言もつけましょう。
文書は論理的にマークアップし、見栄えはスタイルシートで定義するようにします。こうすることで、たとえば、特定の人に読みにくいようなスタイルを切り離して別のスタイルを再定義することが簡単にできるなど、さまざまなメリットがあります。
pt とか cm を避けて、% や em を使います。こうしないと、ユーザは自由に文字サイズを変更できなくなり、自分の読める大きさ文字を調節することができないことがあります。
h1, h2 などの見出し要素を適切に使うことで、文書の構造が明確になります。いきなり h2 が出てきたり、h3 なしに h4 が出てきたりすることのないようにします。
リストは単なる段落の列挙や pre要素で表現するのではなく、ol要素、ul要素、dl要素などとしてマーク付けします。
引用部は blockquote要素や q要素としてマーク付けします。また、blockquote要素はインデントの道具ではありません。
クライアント側のスクリプトなど、オフであっても内容にアクセスできるようにします。それができないなら代替文書を用意しましょう。
フレームについても同様です。
点滅する文字は読みにくいものです。文字の点滅をユーザの手で止められないブラウザがあるので、点滅する文字は避けましょう。
meta http-equiv=refresh などを使った自動更新は、読み終わらないうちにページが消えてしまったり、ウィンドウを非アクティブにしている間にどんどん進んでしまったり、意図しないのに移動してしまったりと、ユーザにとってさまざまな不利益があります。
自動更新するページは避けましょう。
meta http-equiv=refresh や JavaScript を使ったクライアント側のリダイレクトもユーザを混乱させたり、ブラウザの「戻る」機能を無効にしたりと、さまざまな弊害をもたらします。
リダイレクトはサーバ側で 302 などを発行して行いましょう。
ポップアップウィンドウや別ウィンドウもユーザを混乱させたり、余計なコンピュータ資源を使ったりするので嫌われます。できれば避けましょう。
最新のものはよりアクセシビリティに配慮されている……はずです。
お勧めできないものがお勧めできないのは、それなりの理由があるからです。
文書には h1, h2 などの見出し要素をつけて整理します。フォーム要素についても、fieldset 要素や optgroup要素をうまく使ってグループ化するとアクセスしやすくなることがあります。
a要素のアンカーに「ここをクリック」とだけ書いてあっても、リンク先が何なのかさっぱり分かりません。リンク先がどんなものなのか分かるように、適切な言葉をアンカーにし、必要ならば適切なキャプションをつけましょう。
meta要素をうまく使ってデータを提供しましょう。link要素が役立つこともあります。
目次やサイトマップを作って活用しましょう。
たとえば、ナビゲーションバーの構造がページごとに違っていると、ユーザは混乱します。一定したナビゲーションを提供しましょう。
原則として表をレイアウト目的に使うべきではありませんが、レイアウト目的で表を使う際には、頭からだらだらと読んでも意味が通じるようにすべきです。頭から読んで意味が通じないような場合には、別途代替文書を設けて誘導しましょう。
たとえば th要素を「太字、センタリング」という見栄えのために使うべきではありません。
各フレームには title 属性で簡単な説明を書きますが、それでもフレームの構造がはっきりしないようであれば、longdesc属性を使って説明を書きます。
ラベルの配置がまずいと、どのラベルがどのコントロールに対応しているのか分からなくなる恐れがあります。
ラベルはコントロールの近く、同じ行に置くと良いでしょう。
配置だけでなく、label要素の for属性を使ってマーク付けでも明確に関連付けましょう。
たとえば、onclick というイベントハンドラは、マウスクリックに反応しますがキーボード操作には反応しません。onkeypress も一緒に使えばキーボードでも操作できるようになります。
文字などが動く場合、それをユーザの操作で止められるように設計します。
JavaScript, JavaApplet などで作られるインターフェイスに関しても、キーボード操作できる、動きが止められるなどなど、さまざまな観点でアクセシブルに設計しましょう。
Flash などについてもデバイスに依存しないように作りましょう。
たとえば、フォームを submit した瞬間に動作するスクリプトを使うならば、submitボタンに onclick 属性を指定するよりも、form要素に onsubmit属性を指定した方が良いでしょう。onfocus, onblur, onchange などのデバイスに依存しないハンドラを積極的に使いましょう。
略語には abbr や acronym要素と title属性を使うと、音声読み上げの助けとなったり、他の環境でも理解しやすくなることがあります。XHTML1.1 ならば、ruby要素を使うことで分かりやすくなることもあるでしょう。
文書がどの言語でかかれているかはっきりさせておくと、音声読み上げの環境などで役に立つことがあります。言語によって発音が違うことがありえるからです。html要素に lang 属性もしくは xml:lang属性を指定しておくと良いでしょう。
時には複数の言語が混じっていることもあるでしょうが、その場合も主となる言語を明示しておきます。
普通、タブ移動順序はソース内での出現順になります。通常はそれで問題ありませんが、たとえば CSSでポジショニングをしていたり、フォーム内にヘルプメッセージへのリンクがあったりすると、直感的なタブ移動順序が実際のタブ移動順序と食い違ってしまうことがあります。そうなると操作しづらいですし、混乱や操作ミスをまねく原因にもなります。
そんな場合は tabindex属性を適宜指定して、ユーザに分かりやすいようなタブ移動順を設定すると良いでしょう。
重要なリンクには、accesskey属性でショートカットキーが指定してあると便利かもしれません。またフォーム入力の際も、コントロールにアクセスキーが指定してあると便利です。特に携帯電話のようなポインタ移動がしづらいデバイスでは助かります。
注意すべきなのは、アクセスキーがブラウザの機能に割り当てられている場合があることです。たとえば IE5 では Alt+F は「ファイル」メニューに割り当てられているのですが、accesskey="F" を指定すると競合し、IE の機能のほうが使えなくなってしまいます。
また、アクセスキーが指定してあってもその旨を表示などに反映させないブラウザがほとんどなので、文中にキーを明示する必要があります。
複数のアンカー同士が隙間なくぴったり隣り合っていると、何処から何処までがどのアンカーなのか分からなくなります(というか、全体で一つのアンカーに見えてしまいます)。アンカーになっていない文字を何かはさんで、アンカー同士がくっつかないようにしましょう。
コンテント・ネゴシエーションをうまく活用すると、ユーザは自分にあった言語や文字符号化方式の文書を受け取ることができます。
スタイルシートに関しても、@media などをうまく使えば、それぞれのユーザ環境に適したスタイルを提供できます。うまく活用しましょう。
ナビゲーションバーを提供しましょう。
各ページの頭にあるナビゲーションバーは、音声読み上げの環境や、きわめて狭い画面では逆に鬱陶しいと感じられることがあります。スキップするためのリンクを作る、ユーザスタイルシートなどで非表示にできるようにグループ化してマーク付けしておくなどの工夫があると、これらの環境でも快適にアクセスできる可能性があります。
たとえば、検索エンジンにスペルチェック・補正機能があると、文字入力が苦手な人がミスタイプしても割と問題なく検索できるようになります。キーワード型の検索のほかにディレクトリ型の検索を用意しておく、というのも一つの方法です。
音読や速読の際、必要な情報にすばやくアクセスするためには読み飛ばしが重要になってきます。各段落の最初に「この段落では何を言っているのか」が分かるような文章があると、その段落を読む必要があるかどうかすぐに分かるので、必要ないものはさっさと読み飛ばして次に進むことができます。
あるサイトが複数の文書で構成されている場合、その文書群についての情報を提供するとアクセスしやすくなる場合があります。たとえば、link rel=index や link rel=next などの情報はブラウズを助けます。
また、サイト全体をアーカイブとして提供することがアクセスを助けることもあります。
読み上げ環境ではスキップしたいでしょうから。
テキストを添えることで、内容が理解しやすくなります。
一定のスタイル(配色、レイアウトなど)になっていると、何が何処にあるかユーザはすぐに学習でき、迷いにくくなります。
画像が表示できない環境のために area には alt属性を指定できるのですが、それを認識しないブラウザがあるので、イメージマップを使う場合はテキストのリンクも用意しておいたほうが良いでしょう。
table には summary属性を指定しましょう。
summary の書き方にはいろいろと宗教的な議論もありますが、とりあえずWCAG 1.0 techs 5.1.1 Providing summary informationから引用しておきます。
Provide a summary via the "summary" attribute. Summaries are especially useful for non-visual readers. A summary of the relationships among cells is especially important for tables with nested headings, cells that span multiple columns or rows, or other relationships that may not be obvious from analyzing the structure of the table but that may be apparent in a visual rendering of the table. A summary may also describe how the table fits into the context of the current document. If no caption is provided, it is even more critical to provide a summary. Two examples:
"This table charts the number of cups of coffee consumed by each senator, the type of coffee (decaf or regular), and whether taken with sugar."
"Total required by pollution control standards as of January 1, 1971. Commercial category includes stores, insurance companies and banks. The table is divided into two columns. The left-hand column is 'Total investment required in billions of dollars'. The right--hand column is 'Spending' and is divided into three sub-columns. The first sub-column is titled '1970 actual in millions of dollars', the second is '1971 planned in millions of dollars', and the third is 'Percent change, 1970 versus 1971.' The rows are industries." [NBA, 1996].
単に「表です」と言われても何の助けにもなりません。何処にあるセルがどういったものなのかを説明しておくと良いでしょう。また、レイアウト用の表に関しては(そもそもレイアウトに表を使うべきではありませんが)、summary="" を明示的に指定して、余計な summary を読み上げられないようにすると良いでしょう。
読み上げ環境では、表は「見出しセル、1列目のデータ、見出しセル、2列目のデータ……」という具合に、同じ見出しセルが何度も読み上げられる可能性があります。見出しセルの内容が長いと、これは苦痛です。abbr属性で略を定義すると、2度目からはその略が読み上げられることが期待できます。
見出しセルの内容が長いときには指定しましょう。
レイアウト用に表を利用していて、語が複数のセルにまたがっていたり、ソース上の順序が見た目の順序と異なるような場合、それを意味が通るように読み上げるのは非常に困難です。そんな場合は、レイアウトされない一直線のテキストを別途用意しておいてそちらに誘導すると、読み上げに助かります。
空のテキスト入力欄やテキストエリアがあると、うまく動作しないブラウザがあるようです。