飯塚慎司

検出理由

「問題あり」として検出される項目です。
フォントサイズの指定に 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%くらいに拡大してから、はみ出た部分をスクロールして表示しようとすると、テキストや画像の一部が欠けてしまっていることがあります。かならず、ズーム拡大でも正しくすべてのエリアが表示されているかどうか確認することが必要です。

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

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

• 達成基準 1.4.4: 情報及び関係性
• 達成方法 C12: フォントサイズにパーセントを使用する
• 達成方法 C13: 名前付きフォントサイズを使用する
• 達成方法 C14: フォントサイズに em 単位を使用する

---

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

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 もページ左側の使いやすいところに配置されています。コントラスト変更ボタンはとても助かりますし、テキスト拡大も、テキストだけの拡大はブラウザでは面倒になっていますので、こうした独立ボタンはとても有用だと思います。

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

検出理由

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

根拠

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

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

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

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

修正方針

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

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

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

補足

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

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

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

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

• 達成基準 1.3.1: 情報及び関係性
• 達成方法 H63: データテーブルで見出しセルとデータセルを関連付けるために、scope 属性を使用する

---

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

検出理由

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

根拠

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

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

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

修正方針

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

• 空にできないか検討する。
• 代替テキストに適度に情報を追加する。

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

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

補足

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

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

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

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

• 達成基準 1.1.1: 非テキストコンテンツ
• 達成方法 H30: label 要素を使用できない場合に、フォームコントロールを特定するために、title 属性を使用する

---

(他のテクニックは「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 は読み上げ対象としません。）

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

• 達成基準 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には大きな変更がありますので、改めて、ブラウザの「お気に入り」「ブックマーク」などに登録していただけましたら幸いです。

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