ハンディがあっても利用できるページづくり

様々な環境に配慮して、どんなユーザーでも使いやすい方法で提供されている情報はアクセシビリティ (accessibility) が高いと言います。アクセシブルなコンテンツづくりとは、ウェブでのコミュニケーションに誰もが参加できるよう設計すること。情報の利用者であると同時に提供者でもある私たちは、常にこの点に配慮していきたいものです。

なぜアクセシビリティか

障碍のある人でも支障なく利用できる「バリアフリー」、誰にとっても使いやすく設計する「ユニバーサルデザイン」という考え方がさまざまな分野で重視されるようになってきました。ユニバーサルな情報共有のためには、ウェブ文書でもこの考え方はとても大切です。

しかしコンピュータの環境はまだまだ障碍のある方や高齢の方にとって使いやすいものとは言えません。むしろ、WindowsのようなGUIが全盛になって、かえってそういう配慮が置き去りにされたとも言えるでしょう。新聞報道にも示されるように、官公庁のウェブですら健常者のみを念頭に置いたページがたくさん作られてきたのです。

私たちも、病気やけがによって、いつ障碍を持つことになるかわかりません。もちろん、言うまでもなく誰もが年をとります。また車を運転しながら「目で読む」ことは危険極まりなく、騒音の中では「聞き取る」ことは困難です。誰でも、どんな環境でもアクセスできるページを提供するのは、特別なことではないと理解しましょう。

コミュニケーションとしてのアクセシビリティ:WCAG 2.1

私たちがウェブで情報を発信するのは、このメディアを通じて利用者(読者)とのコミュニケーションを図ろうとすることだと言っていいでしょう。このコミュニケーションが成立するためには、「ページ内に情報や機能があることを認識(認知)できる」→「必要な機能を操作したり他のページに移動したりして情報を利用できる」→「コンテンツの内容を理解する」という段階を経て、利用者に内容が伝わらなければなりません。

W3CWeb Accessibility Initiative (WAI)から2018年6月に勧告されたWeb Content Accessibility Guidelines 2.1WCAG2.1: ウェブコンテンツのアクセシビリティのための指針 2.1)は、この段階を踏まえた構成で、誰もが利用しやすいウェブコンテンツコンテンツを設計する指針を目指しています。「何のために」を考えながらアクセシビリティを検討するにはとても参考になるので、紹介しながらページづくりの基本を考えてみます。以下、1.4.の各項目はWCAG2.1の基本方針(principle)、1.1, 1.2...などは指針(guideline)に相当します。

(※細部の確認は2008年4月30日のWCAG 2.0勧告候補まで行なっています。その後、2008年12月のWCAG 2.0勧告および、2018年6月の同2.1勧告の内容も適宜反映させていますが、念のため最新の勧告を確認してください)

WCAG 2.0は2012年10月に国際標準ISO/IEC 40500:2012となりました。

1. コンテンツは認識可能であること

そもそも情報や操作機能が「そこにある」ということが分からなければ、コミュニケーションは始まりません。狭い意味での「アクセス可能性」をきちんと整えることが、全ての出発点です。

1.1 代替テキスト:全ての非テキスト内容に、代替となるテキストを用意し、拡大印刷、点字、音声合成、シンボルや簡略言語など他の形態に変換できるようにする
  • 非テキスト内容が情報やユーザへの応答である場合は、同じ目的を達成できる(それが困難なら、少なくともその目的を示す)代替テキストを用意します。
  • ボタンなどのコントロールや入力フィールドの場合は、その要素に目的を表す名前(label要素)を与えます。
  • 時間軸を持つメディア(音楽、映像など)あるいは感覚効果(specific sensory experience)をもたらすことを目的とする場合は、それが何であるかを説明するラベルを提供します。
  • 純粋な装飾や視覚フォーマットのためなら、補助技術がそれを正しく無視できるようにします(たとえばalt="")。
