お知らせ

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

参加者は約25名でした。

続けて、12月22日に WCAG2.1の後半について説明させていただきます。

一度で説明しきる体力が無く、申し訳ありません。

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

お知らせ

12月8日(水)の内容について、事前にどのような内容か、最初の1つをここでご紹介します。

最初に、1つの問いかけを行います。
状況を示し、このような状況にある方に対して、Webページを制作する上で必要になるアクセシビリティの配慮を、参加している皆様自身で最初に少し考えていただきます。

問い掛けのページ。例では、モバイルデバイスを車椅子に取り付けた方にとって、どんな配慮が必要か問うている。

次にWCAG2.1で新しく追加された、上記の問いに該当する達成基準の説明をします。少し考えた後ですから、きっと、すんなりと意図あるいは根拠も理解できると思います。

該当する達成基準が1.3.4表示の向き(AA)であること、その意図などが書かれています。

意図を理解した後、対処方法について解説します。
基本的にはWCAG2.1の解説書をベースにしますが、すでに検査を行っている経験から、間違えやすいところ、実際に多く誤りが見つかる事、判断に未だ曖昧性がある部分などを率直にお伝えしようと思います。

1.3.4について対処法と補足を記述した資料。地図表示でレイアウトが横向きに強いられていることを適合例として説明している。

もし、解説をお聞きになって、「よく分からない」「いや、そういう意味ではない」「厳しすぎて現実的ではない」「もっと厳しいことを求めている」など、ぜひ、ご指導をいただけるととても有り難いです。私たちも検査を始めたばかりですから、正しい理解をしていないこともあるかもしれません。今は、率直に学び、近い将来、WCAG2.1あるいは2.2の検査が標準で行われるようになる時には、より多くのお客様に貢献したいと考えています。

勉強会の前半では、次の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)

現在のところ、昼の部、夜の部ともに同じくらいの人数が集まりつつあります。どちらも間違いなく開催いたしますので、お気軽にお申し込みください。

→申込ページ

お知らせ

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