hamashun.com

関連リンク

アクセシブルなPDFとFlash のまとめ

JavaScriptを利用した動的なWebのアクセシビリティ のまとめ

先月の事になってしまいましたが、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側の実装が追いついていないのでアクセシブルにならない。 製作者はこの問題に対して選択が求められる。
一つは仕様を重視して特に対処はしない。 もう一つは情報が正しく伝わる事を重視して、冗長な表現やバッドノウハウの使用も検討する。 或いは、その中間を取る。