検出理由

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

根拠

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

<img src="seaside.png" alt="海　岸　の　様　子">

修正方針

代替テキスト中の無用な空白を取りぞいてください。

<img src="seaside.png" alt="海岸の様子">

補足

代替テキストであって、表示されるものでもないため文字間の空白は不要です。

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

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

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

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

• 達成基準 1.3.2: 意味のある順序
• 達成方法 C8: フォントサイズにパーセントを使用する
• 失敗例 F32: 単語内の間隔を制御するために、空白文字を使用しているフォントサイズに em 単位を使用する

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

検出理由

「問題の可能性大」として検出される項目です。
area要素を用いてイメージマップ上でのクリック可能な領域を定義する時、領域を画像に変わって説明するalt属性に、空白を含むテキストが設定されていると検出されます。単語の間に空白があれば常に検出しているわけではなく、漢字の文字数と空白の数などで判定しているようです。漢字２文字からなる単語を１つの空白で２分割すると必ず指摘されます。漢字３文字あるいは４文字だと２つの空白で３分割されると指摘されます。

根拠

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

<area shape="rect" coords="0,0,100,50" href="#" target="_blank" alt="北　海　道">

修正方針

代替テキスト中の無用な空白を取りぞいてください。

<area shape="rect" coords="0,0,100,50" href="#" target="_blank" alt="北海道">

補足

代替テキストであって表示されるものでもないため文字間の空白は不要です。

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

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

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

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

• 達成基準 1.3.2: 意味のある順序
• 達成方法 C8: フォントサイズにパーセントを使用する
• 失敗例 F32: 単語内の間隔を制御するために、空白文字を使用しているフォントサイズに em 単位を使用する

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

検出理由

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

根拠

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

<input class="order" type="button" value="日 時 を 決 定">

修正方針

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

<input class="order space" type="button" value="日時を決定">

.space {letter-spacing: 1em;}

微調整は text-indent など利用してください。

補足

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

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

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

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

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

• 達成基準 1.3.2: 意味のある順序
• 達成方法 C8: フォントサイズにパーセントを使用する
• 失敗例 F32: 単語内の間隔を制御するために、空白文字を使用しているフォントサイズに em 単位を使用する

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

検出理由

「手動確認」項目のため、miCheckerによる自動検出はありません。

根拠

音声ブウラザによっては、ページで使われている言語と異なる言語が使われている箇所について、その言語に変えて読み上げてくれる機能を有します。ただし、その機能を使用するには、その箇所が異なる言語で書かれていることをlang属性で示しておく必要があります。lang属性が指定されていないと、英語であっても無理矢理に日本語読み上げようとするため、理解不可能な発声になる場合があります。

とはいえ、最近の音声合成ソフトは日本語のエンジンであっても、それなりに外国語もそれらくし読むようには配慮されています。以前ほど酷いことはないようです。しかし、それでも"criteria"などは"クリターヤ"と読み上げるため内容の理解は困難です。

さて、この項目はmiCheckerは自動検出はしてくれません。検証結果の一覧には、いつも『固有名詞、技術用語、どの言語なのか不明な語句、及びすぐ前後にあるテキストの言語の一部になっている単語又は語句を除いて、コンテンツの一節又は語句それぞれの自然言語がどの言語であるかを、プログラムが解釈可能であることを確認して下さい。』と出力されますので、それを受けて、自分で確認し結果を残すことになります。

修正方針

HTMLの場合、その部分にspan要素など用いlang属性を追加します。
XHTML1.0の場合、その部分にspan要素など用いlang属性とxml:lang属性を追加します。
XHTML1.1の場合、その部分にspan要素など用いxml:lang属性を追加します。(宮沢賢治 処世)

<p>「おもてなし」は英語にし難いが、もっとも近いのは<span lang="en">hospitality</sapn>であろう。</p>

一部分の言語の判断は常に難しいものです。もし判断が難しい場合は、その部分を日本語に置き換えてみてください。日本語にすると意味がなくなるような場合は、多くの場合、正しく言語指定をした方が良いでしょう。反対に、例えばネイティブの発音で読まれると日本語を母国語とする話者では混乱してしまうことが予想される場合は、無理に言語を変更する必要はないかもしれません。

補足

• 日本語と英語を切り替えるために English というリンクが用意されている場合、そのリンクは英語の音声ブラウザ等で利用される可能性があります。そのような場合には正しく英語であることを指定しておく必要があります。
• ホームページのフッターに配置される Copyright は多くの場合に英語で記述されておりlang属性が必要です。
• 固有名詞、技術用語、言語が不明な語句及びすぐ前後にあるテキストの言語の一部になっている単語や語句は、例外とみなすことができます。
• ISO 639-1 のコードリスト（別ウィンドウで開く）
• 達成方法H57（別ウィンドウで開く）の訳註において、meta要素のcontent属性がtext/htmlの場合にはlang属性があれば、あるいは、application/xhtml+xmlの場合にはxml:lang属性があれば規格を満たすとされています。

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

• 達成基準 3.1.2: 一部分の言語
• 達成方法 H58: 自然言語の変更を指定するために、言語属性を使用する

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

補足

• ISO 639-1 のコードリスト（別ウィンドウで開く）
• 達成方法H57（別ウィンドウで開く）の訳註において、meta要素のcontent属性がtext/htmlの場合にはlang属性があれば、あるいは、application/xhtml+xmlの場合にはxml:lang属性があれば規格を満たすとされています。

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

• 達成基準 3.1.1: ページの言語
• 達成方法 H57: html 要素の言語属性を使用する

(他のテクニックは「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">の利用は避けてください)』

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

• 達成基準 2.2.1: タイミング調整可能
• 達成基準 2.2.4: 割り込み
• 達成基準 3.2.5: 要求による変化
• 達成方法 F40: 達成基準 2.2.1 及び 達成基準 2.2.4 の失敗例 － 制限時間付きの meta 要素リダイレクトを使用している
• 達成方法 F41: 達成基準 2.2.1、達成基準 2.2.4、及び 達成基準 3.2.5 の失敗例 － ページを再読み込みするために、meta 要素リフレッシュを使用している
• 達成方法 G76: 自動的に更新する代わりに、利用者がコンテンツの更新を要求するメカニズムを提供する
• 達成方法 G180: 利用者がデフォルトの制限時間を 10 倍に設定できる手段を提供する
• 達成方法 G198: 利用者が制限時間を解除するための手段を提供する
• 達成方法 H76: クライアントサイドで瞬間的にリダイレクトするために、meta 要素の refresh を使用する
• 達成方法 SVR1: クライアントサイドではなく、サーバサイドで自動リダイレクトを実装する

(他のテクニックは「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属性”（検出語）”は文字間に空白を含んでいるため、音声で正確に読み上げることが出来ない可能性があります。

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

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

• 達成基準 1.3.2: 意味のある順序
• 達成方法 C8: フォントサイズにパーセントを使用する
• 失敗例 F32: 単語内の間隔を制御するために、空白文字を使用しているフォントサイズに em 単位を使用する

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

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

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

• 達成基準 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属性）がない場合に指摘されます。どのような時に曖昧であると判断するかは公表されていませんが、次の様なケースでは検出されることが多いようです。

• 行見出しと列見出しの両方があり、かつ左上にth要素が用いられているとき。
• 見出しセルの結合が多用されているとき。表によっては一つ程度の結合は問題にならないが、大抵の場合、検出対象になる。
• scope属性は使われているが、全ての見出しセルに使われているわけではない場合。

根拠

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

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

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

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

修正方針

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

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

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

補足

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

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

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

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

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

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