技術コラムAMCC,miChecker

検出理由

「問題あり」として検出される項目です。
object 要素によるコンテンツのレンダリングができない場合、代替のコンテンツが提供されるようになっていないと問題として指摘されます。

<object (10分おきの株価をイメージにして表示する外部コンテンツ)>
</object>

根拠

object要素によって組み込まれる外部コンテンツがレンダリングされない場合、代替のテキストが無いと利用者は何が起きているのか知ることができません。代替コンテンツを提供していれば、少なくとも、そこに何が提供されようとしていたのか、あるいは、同等のコンテンツを提供することも可能になるかもしれません。

修正方針

代替コンテンツを提供します。

例えば、10分おきに株価を表示する外部コンテンツを組み込む場合、仮にそれが機能しなくとも、そこで何が提供されているかわかるようにします。

<object (10分おきの株価をイメージにして表示する外部コンテンツ)>
  株価を10分おきに更新して表示するコンテンツがあります。お使いの環境では正しく動作していません。
</object>

可能ならば、代替となるページへのリンクも追加すると良いでしょう。

補足

(特になし)

関連する達成基準、達成方法


(他のテクニックは「miChecker対策テクニック集」に整理されています。)

技術コラムAMCC,miChecker

検出理由

「問題あり」として検出される項目です。
applet 要素にalt属性による代替テキストが設定されていないと指摘されます。

しかし、そもそも、HTML4.01以降では使用することのできない要素であり、いつ、ブラウザで動作しなくなるとも分かりません。これが検出された場合は、該当箇所の削除、あるいはobject要素など用いて他の方法で実装するべきです。どうしても残す場合は、埋め込むJava アプレットであることと目的を代替テキストとしてapplet要素に記述すると良いでしょう。

根拠

(省略)

修正方針

(省略)

補足

(特になし)

関連する達成基準、達成方法


(他のテクニックは「miChecker対策テクニック集」に整理されています。)

技術コラムWCAG 2.1

WCAG 2.1 は 2018年6月5日に勧告(Recommendation勧告)になりました。それからすでに3年近く経ちますが、普及これからのようです。特に、解説書が示す達成方法(Techniques)が十分ではなく、追加された達成基準の意図はわかりますが、実際にどうしたらよいかが明確ではなかったからだと思います。しかし、昨年 2020年12月2日に公開された解説書では、ふたつの達成基準を除いて、ひととおりの達成基準で達成方法(十分な達成方法を含む)が示されるようになり、今後は検査も容易になり普及が進むものと思われます。

日本ではWAICの有志メンバーが中心となって規格の翻訳は終えています。(JIS X 8341-3:2010の時に比べると翻訳の質がとても高くなったと思います。素晴らしい活動だと思います。)しかし、解説書の方は2019年3月6日版が公開されていますが、本家の2020年12月2日のバージョンのものは未だ翻訳中です。(2021年3月7日時点)そのため、達成方法については日本では未だ不十分な情報しか得られない状況にあります。また、解説そのものも、2019年3月6日版と2020年12月2日版ではそれなりの差異があり、現状でWCAG2.1を日本で普及させていくにはまだまだ情報が足りていない印象があります。

規格 : WCAG 2.1 Recommendation – 2018/6/5
https://www.w3.org/TR/WCAG21/
規格の翻訳版 : 2018/6/5
https://waic.jp/docs/WCAG21/
解説書 : Understanding WCAG 2.1 – 2020/12/2
https://www.w3.org/WAI/WCAG21/Understanding/
解説書の翻訳版 : 2019/3/6 (少し古いことに注意)
https://waic.jp/docs/WCAG21/Understanding/

また、WCAG 21 解説書ですが、WAIに敬意を持ちつつ発言しますが、正直なところ理解が難しいところがいくつもあるように感じます。もしかすると、Webの専門家には当たり前で理解は容易なことばかりなのかもしれませんが、自治体や企業でウェブを運用している現場の責任者においては、180度誤った解釈をしかねないような項目もあります。これでは普及は難しいのではないかと不安になります。

そこで、WCAG 2.1 解説をもう一段わかりやすくした入門編を提供しようと思います。入門編を理解した上で、解説書を読んでいければ、もう少し理解が容易になるのではないかと期待しています。

WCAG 2.1 の特徴

WCAG 2.1 の特徴を書き出しておきます。

