技術コラムAMCC,miChecker

検出理由

「問題あり」として検出される項目です。
そのページが何語で書かれているか、html要素にlang属性を用いた指定がありません。

根拠

音声ブウラザはそのページの使用言語がわかると読み上げに使用する音声エンジンをその言語に切り替える機能を持つものがあります。もし、英語のページなのに日本語と指定したりすると、日本語の音声エンジンで読み上げようとするため、無音になってしまうか、意味の無いアルファベットなど読み上げることになり、利用者を混乱させてしまいます。

『日本語のページは日本語で書かれているのだから、そのページが日本語で書かれていることはすぐにわかるのでは無いか。』と思われるかもしれません。確かに、広く使われているブラウザの場合は、lang属性がなくとも、そのページで使用されている言語を高い確率で推測する機能が備わっています。しかし、完璧とは限りませんし、音声ブウラザなど利用者の少ないブラウザでは、そうした機能が十分に備わっているわけではないとご理解ください。

修正方針

HTMLの場合、html要素にlang属性を追加します。
XHTML1.0の場合、html要素にlang属性とxml:lang属性を追加します。
XHTML1.1の場合、html要素にxml:lang属性を追加します。

<!-- htmlの場合 -->
<html lang="en">

<!-- xhtml1.0の場合 -->
<html lang="en" xml:lang="en">

<!-- xhtml1.1の場合 -->
<html xml:lang="en">

補足

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

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

技術コラムAMCC,miChecker

検出理由

「問題あり」として検出される項目です。
<meta http-equiv="Refresh">を用いた画面の書き換えが行われ、時間が0秒以外の時に検出されます。ただし、miChekcerをローカルで実行する場合では、すぐにリダイレクトされてしまいリダイレクト後のページを検証することになるため、この問題はあまり検出されません。miCheckerを検証エンジンに持つクラウドサービス等では検出されることがあります。

根拠

利用者によっては画面に書かれた文字を読むことに時間を要することがあります。特に音声ブラウザの利用者においては、キーボードで操作し読み上げて内容を聞き取るため、黙読よりはどうしても時間がかかります。もし、黙読にかかる時間をもとに画面書き換えの時間を決めていたとしたら、おそらく、利用者によってはいつまでたっても情報を得られなくなります。

よく見かけるのは404ページにおいてです。一定時間、urlが変わったことを表示し、その後、リダイレクトするパターンです。

修正方針

遷移は自動的にさせず、利用者の指示を待って移動するようにします。利用者によっては、その間にブックマークを修正するかもしれませんし、別のアクションをとるかもしれません。あるいは、次ように間髪入れずリンクするようにします。

<meta http-equiv="refresh" content="0,(url)">

補足

urlが省略されている場合は周期的なリロードが行われることを意味します。この場合も同じ問題が発生していることになりますので、miCheckerは次の指摘を行います。

2.2.1 『周期的にページのリロードを行う事は避けてください (<meta http-equiv="Refresh">の利用は避けてください)』

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

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

技術コラムAMCC,miChecker

検出理由

「問題の可能性大」として検出される項目です。
文字間に空白を含んでいるときに検出されます。単語の間に空白があれば常に検出しているわけではなく、漢字の文字数と空白の数などで判定しているようです。漢字２文字からなる単語を１つの空白で２分割すると必ず指摘されます。漢字３文字あるいは４文字だと２つの空白で３分割されると指摘されます。

なお、姓が「森」名が「花」というような場合に「森　花」と表現するのは間違いではありません。しかし、miCheckerではこれも問題の可能性大として検出します。そのため、すべての検出箇所は目視で本当に問題かどうかを確認する必要があります。

根拠

ブラウザや支援技術などのプログラムは、テキストを解析する際に空白は区切りであると認識する可能性があります。例えば、音声ブラウザは読み上げの際に誤った読み上げを行う可能性があります。あるいは、音声認識プログラムで操作しようとしたとき、発声した内容とプログラムが認識している語に相違が生じる可能性もあります。

音声ブラウザは「日　時」を＂にちじ＂と読まずに"ひ　じ“と読み上げる。

