ウェブページを企画・設計・制作・保守する方達のアクセシビリティ配慮を助け、共に考えるサイトです
総務省「みんなのアクセシビリティ評価ツール：miChecker（エムアイチェッカー）」のVer.3.0公開から早2ヶ月が経とうとしています。皆様、もうお使いでしょうか？
総務省｜みんなのアクセシビリティ評価ツール：miChecker (エムアイチェッカー)Ver.3.0
今後は令和5年度中を新バージョンへの移行期間とし、旧バージョンについては公開終了を予定しているとのことです。
初めてお使いの方、旧バージョンからの乗り換えに重い腰を上げた方、ぜひ一緒にmiChecker Ver.3.0を導入してみましょう。（所要時間：15分程度）
「問題の可能性大」として検出される項目です。
DOCTYPE宣言がない場合に問題が指摘されます。
現在、DOCTYPE宣言がなくて誤動作するスクリーンリーダーは無いかもしれません。しかし、バリデータが誤った検証結果を返もしてしまったり、文書が仕様に準拠するかどうか判定できない可能性がありますので、対応するようにしてください。
公開識別子が知られたものでない場合は、「問題の可能性大」ではなく、「要判断箇所」として『文書のDOCTYPE宣言で指定された公開識別子はよく知られたものではないようです。そのため、バリデータが誤った検証結果を返す可能性があります。また、文書が仕様に準拠するかどうか判定できない可能性があります。』が指摘がされます。
DOCTYPE宣言を追加してください。
（なし）
(他のテクニックは「miChecker対策テクニック集」に整理されています。)
「問題あり」として検出される項目です。
同じid値を持つものが2つ以上ある場合に問題が指摘されます。
idは、仕様上では1ページの中でユニークなものであることが求められています。同じ値を持つ物を複数設定してはいけません。広く利用されている汎用的なブラウザでは、恐らく、何も問題は起きません。そのため、製作者もidに重複があるに気がつかないことが多くあります。しかし、スクリーンリーダーなど、利用者数が決して多くない支援技術などでは、ちょっとした文法エラーでもうまく処理できずに、おかしな動作をしてしまう可能性があります。
PC用とスマートフォン用のコード、例えば検索用のコードなどを1つのページに入れてある場合に、同じidが使われていることがよくあります。動作に問題はないとしても、支援技術が混乱しないように、異なるidを設定してください。
アクセシビリティのエラーにはなりませんが、idの先頭を数字にすることは正しくありません。必ず、先頭文字は英字にしてください。
(他のテクニックは「miChecker対策テクニック集」に整理されています。)
::after疑似要素を用いてコンテンツが挿入されている場合「問題の可能性大」として指摘される項目です。
実際、これが問題であることは多く、検出された場合は注意して確認し、必要に応じて対処する必要があります。
例えば次のように指定されていたとします。
p.good:before { content: "大正解: " }
p.bad:before { content: "不正解: " }
これを次のようにして用いたとします。
コードの例 <p class="good"> <q>::before疑似要素を使って追加されたコンテンツはスクリーンリーダーの読み上げ対象にならない場合があるので注意が必要である。</q> </p> <p class="bad"> <q>::before疑似要素を使って追加されたコンテンツはスクリーンリーダーの読み上げ対象になるので、何の配慮もなく使用して構わない。</q> </p>
これで、それぞれの文章の前に「大正解:」と「不正解:」が表示されますが、スクリーンリーダーはこれを読み上げ無い可能性があります。
この手法によるコンテンツの追加は大変便利ですが、スクリーンリーダーによっては対応していないと考えて下さい。つまり、期待しているような表示はされず、音声化されることもありません。
残念ながら根本的な修正方法はありません。これを重要な項目には利用しないことしかできません。
例えば、隠しテキストで対処する方法が考えられますが、それであれば、疑似要素は使わずに普通に表示すれば良いことになります。よって、疑似要素は、視覚的に見て操作しているに向けて、補助的なものとして何か情報を提供するときに使用は限るようにしてください。あるいは、装飾的なものに限ってください。
（なし）
(他のテクニックは「miChecker対策テクニック集」に整理されています。)
::before疑似要素を用いてコンテンツが挿入されている場合「問題の可能性大」として指摘される項目です。
実際、これが問題であることは多く、検出された場合は注意して確認し、必要に応じて対処する必要があります。
例えば次のように指定されていたとします。
p.good:before { content: "大正解: " }
p.bad:before { content: "不正解: " }
これを次のようにして用いたとします。
コードの例 <p class="good"> <q>::before疑似要素を使って追加されたコンテンツはスクリーンリーダーの読み上げ対象にならない場合があるので注意が必要である。</q> </p> <p class="bad"> <q>::before疑似要素を使って追加されたコンテンツはスクリーンリーダーの読み上げ対象になるので、何の配慮もなく使用して構わない。</q> </p>
これで、それぞれの文章の前に「大正解:」と「不正解:」が表示されますが、スクリーンリーダーはこれを読み上げ無い可能性があります。
この手法によるコンテンツの追加は大変便利ですが、スクリーンリーダーによっては対応していないと考えて下さい。つまり、期待しているような表示はされず、音声化されることもありません。
残念ながら根本的な修正方法はありません。これを重要な項目には利用しないことしかできません。
例えば、隠しテキストで対処する方法が考えられますが、それであれば、疑似要素は使わずに普通に表示すれば良いことになります。よって、疑似要素は、視覚的に見て操作しているに向けて、補助的なものとして何か情報を提供するときに使用は限るようにしてください。あるいは、装飾的なものに限ってください。
（なし）
(他のテクニックは「miChecker対策テクニック集」に整理されています。)
「問題あり」として検出される項目です。
a要素の開始タグと終了タグの間に何もテキストの情報が提供されていない場合に、この項目が検出されます。
よく見かけるのはリンク画像を提供し、その代替テキストが空になっている場合です。あるいは、スタイルシートでリンクと分かるような画像を表示させている場合なども該当します。
<!-- リンク画像に代替テキストが設定されていないケース --> <a href="/news/"><img src="newsicon.png" alt="" /></a> <!-- スタイルシートでアイコンを表示しているケース --> <a href="/news/" class="newsicon"></a>
この問題はスクリーンリーダーの利用者にとっては致命的です。もし検出されていたら、いま直ぐに修正すべきです。目で見て操作している人の状況に例えるならば、肝心のリンクが黒塗りされているか、切り取られて存在しない状態になっているのと同じ状態です。利用者には大変失礼であり、最悪の状態にあると思ってください。
しかし、残念ながらこの問題が検出されるウェブページは少なくありません。リンクが失われることは大きな問題になりますから、このような場合、スクリーンリーダーは読み上げるべき情報がないことを伝えたり、あるいは飛び先として指定されているURLを読み上げるなど工夫します。あるいは、そのページのタイトルを読み上げるような場合もあります。
URLなど読み上げて、たまたま内容が理解できれば良いですが、大抵はそのような情報は製作者の為のものであって、利用者に提供するものではないため、利用者においてはますます混乱してしまいます。
リンク画像の場合は画像にしっかりとalt属性を入れれば問題は解決します。
cssで画像を表示している場合は少し対処は難しくなります。たまに、cssのcontentプロパティに情報を入れている場合がありますが、それでは不十分です。実は、スクリーンリーダーによってはcontentプロパティを読み上げてくれたりもしますが、読み上げない場合もありますし、htmlの定義から考えれば、cssにそのような役割をさせるべきではありません。このような場合は、非表示のテキストを追加するのがもっとも容易です。
<!-- リンク画像に代替テキストが設定されていないケース --> <a href="/news/"><img src="newsicon.png" alt="ニュース" /></a> <!-- スタイルシートでアイコンを表示しているケース --> <a href="/news/" class="newsicon"><span class="visually-hidden">ニュース</sapn></a>
なお、a要素にtitle属性を用いる方法では適合にはなりません。title属性は補足情報を提供するものであって、主となる情報提供に用いることはできません。
（なし）
(他のテクニックは「miChecker対策テクニック集」に整理されています。)
「問題の可能性大」として検出される項目です。しかし、実際にはほとんどの場合が「問題あり」になります。
ページ内リンクにおいて、a要素の開始タグと終了タグの間に何もテキストの情報が提供されておらず、a要素にtitle属性が使用されている場合に、この項目が検出されます。
よく見かけるのはリンク画像を提供し、その代替テキストが空になっている場合です。あるいは、スタイルシートでリンクと分かるような画像を表示させている場合なども該当します。
<!-- リンク画像に代替テキストが設定されていないケース --> <a href="#news" title="ニュース一覧"><img src="newsicon.png" alt="" /></a> <!-- スタイルシートでアイコンを表示しているケース --> <a href="#news" class="newsicon" title="ニュース一覧"></a>
この問題はスクリーンリーダーの利用者にとっては致命的です。もし検出されていたら、いま直ぐに修正すべきです。title属性はアクセシビリティのための対策とはなりません。
目で見て操作している人にとっては、ツールチップが現れて便利かもしれません。（この場合でも、リンクの目的を示すようなものをそこに表示させているわけではなく、補助的な情報であることに注意が必要です） しかし、スクリーンリーダーで利用している人にとっては、依然、肝心のリンクが黒塗りされているか、切り取られて存在しない状態になっているようなものです。利用者には大変失礼であり、最悪の状態にあると思ってください。
リンクが失われることは大きな問題になりますから、このような場合、スクリーンリーダーは読み上げるべき情報がないことを伝えたり、あるいは飛び先として指定されているURLを読み上げるなど工夫します。あるいは、そのページのタイトルを読み上げるような場合もあります。
URLなど読み上げて、たまたま内容が理解できれば良いですが、大抵はそのような情報は製作者の為のものであって、利用者に提供するものではないため、利用者においてはますます混乱してしまいます。
リンク画像の場合は画像にしっかりとalt属性を入れれば問題は解決します。title属性を消す必要はありません。ただし、alt属性とtitle属性を同一にすることはおかしなことです。title属性には、例え、それが誰にも伝わらなかったとしても、問題の無い補足的な情報を入れるに留めてください。
cssで画像を表示している場合は少し対処は難しくなります。たまに、cssのcontentプロパティに情報を入れている場合がありますが、それでは不十分です。実は、スクリーンリーダーによってはcontentプロパティを読み上げてくれたりもしますが、読み上げない場合もありますし、htmlの定義から考えれば、cssにそのような役割をさせるべきではありません。このような場合は、非表示のテキストを追加するのがもっとも容易です。
<!-- リンク画像に代替テキストが設定されていないケース --> <a href="#news" title="ニュース最新情報"><img src="newsicon.png" alt="ニュース" /></a> <!-- スタイルシートでアイコンを表示しているケース --> <a href="#news" class="newsicon" title="ニュース最新情報"><span class="visually-hidden">ニュース</sapn></a>
（なし）
(他のテクニックは「miChecker対策テクニック集」に整理されています。)
「問題あり」として検出される項目です。
ページ内リンクにおいて、a要素の開始タグと終了タグの間に何もテキストの情報が提供されていない場合に、この項目が検出されます。
よく見かけるのはリンク画像を提供し、その代替テキストが空になっている場合です。あるいは、スタイルシートでリンクと分かるような画像を表示させている場合なども該当します。
<!-- リンク画像に代替テキストが設定されていないケース --> <a href="#news"><img src="newsicon.png" alt="" /></a> <!-- スタイルシートでアイコンを表示しているケース --> <a href="#news" class="newsicon"></a>
この問題はスクリーンリーダーの利用者にとっては致命的です。もし検出されていたら、いま直ぐに修正すべきです。目で見て操作している人の状況に例えるならば、肝心のリンクが黒塗りされているか、切り取られて存在しない状態になっているのと同じ状態です。利用者には大変失礼であり、最悪の状態にあると思ってください。
しかし、残念ながらこの問題が検出されるウェブページは少なくありません。リンクが失われることは大きな問題になりますから、このような場合、スクリーンリーダーは読み上げるべき情報がないことを伝えたり、あるいは飛び先として指定されているURLを読み上げるなど工夫します。あるいは、そのページのタイトルを読み上げるような場合もあります。
URLなど読み上げて、たまたま内容が理解できれば良いですが、大抵はそのような情報は製作者の為のものであって、利用者に提供するものではないため、利用者においてはますます混乱してしまいます。
リンク画像の場合は画像にしっかりとalt属性を入れれば問題は解決します。
cssで画像を表示している場合は少し対処は難しくなります。たまに、cssのcontentプロパティに情報を入れている場合がありますが、それでは不十分です。実は、スクリーンリーダーによってはcontentプロパティを読み上げてくれたりもしますが、読み上げない場合もありますし、htmlの定義から考えれば、cssにそのような役割をさせるべきではありません。このような場合は、非表示のテキストを追加するのがもっとも容易です。
<!-- リンク画像に代替テキストが設定されていないケース --> <a href="#news"><img src="newsicon.png" alt="ニュース" /></a> <!-- スタイルシートでアイコンを表示しているケース --> <a href="#news" class="newsicon"><span class="screen-reader-text">ニュース</span></a>
class screen-reader-text については"White House の取り組むWebアクセシビリティ“をご覧下さい。これにより、視覚的に「ニュース」が表示されることはありませんが、音声ブラウザはしっかりと「ニュース」と読み上げてくれます。
なお、a要素にtitle属性を用いる方法では適合にはなりません。title属性は補足情報を提供するものであって、主となる情報提供に用いることはできません。
（なし）
(他のテクニックは「miChecker対策テクニック集」に整理されています。)
html要素にlang属性は存在していますが、プログラムがlang属性の値を読み取ることができない場合にこの問題が検出されます。
音声ブウラザはそのページの使用言語がわかると読み上げに使用する音声エンジンをその言語に切り替える機能を持つものがあります。ただしく、プログラムが解釈可能なように正しく設定されている必要があります。
そこで、miCheckerではlang属性が存在するか、また、正しく設定されているかをチェックし報告してくれます。本ページで紹介しているケースは、lang属性値が正しく設定されていない場合に検出されます。確認できた範囲では次のような時に検知されます。
また、属性間にスペースを設けない場合なども本問題が指摘される可能性があります。
なお、lang属性そのものが存在しない場合は、『文書内で主に利用されている言語を*属性を用いて明示してください (例： <html lang="ja">)』が検出されます。
エラーが検出された場合、何か文法上のエラーが無いか確認してください。見つけたら、それを直してみてください。w3c validator を用いて確認するのも良いかもしれません。
<!-- htmlの場合 --> <html lang="en"> <!-- xhtml1.0の場合 --> <html lang="en" xml:lang="en"> <!-- xhtml1.1の場合 --> <html xml:lang="en">
経験的にはCMSなど用いているわけではなく、ソースコードを直接エディターで編集しているようなケースで検出されることがあるように思います。ご注意ください。
(他のテクニックは「miChecker対策テクニック集」に整理されています。)
Gmailはブラウザさえあれば利用できますから、ちょっとした時に便利で私もたまに使用しています。基本的にはテキストメールしか送らないのですが、たまに画像など貼り付ける場合もあります。そんなとき、Gmailが提供しているWysiWigエディターでは代替テキストを設定することができません。Gmailでできるのサイズを調整することくらいです。
こんなときは、Googleドキュメントを開いて、そこに画像を貼り付けます。続いて、貼り付けた画像上で右クリックすると代替テキストの設定画面へのコンテキストメニューが現れます。
あとは簡単です。この代替テキスト設定済み画像をGmailのエディターにCopy&Pasteして貼り付けるだけです。これで代替テキストの付きのソースコードを含んだまま画像が貼り付けられます。
Googleドキュメントでなくとも、HTMLエディターであれば同様のことは可能なはずです。利用者の多いと思われるマイクロソフトワード については、デフォルトですとソースコード中に不要な要素が多く、GoogleのWysiWigエディターにはうまく貼り付けることができないようです。(ワードの設定でできるようになる可能性はありますが、試していません)
Gmailでは署名を管理する機能を提供しています。署名でも同様に他のエディターやあるいはWebページからそのまま貼り付けることで、代替テキスト付き画像を貼り付けた署名を作成することができまです。
Gmailには便利なプラグインが多数提供されています。ソースを直接編集可能にするエディターのプラグインなどもあるようです。そうしたものを使ってももちろん代替テキストの設定はできるようになるはずです。とはいえ、システム部門の方針でプラグインを自由に追加できない場合もあるでしょうから、上記の方法は覚えておくと良いと思います。