2.0 の達成基準の削除や変更はありません。新しく17項目が追加されたのが WCAG 2.1 です。よって、2.1 を満たせば 2.0を満たしていることになります。

認知あるいは学習障害

障害としては、脳による情報処理に関連する認知あるいは学習障害に特にフォーカスを与えています。これら障害に対する配慮が欠けているということは、WCAG 1.0 の時から指摘されていたのですが、10年経ってその領域の知識も多くなり、やっと配慮すべき項目を検討できるようになったのだと思います。追加された項目は、誰でも得て不得手として、あるいは環境によっと受ける困難を改善するものであり、WCAG 2.1の有用性が高まったとも言えます。具体的なことは今後の記事の中で説明させていただきます。

ロービジョン

ロービジョンに対する配慮はより幅広く厳格になりました。WCAG 2.0 まではコントラスト比についてはテキストにのみ適用されていましたが、今後は情報を伝えるシンボル、アイコンといったものに対しても適用されます。とても細かく規定されていて、慣れるもでは運用に苦労するかもしれません。

モバイル機器

また、なんといっても、モバイル機器に対する配慮がいくつか加わっています。スマートフォンの普及により、タッチやジェスチャーによる操作に対する配慮が必要になりました。

これら特徴の他、もう一つ大切なことは、スマートフォン等のネイティブアプリへ対応することも意識されています。これまで、モバイルアプリ用の規格としてはBBCが提供するものくらいしかなかったのですが、今後は、WCAG 2.0 を用いたアプリの試験が増えているものと予想されます。ただ、HTML技術に対する達成方法は多く示されていますが、ネイティブアプリに対する達成方法は示されていませんので、先行してアプリ開発でWCAG 2.1を利用している企業があれば、積極的にその具体的な基準(実装方法チェックリスト等)を公開して欲しいものです。

WCAG 2.1 で追加された達成基準

4月から達成基準ごとに説明ページを追加し、次の表からリンクさせる予定です。6月までに全項目の追加を目標にしています。

レベル順

Level番号達成基準名
A2.1.4文字キーのショートカット
A2.5.1ポインタのジェスチャ
A2.5.2ポインタのキャンセル
A2.5.3名前 (name) のラベル
A2.5.4動きによる起動
A1.3.4表示の向き
A1.3.5入力目的の特定
AA1.4.10リフロー
AA1.4.11非テキストのコントラスト
AA1.4.12テキストの間隔
AA1.4.13ホバー又はフォーカスで表示されるコンテンツ
AA4.1.3ステータスメッセージ
AAA1.3.6目的の特定
AAA2.2.6タイムアウト
AAA2.3.3インタラクションによるアニメーション
AAA2.5.5ターゲットのサイズ
AAA2.5.6入力メカニズム非依存

達成基準順

番号Level達成基準名
1.3.4AA表示の向き
1.3.5AA入力目的の特定
1.3.6AAA目的の特定
1.4.10AAリフロー
1.4.11AA非テキストのコントラスト
1.4.12AAテキストの間隔
1.4.13AAホバー又はフォーカスで表示されるコンテンツ
2.1.4A文字キーのショートカット
2.2.6AAAタイムアウト
2.3.3AAAインタラクションによるアニメーション
2.5.1Aポインタのジェスチャ
2.5.2Aポインタのキャンセル
2.5.3A名前 (name) のラベル
2.5.4A動きによる起動
2.5.5AAAターゲットのサイズ
2.5.6AAA入力メカニズム非依存
4.1.3AAステータスメッセージ

技術コラムAMCC,miChecker

検出理由

「問題の可能性大」として検出される項目です。
alt属性が半角スペースか全角スペースのみで構成されている場合、およびmiCheckerの「不適切なalt属性リストの編集」で設定されている語句が使用されている場合に、この項目が検出されます。

<!-- 半角スペース -->
<img src="example.png" alt=" ">
<!-- 全角スペース -->
<img src="example.png" alt=" ">
<!-- miChecker の不適切なalt属性に含まれる語句が設定されている -->
<img src="example.png" alt="image">
miChecker設定

miCheckerのメニューからの場合、「ウィンドウ」-「設定」で設定パネルが開きますので、音声ユーザビリティ視覚化の不適切なalt属性にある[不適切なalt属性リストの編集]を選択してください。一覧が表示され内容を確認できます。

初期値では、つぎの語句が登録されています。自分で追加・削除することも可能です。