音声入力でブラウザを操作している場合、「入　力」ボタンがあったとして、「にゅうりょく」と発声しても反応せず、「いり ちから」と発声しないと反応しない。

修正方針

文字間に空白を入れたい場合は letter-spacing を使います。調整のコツは半角スペースを追加しているケースならば 0.5em、全角スペースを追加しているケースならば1em、全角スペース2個ならば2em程度を追加すれば似たような感じになります。

.space {letter-spacing: 1em;}

ただし、文字をセンタリングしている場合は、文字が左側に寄り気味になるはずです。その場合は text-indentを加えて調整します。

  .space {letter-spacing: 1em;
          text-indent: 0.5em;}

補足

日本語の場合、文字間を広めても比較的混乱はし難いですが、英単語の場合は、もともと空白が単語と単語の区切りを示すので過度に文字間を広げると読みにくくなります。また、日本語の場合でも、読字障害などではやはり文字間隔の空いたテキストは認識が困難になる場合があります。画面を拡大して文字を追っている人も当然読みにくくなります。よほど詰まって見難いという時以外は、無用に文字間を広げるべきではありません。

miCheckerでは文字間空白を次のケースでも検出し報告します。

  • ”（検出語）”ボタン（inputのvalue属性）は文字間に空白を含んでいるため、音声で正確に読み上げることが出来ない可能性があります。
  • （検出語）は文字間に空白を含んでいるため、音声で正確に読み上げることが出来ない可能性があります
  • areaのalt属性”（検出語）”は文字間に空白を含んでいるため、音声で正確に読み上げることが出来ない可能性があります。
  • 画像のalt属性”（検出語）”は文字間に空白を含んでいるため、音声で正確に読み上げることが出来ない可能性があります。
  • 画像ボタンのalt属性”（検出語）”は文字間に空白を含んでいるため、音声で正確に読み上げることが出来ない可能性があります。

「問題の可能性大」の項目ではありますが、指摘の正解率も高い項目ですので、指摘された箇所はすべて確認し問題の無いことを確認すべきです。

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

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

技術コラムAMCC,miChecker

検出理由

「問題あり」として検出される項目です。
フォントサイズの指定に px および pt を使用している場合に検出されます。miCheckerの場合、検出対象は style要素あるいはstyle属性でページ内で指定されているフォントサイズ、及びlink要素で外部リソースとしてリンクされている外部スタイルシートにおける指定が対象になります。

根拠

pt と px はフォントサイズの指定でもっともよく用いられる単位です。pt は1/72インチ（0.352mm）相当であり、px は画面上のピクセル数を示す絶対単位です。この pt あるいは px を用いて作成されたページでは、期待するようにテキストは拡大されない可能性があります。その為、相対単位でありテキストの拡大が有効に働く em や rem を使うことが求めらてれいます。

また、ディスプレイの解像度にも影響を受けますので、環境によっては文字が小さくなりすぎることもあります。

修正方針

相対的にサイズを指定する em や rem を単位として使用します。値の変換が必要になりますが、"pt px em 変換“として検索エンジンで探せば、いくらでも変換表や変換サービスを提供するサイトを見つけることができます。

補足

本問題が指摘されていてもズーム拡大（文字も画像も同一尺度で拡大する）で問題がなければ不適合とはなりません。しかしながら、タブレットやスマートフォンで閲覧される可能性を考えた時、テキストに絶対値指定のフォントを用いると極端に文字が小さくなったり、重なってしまって読めなくなる可能性もありますので、rem等の相対単位を使ってサイズを指定すべきです。

最近の主要ブラウザのテキスト拡大のあり方も変わりつつあります。FireFoxでは絶対値指定であっても相対値指定と同様に拡大縮小をしますので、上述の根拠は薄いように思われるかもしれません。一方、Chromeのテキスト拡大ではpxとpxで指定された文字の大きさは変化しません。（設定は面倒になりました）

ところで、検査をしていると、ズーム拡大での不具合によく遭遇します。ただ全体的に拡大しているだけだから、何の問題もないだろうと高を括るととても危険です。例えば、200%くらいに拡大してから、はみ出た部分をスクロールして表示しようとすると、テキストや画像の一部が欠けてしまっていることがあります。かならず、ズーム拡大でも正しくすべてのエリアが表示されているかどうか確認することが必要です。

