検出理由

「問題あり」として検出される項目です。
フォームコントールにはラベルテキストが必要です。テキストラベルは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 は読み上げ対象としません。）

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

• 達成基準 1.1.1: 非テキストコンテンツ
• 達成基準 1.3.1: 情報及び関連性
• 達成基準 3.3.2: ラベル又は説明
• 達成基準 4.1.2: 名前 (name) ・役割 (role) 及び値 (value)
• 達成方法 H44: テキストラベルとフォームコントロールを関連付けるために、label 要素を使用する
• 達成方法 H65: label 要素を使用できない場合に、フォームコントロールを特定するために、title 属性を使用する

---

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

miCheckerが検出する問題の種類

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

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の観点から見つけていただく機会が大きく減少するためです。読者の皆様からすると、試験と検査が混在して読みにくい場合もあるかと思いますが、上記のような理由がありますので、お許しいただければと思います。

検査機関として年間に約100件、ページ数でいうならば4000ページ近く、あるいは以上を検査している中では、お客様から多くのご質問をいただきます。それらのご質問のうち、典型的なものについてはこのサイトからご紹介することを検討しておりますが、年度末に向けて、それとは別に、今、疑問を抱えて困っている制作者やサイトオーナーの方がいらっしゃいましたら、お気軽にご質問ください。すべてのご質問に回答できるかどうかはわかりませんが、できるだけ回答させていただきます。

ご質問はこちらで受け付けております。

本日、ホームページをリニューアルしましたので、お知らせします。

本リニューアルにともない、これまでの「やさしいWeb研究会」というサイト名称は「accessibility.jp」に変更させていただきます。今後は、インフォ・クリエイツ社が検査機関として活動してきたノウハウや知識をここで広く提供することで、日本のアクセシビリティに対する活動が少しでも前進していくよう貢献していきたいと考えています。

サイトの構成、URLには大きな変更がありますので、改めて、ブラウザの「お気に入り」「ブックマーク」などに登録していただけましたら幸いです。

これからも、引き続きご利用の皆様のお役に立つ情報のご提供や、内容の充実に努めてまいります。
今後ともご愛顧賜りますようお願い申し上げます。