image, blank, void, jpeg image, gif, line, alt, click here!, icon, banner, photo, spacer gif, gif image, ボタン, space, button, clickhere, null, jpeg, spacer, bullet, click here, dashiline, spacer.gif

image という語句が適切な場合も当然のことながら十分にありえます。そのため、この項目は「問題あり」ではなく「問題の可能性大」になっており、miCheckerを使った人自身が最終的な判定を行う必要があります。

根拠

空白文字のみを代替テキストに入れるということは、不適切というよりは、代替テキストの目的を理解していないことを公表しているようなものです。必ず意味のあるテキスト情報を入れるか、alt=""と null を設定します。

ちなみに、NVDAでは次のように空白文字を扱うようです。(非リンクの場合)

  • ノーブレークスペース &nbsp; の場合は、フォーカスがあたり「ブランク」と読み上げる。
  • 半角スペース「 」の場合は、フォーカスは当たらず読み上げもしない。
  • 全角スペース「 」の場合は、フォーカスは当たるが何も読み上げない。無音のままになる。

このように微妙な違いがあります。この違いを何か詩的な表現に使用してみたくなるかもしれませんがお勧めはできません。ブラウザによって動作が異なる可能性があるからです。

不適切なalt属性リストにある語句は、実際によく見かけることの多い語句で大抵の場合画像の内容を適切に表現したものになっていません。どのように設定すれば良いかわからず、エイヤーで image のように入れてしまっていると思われます。

修正方針

支援技術がこの画像を無視して良いと判断できる場合はスペースを削除して alt=""としてください。ただし、リンクの場合は、何らかの情報は必ず必要です。単純にnullにはしないでください。

無視するべきではない画像の場合は、miChecker:『画像にalt属性がありません。代替テキストを提供してください。(もし支援技術がこの画像を無視するべき場合は、 alt=”” と設定してください): src=”*”』を参考に適切な代替テキストを設定してください。

補足

音声ブラウザの黎明期の頃は、アスタリスクや半角スペースを何も無いことの印として入れる場合がありました。いずれもルールとして確立していませんので、WCAG 2.0で求めるとおり alt="" とするのが適切です。

関連する達成基準、達成方法


(他のテクニックは「miChecker対策テクニック集」に整理されています。)

技術コラムAMCC,miChecker

検出理由

「問題あり」として検出される項目です。
alt属性に空白が設定されている場合に指摘されるとありますが、半角スペース、全角スペースではこの項目は検出されません。この項目が検出されるのは、調査した範囲では &nbsp; からなる場合のようです。あまり意味の無い例のように思いますので、他の検出例がありましたら、お知らせいただけると助かります。

なお、半角スペース、全角スペースのケースの場合は「問題の可能性大」の『*は画像のalt属性として不適切な可能性があります。(もし支援技術がこの画像を無視するべき場合は、alt=""と設定してください。そうでなければ適切な代替テキストを提供してください。)』にて検出されます。

<img src="example.png" alt="&nbsp;">

根拠

空白文字のみを代替テキストに入れるということは、不適切というよりは、代替テキストの目的を理解していないことを公表しているようなものです。必ず意味のあるテキスト情報を入れるか、alt=""と null を設定します。

ちなみに、NVDAでは次のように空白文字を扱うようです。(非リンクの場合)

  • ノーブレークスペース &nbsp; の場合は、フォーカスがあたり「ブランク」と読み上げる。
  • 半角スペース「 」の場合は、フォーカスは当たらず読み上げもしない。
  • 全角スペース「 」の場合は、フォーカスは当たるが何も読み上げない。無音のままになる。

このように微妙な違いがあります。この違いを何か詩的な表現に使用してみたくなるかもしれませんがお勧めはできません。ブラウザによって動作が異なる可能性があるからです。

修正方針

支援技術がこの画像を無視して良いと判断できる場合は &nbsp; を削除して alt=""としてください。

ただし、リンクの場合は、何らかの情報は必ず必要です。単純にnullにはしないでください。

補足

音声ブラウザの黎明期の頃は、アスタリスクや半角スペースを何も無いことの印として入れる場合がありました。いずれもルールとして確立していませんので、WCAG 2.0で求めるとおり alt="" とするのが適切です。

関連する達成基準、達成方法


(他のテクニックは「miChecker対策テクニック集」に整理されています。)

技術コラムAMCC,miChecker