レスポンシブデザインで作られたページも要注意です。レイアウトを大きく変えるような場合、その寸前あたりで表示の問題に遭遇することが多いように感じます。

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

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

技術コラムWCAG 2.1

miCheckerの記事は休憩して、新しいホワイトハウスのサイトがとても素晴らしいので紹介します。

The White House

アクセシビリティステートメントも素晴らしいです。

Accessibility Statement

確実にアクセシビリティを実践しています。ソースコードを見て欲しいのですが、いたるところに class="screen-reader-text" というクラスを見つけることができます。ご想像どおり、これは、音声ブラウザの利用者向けのテキストであることを示します。aria-labelledby も活用していますし、ステートメントは嘘ではないことがよくわかります。

アーカイブで昨年11月頃のサイトも確認しましたが、雲泥の差がありました・・・。

さて、クラス screen-reader-text を見てみたいと思います。とても参考になると思います。今度、お客様に隠しテキストの例を紹介するときは、これを紹介しようと思うくらいです。 (少しいじっています)

/*--------------------------------------------------------------
# Accessibility
--------------------------------------------------------------*/
/* Text meant only for screen readers. */
.screen-reader-text:not(:focus):not(:active) {
  border: 0;
  clip: rect(1px, 1px, 1px, 1px);
  clip-path: inset(50%);
  height: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute !important;
  width: 1px;
  word-wrap: normal !important; /* Many screen reader and browser combinations announce broken words as they would appear visually. */
}
.screen-reader-text:focus {
  background-color: #000;
  border-radius: 3px;
  box-shadow: 0 0 2px 2px #000;
  clip: auto !important;
  -webkit-clip-path: none;
  clip-path: none;
  color: #fff;
  display: block;
  font-size: .875rem;
  font-weight: 700;
  height: auto;
  left: 5px;
  line-height: normal;
  padding: 15px 23px 14px;
  text-decoration: none;
  top: 5px;
  width: auto;
  z-index: 100000
}

SNS関係のアイコンの処理も素敵です。別ウィンドウで開くことも書かれています。

<span class="screen-reader-text">Facebook<span class="screen-reader-text">Opens in a new window</span></span>

アクセシビリティ機能としては、コントラストを変更する Toggle High Contrast という機能と、テキストサイズを拡大する Toggle Large Font Size もページ左側の使いやすいところに配置されています。コントラスト変更ボタンはとても助かりますし、テキスト拡大も、テキストだけの拡大はブラウザでは面倒になっていますので、こうした独立ボタンはとても有用だと思います。

Toggle High Contrast ボタンイメージ
Toggle Large Font Size ボタンイメージ

動画をまだ見つけることができていないので、見つけたら、どのような具合かレポートさせていただきます。

技術コラムAMCC,miChecker

検出理由

「問題あり」として検出される項目です。
表における見出しセル（th要素）の示す方向が、行方向なのか列方向なのかが曖昧であると判断され、かつ、その指定（scope属性）がない場合に指摘されます。どのような時に曖昧であると判断するかは公表されていませんが、次の様なケースでは検出されることが多いようです。

  • 行見出しと列見出しの両方があり、かつ左上にth要素が用いられているとき。
  • 見出しセルの結合が多用されているとき。表によっては一つ程度の結合は問題にならないが、大抵の場合、検出対象になる。
  • scope属性は使われているが、全ての見出しセルに使われているわけではない場合。
左上角に見出しがある表の例。左上角の見出しセルは、行と列のどちらの方向のものなのか、視覚的には内容やセルの色から判別できても、音声で聞くと判別できない場合がある。

根拠

音声ブラウザは、見出しセルが、どのセルと関連付くのかを判断し、読み上げの際には、関連付けられたセルを一緒に読み上げてくれます。例えば、次の例では「120円」というセルを読み上げるときに、列方向には「普通」を、行方向には「珈琲」を見出しとして見つけ、「普通 コーヒー 120円」と読み上げてくれます。これにより、視覚的に見ていなくとも、音声だけでも表の構造を想像することができるようになります。

