miChecker 対策テクニック集の掲載を始めるにあたって

技術コラムAMCC,miChecker

miCheckerが検出する問題の種類

miCheckerは問題を4つの種類に分けて検出します。
「問題あり」として検出する箇所は、ほぼ間違いなく問題を含んでいます。
「問題の可能性大」と検出する箇所は、問題ではない場合もあり、人による判断が必要になります。
「要判断箇所」は判定が必要と考えられる箇所を示しているだけで、問題があるかどうかは人が目視で判定してみないと分かりません。
「手動確認」は、判定すべき箇所があるかどうかもわからない項目です。人が目視でページ全体から該当箇所を探し、該当箇所があれば判定を行います。
この4種類の指摘項目をすべてを判定していくことで、十分な検査を行うことができるようになっています。

もう少し勉強した方ならば、AC/AF/HCという分け方をご存知と思います。(参考 : JIS X 8341-3:2016 試験実施ガイドライン(実装チェックリストの作成方法の具体例))これに当てはめるならば、「問題あり」と「問題の可能性大」が AC。「要判断箇所」はAF。「手動確認」がHCとざっくりわけることができます。
将来、AIを活用し、ACやAFの検出割合が増えると良いと期待しています。

1ページでも4時間は検査にかかるもの

miCheckerを用いた検査の場合、すべての指摘項目を検査するとおおむね4時間はかかります。経験的には、最初のページの場合は4時間でも難しいでしょう。ただ、2ページ目以降は似たコーディングを判定することも多くなりますから、検査時間は短くなります。40ページも検査する場合ならば、平均では 4時間を切るかもしれません。しかし、いずれにしても大変な作業です。

「問題あり」「問題の可能性大」しか活用できていない

検査方法として「miCheckerを用いて検査した」と報告するサイトが多いのですが、私たちからみると「問題あり」あるいは「問題の可能性大」で指摘された項目だけに注目して検査し、問題に対処しているように見えます。残念ながら、「要判断箇所」や「手動確認」は無視しているように見えます。そのため、適切な検査が行われているのか疑問に思うサイトは少なくないのが現状です。最初に説明しましたように、miCheckerは検査に必要なすべての項目を示しています。「要判断箇所」「手動確認」の箇所ももれなく検査することで規格の要求を完全に満たす検査を実施したいものです。

その上で(完全な検査、つまり目視検査を実施した上で)、「問題あり」「問題の可能性大」の項目だけをサイト全体に渡って調査することには大きな意味があります。これについては、別の機会を設けて説明したいと思います。

浅い知識では修正は負担になる

こうした状況を引き起こす理由の一つは、「問題あり」「問題の可能性大」のような問題がはっきりしているものであっても、実際に修正しようとすると、典型的な例による説明だけでは具体的にはどうしたら良いか分からないことが多いからでしょう。具体的な解決案を考えるには、なぜその問題が指摘され、どう改善するとどのような効果があるのか、その改善に使うテクニックは何か、そして、それが使えない場合、他にどんな代案があるのか?こうしたことが一通り分かっている必要があります。そうでないと、簡単なことでも修正に時間を要したり、大きな負担になってしまいます。反対に適切に一通りの知識を持っていれば、代案も思いつくようになりますし、対応の程度も検討がつくようになります。

miChecker対策テクニック集では

そこで、accessibility.jpでは、miCheckerが出力する主要な指摘項目について、検出理由、与える問題、修正方針、効果を指摘問題対策集として説明していく予定です。これにより、miCheckerがもっと有効に活用されるようになって欲しいと考えています。

[miChecker対策テクニック集]

miChecker のインストールから使用方法の概要については、こちらをご覧ください。→ リソース > ツール > miChecker

2021年1月15日