代表的なのは、img要素にalt属性で代替テキストを記述することです。これによって、画像を表示できない環境や見ることができない利用者でも、音声合成などの方法でその内容を認識できるようになります。当サイトの「img要素におけるalt属性について」も参照してください。
1.2 時間ベースメディア:時間軸を持つメディアには、代替内容を提供する
音声と同等内容のテキストを用意する、動画に音声トラックを付加する、主な会話や音楽にキャプションを付ける、同期マルチメディア(内容と同期したインタラクションがあるコンテンツ)ではやり取りも含めた代替テキストもしくは適切な代替メディアを提供する、など。マルチメディアコンテンツを作成する時に考えるべき点です。
1.3 適応性:情報内容(information)や構造(structure)を失うことなく、異なる表現(presentation)ができるようにする
内容と表現を分離しておくことで、その表現が困難な環境でも内容はきちんと伝えることができます。見出し要素リスト要素を適切に用い、表現はスタイルシートに委ねましょう。
  • 表現を通して提供される情報、構造や関係性は、プログラムによっても認識できること
  • 内容の順序が意味に関係するときは、その順序はプログラムによっても認識できること
  • 内容の理解や操作に必要な指示情報が、その要素の形、サイズ、視覚的な位置や方向、音声などの感覚的特徴に依存しないこと
  • 内容は特に必要がない限り縦横などその表示方向を一つに制約しないこと(WCAG 2.1での追加)
  • 利用者の情報を取得する入力フィールドはその目的がプログラムで判断できること(WCAG 2.1での追加)
  • マークアップ言語で実装される内容においては、利用者インターフェイス部品、アイコン、領域の目的がプログラムで判断できること(WCAG 2.1での追加)
1.4 識別性:前景(foreground)情報を区別できるようにするなど、障碍のある人が内容を見たり聞いたりしやすいようにする
情報の区別を色だけに依存しないようにしましょう。また、内容をはっきり認識できるようにするためには、文字と背景色のコントラストを明瞭にする、背景に画像やパターンを使うことを控えるなどの配慮が必要です。デザインだけにこだわって、背景色と文字色を同系統にしたりしないようにしましょう(背景「イメージ」に濃色系の画像を使って文字色を白にしているページは、画像を表示しないと全く読めないことに注意してください。この場合は、背景「色」も合わせて指定しておくべきです)。2005年11月の草案では、輝度比を用いたコントラスト評価の導入が検討されています。聴覚表現の場合は、意味のないBGMや音を使わない、あるいはこれらをOFFにできるようにすることが大切です。

2. コンテンツのインターフェイス要素は誰にでも操作可能であること

移動、入力などの機能は、存在を認識できるだけでなく、特別な装置に依存することなく操作可能でなければなりません。

2.1 キーボードアクセス:コンテンツの全機能を、キーボードで操作可能にする
キーボードによるインターフェイスは、視覚に障碍があっても操作可能ですし、音声入力デバイスでも(キーボードをシミュレートするので)利用できるようになります。全ての機能は、じっくり時間をかけても(without requiring specific timings for individual keystrokes)キーボードで操作できるようにします。また、入力フォーカスは、矢印キーやTABキーなどで移動可能にします。もちろん、これと合わせてマウスなどの別の操作インターフェイスを提供することは問題ありません。
また文字によるキーボード・ショートカットを実装している場合は、その機能を無効化する、割り当ての変更を可能にする、もしくはその利用者インターフェイス部品にフォーカスが当たっている時のみ有効になるようにします。(WCAG 2.1で追加)
2.2 十分な時間:コンテンツを読んだり操作をしたりするための時間を十分提供する
入力に時間制限があったり、勝手に次の画面に移動したり、リフレッシュしたりすると、環境や利用者によってはコンテンツが使えなくなってしまいます。自動的な動きが必要な場合は、利用者がその挙動を抑制もしくは変更できるようにするか、十分ゆとりを持って予告する、あるいはやり直すときにいったん入力したデータが失われないようにします。
2.3 発作:てんかん発作などを招くことが知られているようなコンテンツをつくらない
激しく明滅する画面は光過敏性てんかん発作の原因になることがあります。コンテンツが1秒に3回以上明滅する要素を含まないように求められています。また、このガイドラインでは触れられていませんが、点滅したり動いたりする情報は、煩わしいだけでなく、障碍のある人には読解不能だったりもします。どうしてもその効果が必要な場合は、あらかじめ警告し、ユーザーが解除できるようにします。
2.4 移動可能:利用者が移動し、コンテンツを見出し、それがどこにあるかを把握することを助ける手段を提供する
次のような基準が示されています。
  • 複数ページで繰り返し出現するブロックはスキップできるようにする
  • ページにタイトルを与え、リンクはその目的が分かるテキストをプログラムで利用できるように結びつける
  • ページ内を順次辿る場合は、その順序と関係を適切に反映した部分にフォーカスが移っていくようにする
  • 一連のコンテンツ内で、あるコンテンツ把握する手段を複数用意し、かつユーザ自身の現在位置を知るための情報を提供する
  • タイトル、見出し、ラベルは説明的なものにする
