Mozilla FirefoxとWeb Developer ToolsでEasy Checks （第8回アクセシビリティキャンプ東京に参加してみて）

第8回アクセシビリティキャンプ東京は、W3Cが公開しているEasy Checksに沿って、実際にサイトをチェックしてみるという内容でした。Easy Checksはチェックツールではなく、チェックの観点と方法を説明しているドキュメントです。当日、対象となったサイトはクックパッドで、チェック結果の概要はたださんの「アクセシビリティキャンプ東京#8でクックパッドのアクセシビリティチェックをした」にまとまっています。

私がキャンプに参加して感じたことは、キャンプに参加したかたが、また別のかたにチェック方法を教えていったら良いなあということです。そこで、この記事ではMozilla FirefoxとWeb Developer Toolsを組み合わせてチェックする方法について、簡単に述べたいと思います。内容はできる限りEasy Checksに合わせた、つもりです。また「メモ」として補足やキャンプ当日に出た話などを載せています。

1. ページタイトル

ページタイトルは次のように使われます。

ブラウザーによってはウィンドウのタイトルバーに表示されます
複数のWebページを開いている時にブラウザーのタブに表示されます
検索エンジンに表示されます
ブックマークやお気に入りに使われます
スクリーン・リーダーが（一般的には最初に）読み上げます

チェック内容

ページの内容を十分かつ簡潔に述べているタイトルがあること
サイト内の他のページと異なること、そして他のページと十分に区別できるタイトルであること

チェック方法

ブラウザーのタイトルバーを表示してチェックします。

Mozilla Firefoxではブラウザーウィンドウ上部の何もない場所を右クリックして「メニューバー」を選択することでタイトルバーを表示できます。また、Altキーを押してメニューバーを表示し、「表示」の「ツールバー」から「メニューバー」を選択することでタイトルバーを表示できます。

メモ

サイト全体が同じタイトルが同じでは、どの内容のページに移動したのか、ブックマークに登録したのか、などがわかりません。HTML5のtitle要素にも、次のようにあります。

Authors should use titles that identify their documents even when they are used out of context, for example in a user's history or bookmarks, or in search results.

2. 画像の代替テキスト

画像には代替テキストを設定します。代替テキストは画像を見ることができない人が使います。

視覚障害でスクリーン・リーダーを使っている人
ネットワークスピードの向上や帯域の節約のために画像を無効にしている人

チェック内容

全ての画像に適切な代替テキストがついているかどうか

チェック方法

Web Developer Toolsを使ってチェックします。

「画像」から「画像を枠で囲う」、「alt属性値がない画像を枠で囲む」を選択
「画像」から「alt属性値を表示」を選択

図：Web Developer Toolsで「画像」から「alt属性値を表示」を選択した画面（f:id:takenspc:20131104165117p）

メモ

画像のダウンロードに失敗した場合にも代替テキストは使われます。

適切な代替テキストとは何か、という問題は、ここではいくつかのサイトを挙げてお茶を濁したいと思います。

3. 見出し

見出しは見出しとしてマークアップします。見出しとしてマークアップすることでページ内の移動にも使うことができます。

マウスを使えずキーボードだけを使っている人
スクリーン・リーダーを使っている人

見出しのレベルは論理的な階層構造を持つべきです。

見出し1
- 見出し2
  - 見出し3
- 見出し2

チェック内容

見出しが存在していること
見出しのように見えるテキストが全て見出しとしてマークアップされていること
見出しとしてマークアップされている全てのテキストが、本当にセクションの見出しであること
見出しの構造が意味を持っていること（理想的にはページはh1から始まり、見出しレベルをスキップしないこと。ただしこの項目は絶対に必要というわけではない）

チェック方法

Web Developer Toolsを使ってチェックします。

「情報」から「見出し（h要素）を表示」を選択
「アウトライン」から「枠で囲う時はタグ名を表示」を選択し、再度「アウトライン」から「h要素を枠で囲う」を選択

メモ

スクリーン・リーダーには見出しごとにジャンプできるものが多くあります
Opera 12はSキーとWキーで見出しごとにジャンプできます（シングルショートカット機能が有効な場合）
フィードリーダーでは見出し要素に専用のスタイルが設定されていることがあります
SafariやFirefoxのリーダー・モードでも見出し要素には専用のスタイルが設定されます

4. コントラスト比（カラーコントラスト）

