アクセシブルなコンテンツ、ナビゲーション、フォーム のまとめ
- 関連リンク
- アクセシブルな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側の実装が追いついていないのでアクセシブルにならない。 製作者はこの問題に対して選択が求められる。
一つは仕様を重視して特に対処はしない。 もう一つは情報が正しく伝わる事を重視して、冗長な表現やバッドノウハウの使用も検討する。 或いは、その中間を取る。
アクセシブルなPDFとFlash のまとめ
- 関連リンク
- アクセシブルなコンテンツ、ナビゲーション、フォーム のまとめ
- JavaScriptを利用した動的なWebのアクセシビリティ のまとめ
前回の記事同様、Webアクセシビリティ ~標準準拠でアクセシブルなサイトを構築/管理するための考え方と実践~の出版記念セミナーのまとめです。
11章と12章を翻訳されたのはインフォアクシア代表の植木さんです。 内容はPDFとFlashのアクセシビリティについてです。
なお、便宜上この記事では音声支援技術をスクリーンリーダーと呼んでいます。
資料へのリンク
イントロダクション
FlashやPDFを取り巻く環境はコンテンツ、オーサリングツール、UAの3つに分けられる。 そしてそれぞれに対応するのがWCAG、ATAG、UAAGの3つのガイドライン(ちなみに作っているのはW3C)。
コンテンツは仕様とWCAGに準拠し、オーサリングツールは仕様通りに生成し、UAはコンテンツを忠実に変換して読み上げる必要がある。
これらが正しく動作して、はじめてアクセシブルになる。
課題はUA
コンテンツとオーサリングツールに比べて、UAの実装が遅れている。 更に日本で大きなシェアを持つホームページリーダーは、VistaとIE7はサポートしないと言っている。
FlashやPDFも、オーサリングツール側ではアクセシブルにする手段が用意されているが、やはりUA側がネックになっている。
PDFのアクセシビリティ
12章。 原著はAndrew Kirkpatrick。
Andrewはアドビ全製品のアクセシビリティ統括責任者。 以前は公共放送の字幕や副音声に関わっていた。
過去の問題と現在の状況
過去には、PDFはスクリーンリーダーでは読む事ができなかった。 また、キーボードでの操作も難しかった。
読み上げに対応した後も、セキュリティを設定するとアクセシビリティが犠牲になったりしていた。
しかし、バージョンを重ねるごとにアクセシビリティも向上してきている。
現在ではタグを埋め込む事で、HTMLに近い読み上げが可能(日本ではFocusTalkが対応)。
作成する方
アクセシブルなPDF作成フロー
Word文書を元にPDFファイルを作成する流れを解説。 Wordは2007との事。
- 文書構造を、書式→スタイル で定義する。 これはHTMLのマークアップと同じ感覚
- 画像ファイルには代替テキストを付ける。 alt属性のように。 画像を右クリックして設定→代替テキストタブを選択(オフィス2007の場合)
- 段組を使用する場合は、書式→段組 で設定する(表機能を使わない事)。
- 箇条書きや見出しも、それぞれのスタイルを使用する
- WordファイルをPDFに変換する
- 変換設定の変更 で各種設定を行う 参考:植木さんのプレゼン資料
- 変換する
InDesignから変換する事もできるが、タグ付けなどの面で厳しい。 要素名を自由に設定できるので、逆に厄介。
アクセシブルチェック機能
詳細チェックはProfessional版を使うとよい。
アドバンスド→アクセシビリティ→完全チェック を選択。 詳細なエラーやその修正方法が表示される。 画像の代替テキストを忘れていた場合など、エラーテキストをクリックすると対象の画像を示してくれるので親切。
たまに関係のないエラーが出る事もあるので注意。
読む方
各種設定を変更する事で、リーダーをアクセシブルにできる。
- 編集→環境設定→アクセシビリティ でコントラスト、背景色、文字色を変更できる
- 表示→折り返し で横スクロールせずに画面を拡大できる
- 表示→自動スクロール で画面の自動スクロールを設定できる(これは使い勝手は微妙)
- 表示→読み上げ で読み上げる事ができる(英語エンジンしか積んでないので、日本語は微妙)
Flashのアクセシビリティ
11章。 原書はBob ReganとAndrew Kirkpatrick。
BobはFlashのアクセシビリティで有名な人だとか。
過去の問題と現在の状況
スクリーンリーダーで読む事ができなかったり、一度Flashにフォーカスするとそこから抜け出せなくなったりしていた(いわゆるフォーカストラップ)。
現在ではFlash(オーサリングツールの方)にアクセシビリティパネルが搭載されている。 これで代替テキストを割り当てたり、フォーカスの順序(tabindexみたいな)を指定できる。
CS3では動画に字幕を付ける事も容易。 また、プレイヤー側でフォーカストラップは解決済みである。
アクセシブルなFlashのベストプラクティス
- 等価テキストを提供する
- 状況を伝える
- 音声読み上げ順序を制御する
- アニメーションを制御する
- キーボードで操作可能にする
- 段階的に情報を公開する
- コンポーネントのアクセシビリティを有効にする
- キャプションを提供する
- 音声再生のコントロールを提供する
- よく考えて色を使用する
- ロービジョンのユーザーをサポートする
- Flashをサクセシブルに埋め込む
書籍の388ページ以降に、詳しい解説が載っています。
下記に、セミナーで解説された内容を記述します。
等価テキスト
アクセシビリティパネルの名前フィールドに、alt属性のように記述する。 説明フィールドは使わない方が無難との事。
等価テキストが不要な場合は、「オブジェクトをアクセス可能にする」のチェックを外す。 これにより「意味を持たない画像」のような扱いになる。
状況を伝える
全体の構成を説明する。 どんな画面で、どんな情報で、どんな機能なのか。 概略ページへのリンクを設置してもよい。
HTMLページの一部にFlashのコンテンツを設置する場合には、Flashと連動する動的なテキストで現在の状況を知らせる。
(感覚的に解りづらいんですが、動的なコンテンツには、その時の状況を知らせるテキストを動的に出力する必要がある、という事だと思います)
CS3の新機能、字幕を簡単に付ける
Flash CS3では、簡単に字幕を付ける機能が追加された。
- ファイルを開く
- コンポーネントの選択でビデオ→FLVPlaybackCaptioningをドラッグしてステージへ
- パラメータを指定する
字幕部分はシンプルなXMLファイルになっていて、表示されるテキストやその文字列が表示されるタイムラインなどが記述されている。
JavaScriptを利用した動的なWebのアクセシビリティ のまとめ
- 関連リンク
- アクセシブルなコンテンツ、ナビゲーション、フォーム のまとめ
- アクセシブルなPDFとFlash のまとめ
前回、前々回の記事同様、Webアクセシビリティ ~標準準拠でアクセシブルなサイトを構築/管理するための考え方と実践~の出版記念セミナーのまとめです。
10章の翻訳をされたのは中村精親さんですが、セミナーでは渡辺さんが話をしてくれました。 内容はアクセシブルなJavaScriptについてです。
なお、便宜上この記事では音声支援技術をスクリーンリーダーと呼んでいます。
資料へのリンク
JavaScriptはアクセシビリティ的にも誤解されている
JavaScriptは、アクセシビリティを妨げる使われ方が多かった。 例えば、右クリック禁止やポップアップ・ウィンドウなど。
また、アクセシブルでないスクリプトにより、JavaScriptをオフにすると利用できなくなってしまうコンテンツが(現在でも)ある。
著者の主張
原著を書いたのはChristian Heilmann。 ChristianはWaSPのDOMスクリプティング・タスク・フォースのメンバー。
Christianは、でしゃばらないJavaScriptがよいと言う。 JavaScriptが無い環境でも得られる情報は同じで、JavaScriptが利用できる環境では更にリッチな体験ができる、というように。
(この辺、Webデザインで言うところのMOSeを連想させますね。 アクセシビリティ関係ないですけど)
JavaScriptは「振る舞い」を担当する
HTMLが構造、CSSが表現であるなら、JavaScriptは振る舞いであると言える。
RIAのアクセシビリティ
これは、書籍から離れた内容。 GoogleのiGoogleとGoogleドキュメントのアクセシビリティについて。
なお、この調査は渡辺さんの生徒さんによるものだそうです。
渡辺研究室の2007年度卒業研究「JavaScriptを利用した動的なWebのアクセシビリティ」(松田理沙)から,GoogleのRIAのアクセシビリティ問題のケーススタディを紹介.
との事。(資料11ページより)
(セミナーでは悪い点ばかりが取り上げられていましたが、良い点もあったのでしょうか? 気になるところです)
操作部分のHTML
ホームページリーダーを使用すると、キーボードで操作できない部分がある。 これらは内容を持たない要素と背景画像でコーディングされているので、HTML的には意味の無い存在という扱い。
他にも、Googleドキュメントにある「新規作成」というタブをクリックすると「リンクではありません」と読み上げられる(div要素やspan要素でマークアップしてあるため)。
ショートカットキー競合
Webアプリケーションのショートカットキーと、スクリーンリーダーのショートカットキーが競合してしまう事がある。 これは本質的な問題である。
追加されるHTML
Googleドキュメントでは、ドロップダウンメニューを開くとHTMLの最後にソースが追加される。 その為、スクリーンリーダーでは開いた時には読み上げられない。
動的なページ書き換え
例えば、nowaの管理画面では自動的に新着記事を表示しますが、スクリーンリーダーでは更新がなされた事を知る術がない。
WAI-ARIAのlive属性はこの問題を解決できるかもしれない。
(WAI-ARIAについては、梅垣さんの(今回のセミナーとは関係の無い)資料Ajaxアクセシビリティ~リッチ・インターネット・アプリケーションのゆくえ~が解りやすいかも)
個人的な意見
アクセシビリティ業界(?)では、JavaScriptは悪役にされがちな気がします。
hamashun個人としては、「全てのWebサイトはアクセシブルなJavaScriptを採用すべき」という必要は無いと思います。
伝えたい情報が伝えたい相手に正しい形で伝わる事が大事なのであって、HTMLやCSSやJavaScriptなどの技術はその手段であるべきだと考えます(ここで言う情報とはテキストのみならず、デザインや操作感も含みます (いわゆるUser Experienceと言えるかも))。