お知らせ

さる11月24日のセミナーにご参加いただいた皆様、大変ありがとうございました。

参加者は約20名でした。

Twitter等を使った案内もせず、2週間弱の呼びかけでご参加いただいた数としては少なくはないと思います。

また、同じ内容で、年明けにでも行いますので、miCheckerで困っている制作業者様がいらっしゃいましたら、ぜひ、声を掛けていただければと思います。

よろしくお願いいたします。

お知らせ

WCAG 2.1 のウェブアクセシビリティ検査へのニーズが高まりつつあります。日本ではJIS X 8341-3:2016 すなわち WCAG 2.0 への対応までが殆どですが、ワールドワイドで活動している企業においては、SDGs/ESGの観点から、あるいは国の法律や規制、業界団体が求めるガイドライン等に対応するために、WCAG 2.1 で検査する必要が生じてきているからです。

そこで今回のセミナーでは、WCAG 2.1 の検査をすでに提供している検査機関として、新しく追加された達成基準について、その意図と要求事項について解説させていただきます。やや制作者向けでは有りますが、追加された意図など基本的なことについてもご説明しますので、Webの管理・運用に携わる方、広報部門の方などにも有益な情報が提供できるのではないかと思います。

なお、追加された達成基準はレベルAおよびAAで12と多くあるため、今回は、次の6項目について解説いたします。

  • 1.3.4 表示の向き (AA)
  • 1.3.5 入力目的の特定 (AA)
  • 1.4.10 リフロー (AA)
  • 1.4.11 非テキストのコントラスト (AA)
  • 1.4.12 テキストの間隔 (AA)
  • 1.4.13 ホバー又はフォーカスで表示されるコンテンツ (AA)

これまでの検査の経験では、1.4.11の「非テキストのコントラスト」あたりが多く問題が指摘されているようです。この項目はデザインにも影響を与えますので、早めに内容を理解し、対応を進めることが必要と思います。

残りの6項目につきましては、12月22日(水曜日)に同様に無料セミナーとして提供させていただく予定です。

いずれも、御時間が合うようでしたら、是非、ご参加ください。

WCAG 2.1 勉強会(前半)の要領

項目内容
開催日時昼の部　2021年12月8日(水曜日) 16:00〜17:00 (1時間)
夜の部　2021年12月8日(水曜日) 19:30〜20:30 (1時間) (内容に違いはありません)
形式オンライン (Zoom)
申込方法申し込みフォームはこちら
費用無料
制限同業者でも学生でもどなたでも気軽に参加ください。
説明する人株式会社インフォ・クリエイツ 　アクセシビリティ事業本部長、検査部長 飯塚 慎司
経歴音声ブラウザの普及活動
アクセシビリティチェックツールの企画・開発
アクセシビリティ指針の普及活動、JIS X 8341-3 シリーズなど標準化の活動
アクセシビリティ試験(検査)の提供
その他1名でも参加者がいらっしゃれば、必ず実施します。

よろしくお願いいたします。

技術コラムAMCC,miChecker

検出理由

「問題の可能性大」として検出される項目です。
DOCTYPE宣言がない場合に問題が指摘されます。

根拠

現在、DOCTYPE宣言がなくて誤動作するスクリーンリーダーは無いかもしれません。しかし、バリデータが誤った検証結果を返もしてしまったり、文書が仕様に準拠するかどうか判定できない可能性がありますので、対応するようにしてください。

公開識別子が知られたものでない場合は、「問題の可能性大」ではなく、「要判断箇所」として『文書のDOCTYPE宣言で指定された公開識別子はよく知られたものではないようです。そのため、バリデータが誤った検証結果を返す可能性があります。また、文書が仕様に準拠するかどうか判定できない可能性があります。』が指摘がされます。

修正方針

DOCTYPE宣言を追加してください。

補足

（なし）

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

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

お知らせ

申し込みフォームを一つ前の記事「miChecker勉強会のお知らせ (11月24日)」に追加しました。

お申し込み、お待ちしております。

お知らせ

11月に入り、官公庁・自治体のWebアクセシビリティ案件もだんだんと増えてきました。ここを読んでいただけている方も、アクセシビリティ対応に追われる日々が始まっているかもしれません。そんな方のために、miCheckerを使ったアクセシビリティ対策の勉強会を開いてみようと思います。

miCheckerはとても良く出来たツールです。ツールとしてチェックできる項目はほぼ網羅していますし、海外のツールには無いような日本語での読み上げにかかる時間を想定して問題を検出してくれる機能もあります。なかなか有能で素敵なツールです。

しかし、出力メッセージは規格の専門用語で書かれていますので、慣れていないとなかなか理解することは容易ではありません。また、出力されるエラーは「問題あり」で49種類、「問題の可能性大」で43種類もあります。それぞれのそのすべてを理解することはなかなか大変なことです。

今回のセミナーでは、https://accessibility.jp (*)で掲載している『miChecker対策テクニック集』について、特にお客様からよく質問を受ける項目を中心に、丁寧に説明する予定です。御時間が合うようでしたら、是非、ご参加ください。

miChecker勉強会の要領

項目内容
開催日時昼の部　2021年11月24日(水曜日) 16:00〜17:00 (1時間)
夜の部　2021年11月24日(水曜日) 19:30〜20:30 (1時間) (内容に違いはありません)
形式オンライン (Zoom)
申込方法申し込みフォームはこちら
費用無料
制限同業者でも学生でもどなたでも気軽に参加ください。
説明する人株式会社インフォ・クリエイツ 　アクセシビリティ事業本部長、検査部長 飯塚 慎司
経歴音声ブラウザの普及活動
アクセシビリティチェックツールの企画・開発
アクセシビリティ指針の普及活動、JIS X 8341-3 シリーズなど標準化の活動
アクセシビリティ試験(検査)の提供
その他1名でも参加者がいらっしゃれば、必ず実施します。

1回目ですので、欲張らず、10程度のエラー出力の説明をしたいと思っています。

また、この勉強会は何回かのシリーズにて、miCheckerだけでなく、WCAG2.1 や スマートフォンアプリの検査についても、近いうちにお話しできればと考えています。

技術コラムAMCC,miChecker

検出理由

「問題あり」として検出される項目です。
同じid値を持つものが2つ以上ある場合に問題が指摘されます。

根拠

idは、仕様上では1ページの中でユニークなものであることが求められています。同じ値を持つ物を複数設定してはいけません。広く利用されている汎用的なブラウザでは、恐らく、何も問題は起きません。そのため、製作者もidに重複があるに気がつかないことが多くあります。しかし、スクリーンリーダーなど、利用者数が決して多くない支援技術などでは、ちょっとした文法エラーでもうまく処理できずに、おかしな動作をしてしまう可能性があります。

修正方針

PC用とスマートフォン用のコード、例えば検索用のコードなどを1つのページに入れてある場合に、同じidが使われていることがよくあります。動作に問題はないとしても、支援技術が混乱しないように、異なるidを設定してください。

補足

アクセシビリティのエラーにはなりませんが、idの先頭を数字にすることは正しくありません。必ず、先頭文字は英字にしてください。

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

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

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

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

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

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