2.5 複数の入力方法:利用者がキーボードだけでなくさまざまな入力手段によって容易に機能を操作できるようにする
(WCAG 2.1での追加)次のような基準が示されています。
  • 複数ポイントもしくは経路を用いたジェスチャによる操作は、それが本質的に必要でない限り単一ポイントでの操作も可能にする
  • 単一ポイントでの操作はキャンセルを可能にする
  • 利用者インターフェイス部品がラベルを持つとき、その部品名は視覚的に表示されるラベルのテキストを含むようにする
  • 機器もしくは利用者の動きによって操作される機能は、利用者インターフェイス部品でも操作可能とし、動きに対する反応は解除可能にする
  • ポインター入力の操作対象は、それがテキストの一部であるなどの条件に当てはまる場合を除き、44 x 44ピクセル以上のサイズとする
  • 特に必要である場合を除き、操作環境で利用できる入力方法はその使用を妨げない

3. コンテンツの内容、および操作方法が理解可能であること

せっかくコンテンツにたどり着いてもらっても、内容や操作ボタンなどが理解しにくくてはコミュニケーションがうまく成立しません。いくつかの工夫で、理解しやすいコンテンツを提供することができます。

3.1 読解可能:テキスト内容は読むことができ、理解できるようにする
音声読み上げの正しい発音などのためにページ全体(および部分)の言語情報を示し、辞書に載っていないような専門用語や省略語は、その定義あるいはフルスペルを与えておきます。abbr要素dfn要素を活用し、必要に応じて用語集などにリンクすると良いでしょう。
3.2 予測可能:ウェブページの内容の現れ方と機能・動作は予測可能なものにする
予期せぬ内容や挙動は利用者を混乱させます。
  • フォーカスを与えたり入力しただけで(アクションを起こしていないのに)ページが遷移する、リンクをクリックすると別ウインドウが開くなど、突然コンテクストが変わってしまう設定は避けるべきです。
  • また、複数のページで用いられる要素は常に同じ相対順序になるようにする、同じ機能には同じ用語(ラベル)を用いるなど、一貫性を持たせます。
その他、リンク色が一般的な色と異なる、あるいはページによって違う、リンクに下線がない、ボタン状のオブジェクトをクリックしても反応しないなど、常識的に反応が予測できないインターフェイスを避け、できるだけ一般常識を尊重し、特殊な挙動は事前に予告したり、ユーザーがその機能を制御できるようにしてください。
3.3 入力補助:誤りを犯さないように、また訂正できるように利用者を助ける
利用者が間違いやエラーをおかしにくいような配慮と工夫を施します。
  • 入力エラーが生じた場合は、利用者に問題の所在と内容をテキストで提供します。
  • 入力を求めるときは、ラベルや指示を適切に与えます。
  • セキュリティやコンテンツ上の問題が生じない限り、できるだけうまく正常な状態に復帰できるようサポートしてください。例えば、選択肢を提供すればテキスト入力よりミスの可能性は減りますし、ミススペルに対して正しい綴りの候補を提供することもできます。
  • 法的、あるいは金銭的なやり取りが関係する、あるいはデータを変更したり削除するような重要なフォームは、操作を元に戻したり、エラーチェックを行ったり、最終的な送信の前に確認ができるようにすることも大切です。

