アクセシブルなコンテンツ、ナビゲーション、フォーム のまとめ
- 関連リンク
- アクセシブルな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のアクセシビリティ問題のケーススタディを紹介．
との事。（資料１１ページより）
（セミナーでは悪い点ばかりが取り上げられていましたが、良い点もあったのでしょうか？ 気になるところです）
操作部分の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と言えるかも））。
amachangの言葉に（勝手に）後押しされてプログラム勉強Blogを公開するよ！
amachangの（いいよって言われたけど未だに「さん」を抜くのにためらってしまう）採用説明会資料に後押しされて、ちょっと前から書いてるプログラム勉強Blogを公開してみます。
別に隠してた訳ではないんですけど、多分まだ誰にも読まれてない雰囲気なので。
毎日毎日、凄い人達に囲まれて仕事をしている訳で、自分の本業務以外の部分でも勉強になる事がたくさんあります。 と言うか教えて貰ってます。 いやもうホント感謝です。
ですが、せっかく教えて貰った事も自分的にまとめないとどんどん忘れていってしまいます。 これはもうアウトプットするしかないなと！
こっちのBlogと使い分ける理由は、あくまで勉強中という事で、中途半端だったり間違った内容を公開してしまう恐れが高いためです。 身についてきたら、こっちでも色々書きたいなと。
あと、使っているBlogサービスはあれです。 ほら、なんて言うかその、たくさん言及貰えそうなイメージがあったので！ あと記法とか！
という訳でこちらです。 よろしくお願いします。
hamashun.hatena
間違っている部分とかを発見されましたら、お手すきの時にでもDisって頂けると嬉しいです。
あー、なんか書いてて冷や汗かいてきた。 小心者小心者。
IE7用のCSSハックがOpera9.2xにも適用される件
Re:ブログの使い訳けについてみんなに聞きたい
ブログの使い訳けについてみんなに聞きたい｜| Woops'dez | Bloggin'より。
結論から言うと、人それぞれで良いと思います。 というのは当たり前すぎるので、僕の場合の使い分けを書きます。
あと元記事のタイトル、 使い訳→使い分け ですよね。
使い分け派
僕は使い分ける派です。 理由はいくつかあります。
特化させたい
例えばこのBlogの役割というのは3つくらいあって、勉強報告と告知と情報発信という感じになります。
勉強報告と言うのはイベントとかのレポートが主で、告知は勤務先の新コンテンツや執筆した本の紹介など。
情報発信はHTMLやCSS関連の内容になります。
で、このBlogを読んでいる人は、別に僕の好きな食べ物や先週の週末に何をしてたかなんて事をを知りたい訳じゃ無いと思うんです。 技術関連の情報が欲しくて読んでいるんじゃないかなと。
そうなると、このBlogでは私生活ではなく、技術関連に特化させた方が良いと思います。
私生活が知りたい人は、TwitterやTumblrやnowaを見てください、みたいな。
情報発信をする立場
このBlogはLDRだけを見ても、250人以上の人がフィードを購読してくれています。 しかもlivedoorという、影響力の強い会社で働いています。
例えばこのBlogで、現在思いっきり素人レベルであるJavaScriptの記事を書いてしまっていいのだろうか、という疑問が沸きます。
僕自身は正しいと思っていても間違っている情報を発信してしまう可能性が非常に高いです。
間違っている事を指摘されたら訂正すればいいと思うかもしれませんが、訂正情報が全ての人に届くかと言うと、その確証はありません。
決して自惚れている訳では無く、誤った情報を発信してしまう事の重大さは注意してしすぎる事は無いと思っています。
なので、はてダを勉強専用Blogにしました。 Disり大歓迎です。 そうだね。 宣伝だね。
口調
あとは、口調って言うか文体？も、記事ごとにあんまりにも変わっているのは避けたいです（これは完全に好みの問題ですが）。
でも、趣味の話だと思いっきりハジけたい時もあったりするので、それも使い分けている理由の一つです。
おまけ
なお、現在頻繁に更新しているWebサービスの情報は、iddyが一番まとまっています。
本当はこのBlogにそういうページを作ろうと思っているんですが、リニューアルに合わせて…とか思ってたら、気づいたら一年経ってました。 ふしぎですね。