テキストと背景に十分なコントラストがないテキストを読めない人がいる
高齢者を含めた弱視者には高いコントラスト（明るい背景に暗いテキストや暗い背景に明るいテキスト）が必要な人がいる
ディスレクシアのようなある種の識字障害では明るい色（高輝度）を読めない人がいる

ブラウザーはテキストの色と背景色を変更する機能をユーザーに提供するべきだし、Webページはユーザーが色を変えた時にも使える必要があります。

チェック内容

（通常の大きさの文字に対して）Webページは4.5:1のコントラスト比を持っていること

チェック方法

カラー・コントラスト・アナライザーを使ってチェックします。

カラー・コントラスト・アナライザーのスポイトツールでテキスト部分のピクセルと背景部分のピクセルを選択すると、コントラスト比が自動的に計算されます。

図：カラー・コントラスト・アナライザーでコントラスト比を測定している画面（f:id:takenspc:20131104170000p）

メモ

基本的には、画像も含めテキストの色と背景色の組み合わせをすべてチェックします。

5. ズーム

Webページを拡大して読んでいる人たちがいる
フォントや行間などを変更する必要のある人もいる
拡大機能は一般にはブラウザーの機能であり、Webページはズームしても動作するように設計する必要がある
メジャーなブラウザーは全て、ページズーム機能（フルズーム機能）を提供している
ブラウザーの中にはテキストズームを提供しているものもある（今のところMozilla FirefoxとSafari）。可能ならテキストズームをチェックすべき

チェック内容

テキストズーム：全てのテキストが大きくなること
ページズーム：ページ内の全てが大きくなること
テキストが消えたり欠けたりしないこと
テキスト、画像や他のコンテンツが重なったりしないこと
ボタン、入力欄、他のフォームコントロールが視認できて、使えること

ズームした場合でも、1行が画面の中に納まって水平スクロールが発生しないことがベストプラクティスです。

チェック方法

ブラウザーのズーム機能を使ってチェックします。

Mozilla FirefoxではCtrl++で拡大、Ctrl+-で縮小することができます。Ctrlキーを押しながらマウスホイールを回転させることでも拡大・縮小できます。Ctrl+0でズームをリセットできます。

なお、Mozilla Firefoxではメニューバーを表示していないと、メニューからズーム機能を呼び出すことやテキストズームとページズームの切り替えなどを行うことができません。

6. キーボードアクセスと視覚的なフォーカス

マウスを使えずにキーボードを使っているページを操作している人もいます。

視覚障害者
目の見える運動機能障害者

いわゆるキーボードではなく、OSやブラウザーからはキーボードのように認識される入力デバイスを使うこともあります。ページのすべての機能はキーボードで操作できるべきだし、フォーカスは視覚的に見えて、論理的な順番で移動するように作ります。

チェック内容

全ての要素と順番

リンク、入力欄、ボタン、マルチメディアのコントロールを含めた全ての要素にtabキーでフォーカスを移動できること。移動できない場所に（マウスなどで）操作したり選択するものがないこと。
tabキーでフォーカスを移動した要素からtabキーでフォーカスを移動できること（よくある問題は、メディアコントロールからフォーカスを移動できなくなる場合）
tabキーを移動した順番が論理的な読み上げ順にそっていること（例えば、左から右に書く言語では上から下、左から右）
フォーカスがページの末尾で止まらないこと（ページの先頭に移動するか、ブラウザーのUIに当たった後ページに移動すること）

視覚的なフォーカス

フォーカスインジケーターが明確に見えていること（アウトラインやハイライトなど）
マウスホバーで発生する視覚的な変更（ハイライトなど）が全て、キーボードフォーカスでも発生すること

ドロップダウンリストと画像リンク

ドロップダウンリストにフォーカスをあわせた後、矢印キーで全ての項目に移動できること（よくある問題はナビゲーションとしてドロップダウンリストを使っていて、矢印キーを押した瞬間に移動してしまう場合）
リンクである画像にフォーカスを合わせた場合、明瞭な視覚的なフォーカスがあり、キーボードを使ってリンクを開けること

チェック方法

アドレスバーをクリックする（その後はマウスを使わない）
tabキーを押す
セレクトボックスやメニューバーでは矢印キーを押す
ドロップダウンリストの特定の項目を選択するにはEnterキーやスペースキーを押す

メモ

キーボードサポートはなぜ重要か