4. コンテンツは、幅広いユーザエージェントで十分な信頼性をもって解釈できるよう、脆さがない(robust)ものであること

エージェントの技術は変化していきます。特殊な手段ではなく、標準的な技術を仕様に準拠してコンテンツを作成する方が、相互運用性が高く、将来にわたってアクセシブルなものとなります。独自のインターフェイスを採用する場合は、それがアクセシブルになるよう十分注意して設計する必要があります。

4.1 互換性:現在および将来の、支援技術を含むユーザエージェントと互換性が保てるようにする
たまたま自分が使っているブラウザで表示できるというだけではなく、将来登場するさまざまなものも含め、異なる環境でも通用するためには、標準に準拠したコンテンツづくりが基本です。
  • コンテンツは曖昧さなく解析(parse)できるようにします。開始タグと終了タグが正しくマッチすることが重要です(整形式XHTML!)
  • 全てのユーザインタフェイス要素について、名前と役割がプログラムに分かるようにします。また、状態、プロパティ、値の設定などユーザが行うことは、支援技術を含むプログラムにも実行できるようにします。

元祖ガイドライン:WCAG 1.0

1999年5月に勧告されたWeb Content Accessibility Guidelines 1.0は、14の指針と付随するチェックポイントで、主としてHTMLを用いたコンテンツのアクセシビリティ向上のための留意点を示します。今となっては必ずしも適切な指針とは言えないところもありますが、アクセシビリティといえばWCAG1.0だと思いこんでいる人も多いようなので、参考までに列挙しておきます。

WCAG 1.0の基本テーマ

  1. Ensuring Graceful Transformation; 環境に応じて適切に表現される「優しい」コンテンツ
  2. Making Content Understandable and Navigatable; 理解しやすく移動しやすいコンテンツ

14の指針

  1. 音声や画像コンテンツには、同じ意味を伝える代替手段を用意する
  2. 色に依存した表現をしない
  3. マークアップとスタイルシートを正しく使う
  4. 使用している自然言語を明示する
  5. テーブルは適切に表示・表現できるように記述する
  6. 最新技術をサポートしていなくてもきちんと表示・表現できる
  7. 動いたり、チカチカしたりするものをユーザーが制御できる
  8. アクセシビリティをきちんと持つ埋め込みオブジェクト
  9. 機種に依存しないデザイン:マウス以外にも、キーボードや音声によって操作できる
  10. 補助技術や古いブラウザが正しく動作するような解決策を用意する
  11. W3Cの技術と指針を利用する
  12. 文脈や文書の流れを理解するための情報を提供する
  13. 明解なナビゲーションの機能を提供する
  14. 簡潔明瞭な文書にする

WCAG1.0はHTML4のアクセシビリティ関連機能がブラウザに組み込まれることを期待していたところがあるため、一部のチェックポイントが実情に合わなくなっていることは否めません。特に優先度3のチェックポイントの中には、(WAIのメイ氏も言ってましたが)無理に適用しようとすると、ページやサイトの全体設計を損ないかねないものもあります。

ガイドラインに書かれているから、チェックツールで警告されたからといって、無闇に機能を追加するのではなく、何のためにその機能が必要なのかを考えて採用するようにしましょう。大切なのは、AAAのロゴを表示したり、チェッカーで高得点を上げることではなく、できるだけ多くの利用者とコミュニケーションを実現させることなのです。

アクセシビリティのJIS規格(2004年初出時の情報)

