アクセシブルなコンテンツ、ナビゲーション、フォーム のまとめ
先月の事になってしまいましたが、Webアクセシビリティ ~標準準拠でアクセシブルなサイトを構築/管理するための考え方と実践~の出版記念セミナーに行ってきました。 という訳で遅まきながらまとめです。
6章～8章の翻訳をされた梅垣さんは、「アクセシブルなコンテンツ、ナビゲーション、フォーム」という内容でした。
実装寄りでアクセシビリティを考える時は、HTML、CSS、JSと、別々で考える必要がある、との事でした。
資料へのリンク
著者について
原著を書いたJim Thatcherは、情報科学を専門とする博士で、IBMスクリーンリーダーを作った人。 だからなのか、視覚障碍者やスクリーンリーダーを強く意識した内容になっている。
なお、便宜上この記事では音声支援技術をスクリーンリーダーと呼んでいます。
画像
代替テキストとは
代替テキスト、と聞くとイコールalt属性を連想しがちだが、それだけに限った事ではない（alt属性は代替テキストの内の一つ）。 代替テキストとは、（例えば）画像の代替となるテキストの事（そのまんまだけど）。 つまり、代替になればalt属性に限らないという事。
これはlongdesc属性や画像（など代替テキストを必要とするコンテンツ）の近くに記述するテキストが挙げられる。
よくある代替テキストの例
- 意味を持つ画像（見出しなど）
- その意味をalt属性の値とする
- 意味と機能を持つ画像（ナビゲーションなど）
- 基本的には見出しなどと同様。 ただ、例えばロゴマークにトップページへのリンクを貼っている場合には、画像にあるテキストが社名であっても「hoge社トップページ」などの文言にする
- 意味を持たない画像（装飾用画像、スペーサー）
- alt属性の値に何も含めない。 半角スペースではなくいわゆるnull。 その理由は装飾およびレイアウト目的の画像の代替テキスト | アクセシビリティBlog | ミツエーリンクスに詳しい
グラフの代替テキストの例
- longdesc属性
- 理想的な代替テキストだが、日本で主に使われているスクリーンリーダーは非対応
- alt属性に内容を記述
- 長文になってしまう（例えばブラウザシェアのグラフなら、「ブラウザシェアは、Internet Explorer 7が20%、Internet Explorer 6が70%、Firefox2が・・・」となってしまう）。 JAWS（高機能のスクリーンリーダー）でもalt属性の値は150文字までしか読み上げてくれないので、これでは代替にならない
- alt属性に概要を記述
- 例えば「ブラウザシェアは、IEだけで90%を占めます」など。
- そもそもグラフにする必要があるのか考える
- テーブルで表として表現する事も可能
- 文脈的に書く
- グラフの画像の近くに説明テキストを記述するなど
hamashun注
こういう例を出すと、「どれがベストか？」という話に終始しがちですが、僕個人としてはその考え方自体が既にベストでは無いと思います。
その情報の種類や対象ユーザーに合わせて、毎回最適な選択をする事がベストなのではないでしょうか。
音声
音声ファイルの等価テキスト
対談などで、音声ファイルを配布する場合には書き起こしテキストも提供する。 これには重要な音響的手がかりも記述する（例えば「ここで大きな拍手！」とか）。
（そういえば、「辻ちゃん・ウエちゃんのアクセシビリティPodcast」でも提供されていますね）
色
色のみの情報にしない（「赤いテキストが最新です」だと、色覚に障碍のある人が分からない可能性）。
また、コントラストを十分に取る事も重要。 カラー・コントラスト・アナライザー 2.0 日本語版が参考になります。
テーブル
アクセシビリティーの世界では、データテーブルとレイアウトテーブルの2種類に分類している。
レイアウトテーブル
スクリーンリーダーの読み上げ順に気をつける。 また、th要素やthead要素などは使用せず、table要素、tr要素、td要素のみを使用する。
データテーブル
見出しは必須。 1行目や1列目に記述する（普通は自然にそうするけど）。 昔のスクリーンリーダーは1列目や1行目を強制的に見出しとしていたので、その為。
その見出しがどの方向の見出しかを示すにはscope属性を使用する。 参考：テーブルとアクセシビリティ -- ごく簡単なHTMLの説明
階層型テーブル
複雑な構造のテーブルにはheaders属性とid属性を使用する。 参考：テーブルとアクセシビリティ -- ごく簡単なHTMLの説明
ただし、日本のスクリーンリーダーは余り対応していない（ホームページリーダーは対応しているらしい）。
視覚障碍者が複雑な表の内容を理解するのは難しい。 なので、1つの複雑な表にまとめるよりは、シンプルな2つの表に分割できないかなどの対応も考えるべき。
画面の点滅
フリッカーと呼ばれる現象（写真サイトではない）。 Flashゲームなどを作る際には留意する。
ナビゲーション
JAWSは各hn要素にジャンプできる機能がある（きちんとしたマークアップをすれば、それだけで便利になる）。
JAWSとホームページリーダーは、ナビゲーションスキップ機能がある（何の事かよく解りませんでした。 連続するリンクをスキップできるという事？）
音声リーダーを使用するユーザーは、tabキーでリンク部分のみを選択してブラウジングする事がある。 リンクテキストが「ここをクリック」などであると、何の事か解らない（これはSEO的にもよくないと言われていますね）。
フレーム
framesetのぺーじではたいとるぞくせいをつかう。 各ふれーむには、head要素にたいとるぞくせい。
イメージマップ
クライアントサイドの画像を使う。 サーバーサイドの画像を使う場合には代替リンクが必要。 area要素にはalt属性が必須。
フォーム
labelは明示的に付ける。 label付けが無くてもスクリーンリーダーがある程度推測してくれるが、これに依存しないように。
フォームのマークアップにテーブルを使う事はよくある。 スクリーンリーダーは、テーブルモードとフォームモードを両立できないが、labelを正しく付ければ読み上げる事ができる。
しかし、idはUniqなのでlabelが複数ある場合には対応できない（これがよく解らなかったんですが、資料を見ると、左と上に二つあるthの事？）。
fieldset要素とlegend要素でフォームをグループ化する事ができるが、日本のスクリーンリーダーはlegend要素に対応していない。
フォームの設計段階の話だが、聴覚障碍者は電話番号の入力を求められても躊躇する。 それ以外の連絡手段が必要である。
日本のスクリーンリーダーは力不足である
仕様通りに作ったとしても、UA側の実装が追いついていないのでアクセシブルにならない。 製作者はこの問題に対して選択が求められる。
一つは仕様を重視して特に対処はしない。 もう一つは情報が正しく伝わる事を重視して、冗長な表現やバッドノウハウの使用も検討する。 或いは、その中間を取る。