3x3の表、1行目、1列目は見出し。左上から、サイズ、普通、ラージ、コーヒー、120円、180円、リッチ珈琲、150円、200円とあり、サイズ、普通、ラージとコーヒー、リッチコーヒは異なる背景色。

しかし、この表には一つ問題があることにお気づきでしょうか? 問題の箇所は「サイズ」です。
視覚的に見ている人は、セルの色や内容から、「サイズ」は「普通」と「ラージ」に対する見出しセルであることが容易に判断できます。しかし、音声ブラウザでは「サイズ　普通　ラージ」と聞こえてくるだけですので、「サイズ」が行方向に対する見出しなのか、列方向に対する見出しなのかはよくわかりません。

そこで、アクセシビリティの規格では、見出しセルが示す見出しの方向をscope属性を用いて指定するように求めています。正しく用いられていると、「普通」を読み上げる時に、ただ「普通」と読み上げるのではなく、「サイズ　普通」と読み上げるようになりますので、正確な表の構造を知ることができるようになります。

表を音声だけで理解するには、聞きながら頭の中で表を再構築する必要があります。そのためには、そのセルが見出しセルであること、データセルであることに加え、見出しセルでは見出しの方向を示すことが求められています。

修正方針

まず、第一にすべきことは、この後に説明する処理をしなくとも良いくらいに表をシンプルにすることです。可能であれば行見出しか列見出しのどちらか一つだけを含み、結合セルを使用していないシンプルな表がベストです。そうした表であれば、問題だと指摘される可能性はほとんどありませんし、実際、音声ブラウザで聞いていても混乱することはありません。

しかし、行と列の見出しが必要、あるいは結合セルを用いるような場合は、すべての見出しセルに、その見出しが示す方向をscope属性で明示してください。列方向の見出しならば scope="col"（列グループならば “colgroup"）、行方向の見出しならば scope="row"（行グループならば “rowlgroup"） と設定します。

見出しセル、サイズ、珈琲、リッチコーヒーにはscope="row"、普通、ラージには scope="col"が゛設定

例えば、このように、すべての見出しセルに scope属性を追加することで、音声ブラウザは表の構造を正しく理解し、これを利用者に伝えることができるようになります。

補足

左上角は厄介です。行と列の見出しを持つ表で、左上のセルが空の場合は th要素を用いず、td要素を用いる方がより適切です。セル色は別途cssを用いて設定してください。

なお、日本では表が好んで使われます。表は、視覚的に理解を容易にするからです。一方、欧米では意外と表は用いられません。いろいろな説がありますが、定かなことは分かりません。ただ、表の場合、Cut & Paste で情報をコピーしようとしたときにうまくできなかったり、レイアウトが固定されることで、画面の幅を狭めたり、縦横の表示方向を変えたりすると、スクロールが発生するなどして読みにくくなる場合があります。本当に表にすることが必要なのか、検討してから用いるべきです。

まして、セルの結合が多用された複雑な表は、誰にとっても使いにくい可能性があります。そのような場合は、表を複数に分割するなど工夫が望まれます。

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

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

技術コラムAMCC,miChecker

検出理由

「問題あり」として検出される項目です。
画像の代替テキストと隣接するテキスト、あるいは隣接する画像の代替テキストが同じ内容になっている箇所があるため問題として検出されています。

画像の代替テキストと続くテキストが同じ様子であることを示した説明図
<img src="(画像ファイル)" alt="abcの写真">
<p>abcの写真</p>
二つの画像が並び、両方の代替テキストが同じ内容であることを示した説明図
<img src="(画像1のファイル)" alt="写真">
<img src="(画像2のファイル)" alt="写真">

根拠

音声ブラウザを利用している人は、指摘された箇所では、二度、同じ内容を音声で聞くことになります。まず、これが大きな問題であると知ることが大切です。音声ブラウザでの操作はもともと時間がかかるもので、さまざまな工夫をしながら操作されています。このような時に、二度同じことが聞こえてくるというのは、操作性を失望とともに下げてしまうものです。3分で読み出していたものが6分になるかもしれないのです。ページの構成の理解も難しくしてしまいます。何より、この問題は昔から指摘されている典型的な問題のため、利用者には「このページ制作者は、アクセシビリティのことを全然意識していないのだな」と思われてしまう可能性もあります。