代替テキストに関する一般的な事項は miChecker:『画像にalt属性がありません。代替テキストを提供してください。(もし支援技術がこの画像を無視するべき場合は、 alt=”” と設定してください): src=”*”』に整理していますので、そちらもご覧ください。

検出理由

「問題の可能性大」として検出される項目です。
href属性を持つarea要素に、miCheckerの設定で「不適切なalt属性」として登録されたテキストと一致する場合か alt="" と設定されている場合です。

  <area
      shape="rect"
      coords="469,370,1625,450"
      href=".."
      alt="image"
      >

alt属性がまったく存在していない場合は、『area要素にalt属性がありません:*。代替テキストを提供してください。』が検出されます。

alt属性に文字間に空白を含む代替テキストが設定されている場合は、『areaのalt属性 ”*”は文字間に空白を含んでいるため、音声で正確に読み上げることが出来ない可能性があります。』が検出されます。確認して、不要ならば空白を取り除きます。

根拠

area要素はイメージマップを提供する時に使われます。視覚的に見ている人は領域を目視で判別し、クリックしたことで起きるアクション(大抵はリンク)を想像します。しかし、音声ブラウザで操作する人は、area要素で示されるものは画像ですから、その領域固有の情報を代替テキストから得られないと、リンクの目的を知ることができません。(マップ画像全体の代替テキストだけでは不十分です。)

なお、href属性を持たないarea要素の場合、alt属性を省略して良いことになっています。miCheckerも何も検出しません。

修正方針

その領域を選択することで何が起きるかを、機能を提供するイメージ (Function Images) として代替テキストを設定します。

リンクであることは音声ブラウザが伝えてくれますので、わざわざリンクであることを伝える必要はありません。視覚的に見る情報と同じで大抵の場合は十分です。

  <area
      shape="rect"
      coords="469,370,1625,450"
      href=".."
    alt="開発部"
      >

補足

(特になし)

関連する達成基準、達成方法


(他のテクニックは「miChecker対策テクニック集」に整理されています。)

技術コラムAMCC,miChecker

代替テキストに関する一般的な事項は miChecker:『画像にalt属性がありません。代替テキストを提供してください。(もし支援技術がこの画像を無視するべき場合は、 alt=”” と設定してください): src=”*”』に整理していますので、そちらもご覧ください。

検出理由

「問題あり」として検出される項目です。
href属性を持つarea要素に、alt属性による代替テキストが設定されていないと指摘されます。

  <area
      shape="rect"
      coords="469,370,1625,450"
      href=".."
      >

alt属性が空の場合、あるいは不適切と考えられる代替テキストが設定されている場合は、『*はarea要素のalt属性として不適切である可能性があります』が検出されます。* の内容を見直す必要があります。

alt属性に文字間に空白を含む代替テキストが設定されている場合は、『areaのalt属性 ”*”は文字間に空白を含んでいるため、音声で正確に読み上げることが出来ない可能性があります。』が検出されます。確認して、不要ならば空白を取り除きます。

根拠

area要素はイメージマップを提供する時に使われます。視覚的に見ている人は領域を目視で判別し、クリックしたことで起きるアクション(大抵はリンク)を想像します。しかし、音声ブラウザで操作する人は、area要素で示されるものは画像ですから、その領域固有の情報を代替テキストから得られないと、リンクの目的を知ることができません。(マップ画像全体の代替テキストだけでは不十分です。)

なお、href属性を持たないarea要素の場合、alt属性を省略して良いことになっています。miCheckerも何も検出しません。

修正方針

その領域を選択することで何が起きるかを、機能を提供するイメージ (Function Images) として代替テキストを設定します。

リンクであることは音声ブラウザが伝えてくれますので、わざわざリンクであることを伝える必要はありません。視覚的に見る情報と同じで大抵の場合は十分です。

  <area
      shape="rect"
      coords="469,370,1625,450"
      href=".."
    alt="開発部"
      >

補足

(特になし)

関連する達成基準、達成方法


(他のテクニックは「miChecker対策テクニック集」に整理されています。)

技術コラムAMCC,miChecker

代替テキストに関する一般的な事項は miChecker:『画像にalt属性がありません。代替テキストを提供してください。(もし支援技術がこの画像を無視するべき場合は、 alt=”” と設定してください): src=”*”』に整理していますので、そちらもご覧ください。

検出理由

「問題あり」として検出される項目です。
type="image" 属性を持つinput要素に、alt属性による代替テキストが設定されていないと指摘されます。