2004年6月20日に、ウェブのアクセシビリティ指針を記した日本工業規格「JIS X 8341-3 高齢者・障害者等配慮設計指針 - 情報通信における機器、ソフトウェア及びサービス - 第3部:ウェブコンテンツ」が制定されました。内容はWCAG 1.0に近いものですが、対象をHTMLに限定せず、また内容も「構造及び表示スタイル」「操作及び入力」といった項目に整理されているので、応用範囲が広いと言えます。

2010年8月には、WCAG 2.0を踏まえた改正JIS X 8341-3:2010が発行され、2016年3月にはさらにJIS X 8341-3:2016に改定されています。

一般的原則

「4.一般的原則」のセクションでは、(1)基本方針として高齢者や障害者への配慮、多様な機器やディスプレイ、ブラウザで利用できること、これらを企画から運用に至るプロセス全体で常に考慮することを求め、(2)基本的要件として、視覚、聴覚、身体のハンディにかかわらずコンテンツを操作・利用できることをあげ、(3)推奨要件として、認知及び記憶に過度な負担をかけない、多様な環境で利用できる、操作に不慣れな利用者でも使える、ということを掲げています。

開発及び制作に関する個別要件

技術的なガイドラインは「5. 開発及び制作に関する個別要件」のセクションで定義されています。各要件には参考や例が添えられ、具体的にどうやって適用すべきかが示されていますが、ここでは要件のみを列挙してみます。

5.1 規格及び仕様

  1. ウェブコンテンツは、関連する技術の規格及び仕様に則り、かつそれらの文法に従って制作しなければならない。
  2. ウェブコンテンツには、アクセス可能なオブジェクトなどの技術を使うことが望ましい。

5.2 構造及び表示スタイル

  1. ウェブコンテンツは、見出し、段落、リストなどの要素を用いて文書の構造を規定しなければならない。
  2. ウェブコンテンツの表示スタイルは、文書の構造と分離して、書体、サイズ、色、行間、廃液色などをスタイルシートを用いて記述することが望ましい。ただし、利用者がスタイルシートを利用できない場合、又は意図的に使用しないときにおいても、ウェブコンテンツの閲覧及び理解に支障が生じてはならない。
  3. 表は、分かりやすい表題を明示し、できる限り単純な構造にして、適切なマーク付けによってその構造を明示しなければならない。
  4. 表組みの要素をレイアウトのために使わないことが望ましい。
  5. ページのタイトルには、利用者がページの内容を識別できる名称を付けなければならない。
  6. フレームは、必要以上に用いないことが望ましい。使用するときは、各フレームの役割が明確になるように配慮しなければならない。閲覧しているページがウェブサイトの構造のどこに位置しているか把握できるように、階層などの構造を示した情報を提供することが望ましい。

5.3 操作及び入力

  1. ウェブコンテンツは、特定の単一デバイスによる操作に依存せず、少なくともキーボードによって全ての操作が可能でなければならない。
  2. 入力欄を使用する時は、何を入力すればよいかを理解しやすく示し、操作しやすいように配慮しなければならない。
  3. 入力に時間制限を設けないことが望ましい。制限時間があるときは事前に知らせなければならない。
  4. 制限時間があるときは、利用者によって時間制限を延長又は解除できることが望ましい。これができないときは、代替手段を用意しなければならない。
  5. 利用者の意志に反して、又は利用者が認識若しくは予期することが困難な形で、ページの全部若しくは一部を自動的に更新したり、別のページに移動したり、又は新しいページを開いたりしてはならない。
  6. ウェブサイト内に置いては、位置、表示スタイル及び表記に一貫性のある基本操作部分を提供することが望ましい。
  7. ハイパリンク及びボタンは、識別しやすく、操作しやすくすることが望ましい。
  8. 共通に使われるナビゲーションなどのためのハイパリンク及びメニューは、読み飛ばせるようにすることが望ましい。
  9. 利用者がウェブコンテンツにおいて誤った操作をした時でも、もとの状態に戻すことができる手段を提供しなければならない。