いわゆるキーボードではなく、OSやブラウザーからはキーボードのように認識される入力デバイスを使うこともある。

一時期流行したWiiリモコンを使ったPCで操作では、リモコンのボタンを特定のキー入力にマッピングすることが多く行われていました。キーボード操作をサポートすることは、キーボードと呼ばれているデバイス以外のデバイスにとっても重要です。

ブラウザーのフォーカスリングを見やすく

キャンプではブラウザーのフォーカスリングがそもそも見やすくない、という話がでました。Mozilla Firefoxではabout:configでフォーカスリングの設定を変更できます。

browser.display.focus_ring_on_anythingをtrueにして、入力欄やドロップダウンメニューにもフォーカスリングが表示されるようにする
browser.display.focus_ring_widthを3などにしてフォーカスリングを太くする

browser.display.focus_ring_widthでフォーカスリングを太くするとbutton要素の見た目が変わるため、私はユーザーCSSでフォーカスリングを見やすくすることの方が多いです。

@namespace url(http://www.w3.org/1999/xhtml);
@-moz-document url-prefix(http://),
               url-prefix(https://),
               url-prefix(file://) {
:focus {
  outline: medium dotted !important;
}
}

マウスで操作できてキーボードで操作できない要素

マウスでは操作できるけれど、キーボードフォーカスがあたらない要素を探すことは、ページの機能を知らないと難しい、という話も出ました。実際、そうだと思います。

完全なソリューションではありませんが、Google Chromeの拡張機能、Accessibility Developer Toolsにはフォーカスがあたらない要素にclickイベントハンドラーが設定されていると警告する機能があります。この機能は次のようにして使うことができます。

Accessibility Developer Toolsをインストールした状態でデベロッパーツールを立ち上げ「Audits」パネル（監査）を開く
「Select audits to run」（実行する監査を選択）で「Accessibility」にチェックが入っていることを確認し「Run」（実行）を押す
監査が終わると結果が表示され、その中に「[Warning] Elements with onclick handlers must be focusable」項目（[警告] onclickハンドラ―が設定されている要素はフォーカスがあたらなくてはならない）があれば、マウスでは操作できるがキーボードで操作できないオブジェクトがある可能性が高い
監査結果の項目はツリー上に開閉でき、イベントハンドラーが設定されている要素の一覧も表示

図：Accessibility Developer Toolsの監査（Audits）結果画面（f:id:takenspc:20131104162024p）

7. フォーム

フォームコントロールにラベルが設定されていること
キーボードで操作できること
明確な指示・説明がついていること
エラー処理がわかりやすいこと

チェック内容

キーボード

全てのフォームコントロールがキーボードでアクセスできること

ラベル

label要素を使って全てのフォームコントロールにラベルが関連付けられていること（これはベストプラクティスだが必須ではない）
ラベルが正しい位置にあること。左から右に書く言語では、ラベルは通常、次の位置にある。
- 入力欄とドロップダウンメニューでは左
- ラジオボタンとチェックボックスでは右

必須入力欄とそのほかの説明文

必須項目が明確にわかること
- 必須かどうかインジケーターが色だけに依存していないこと
- 必須項目であることがlabel要素（入力欄とドロップダウンメニュー）かlegend要素（ラジオボタンとチェックボックス）の中でマークアップされていること
フォームを記入するために使う説明文が、必要となるコントロールの前に書かれていること
- 一般的な説明文は関連するフォームの前かセクションの前に書かれていること
- 入力フォーマットはlabel要素に書かれていること

エラー処理

エラー処理がありそうなフォームで、必須項目を空にしたり、間違った書式で入力したまま送信する。エラーが表示された場合は、エラーが次を満たしていること
- ユーザーが理解できエラーを修正できる明確なメッセージが提供されていること（フォーマットが決まっている項目には、正しいフォーマットが説明されていること、など）
- エラーが容易に発見できること（通常はフォームの前にエラーを置くのがベスト）
- エラーが起きなかったコントロールが入力済のままになっていること（これはベストプラクティスですが必須ではない）

チェック方法

Easy ChecksではMozilla Firefoxを使った簡単なチェック方法はないと書かれていますが、Web Developer Toolsを使ったチェック方法をいくつかか紹介します。

「フォーム」から「ラベルが指定されていないフィールドを枠で囲う」を選択
「アウトライン」から「任意の要素を枠で囲う」を選択して、表示されたダイアログにlabel入力（label要素が枠で囲まれる）
- ラベルをクリックしてコントロールにフォーカスが移動するかチェック
フォームを空もしくは適当に入力した状態で送信して、表示されるエラーメッセージを確認する

図：Web Developer Toolsで「フォーム」から「ラベルが指定されていないフィールドを枠で囲う」を選択した画面（f:id:takenspc:20131104165306p）

メモ

必須かどうかインジケーターが色だけに依存していないこと

必須項目であることが色だけに依存している例としては「赤字の項目は入力必須です」などがあります。色だけに依存している場合、視覚障害のユーザーが判断できなかったり、（カラーでない）電子ペーパーを使っているユーザーにも判断できないかもしれません。

フォームを記入するために使う説明文が、必要になる前に書かれていること

コントロールの後ろに入力を終えてからフォーマットの説明がくると、そのフォーマットで書いていなかったユーザーは入力をやり直さなくてはなりません。例えば、説明文は画面外に出ていて気が付かなかったが、入力欄は画面内にあったので、制作者の意図とは違うフォーマットで入力した場合や、スクリーン・リーダーを使っていて、説明文が読み上げられる前に入力欄が読み上げられたので、制作者の意図とは違うフォーマットで入力した、といった場面を想像してみてください。

8. マルチメディア（ビデオとオーディオ）の代替コンテンツ

（略）

9. プレーンコンテントビュー

Webページはマルチカラムや色などを使ってデザインされていることが多いが、全ての人がそのようにページを見ているわけではない
スクリーン・リーダーを使って読み上げているかもしれないし、点字ディスプレイで読んでいるかもしれないし、マルチカラムを1カラムにしたり、テキストサイズなどを変更して読んでいるかもしれない
ページのプレゼンテーション（表現）を変えた際のアクセシビリティのバリアについて気づくために、プレーンコンテントビューでページを見てみる

画像とスタイルを無効にしてページをリニアライズした状態のことをEasy Checksではプレーンコンテントビューと言っています。

チェック項目

プレーンコンテントビューで表示されている順に読んで情報がわかること（見出しが見出しの内容の直前に来ている、など。ただしデータテーブルは除く）
代替テキストが画像と等しい情報を提供していること
情報のまとまりに明確な見出しがついていること

チェック方法

画像を無効にして代替テキストを表示する（「画像」から「画像を無効化する」、「全ての画像」を選択）
CSSを無効にする（「CSS」から「CSSの無効化」、「全てのCSSを無効化」を選択）
ページもしくは表をリニアライズする（「その他」から「リニアライズ（線形化）する」を選択）

メモ

リニアライズはHTMLに記述された順番に要素を表示することです。テーブルレイアウトでの問題を考えるとわかりやすいです。

<table>
  <tbody>
    <tr>
      <td>ナビゲーション</td>
      <td>メインコンテンツ</td>
    </tr>
    <tr>
      <td>ナビゲーションの続き</td>
      <td>メインコンテンツの続き</td>
    </tr>
  </tbody>
</table>

この場合、「ナビゲーション」の次に「ナビゲーションの続き」が来ること、「メインコンテンツ」の次に「メインコンテンツの続き」が来ることが意味的に正しいとします。しかし、リニアライズをすると「ナビゲーション」、「メインコンテンツ」、「ナビゲーションの続き」、「メインコンテンツの続き」の順になってしまい、意味が通らなくなってしまいます。

ただし、データを表として表現している場所では、リニアライズしたときに意味が通じるようにする必要はありません（スクリーン・リーダーもサポートしています）。

<table>
  <thead>
    <tr>
      <th>日付</th>
      <th>最高気温</th>
    </tr>
  <tbody>
    <tr>
      <td>8月1日</td>
      <td>32℃</td>
    </tr>
    <tr>
      <td>8月2日</td>
      <td>35℃</td>
    </tr>
  </tbody>
</table>

その他

Web Developer Toolsはキーボードショートカットを使って機能の有効・無効を切り替えることができます。

「設定」から「設定」を選択し、「Web Developerオプション」ダイアログを開く
「キーボード」タブを開き、「追加」ボタンをクリックして、「オプション」ダイアログを開く
「オプション」ダイアログで、「機能」プルダウンメニューで切り替えたい機能、「キーボード」でショートカットキーを設定
Mozilla Firefoxを再起動

図：キーボードショットカットを設定する「オプション」ダイアログ（f:id:takenspc:20131104162127p）