Webアクセシビリティ・チェッカーで見落とされる問題

仕事でWebサイトのアクセシビリティ調査を行う機会がありました。2、3年前に比べると、アクセシビリティに対する配慮は確実に増えていました。たとえば、画像にalt属性で代替テキストを指定していないようなページは、ごく一部になっていました。しかし代替テキストが付いていても、その内容が不十分だったり、とんちんかんだったりというサイトが結構あります。

このような問題は、Bobbyやi-Checkerのようなアクセシビリティ・チェッカーではチェックできません。プログラムでは、「alt属性が付いているかどうか」というようなことを機械的にチェックできても、「alt属性のテキストが適切かどうか」といったことまでは判断できないからです。

そこで、アクセシビリティ・チェッカーでチェックされない部分で、よくある問題をまとめてみました。

画像のalt属性

alt属性には、画像が表示されない場合に、代わりに表示するテキストを指定します。スクリーン・リーダーなどで音声出力してページを閲覧したり、点字出力したり、Lynxのようなテキストベースのブラウザで表示する場合、あるいは表示速度を速くするために画像表示オフで閲覧しているような場合に、この代替テキストが表示されます。

たとえば、以下のようにアプリケーションの新規作成アイコンの画像にalt属性を付けたとします。

<p><img src="images/new.gif" alt="新規作成">アイコン</p>

画像を表示する場合は、以下のように表示されます。

アイコン

画像が表示されない場合は、以下のように表示・出力されるので、何のコマンドなのかが分かります。

新規作成アイコン

一方、alt属性を付けていない場合には、以下のように画像を読み飛ばしたり、画像のファイル名を表示・出力してしまいます。

アイコン

images/new.gifアイコン

ですから、alt属性には、画像の内容を説明するテキストを入力し、画像が表示されないでも、画像表示時と同じように意味が取れるようにします。

ここで問題なのが、「画像の内容を説明するテキスト」というところです。アクセシビリティ調査で目立ったのは、以下のような例です。

不適切なalt属性の例

1.修飾用の画像に不要な説明を付けている。

たとえば、リスト項目の先頭の画像に、「まる」「さんかく」のような代替テキストを付けているサイトが、数多く存在します。以下の例では、「オレンジの右向き矢印」と全画像のaltに指定しています。

オレンジの右向き矢印 ニュース
オレンジの右向き矢印 サイトマップ
オレンジの右向き矢印 検索

これをスクリーン・リーダーで読み上げると、

オレンジの右向き矢印 ニュース
オレンジの右向き矢印 サイトマップ
オレンジの右向き矢印 検索

となり、代替テキストが煩わしくなります。
修飾用の特に意味のない画像の場合は、alt=""のように空文字列を指定すると、スクリーン・リーダーなどで読み飛ばされます。(空文字列で不都合がある場合は、alt=" "のように半角スペースを入れください。)また、リスト項目の先頭に画像を入れたいのならば、CSSのlist-styleを利用すると、画像を表示しないブラウザなどでも、リスト項目として適切に表示・出力されます。

2.画像の後の文字と代替テキストの内容がだぶっている。

イメージアイコンの後に見出しを入れたり、画像の後に補足説明のテキストを入れている場合です。たとえば、以下のようにクエスチョンマークの画像の後に「ヘルプ」とヘルプページへのテキストリンクを付けている場合、画像のaltにもその後のテキストと同じ「ヘルプ」と入力すると、「ヘルプヘルプ」になってしまいます。このような場合も、画像の代替テキストはalt=""で良いでしょう。

ヘルプヘルプ

3.代替テキストが画像の内容を説明していない。

見出しの画像に対して「タイトル」と入力したり、リンクボタンの画像に「ここをクリック」と入力しているような例です。見出し画像ならば、見出し自体のテキスト、リンクボタンならばリンク先が分かるテキスト(たとえば「アンケートページに進む」)を入力してください。

4.図表の代替テキストが不十分。

グラフやフローチャートを画像で表示しているサイトが多いのですが、大半のページが代替テキストに「グラフ」「購入の流れ」といったタイトルのみを付けています。それぞれの項目やパーセンテージ、フローチャートの内容などが全く分かりません。グラフの元となる表へのリンクや、テキストでの詳細な説明が必要です。

リンクのスキップ

各ページの上下などに、以下のようなナビゲーションバーを使用しているサイトが数多くあります。

HOME
製品情報
ショップ
サポート
会社概要

 