それでもピンと来ない方は、この行を読めば、何が問題か分かるはずです。
それでもピンと来ない方は、この行を読めば、何が問題か分かるはずです。

わざと二行に同じことを書いてみました。違和感はありませんか?
この問題が指摘される箇所は、これと同じような状態だとお考えください。

修正方針

画像の代替テキストの内容を再検討し変更してください。多くの場合、画像の代替テキストは空で構わないはずです。先の一つ目の例にあたります。二つ目の例では、それぞれの写真の簡単な説明を入れるか、最低でも"写真1″と “写真2″のように通し番号など入れて区別できるようにします。

  • 空にできないか検討する。
  • 代替テキストに適度に情報を追加する。
画像の代替テキストを空にして、続くテキストと重複しないようにしたことを示す説明図
<img src="(画像ファイル)" alt="">
<p>abcの写真</p>
二つの画像の代替テキストを、例えば連番をつけることで異なるものであるようにしたことを示す説明図
<img src="(画像1のファイル)" alt="写真1">
<img src="(画像2のファイル)" alt="写真2">

なお、miCheckerはテキストの前後のスペースは無視しますので、対策としてalt="abc&nbsp;"としても効果はありません。ツールをごまかす方法はいろいろあるのですが、まずはそうした方法ではなく、純粋にどうあるべきかを考えれば、大抵はそれでうまくいくはずです。

また、画像リンクにおいて、代替テキストがリンクテキストの唯一の情報である場合は、alt="" として空にすることは絶対にしないでください。視覚的に見て操作している人は、その画像をクリックしてリンクさせることが可能ですが、音声ブラウザの利用者では、そこにリンクがあることにすら気がつかなくなる恐れがあります。miCheckerでは、このような場合、『このリンク内には読み上げ可能なテキストが存在しないため、アクセシブルではありません。』（問題の可能性大）として検出します。もし、ページ内リンクの場合は、『ページ内リンク “*"　は、読み上げ可能なテキストを持たないため、音声アクセスできません』」（問題あり）として検出します。

補足

次のように、リンクとしてテキストも画像も存在していない場合はどう判定すべきでしょうか?

<a href="(url)"></a>

miCheckerはページ内リンクの場合は「問題あり」として検出しますが、ページ外へのリンクの場合は実は何も検出しません。これは、視覚的に見て何も無いことが許されているならば、音声で聞こえる必要もない、と判断しているのかもしれません。しかし、実際にはクラスを用いて擬似画像を表示することもできるわけですから、これは目視検査では不適合となります。「miCheckerで検出されないから問題無い」というわけでは無いことにご注意ください。

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

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

技術コラムAMCC,miChecker

検出理由

「問題あり」として検出される項目です。
フォームコントールにはラベルテキストが必要です。テキストラベルはlabel要素により定義するか、title属性により設定しますが、検出箇所ではそのいずれも存在しないため検出されています。対象になるフォームコントロールは、input要素、textarea要素、select要素とisindex要素になります。送信(submit)、リセット(reset)、画像ボタン(image)、隠しフィールド(hidden)、スクリプトボタン(button)はそれ自身がラベルとしての機能を持つか、ラベルが必要ないケースのため検出対象にはなりません。

<!-- 視覚的にはラベルに相当するものがあるが、input要素と結び付くマシンアンダースタンダルブルなラベルが無い -->
<p>電話番号</p>
<input id="telNumber" type="text" name="number" size="10" value="">

根拠

入力欄やボタンには、何を入力するものであるか、あるいは実行すると何が起きるのかが分かるようにしておく必要があります。まず、視覚的に見て分かるようにすること、加えて、音声ブラウザで聞いた時にもわかるようにすることが必要です。なぜなら、視覚的に見ている人は、前後のコンテンツの様子、入力欄の並び、配置されている位置などから、そこに何を入れれば良いかをイメージすることができる場合もありますが、音声ブラウザで聞いている人は、そうした位置情報などは見て取れないため、そのフォームコントールの目的が分からないことがあるからです。

