ウェブページを企画・設計・制作・保守する方達のアクセシビリティ配慮を助け、共に考えるサイトです
先日、聖火リレーの様子を見学する機会を得ました。
手話で話す人、車椅子の人、麻痺のある方、視覚に障害のある人、見た目ではなんの障害かわからない人、さまざまな方が笑顔で聖火をリレーしていきました。若い女性はしきりに髪型を気にして、その時を待っていましたし、緊張の面持ちだった方も最後の記念撮影では全力の笑顔でガッツポーズを繰り返していました。端の方では、静かに涙ぐむ姿ももありました。
ウェブアクセシビリティに取り組んでいる皆様の関心と努力は、きっと、ここにいるメンバー、家族、関係者が、思いもよらぬホームページの問題で、がっかりしたり、悔しい思いをすることがないようにすることに確かに貢献しているのだと思います。回り回って、多くの人を笑顔にすることに貢献しているはずです!
明日からパラリンピックです。これを目標にがんばってきた全ての選手と関係者の皆様が、健康上のリスクを最小限に、これまでの努力の成果を十分に発揮できるよう、心からお祈りします。
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には便利なプラグインが多数提供されています。ソースを直接編集可能にするエディターのプラグインなどもあるようです。そうしたものを使ってももちろん代替テキストの設定はできるようになるはずです。とはいえ、システム部門の方針でプラグインを自由に追加できない場合もあるでしょうから、上記の方法は覚えておくと良いと思います。
「問題あり」として検出される項目です。
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対策テクニック集」に整理されています。)
「問題の可能性大」として検出される項目です。
alt属性に設定される文字列が150字を超え、151字以上になるとこの項目が検出されます。文字は半角でも全角でも1文字は1文字としてカウントされます。スペースも1文字としてカウントされます。
<!-- 150字を超える代替テキスト --> <img src="images/logo.gif" alt="1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901">
音声ブウラザで読み進めているときに、うまく聞き取れず、少し戻って聞き直したい時があります。大抵のスクリーンリーダーでは、単語単位、一定の文字数あるいは一文字づつなど前に戻す仕掛けが用意されていますが、代替テキストの内容を読み上げているときは、それらの機能は利用できません。読み始めたら最後、最後まで聞くしかないのです。戻そうとすれば、読み上げポイントは先頭に戻ってしまい最初から聞くことになってしまいます。代替テキストが長ければ長いほど、このリスクは高まります。たとえ、巻き戻す必要がなかったとしても、利用者には常に注意深く聞かないといけないというストレスを与えます。
解決は容易ではありません。説明を長くしたのにはそれなりの理由があるはずだからです。適当に短くするというわけにはいかないはずだからです。このような場合は、次の方法のいずれかを検討してみてください。
なかなか短くできるものではないのですが、それでも、一度は短くすることを考えましょう。それが本当にその画像を通して伝えたかったことなのか、画像の前後で説明済みではないのか、よくよく確認しましょう。
また、そもそも、その画像が視覚的に見る利用者にとって、意味のある情報を提供しているものなのかを考えることも大切です。なんとなく、雰囲気を伝えたくてパワーポイントの絵をそのままイメージにしていることはよくあります。そうした図では、視覚的に見る人にとっても極めて読みにくい場合も多く、そのような場合は"○○の参考図"くらいの代替テキストでも十分かもしれません。
何かのフローやブロックを示すような図の場合は、いくつかのブロックに分割できるかと思います。そのような場合は、その単位でarea要素を使用し、代替テキストをそのブロックごとに設定します。
画像の説明しているポイントだけでも、テキストにして画像の前後に配置します。視覚的に見ている人にとってみると、画像を読めばわかることが、テキストでも提供されていることになります。やや冗長になるかもしれませんが、画像中の文字は読みにくいと感じる方にとってはありがたいことですし、コピべもできるようになります。そうして、テキストで書き出した分は、代替テキストからは省いてしまいます。
もし、どうしても視覚的に見える形でテキストを配置したくないのであれば、非表示のテキストでこの補足説明を提供する方法もあります。非表示のテキストについては、「White House の取り組むWebアクセシビリティ」を参考にしてください。
「達成方法 H45」による方法です。別のページに説明を書いたテキストを用意しておき、それへのリンクを設定します。スクリーンリーダーによっては、詳細な説明があことを伝えるようになります。
（なし）
(他のテクニックは「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対策テクニック集」に整理されています。)
「問題の可能性大」として検出される項目です。
input要素のalt属性がmiCheckerの「不適切なalt属性リストの編集」で設定されている語句が使用されている場合に、この項目が検出されます。
<!-- 半角スペース --> <input type="image" src="images/open.png" alt="void">
登録された不適切な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対策テクニック集」に整理されています。)
「問題あり」として検出される項目です。
alt属性が空、半角スペース、全角スペースのみで構成されている場合に、この項目が検出されます。
<!-- 半角スペース --> <input type="image" src="images/open.png" alt=" ">
ボタンを画像で提供した場合、NVDAは「ボタン (代替テキスト)」と読み上げます。もし、代替テキストが空や空白文字だと「ボタン」としか読み上げません。それでは音声ブラウザの利用者は文脈から何のボタンかを想像するしかありません。
視覚に頼って操作している方は、次の例を考えてみてください。次のようなフォームがあったらどう思われますか? 文脈から何のボタンかわかるとしても、随分と不親切なフォームだと思われませんか? 代替テキストを設定しないとは、これと同じことをしているのと同じです。
すべきことは簡単です。altにそのボタンの目的を記述します。検索を実行するためのものでならば"検索を実行"と入れるのが良いでしょう。フォームの送信であれば"送信"だけで十分かもしれません。
<!-- 半角スペース --> <input type="image" src="images/open.png" alt="検索を実行">
（なし）
(他のテクニックは「miChecker対策テクニック集」に整理されています。)
「問題あり」として検出される項目です。
object 要素によるコンテンツのレンダリングができない場合、代替のコンテンツが提供されるようになっていないと問題として指摘されます。
<object (10分おきの株価をイメージにして表示する外部コンテンツ)> </object>
object要素によって組み込まれる外部コンテンツがレンダリングされない場合、代替のテキストが無いと利用者は何が起きているのか知ることができません。代替コンテンツを提供していれば、少なくとも、そこに何が提供されようとしていたのか、あるいは、同等のコンテンツを提供することも可能になるかもしれません。
代替コンテンツを提供します。
例えば、10分おきに株価を表示する外部コンテンツを組み込む場合、仮にそれが機能しなくとも、そこで何が提供されているかわかるようにします。
<object (10分おきの株価をイメージにして表示する外部コンテンツ)> 株価を10分おきに更新して表示するコンテンツがあります。お使いの環境では正しく動作していません。 </object>
可能ならば、代替となるページへのリンクも追加すると良いでしょう。
(特になし)
object 要素のボディを使用する(他のテクニックは「miChecker対策テクニック集」に整理されています。)
「問題あり」として検出される項目です。
applet 要素にalt属性による代替テキストが設定されていないと指摘されます。
しかし、そもそも、HTML4.01以降では使用することのできない要素であり、いつ、ブラウザで動作しなくなるとも分かりません。これが検出された場合は、該当箇所の削除、あるいはobject要素など用いて他の方法で実装するべきです。どうしても残す場合は、埋め込むJava アプレットであることと目的を代替テキストとしてapplet要素に記述すると良いでしょう。
(省略)
(省略)
(特になし)
img 要素、area 要素、及び type "image" の input 要素の alt 属性又はテキストによる代替を省略しているapplet 要素にテキストによる代替を提供する(他のテクニックは「miChecker対策テクニック集」に整理されています。)