<input type="image" src="search.png"> <!-- alt属性がない -->

根拠

画像ボタンはアクションを引き起こす元になりますので、そのボタンを押すと何が起きるかが正確に伝わらないと、利用者は操作を誤る可能性があります。例えば、検索ボタンにおいては alt="実行" だけですと、何を実行するのか分からない可能性があります。alt=""では、そもそも検索ボタンを見つけられなくなります。

修正方針

そのボタンを押すとどんなアクションがおきるのか、機能を提供するイメージ (Function Images) として代替テキストを設定します。

検索ボックスの例

お勧めは動詞で書くことです。動詞を用いてアクションであることを明確にします。次のような場合、英語では"search"で十分かもしれませんが、日本語の場合に"検索"だけでは名詞として捉えられる可能性もあり、"検索を実行"あるいは"検索を実行する"とすることをお勧めします。

<input type="image" src="search.png" alt="検索を実行">

補足

placeholderをラベルの代わりに用いるケースが散見されます。一つの方法ではありますが、placeholderはカーソルを当てれば消えてしまいますので、目的には適しません。あくまで補助的なものと位置付けて考えるべきです。

ページ右上の虫メガネマークといえばサイト内検索であるということは、おおよその利用者にとっての共通のエクスペリエンスとなっています。そのため、視覚的にはラベルを省略するケースはあっても良いかもしれません。しかし、音声ブラウザで聞く人、あるいはプログラムが解釈するという観点で見れば、慎重にラベルや実行ボタンは十分な代替情報を記述すべきです。これは、WCAG 2.1 ではより厳密に求められるようになります。

関連する達成基準、達成方法


(他のテクニックは「miChecker対策テクニック集」に整理されています。)

技術コラムAMCC,miChecker

検出理由

「問題あり」として検出される項目です。
img要素にalt属性による代替テキストが設定されていないと指摘されます。

<img src="exampleoflogo.png"> <!-- alt属性がない -->

根拠

全盲の方は画像を見て内容を知ることは困難であり、同時に設定されているはずの代替テキストを代わりに読ませて内容を理解しようとします。代替テキストがないと、得られる情報は何も無いことになり、利用者はそこに何があるかを知ることができません。

サンプル写真

近年、FacebookなどいくつかのWebサービスでは画像を自動認識して代替テキストを付けてくれるようになりつつあります。例えば、この写真には alt="木、草の画像のようです"と自動的に代替テキストが設定されていました。

<img height="960" width="720" alt="木、草の画像のようです" class="(省略)" referrerpolicy="(省略)" src="(省略)">

なかなかの解析能力です。しかし、他にも良い例が無いか探しましたが、ほとんどが"写真の説明はありません。"としかありませんでした。生き物や人の表情については使いものになる解析が行われることも多い様ですが、まだまだ補助的なものとしてみておいた方が良さそうです。(マイクロソフト社が研究している画像認識技術では、人が記述したものと相違ないという研究結果も得られているようです。とても期待しています。)いまは、制作者自身が良く内容を考えて、代替テキストを設定すべきです。

修正方針

画像の目的によって次のように代替テキストを設定します。

意味を持つイメージ (Informative Images)

意味を持つイメージとは、その画像をあえて表示しないとしたら困るような画像のことです。そうしたイメージについては、その画像が持つ情報を代替テキストに設定し誰にでも伝わるようにします。例えば、電話のアイコン画像であれば alt="電話" のように設定します。何かの図解であれば、それを言葉で説明するつもりで考えたテキストを設定します。人物写真では、装飾的なものでない限り、それが誰で、場合によってはどのような感情なのか、あるいは写っている人たちの関係性まで記述します。ただし、冗長にならないことがもっとも大切です。必要な情報のみを的確に伝えましょう。

電話アイコンと電話番号、ファックスアイコンとファックス番号からなる例のイメージ

それぞれの画像に代替テキストによる説明がなければ電話とファックスの違いがわかりません。

<img src="tel-icon.png" alt="電話">03-6265-6620<br>
<img src="fax-icon.png" alt="ファックス">03-6265-6630

装飾的なイメージやイラスト (Decorative Images)

