アクセシビリティ教室
ソシオメディア株式会社
Web コンテンツのアクセシビリティ
6 月 20 日に Web コンテンツのアクセシビリティが、JIS （日本工業規格）化されようとしている。最近では"アクセシビリティ"という言葉を見聞きする機会が増えてきた。Google で"アクセシビリティ"で検索してみると、実にいろいろなサイトが出てきて、最近では個人の blog サイトなども増えてきている。
アクセシビリティというと、障害者への配慮だと考えている人が多い。もちろん間違いではないが、日本でアクセシビリティを考える場合には、それ以外にも高齢者層のユーザーへの配慮も考えなくてはならない。6 月 20 日に公示される JIS の正式名称も、JIS X8341-3 『高齢者・障害者等配慮設計指針－情報機器における機器・ソフトウェア・サービス－第三部：ウェブコンテンツ』となっている。
さらには、ユーザーは PC で Web コンテンツを利用しているとは限らない。PDA や携帯電話といったモバイル系端末をはじめ、家電にもブラウザが実装され始めるなど、ユーザーが Web コンテンツを利用する環境はますます多様化していく傾向にある。昨年公開レビューが行われた JIS 素案ではこういった様々なユーザーの環境への配慮も盛り込まれていた。
今回の連載では、まずアクセシビリティの基本として Web コンテンツを制作する際に頭に入れておくべきポイントに焦点を絞って解説していこうと思う。
多様なユーザーの利用特性
ユーザーはどのように Web コンテンツを利用しているのだろうか？
- 画面を見る
- マウスで操作する
- キーボードで入力する
- 音声を聞く
真っ先に思い浮かぶのはこういうことだろう。しかし、全てのユーザーがこのように利用しているわけではない。そのことを理解するのが、アクセシビリティを考える最初の一歩となる。
例えば、視覚障害には、大きく分けて全盲、弱視、色覚特性の 3 つがあり、前述の"音声を聞く"以外のところで以下のような利用特性がある。まず、全盲のユーザーの場合はこうだ。
- 音声ブラウザやスクリーンリーダーで読み上げて、画面の情報を音声で聞く
- 点字ピンディスプレイを使うこともある
- マウスを操作することはできない
- 操作・入力をキーボードのみで行う
次に弱視（ロービジョン）のユーザーの場合。
- 画面を拡大していることが多い
- 白黒反転させていることもある
- 音声ブラウザやスクリーンリーダーを併用している場合もある
- ほとんどの操作／入力をキーボードで行う
- マウスを使う場合は、マウスカーソルを拡大していることが多い
そして、色覚に特性のあるユーザーの場合。
- 画面を見るが、特定の色が識別できない
- マウスとキーボードの両方を使う
というような特性がある。
ユーザーが、"画面を見る"、"マウスで操作する"ということを前提に Web コンテンツを制作していては問題が起こりうることがお分かりいただけるだろう。
さらに、聴覚障害の場合は、前述の"音声を聞く"ことができないか、できても聞こえにくいという特性がある。肢体不自由で手や指先がフルに使えない場合は、以下のような特性があることを頭に入れておいてほしい。
- 程度によってはマウスが使える
（ただし、特殊な補助装置を使用したりするので、細かなマウスカーソルの操作はできない） - 特殊な入力装置を使うことが多い
（仕組みとして、普通のキーボードで操作可能であればこれらでも操作が可能だと考えてよい）
高齢者の場合には、加齢とともに身体機能が衰えてくるので、"画面を見る"、"マウスで操作する"、"音声を聞く"というところに困難が生じてくるようになる。これらの点は、前述の各障害に配慮していれば概ね大丈夫だと考えてよいだろう。ただし、高齢者特有の特性として、外国語や難しい言葉を理解しにくかったり、操作方法を覚えにくかったり、といったものがあるので分かりやすさへの配慮が必要だ。
JIS 化のインパクト
このような多様な利用特性を理解することがまず最初の一歩であり、次の一歩はこのことをふまえて Web コンテンツを制作していくことだ。特に今回の JIS 化により、国および自治体はもちろんのこと、公共的な性格を有する民間企業の Web コンテンツは、真っ先にこうした視点からの制作が求められるようになるのは明らかだ。ブロードバンド化が進むにつれ、動きを伴った一見派手なコンテンツへと注目が集まりがちだが、仮にユーザーが画面を見ることやマウスを操作することなどが出来なくても、音声読み上げやキーボードだけでも操作することが出来れば、より多くのユーザーがその Web コンテンツを利用することができる。企業サイトならより多くのビジネスチャンスにもつながるだろう。そう考えれば、これだって"リッチな" Web コンテンツといえるのではないだろうか。
では、具体的にどのような点に注意すればよいのか。アクセシビリティの場合は、そのポイントがガイドラインで示されている。次回以降、JIS X8341-3 で示されているポイントから基礎的な部分について、4 回に分けてご紹介していこうと思う。
画像の代替テキスト
Web アクセシビリティでよく話題に上がるのが、画像の代替テキストだ。まだアクセシビリティについて詳しくない人でも、画像の img 要素に alt 属性で代替テキストを記述しなくてはならないことは多くの人が知っているだろう。しかし、きちんと記述されていないサイトがまだまだ多い。
JIS X8341-3 『高齢者・障害者等配慮設計指針－情報機器における機器・ソフトウェア・サービス－第三部：ウェブコンテンツ』でも、5.4 非テキスト情報の a) で "" 画像には、利用者が画像の内容を的確に理解できるようにテキストなどの代替情報を提供しなければならない。"、b) で"ハイパリンク画像には、ハイパリンク先の内容が予測できるテキストなどの代替情報を提供しなければならない。"と規定されている。
まず、なぜ画像に代替テキストが必要なのかを確認しておこう。
- 音声ブラウザやスクリーンリーダーは画像を読み上げることができない
- テキストブラウザは画像を表示することができない
- モバイル接続している際に画像を非表示にしているユーザーもいる
代替テキストは、こういった場合に必要となるのだ。音声ブラウザやスクリーンリーダーは画像のかわりに代替テキストを読み上げ、画像を表示できないブラウザは画像の代わりに代替テキストを画面に表示するのだ。そのために代替テキストを記述するということを頭に入れて、どのような代替テキストを記述すればよいかを考えていこう。
代替テキストの記述方法
では、どのように代替テキストを記述すればよいのだろうか。その方法はいたって簡単である。画像を指定する img 要素に alt 属性をつけて、alt 属性の値として代替テキストを記述すればよい。
<img src="images/image.jpg" alt="（ここに画像の代替テキストを記述する）" />
Dreamweaver MX 2004 では、[編集]-[環境設定]の"カテゴリ"で"アクセシビリティ"を選択し、"イメージ"を選択しておくとよい。
そうすると、画像を挿入する際にダイアログボックスが出てきて、代替テキストを記述するように要求してくる。こうしておけば、うっかり代替テキストを記述し忘れたということも未然に防ぐことができる。
同じ画像でもリンク画像の代替テキストは重要だ。例えば、ナビゲーション部分で画像を使用している場合、もし代替テキストがないと、音声ブラウザやスクリーンリーダーはリンク先に指定しているファイル名（a要素のhref属性の値）を読み上げてしまう。リンク先が外部のサイトだった場合には、「エッチ ティー ティー ピー コロン スラッシュ スラッシュ･･･」と読み上げられてしまうので、ユーザーはもうお手上げになってしまう。リンク画像の代替テキストには、テキストリンクのラベルと同じ考え方で、リンク先の内容が分かるようなラベルを記述するようにしよう。
注意すべき画像
画像に代替テキストを記述するのは大原則ともいえるが、画像の種類によっては代替テキストを記述すべきではないものもあるので注意が必要だ。
- スペーサー画像
- 装飾だけを目的にした画像
- テキストリンクのアイコン画像
これらの画像は、特に情報を伝えるために使用されているのではなく、レイアウト制御やページデザインの装飾のために用いられる。こういった画像には代替テキストを記述する必要はない。しかし、img 要素に alt 属性をつけるのは HTML の仕様で必須なので、alt 属性はつけてその値を空（""）にすればよい。
<img src="images/spacer.gif" alt="" />
先ほど紹介した画像を挿入する際のダイアログボックスでは、"代替テキスト"で"空"を選択すれば自動的に値が空の alt 属性が挿入される。代替テキストが必要ない画像を挿入する際には、以下の画面のように"空"を選択すればよい。
『LIFT for Macromedia Dreamweaver』を活用する
Dreamweaver MX 2004のアクセシビリティ機能を拡張するツール『LIFT for Macromedia Dreamweaver（以下、LIFT）』を使うと、さらに効率よく作業を進めることができるようになる。『LIFT』は他のツールにはない独自のセマンティック・アナライザーという機能で、画像の種類を判別してくれる。これと連動した修正ウィザード画面では、画像の種類によって代替テキストを記述できないようになっている。
また、『LIFT』には"ALT エディタ"という機能があり、サイト全体の画像ファイルの代替テキスト（alt 属性の値）を一括編集できる。既存サイトの代替テキストを追加／修正する際には非常に効率よく作業が進められるのが特長だ。
データテーブルとレイアウトテーブル
次にテーブルについて考えてみよう。テーブルは本来データを示す表組みのためのものだが、Webページのレイアウトを組む際にもよく用いられている。ここでは、前者をデータテーブル、後者をレイアウトテーブルとして、説明していくことにする。
JIS X8341-3 『高齢者・障害者等配慮設計指針－情報機器における機器・ソフトウェア・サービス－第三部：ウェブコンテンツ』では、5.2 構造及び表示スタイルで"c) 表は，分かりやすい表題を明示し，できる限り単純な構造にして，適切なマーク付けによってその構造を明示しなければならない。"、"d) 表組みの要素をレイアウトのために使わないことが望ましい。"と規定されている。
アクセシブルなデータテーブルとは？
データテーブルについて、そのポイントを確認しておこう。データテーブルは、2次元でデータを視覚的に表現しているため、特に音声ブラウザやスクリーンリーダーを使用しているユーザーにとっては、その内容が理解しづらいことが多い。音声読み上げでは、テーブルの一番左上のセルから読み上げが始まり、1つずつ順に右へと移動していく。そして、右端のセルを読み上げ終わると、次の行の一番左のセルへ移動して、また1つずつ順に右へと移動していく、というのを繰り返すのだ。セルの数が多くなればなるほど、テーブルのどの部分を読み上げているのかが分かりにくくなるのだ。そこで、データテーブルでは、見出しとなるセル（見出しセル）とデータを示しているセル（データセル）とをソースコードで関連付ける必要がある。
見出しセルとデータセルとを関連付ける
まず、見出しセルをtd要素ではなくth要素でマークアップする必要がある。th要素を使うと、多くのブラウザではテキストが太字になりセンタリングされるが、見た目の制御はスタイルシートを使えばよい。そして、各見出しセルのth要素にscope属性を付加して、その見出しセルが縦方向（下）にあるデータセルの見出しになる場合はscope="col"、横方向（右）の場合はscope="row"とすればよい。
<th scope="row">見出し</th>
Dreamweaver MX 2004 では、テーブルを挿入する際に表示される[テーブルの挿入]ダイアログボックスで簡単にこの関連付けを行うことが出来るので便利だ。"ヘッダ"で見出しセルがどれかを選択するだけで、見出しセルをth要素にしてscope属性も自動的に付加してくれる。
![Dreamweaver MX 2004 の[テーブルの挿入]ダイアログボックス](images/table_dialogue.gif)
データテーブルは、セルを結合したり、見出しセルが2階層以上になっていたり、複雑な構造になる場合もある。そういった複雑なデータテーブルの場合は、LIFTを使うことで簡単に見出しセルとデータセルの関連付けを行うことが可能だ。
表のタイトルと要約を記述する
また、データテーブルにはcaption要素を用いて表のタイトルをつけて、table要素にsummary属性を付加してそのデータテーブルの要約を記述することも大切だ。これらもDreamweaver MX 2004 の[テーブルの挿入]ダイアログボックスの"アクセシビリティ"で簡単に追加できるようになっている。
レイアウトテーブルの注意点
次に、テーブルをレイアウトのために用いる場合だが、音声ブラウザやスクリーンリーダーなどの音声読み上げ順序に注意する必要がある。音声読み上げソフトは、左から右へ、上から下へ、と読み上げていくので、見た目だけを考えてレイアウトテーブルを組んでいくと音声読み上げ順序がおかしくなってしまう。この音声読み上げ順序は、LIFTのリニアライザーを用いると視覚的に確認することが出来る。
また、先に述べたデータテーブルのためのマークアップ（th要素やscope属性など）を行わないことも大切だ。
フォームオブジェクトの挿入
今回はフォームについて考えてみよう。フォームのアクセシビリティでは特に、音声読み上げソフトや特殊な入力デバイスなどの支援技術を利用して閲覧するユーザーにとっての問題を認識し、それらに対応しなければならない。
JIS X8341-3 『高齢者・障害者等配慮設計指針−情報機器における機器・ソフトウェア・サービス−第三部：ウェブコンテンツ』では、5.3a 操作及び入力のa) で「ウェブコンテンツは、特定の単一デバイスによる操作に依存せず、少なくともキーボードによってすべての操作が可能でなければならない。」、b) で「入力欄を使用するときには、何を入力すればよいかを理解しやすく示し、操作しやすいよう配慮しなければならない。」と規定している。
つまり、アクセシブルなフォームに必要なポイントとしては、「入力する内容と入力箇所を明快にする」「入力箇所へのフォーカス移動を容易にする」といったことが大切だと言える。
これらのポイントをクリアするためには、ラベルとコントロールの適切な関連づけを行い、どこに何を入力したら良いのかを明快に表現することが必要だ。フォームの要素をリニアライズ（線形化）したときに、情報の出現順序が論理的に意味がとおることも重要。そして、マウスを利用せず、キーボードで操作を行うユーザーに対する配慮が求められる。
ラベルとコントロールの関連づけ
ラベルとは、テキストフィールドやラジオボタンなどのフォームオブジェクト（コントロール）のそばに置く文字列のこと。例えば、Eメールアドレスを入力してもらうためのテキストフィールドを配置する場合、普通はその横に「Eメールアドレス」といった文字列を置くはずだ。これがラベルである。
しかし単にラベルとコントロールを並べて配置しただけでは、その関連性は曖昧な状態と言える。ラベルとコントロールが交互にいくつも並んでいる状態や、テーブルの中でラベルとコントロールが別のセルに置かれているような場合、音声読み上げソフトを利用しているユーザーにはどのラベルがどのコントロールのためのものか分からなくなる恐れがある。
そういった問題を解決するために、HTMLにはラベルとコントロールを論理的に関連づけるための label 要素というものがある。ラベルとなる文字列を label 要素でマークアップし、for 属性によって関連するコントロールを指定するのだが、Dreamweaver を使えばこの作業を効率的に行える。
また、ラベルとコントロールを関連づければ、ラジオボタンやチェックボックスにおいて、コントロール自体だけでなく、ラベルのクリックでも選択行為ができるようになる。これは細かなマウス操作が困難なユーザーにとって非常に助かる改善だろう。
アクセスキーとタブインデックスを設定する
フォームオブジェクトには、他にもアクセシビリティ向上に役立つ属性がある。accesskey（アクセスキー）属性と tabindex（タブインデックス）属性だ。例えば、input 要素に accesskey 属性として任意の文字（ショートカットキー）を指定しておけば、ユーザーはページ中の特定のコントロールに「alt + ショートカットキー」で直接フォーカスを移動させることができる。
同様に、tabindex 属性で各コントロールにユニークな番号をふっておけば、ユーザーが tab キーを押しながらフォーカスを移動する順序を制御することができる。これらの属性を手作業で記述するのは大変だが、Dreamweaver を使えば簡単に行うことができる。
では、Dreamweaver MX 2004 を使って、ラベルとコントロールの関連づけ、アクセスキーやタブインデックスの指定を行ってみよう。まず Dreamweaver MX 2004 の［環境設定］で“アクセシビリティ”を選択し、“フォームオブジェクト”にチェックを入れておこう。
こうしておくことによって、フォームオブジェクトを挿入する際に、専用のダイアログボックスが表示されるようになる。このダイアログで、ラベルとなる文字列の入力、label 要素の使い方の選択、ラベルの表示位置、アクセスキー、タブインデックスの指定などをいとも簡単に一括して行うことができる。
ラベルとコントロールがソース上で隣接している場合、両者の関連づけは、このダイアログの“ラベルタグで囲む”を選択することで簡単にできる。ただし、明示的なラベルとコントロールの関連づけを行う場合や、ラベルとコントロールがソース上で離れた場所に記述される場合（ラベルとコントロールをテーブル内の違うセルに入れるような場合）には、“for 属性によるラベルタグの添付”を選択して、id 属性や name 属性を適切に記述しなければならない。
フォームオブジェクトの挿入時にこれらの作業をすれば楽なのだが、すでにできあがったフォームページに対して後から明示的な関連づけを行うのは非常に手間がかかる。しかし LIFT を使えば、ラベルとコントロールの関連づけ作業を後から一括して行うことが可能だ。例えば、ひとつのテーブルの中に複数のラベルやコントロールが混在している場合でも、LIFT の修正ウィザードを使うことで、半自動的に label 要素の挿入と、id 属性の適切な指定ができる。詳しくは下のページを見てほしい。
ここまでの作業が適切に行われていれば、音声ブラウザーやテキストブラウザーを利用するユーザー、キーボードのみで操作を行うユーザーにとっても操作可能なフォームになっているはずだ。最後に情報の出現順序に問題がなく、論理性が崩れていないか、フォームをリニアライズ（線形化）して自分の目で確認してみよう。