5.4 非テキスト情報

  1. 画像には、利用者が画像の内容を的確に理解できるようにテキストなどの代替情報を提供しなければならない。
  2. ハイパリンク画像には、ハイパリンク先の内容が予測できるテキストなどの代替情報を提供しなければならない。
  3. ウェブコンテンツの内容を理解・操作するのに必要な音声情報には、聴覚を用いなくても理解できるテキストなどの代替情報を提供しなければならない。
  4. 動画など時間によって変化する非テキスト情報には、字幕又は状況説明などの手段によって、同期した代替情報を提供することが望ましい。同期して代替情報が提供できない場合には、内容についての説明を何らかの形で提供しなければならない。
  5. アクセス可能ではないオブジェクト、プログラムなどには、利用者がその内容を的確に理解し操作できるようにテキストなどの代替情報を提供しなければならない。また、アクセス可能なオブジェクト又はプログラムに対しても、内容を説明するテキストなどを提供することが望ましい。

5.5 色及び形

  1. ウェブコンテンツの内容を理解・操作するのに必要な情報は、色だけに依存して提供してはならない。
  2. ウェブコンテンツの内容を理解・操作するのに必要な情報は、形又は位置だけに依存して提供してはならない。
  3. 画像などの背景色と前景色とには、十分なコントラストを取り、識別しやすい配色にすることが望ましい。

5.6 文字

  1. 文字のサイズ及びフォントは、必要に応じ利用者が変更できるようにしなくてはならない。
  2. フォントを指定する時は、サイズ及び書体を考慮し読みやすいフォントを指定することが望ましい。
  3. フォントの色には、背景色などを考慮し見やすい色を指定することが望ましい。

5.7 音

  1. 自動的に音を再生しないことが望ましい。自動的に再生する場合には、再生していることを明示しなければならない。
  2. 音は、利用者が出力を制御できることが望ましい。

5.8 速度

  1. 変化又は移動する画像又はテキストは、その速度、色彩・輝度の変化などに注意して作成することが望ましい。
  2. 早い周期での画面の点滅を避けなければならない。

5.9 言語

  1. 言語が指定できるときは、自然言語に対応した言語コードを記述しなければならない。
  2. 日本語のページでは、想定する利用者にとって理解しづらいと考えられる外国語は、多用しないことが望ましい。使用するときは、初めて記載する時に解説しなければならない。
  3. 省略語、専門用語、流行語、俗語などの想定する利用者にとって理解しにくいと考えられる用語は、多用しないことが望ましい。使用するときは、初めて記載されるときに定義しなければならない。
  4. 想定する利用者にとって、読みの難しいと考えられる言葉(固有名詞など)は、多用しないことが望ましい。使用するときは、初めて記載されるときに読みを明示しなければならない。
  5. 表現のために単語の途中にスペース又は改行を入れてはならない。
  6. ウェブコンテンツは、文章だけではなく、分かりやすい図記号、イラストレーション、音声などを合わせて用いることが望ましい。

全体的要件

「6. 情報アクセシビリティの確保・向上に関する全体的要件」のセクションでは、企画・制作、保守及び運用、検証、フィードバック、サポートという観点からウェブコンテンツの情報アクセシビリティを確保するような仕組みを求めています。

共通規格と規格票の入手

情報アクセシビリティJIS X 8341には、この「第三部:ウェブコンテンツ」のほかに、先に発表された「第一部:共通指針」(X 8341-1)と「第二部:情報処理装置」(X 8341-2)という規格があります。「共通指針」にはより一般的な形で考え方や機能、技術的要件が示されていますが、これを併読すると、小手先の技術ではなく、本質的に何を念頭に置くべきなのかがよく分かります。たとえば、その「4.3.1 操作に関し配慮すべき要件」の項目を一部抜粋してみると、次のような具合です:

  1. 操作前の準備作業に関する要件
  2. 操作中の作業に関する要件
    1. 提示情報の入手のしやすさ
    2. 分かりやすさ
    3. 一貫性
    4. 代替手段の可能性
    5. 個人への適応性(カスタマイズ)
    6. 分かりやすい手順及び復帰の可能性
    7. (以下略)
  3. 操作後の終了作業に関する要件
    1. (略)

