技術コラムAMCC,miChecker

検出理由

「問題あり」として検出される項目です。
input要素があって、title属性を用いているとき、そのtitle属性の値が空あるいは空白文字の場合に検出されます。

しかしながら、テストケースをいろいろ作成しましたが、この検出が再現できていません。label要素もtitle属性もないケースは「問題あり」として正しく検出しますが、title属性が空あるいは空白文字の場合は検出しません。

検出しないどころか、label要素もtitle属性も無い箇所が同時に存在し、それだけであれば検出するケースであっても、title="" あるいは title=" " があると検出しなくなるようですので注意が必要です。

加えて、参照する達成方法がH44になっています。title属性による対処はH65で、H44はlabel要素による対処ですので、label要素でのラベルが空のケース、および空白文字のみのテストケースも作成しましたが、いずれも検出はされませんでした。

<!-- 検出しないケース -->
<input type="text" class="form-ctl" id="search4" placeholder="🔍" title="">

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

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

技術コラムAMCC,miChecker

検出理由

「問題の可能性大」として検出される項目です。
alt属性に設定される文字列が150字を超え、151字以上になるとこの項目が検出されます。文字は半角でも全角でも1文字は1文字としてカウントされます。スペースも1文字としてカウントされます。

<!-- 150字を超える代替テキスト -->
<img src="images/logo.gif" alt="1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901">

根拠

音声ブウラザで読み進めているときに、うまく聞き取れず、少し戻って聞き直したい時があります。大抵のスクリーンリーダーでは、単語単位、一定の文字数あるいは一文字づつなど前に戻す仕掛けが用意されていますが、代替テキストの内容を読み上げているときは、それらの機能は利用できません。読み始めたら最後、最後まで聞くしかないのです。戻そうとすれば、読み上げポイントは先頭に戻ってしまい最初から聞くことになってしまいます。代替テキストが長ければ長いほど、このリスクは高まります。たとえ、巻き戻す必要がなかったとしても、利用者には常に注意深く聞かないといけないというストレスを与えます。

修正方針

解決は容易ではありません。説明を長くしたのにはそれなりの理由があるはずだからです。適当に短くするというわけにはいかないはずだからです。このような場合は、次の方法のいずれかを検討してみてください。

1. 代替テキストの内容をもう一度だけ再検討する

なかなか短くできるものではないのですが、それでも、一度は短くすることを考えましょう。それが本当にその画像を通して伝えたかったことなのか、画像の前後で説明済みではないのか、よくよく確認しましょう。

また、そもそも、その画像が視覚的に見る利用者にとって、意味のある情報を提供しているものなのかを考えることも大切です。なんとなく、雰囲気を伝えたくてパワーポイントの絵をそのままイメージにしていることはよくあります。そうした図では、視覚的に見る人にとっても極めて読みにくい場合も多く、そのような場合は"○○の参考図"くらいの代替テキストでも十分かもしれません。

2. area要素で画像を分割し、それぞの代替テキストを設定する

何かのフローやブロックを示すような図の場合は、いくつかのブロックに分割できるかと思います。そのような場合は、その単位でarea要素を使用し、代替テキストをそのブロックごとに設定します。

3. 画像の前後に補足する説明テキストを用意する

画像の説明しているポイントだけでも、テキストにして画像の前後に配置します。視覚的に見ている人にとってみると、画像を読めばわかることが、テキストでも提供されていることになります。やや冗長になるかもしれませんが、画像中の文字は読みにくいと感じる方にとってはありがたいことですし、コピべもできるようになります。そうして、テキストで書き出した分は、代替テキストからは省いてしまいます。

もし、どうしても視覚的に見える形でテキストを配置したくないのであれば、非表示のテキストでこの補足説明を提供する方法もあります。非表示のテキストについては、「White House の取り組むWebアクセシビリティ」を参考にしてください。

4. longdesc属性を利用する

「達成方法 H45」による方法です。別のページに説明を書いたテキストを用意しておき、それへのリンクを設定します。スクリーンリーダーによっては、詳細な説明があことを伝えるようになります。

補足

（なし）

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

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

技術コラムAMCC,miChecker

検出理由

「問題の可能性大」として検出される項目です。
miCheckerでは顔文字は検出していないようです。検出するのはASCIIアートの一部である罫線に記号テキストを用いた場合に、この項目が検出されるようです。

<!-- 31個以上の記号 -->
-------------------------------

確認した範囲では、 – (マイナス)、= (イコール)、* (アスタリスク)、# (シャープ) については、これが31個以上使われていると問題の可能性があると判断していました。おそらく、一般的な記号文字を使った場合も同様と思われます。また、30個以下の場合は検出しないようですが、スペースの含み具合などでは検出する場合もありました。全角文字は検出していないようですが、定かではありません。