あるいは、音声ブラウザの利用者は、少しでも読みにかかる時間を短くするために、フォームコントールだけを再生させながら読み進める場合もあります。そうした場合、そのフォームコントロールに確実に関連付けされたテキストラベルが無いと、例えば、「エディット」「エディット」としか聞こえて来ず、何を入れたら良いのか良く分からなくなることもあります。

例えば、電話番号入力欄は一つのテキスト入力欄で済ます場合と、三つにわける場合があります。視覚的に見ている人はテキスト入力欄の幅や数から、直感的にどのように入力すれば良いか見当を付けることができますが、音声ブラウザを利用している人にはそれは容易ではありません。規格が求めているように、三つに分ける場合であれば、一つ目のテキスト入力欄にはtitle="市外局番"、二つ目にはtitle="局番"、三つ目にはtitle="下4桁"のように指定があれば、利用者は「エディット 市外局番」「エディット 局番」「エディット 下4桁」のように聞くことができ、混乱せず、求められている内容を入力できるようになります。

修正方針

最初に視覚的にラベルとして利用している箇所が無いか確認します。なければ、視覚的なテキストラベルを追加することを検討します。そして、それらテキストラベルを label要素を用いてフォームコントロールと関連付けます。場所が無いなどの理由でテキストを配置したくない場合は、最低でも title属性を用いてラベルを定義します。これでエラーは検出されなくなります。

修正例 : label要素による例

label要素を用いた典型的な例です。これをtitle属性に置き換えることもできますが、title属性では視覚的なラベルを提供できないので好ましくはありません。まずは、label要素を用いることを検討すべきです。

<label for="telNumber">電話番号</label>
<input id="telNumber" type="text" name="number" size="10" value="">

修正例 : title属性による例

titlel属性を用いた例です。このケースではテキストラベルを配置すると視覚的に見ている人には冗長になります。このような場合はtitle属性で情報を提供することは容認されます。

<fieldset>
<legend>電話番号</legend>
<input type="text" id="areaCode" name="areaCode" size="3" value="" title="市外局番">
<input type="text" id="exchange" name="exchange" size="3" value="" title="局番">
<input type="text" id="lastDigits" name="lastDigits" size="4" value="" title="下4桁">
</fieldset>

補足

miChecker では visibility:hidden などで非表示にしているフォームコントロールを検証しエラーを検出する場合があります。これは目視検査では不適合にはならず（*1）無視しても良いのですが、都度検出されのも面倒です。このような場合は、気かチェックツール対策にすぎませんが、title="dummy"など適当な値を設定しておくと良いかもしれません。
（*1 – 音声ブラウザは visibility:hidden は読み上げ対象としません。）

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

(他のテクニックは「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

技術コラム

JIS X 8341-3 ではウェブページのアクセシビリティを検証する作業などに「試験」という言葉を用いることにしたため、みんなの公共サイト運用ガイドラインでも、ウェブアクセシビリティ基盤委員会でも、「試験」という言葉が広く使われるようになりました。しかし、本来は適合性を評価する行為は「検査」と呼ぶのが正しい呼び方です。

日本規格協会では「試験」と「検査」の違いを次のように説明しています。

“「試験」が評価対象の特性を確定させる（通常は何らのデータを示す）ことであるのに対し、「検査」は試験の結果を用いたり、設計資料を解析する等の調査により、評価対象が一定の要求事項を満足すること（合格や不適合等）を判断するもの（適合生の確定）である。"

ISO/IEC 17020 により認定された検査機関では、試験とはいわず検査という言葉を用いているのはこれが理由です。私どものウェブアクセシビリティに関するサービスでも、ウェブアクセシビリティ検査と称するようになっています。また、証明書は検査証明書であり、試験証明書とはなりません。

なお、日本では「試験」が一般的な言葉であるため、本サイトでも、適宜、試験という言葉を用いています。検査ではSEOの観点から見つけていただく機会が大きく減少するためです。読者の皆様からすると、試験と検査が混在して読みにくい場合もあるかと思いますが、上記のような理由がありますので、お許しいただければと思います。