このような形で要件が示されていると、WCAG 2.0の場合と同じく、「何のために」を考えながらアクセシビリティを検討することができます。また、「第二部:情報処理装置」の附属書1には、高齢者・障碍者が遭遇する問題点が解説されており、やはり利用者の立場に立った設計のための参考になります。

規格票は日本規格協会から購入することになりますが、日本工業標準調査会でPDFを閲覧することは可能です(印刷はできません)。

JISの改定:X 8341-3:2010と2016

2010年8月には、JIS X 8341-3:2004がWCAG 2.0を踏まえて改正され、JIS X 8341-3:2010が発行されました。

箇条6「ウェブアクセシビリティの確保・向上に関する要件」において、企画、設計、制作・開発、検証、保守・運用という切り口で、開発プロセス全体で実施しなければならない全般的要件を定めた上で、箇条7「ウェブコンテンツに関する要件」において、4つの基本方針に対応する「7.1 知覚可能に関する原則」「7.2 操作可能に関する原則」「7.3 理解可能に関する原則」「7.4 頑健性に関する原則」という原則が示されます。また「8. 試験方法」においては、達成基準を満たしているかどうかを客観的に検証するための方法が示されます。

2016年3月にはさらにJIS X 8341-3:2016に改定されています。訳語を一部改めた他、ISO/IEC 40500:2012一致規格となるよう、JIS独自の要求事項は附属書(参考)に分離されました。

当サイトのアクセシビリティ関連情報

いろいろな配慮を求められても、それが実際、例えば音声ブラウザなどでどう反映されるかがわからないと、使いにくいことも確かですね。新しい音声ブラウザは、いろいろな付加情報を提供できるようになってきています。

当サイトでは、主としてIBMホームページリーダーで確認した結果をもとに、いくつかのページ(の一部)で関連情報を紹介しています。

音声ブラウザと見出し
音声ブラウザには見出し読みモードがあるほか、「現在位置を確認」とすることで直前の見出し内容をチェックできます。また、見出しを読み上げるときはチャイムを鳴らしたり、ゆっくり読み上げたりします。
テーブルとアクセシビリティ
テーブルの見出し項目をth要素できちんとマークアップすると、個々のセルの情報として対応する見出しを読み上げさせることができます。scope属性、headers属性、summary属性も有益です。
title属性について
「ステータスバーの状況と現在の日時を確認する」という機能で、title属性の内容を読み上げさせることができます。
日付の表記に関するノート
01/08/02というスタイルの日付は、文脈や文化的背景によって解釈が違う上に、音声ブラウザでは分数として読み上げられてしまいます。2001-08-02というW3C-DTFの書式を用いることで、データとして処理しやすく、かつ理解しやすい日付とすることができます。
色の組み合わせチェック
文字色と背景色のコントラストが確保できているかどうかを客観的にチェックするため、色の明るさの差などを計算する仕組みを用意しました。色覚の違いのシミュレーションも合わせて行います。ブックマークレットも作ってみました。

2005年時点での音声ブラウザの読み上げ機能については、日本の視覚障害者用ウェブ利用ソフトの機能調査において詳しくレポートされています。

参考になったリソース

アクセシビリティに関する情報を提供するサイトは増えてきましたが、このページ公開当時に参照したものや、最近お世話になった人/組織を中心に、不完全なリストを黎明期の記録として(消滅したものはWayback Machineへのリンクを用いて)掲載しておきます。

このリストの中での定番:

比較的最近(2003~2004年頃)ご縁があったところ:

個人の情報提供の中にも、古くから優れたものがありました:

チェックツールの老舗:

手探りしてきた記録として:

拙著『ユニバーサルHTML/XHTML』でも、第14章「利用者の立場で考える」を中心に、アクセシビリティやユニバーサルな情報発信について記述しています。