根拠

古い音声ブラウザでは、こうした記号の羅列があると、ひたすらその記号を読み上げます。マイナス記号を40個ならべて罫線を表したとすれば、利用者は「マイナス マイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナスマイナス」と耳にすることになります。これは明らかに不便です。

最近の音声ブラウザでは、ある一定数を超えると、「マイナス 40個」などのように読み上げますが、それが問題解決となっているわけではありません。利用者は「マイナス 40個」と聞いて、そこに罫線があるのだと理解するとは限りません。制作者が意図する、例えばコンテンツの区切りと理解してもらえるかどうかは分かりません。

また、記号は読み上げない場合もあります。"(" や “^" は NVDAではデフォルトでは読み上げません。そのため、フェースマーク (^_^) などは「アンダーライン」としか読み上げません。そこに笑顔があることはまず伝わらないでしょう。

iPhone等では単純なフェースマークは、自動的に解釈して、その内容を読み上げることもありますが、すべての顔文字を読み上げることが保証されているわけではありませんから、なんの対策も無しに使用することは止めた方が良いでしょう。

修正方針

基本的にASCIIアートや顔文字は使用しないことをお勧めします。どうしても使用する場合は、前後にテキストで内容を説明してください。あるいは画像で提供することを検討してください。追加するテキストは非表示でも構いません。

<p>旅行はとても楽しかったです。 (^_^)<span class="sr-only">笑顔マーク</sapn>
.sr-only {
  position: fixed !important;
  /* keep it on viewport */
  top: 0px !important;
  left: 0px !important;
  /* give it non-zero size, VoiceOver on Safari requires at least 2 pixels
     before allowing buttons to be activated. */
  width: 4px !important;
  height: 4px !important;
  /* visually hide it with overflow and opacity */
  opacity: 0 !important;
  overflow: hidden !important;
  /* remove any margin or padding */
  border: none !important;
  margin: 0 !important;
  padding: 0 !important;
  /* ensure no other style sets display to none */
  display: block !important;
  visibility: visible !important;
}

補足

クラスsr-onlyについては、次のサイトなど参考にしてください。現在は visually-hidden としているようです。

https://getbootstrap.jp/docs/5.0/helpers/visually-hidden/

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

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

技術コラムAMCC,miChecker

検出理由

「問題の可能性大」として検出される項目です。
input要素のalt属性がmiCheckerの「不適切なalt属性リストの編集」で設定されている語句が使用されている場合に、この項目が検出されます。

<!-- 半角スペース -->
<input type="image" src="images/open.png" alt="void">
miChecker設定

登録された不適切なalt属性は次のようにして確認してください。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

根拠

不適切と思われるalt属性値はアクセシビリティについての知識の無い方が入れがちなものがリストアップされています。いずれも、実際にそう設定されていたことがあるものです。

視覚に頼って操作している方は、次の例を考えて見てください。次のようなフォームがあったらどう思われますか? 文脈から何のボタンかわかるとしても、手を抜いたフォームだと思われませんか? 代替テキストをこのように設定することは、これと同じことをしているのと同じです。

修正方針

すべきことは簡単です。altにそのボタンの目的を記述します。検索を実行するためのものでならば"検索を実行"と入れるのが良いでしょう。フォームの送信であれば"送信"だけで十分かもしれません。

<!-- 半角スペース -->
<input type="image" src="images/open.png" alt="検索を実行">

補足

（なし）

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

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

技術コラムAMCC,miChecker

検出理由

「問題あり」として検出される項目です。
alt属性が空、半角スペース、全角スペースのみで構成されている場合に、この項目が検出されます。

<!-- 半角スペース -->
<input type="image" src="images/open.png" alt=" ">

根拠

ボタンを画像で提供した場合、NVDAは「ボタン (代替テキスト)」と読み上げます。もし、代替テキストが空や空白文字だと「ボタン」としか読み上げません。それでは音声ブラウザの利用者は文脈から何のボタンかを想像するしかありません。

視覚に頼って操作している方は、次の例を考えてみてください。次のようなフォームがあったらどう思われますか? 文脈から何のボタンかわかるとしても、随分と不親切なフォームだと思われませんか? 代替テキストを設定しないとは、これと同じことをしているのと同じです。

修正方針

すべきことは簡単です。altにそのボタンの目的を記述します。検索を実行するためのものでならば"検索を実行"と入れるのが良いでしょう。フォームの送信であれば"送信"だけで十分かもしれません。

<!-- 半角スペース -->
<input type="image" src="images/open.png" alt="検索を実行">

補足

（なし）

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

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

技術コラム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対策テクニック集」に整理されています。)