挿絵のような装飾的な画像や、セクションを区切りライン、目を引きやすくするために置いたワンポイントの画像などの場合は、空の代替テキストを設定します。(alt="")仮に、alt属性そのものを付けていないと、音声ブラウザはsrc属性の内容を代わりに読み上げたり、画像が空であることをいちいち通知するので、利用者は余計な情報を聞くことになってしまいます。もし、判断に迷ったら、その画像を紙で隠してみてください。何も困らなければ、それは装飾的な画像として扱えます。

コーヒーアイコン

ここで一休み。少し休んでから続けましょう。

カップは単なる挿絵のようです。このような場合はalt=""で構いません。altすら付けないと、音声ブラウザは「コーヒー アイコン ドット ピーエネジー」あるいは「空の画像」のように読み上げてしまうことがあります。

<img src="coffee-icon.png" alt="">

機能を提供するためのイメージ (Functional Images)

その画像が何かのアクションにつながる場合は、その画像に表示されている内容を説明するのでは足りません。その画像を操作することで、何が起きるかを説明します。例えば、虫眼鏡マークがあって検索を意味するならば、"検索を実行"と入れます。ウィンドウを開くことを示すアイコンであれば、"別ウィンドウを開く"と入れます。なお、リンクであることを伝える必要は必ずしもありません。大抵の音声ブラウザは、リンクであることは"リンク画像 (代替テキストの内容)"のように同時に読み上げてくれるからです。

commenticon

このページでも使われているコメントをする時に使用するアイコンです。この画像に “吹き出し" や “コメント" とあっても今一つわかりにくいと思います。アクションを説明するぺきです。

<img src="comment-icon.png" alt="コメントを付ける">

テキストをイメージにしたもの (Images of Text)

画像に含まれる文字は全て代替テキストに設定しましょう。写真にたまたま映り込んだ文字や、大抵の人は読めないような飾りとしてのテキスト、あるいはロゴに添えてあるスローガンのような、伝える必要の無いテキストの場合は省略可能です。ただし、開催日が書いてあるなど少しでも情報を含んでいるならば代替テキストに含める必要があります。

カタログ

画像化されたテキストはそのまま代替テキストにいれます。

<img src="catlog-icon.png" alt="カタログ">

複雑なイメージ (Complex Images)

グラフや複雑な画像などは、それを掲載することで伝えたかった内容をできるだけ短くシンプルに記述します。どうしても説明が長くなる場合は、例えば、100字も超えるようであれば、画像を適当に分割し、それぞれに代替テキストを設けるか、画像ではなく本文に説明を追加し画像は補助的なものであるようにします。あるいはグラフであれば元データをcsvファイル等で提供するなどします。

複雑な表の例

この例では、ページ全体の内容も加味して考える必要があります。もし、売り上げが右肩上りで伸びていることを示したかったのならば、次の様で十分です。

<img src="graph.png" alt="売り上げが5年で指数関数的に伸びいていることを示すグラフ">

もし、そうした概要ではなく、具体的な情報を提供する必要があるならば、"2015年は2000万、2016年は2300万・・・"と具体的に設定します。それが、あまりに長くなるようであれば、csvファイルを添付し、それをグラフ化したものであることを設定します。

イメージのグループ (Groups of Images)

複数の画像で一つの情報を伝えることがあります。そのような場合は、一つずつの画像ではなく、最初の画像でその画像群の説明をします。

5つの星の画像を並べ、黒い星の数でスコアを示すような場合、一つ一つの画像に"黒い星""白い星"と入れるよりは、最初の画像に"星4つ"のようにいれます。

<img src="black-star.png" alt="星4つ">
<img src="black-star.png" alt="">
<img src="black-star.png" alt="">
<img src="black-star.png" alt="">
<img src="white-star.png" alt="">

イメージマップ (Image Maps)

組織図やフロアマップ、何かの処理のフロー図などが該当します。こうしたイメージは大抵の場合複雑であり(複雑だから絵イメージにしているので当然です)、一つの代替テキストで表現することは困難です。このような場合はarea要素を用いて領域を分割し、その領域ごとに代替テキストを設定します。その場合、関係性がわかる様にしておくことが必要です。

一つの画像で表現された組織図の例です。この例では一つの代替テキストで組織図の内容を記述できそうではありますが、少しでも情報量が多くなると代替テキストも長くなってしまいますので、次の様にすべきです。

<img src="organization.png"
     alt="会社組織図"
     usemap="#Map">