このナビゲーションバーのように、各ページ共通のリンク機能を付けることでユーザーが操作に迷いにくくなる反面、ナビゲーションバーの存在が邪魔になる場合があります。
たとえば、スクリーン・リーダーで各ページを読み上げると、毎回かならず「ホーム、製品情報、ショップ、サポート、会社概要」と読み上げられることになり、一度読み上げられた後は繰り返し聞かされるのが面倒です。
また、四肢の障害などでマウスを使わずにキーボードのみで操作しているユーザーにとっては、毎回タブキーでひとつずつナビゲーションバーのリンクを進んでいかなければならず、やはり不便です。

そこで、ナビゲーションバーなどをスキップして、本文に直接入れるような仕組みが必要になります。手法としては、ナビゲーションバーをスキップして本文の先頭のアンカー位置にジャンプさせるテキストリンクを、バーよりも先に入れるという方法がまずあります。

本文へジャンプ

HOME
製品情報
ショップ
サポート
会社概要

会社概要
社名:○○株式会社

しかし、ページのデザイン上、「本文へジャンプ」というようなリンクを置きたくないといった場合は、1ピクセルの透過画像を、バーの先頭などに隠しておくこともできます。この画像に代替テキストとしてAltで「本文へのジャンプ」と書いておけば、スクリーン・リーダーでは、「本文へのジャンプ」と読み上げられるため、テキストリンクと同じ効果があります。
ただし、この方法では、キーボードでリンクを進むユーザーにとっては、透過画像が見えないため、逆にタブキーを押す回数が増えるという問題があります。妥協案としては、目立たない位置(たとえば、ページの右端)に小さなフォントでテキストリンクをつけるという方法も考えられます。

本文へジャンプ

HOME
製品情報
ショップ
サポート
会社概要

会社概要
社名:○○株式会社

日本語のレイアウト

表などで、以下の「本日の最高気温」のように、1文字ずつ改行を入れてレイアウトしたり、文字間隔を揃えるために、「東 京」「大 阪」のように文字の間にスペースを入れる例があります。

これをスクリーン・リーダーなどで読み上げると「ひがし きょう だい はん」「ほん ひ の さい だか き おん」のように1つのまとまった単語でなく、1文字ずつ区切って読み上げられるので、意味が分からなくなります。

 
北海道
東 京
大 阪






30度
35度
32度

単語間に余分なスペースを入れたり、単語の区切り以外で強制改行は入れないようにしてください。

NOFRAMES要素とNOSCRIPT要素

フレームに対応していないブラウザのためには、NOFRAMES要素でフレームを表示しない場合に代わりに使用する内容を指定します。スクリプトに対応していない、あるいはスクリプトをオフにしているブラウザのためには、NOSCRIPT要素でスクリプトを実行しない場合に使用する内容を指定します。

たとえばフレームにナビゲーションメニューを表示している場合に、ナビゲーションメニューに代わるリンク項目を記述したり、スクリプトでプルダウンメニューを作成している場合にプルダウンされる項目を記述したりできます。

ところが実際には、

<FRAMESET cols="20%, 80%">
<FRAME src="menu.html">
<FRAME src="main.html">
<NOFRAMES>
<P>このホームページは、フレーム対応のブラウザでご覧ください。</P>
</NOFRAMES>
</FRAMESET>

と、記述したり、

<SCRIPT TYPE="text/javascript" LANGUAGE="JavaScript">

</SCRIPT>
<NOSCRIPT>
<P>このページではJavaScriptを使用しています。JavaScriptをオンにしてください。</P>
</NOSCRIPT>

と、フレームやスクリプトの使用を促すだけのサイトが数多くあります。これではサイトを使いづらいというよりも、サイトに全くアクセスできなくなる可能性があります。スクリーン・リーダーにはJavaScriptに対応していないものもあります。その場合、JavaScriptで覆われたサイトからユーザーは締め出されてしまいます。
フレームやスクリプトに対応していない環境でも閲覧できる代替ページや代替テキストを用意するか、あるいはフレームやスクリプトが本当に必要なものかどうか見直しをかけてみてください。

最後に

今回の調査で感じたのは、「画像にはaltで代替テキストを付ける。」というようなルールだけが先行している気配があるということです。Webサイトを制作されている方は、一度スクリーン・リーダーで制作したサイトを読み上げてみたり、キーボードだけで操作してみたりして、なぜアクセシビリティに関するルールが必要なのか考えてみてください。

今回ご紹介したのは、私が出会った問題のごく一部です。時間があれば追加して行きたいと思います。