<map name="Map" id="Map">
  <area
    shape="rect"
    coords="516,20,828,180"
    href="…"
    alt="一番上に取締役会">  
  <area 
    shape="rect" 
    coords="278,264,590,424" 
    href="…"
    alt="内部監査室は取り締まり役会を監査する">
  <area 
    shape="rect" 
    coords="516,490,828,650" 
    href="…"
    alt="経営会議は取締役会に報告する">
  <area 
    shape="rect"
    coords="100,740,412,900"
    href="…"
    alt="総務は経営会議に報告する">
  <area
    shape="rect" 
    coords="516,740,828,900" 
    href="…"
    alt="営業部は経営会議に報告する">
  <area
    shape="rect" 
    coords="938,740,1250,900" 
    href="…"
    alt="開発部は経営会議に報告する">
</map>

なぜ、長い代替テキストは好ましくないのか

音声ブラウザで聞いているとき、何と喋ったか聞き取れなかったり、一度聞いただけでは覚えられなかったりすることがあります。そのような場合は、少し戻って聞き直したり、一文字づつ漢字を確認したりしながら読み進めることができるようになっています。

しかし、一般的な音声ブラウザでは、代替テキストに書かれている内容については、それはできません。読み始めたら最後まで聞くしかありません。もう一度聞こうとすれば、代替テキストの最初にまで戻って読み上げるのを聞くしかありません。よって、利用者にとって大切な情報が含まれているのであれば、あまり長い代替テキストは好ましくありません。

迷ったら

お客様によっては、代替テキストの処理を難しく考えすぎて、大きな負担になってしまっているケースがあります。本当は、代替テキストの設定は、コツさえ掴めばそれほど難しいものではありません。

例えば、全盲の方が目の前にいるとき、どのみなさんも、必要なことに絞って口頭でうまく説明するはずです。この画像がどのカテゴリーであるとか、短い長いだとか、そんなことを考える前に、さっと口頭で説明するはずです。それを代替テキストに入れれば良いのです。伝える時の反応が見られない分難しいですが、それは、目の前にいらっしゃると想像すると、幾分楽になります。

地図も迷うものの一つです。地図が持つ情報は大量で、その全ての情報を代替テキストにすることは不可能です。そもそも、テキストで説明できないから地図にしているのですから、それは当たり前のことです。必要なことは、それが地図であることを伝えることと、最低限必要な情報、例えば、最寄りの駅の名前であるとか、そこからの距離を代替テキストに入れて伝えます。

<img src="会社の周辺地図.png" alt="会社の周辺地図です。3番出口からだと5分程度で着きます。">

補足

代替テキストを設定するとき、空のリンクを作らない様に注意してください。この問題には、私どもの検査でもたびたび遭遇します。例えば、直前にリンクテキストがあり、続くリンク画像の代替テキストを二度同じことを聞かない様にするために空にしようとする時があります。このとき、その二つのリンクが分離されていると、画像リンクについては空のリンクになってしまいますので注意が必要です。

<!-- 悪い例
 代替テキストとしては「ホームに戻る」が適当だが、直前に説明があり空にした -->
<a href="home.html">ホームに戻る</a>
<a href="home"><img src="home.png" alt=""></a>
<!-- 良い例
 二つのリンクを一つにまとめた上でaltを空にした -->
<a href="home.html">
  ホームに戻る
  <img src="home.png" alt="">
</a>

関連する達成基準、達成方法


(他のテクニックは「miChecker対策テクニック集」に整理されています。)

技術コラムAMCC,miChecker

検出理由

「問題あり」として検出される項目です。
<meta http-equiv="Refresh">を用いた画面の書き換えが行われ、かつページ指定の無い時、つまりリロードが行われる場合に検出されます。

根拠

利用者によっては画面に書かれた文字を読むことに時間を要することがあります。特に音声ブラウザの利用者においては、キーボードで操作し読み上げて内容を聞き取るため、黙読よりはどうしても時間がかかります。もし、黙読にかかる時間をもとに画面書き換えの時間を決めていたとしたら、おそらく、利用者によってはいつまでたっても情報を得られなくなります。

近年、refreshはほとんど見かけない様になりました。もっと高度な制御が必要になってきており、単純な繰り返しは使われる機会はなくなったのかもしれません。

修正方針

リロードは自動的にさせず、利用者の指示を待って移動するようにするなど変更します。

<!-- <meta http-equiv="refresh" content="20"> -->

関連する達成基準、達成方法


(他のテクニックは「miChecker対策テクニック集」に整理されています。)