トピックを検索
データの表として読まれたり、順番が崩れたりするレイアウト用の表
メールマガジンが商品の並びを表で組んでいるため、スクリーンリーダーには各商品が列見出しとして読まれたり、商品名がすべて読まれてから価格が読まれたりしてしまう
<tr><td>$18</td><td>$32</td>…</tr> 問題
スクリーンリーダー利用者には、メールマガジンの商品がデータの表として読まれたり、商品名がすべて読まれてから価格が読まれたりするため、どの価格がどの商品のものか分からない
ある雑貨店が、毎週メールマガジンを送っています。「今週の新入荷」の欄には三つの商品が横に並び、それぞれ写真の下に名前と価格があります。$18のホーローマグ、$32のリネントート、$24の斑点マグです。このメールは、今も多くのメールと同じく表でレイアウトを組んでいます。従来版のWindows用OutlookはWordのエンジンでメールを表示し、CSSのレイアウトのほとんどを無視するためです。同じHTMLは「ブラウザーで表示」のページにもなります。
この並びが崩れる作り方には、よくあるものが二つあります。一つは、Foundation for Emails のように各列を th で書き出すメール用フレームワークのテンプレートを使う場合です。スクリーンリーダー利用者が商品の欄に来ると、行数と列数とともに表が読み上げられ、続いて各商品が列見出しとして読まれます。比べる数字の見出しのように聞こえます。もう一つは、格子を行ごとに組む場合です。写真を三つ並べた行、名前を三つ並べた行、価格を三つ並べた行に分けると、画面では列がきれいにそろいます。先頭から読むと「ホーローマグ、リネントート、斑点マグ、$18、$32、$24」と聞こえ、トートが$32だと知るには数えて戻る必要があります。
表のマークアップは、内容が見出しの下に行と列で並んだデータであることを支援技術に伝えます。WCAG 1.3.1「情報及び関係性」は、コードの構造が画面に示したものと一致することを求めています。商品を横に並べるだけの表に見出しのセルがあれば、存在しない構造を伝えることになります。失敗例F46は、レイアウト用の表の th、caption、summary を挙げています。ブラウザーは表がデータかどうかを推測します。Chromeは罫線も th もない表をアクセシビリティツリーでレイアウト用の表とし、スクリーンリーダーはレイアウト用の表のセルをただの内容として読みます。しかし th があれば、推測の余地はありません。Chromeのアクセシビリティツリーでは、一つ目の作り方の表は table になり、列見出しの名前は「Enamel mug $18」「Linen tote $32」になります。
スクリーンリーダーは表を1行ずつ、左から右へ、マークアップの順に読みます。WCAG 1.3.2「意味のある順序」は、順序が意味を持つときに、コードの順序が意味の通る順序であることを求めています。二つ目の作り方では、写真、名前、価格は列ごとに縦にまとまっているのに、読み上げは行に沿って横に進みます。順に読むと意味が通らないレイアウト用の表として、失敗例F49にあたります。この表に presentation を付けても、隠れるのは表であって、順序は変わりません。
スマートフォンでも、スクリーンリーダー利用者はメールをマークアップの順に一つずつスワイプして読みます。価格が名前から何回もスワイプした先にあるのは、パソコンで聞くときと変わりません。
10グループ中2グループに影響
- 全盲 (影響あり)
- 弱視 (影響なし)
- 色覚 (影響なし)
- ろう (影響なし)
- 難聴 (影響なし)
- 発話 (影響なし)
- 手の操作 (影響なし)
- 筋力・可動域 (影響なし)
- 認知 (影響あり)
- 光過敏 (影響なし)
- 視覚を使わない 商品の前に表が読み上げられ、各商品は列見出しとして読まれるため、比べる数字が続くのだと思ってしまいます。行ごとに組んだ格子では、商品名が三つ続いた後に価格が三つ聞こえ、どれがどれかを数えて戻る必要があります。
- 言語・認知・学習の能力が限られる ディスレクシアのある人が使うこともある読み上げツールもマークアップの順に読むため、行ごとに組んだ格子では、価格が商品名から離れたところで読まれます。
axe には、レイアウト用の表の見出しのセルを確かめるルールがありません。一つ目の作り方では th-has-data-cells ルールが見出しのセルを要確認として挙げるだけで、二つ目の作り方はこのルールを通ります。表がデータを持っているか、読む順に意味が通るかを、コードだけで判断できるツールもありません。この診断は、一つ目の作り方のように th が表をまるごと含んでいて、レイアウト用と分かる場合を問題として報告します。残りの、レイアウト用に見える表(ほかの表を含む表、presentation が付いた表、見出しのセルがなく画像の行が文字の行の上にある表)には、スクリーンリーダーが読む順にセルの文字を並べた確認候補を出します。画像の行が文字の行の上にあれば、そのことも伝えます。AIによるコード生成で Foundation for Emails の <columns> タグを使ってメールを書いても、ビルドすると同じ th のセルになります。th を書き出すのは、AIではなく、フレームワークのコンパイラーである Inky だからです。
試してみる
メールを見ずに、読み上げだけでリネントートの価格を探してみましょう
問題1: 下の欄に、商品の欄の先頭からスクリーンリーダーが読む内容が並びます。商品は何として読まれていますか?
問題2: メールの見た目は同じです。下の欄を読んで、トートの価格はどれか分かりますか?
修正を適用します。 もう一度下の欄を読むと、各商品がまとめて読まれてから、次の商品に移ります。
問題あり 修正できますか?
今週の新入荷
|
|
|
|---|
先頭から読むと、スクリーンリーダーの読み上げ:
- 表、3列、1行
- 列見出し、ホーローマグ、$18
- 列見出し、リネントート、$32
- 列見出し、斑点マグ、$24
- 表の外
修正方法
表を意識させず、商品を一つずつまとめて読ませる
各列が見出しのセル
<table class="row"> <tr> <th class="columns"> <table> <tr> <th> <img src="enamel-mug.jpg" alt=""> <p>Enamel mug</p> <p>$18</p> </th> </tr> </table> </th> <th class="columns"> <table> <tr> <th> <img src="linen-tote.jpg" alt=""> <p>Linen tote</p> <p>$32</p> </th> </tr> </table> </th> … </tr></table>問題点3点
順序は正しく、各商品は一つのセルにまとまって読まれます。問題はセルの種類です。
- 各列が
thのため、ブラウザーは外側の表をデータ表として扱い、スクリーンリーダーは商品の前に、行数と列数とともに表を読み上げる。 - 各商品は、何の見出しでもないのに列見出しとして読まれる。
- 内容を配置するだけの表であることを示す
role="presentation"が、どの表にもない。
表をpresentationにし、一つのセルに一つの商品
<table class="row" role="presentation"> <tr> <td class="columns"> <table role="presentation"> <tr> <td> <img src="enamel-mug.jpg" alt=""> <p>Enamel mug</p> <p>$18</p> </td> </tr> </table> </td> <td class="columns"> <table role="presentation"> <tr> <td> <img src="linen-tote.jpg" alt=""> <p>Linen tote</p> <p>$32</p> </td> </tr> </table> </td> … </tr></table>修正の手順3ステップ
- セルはすべて
tdにする。格子の中に見出しになるものはないため、thは使わない。 - 各商品の写真、名前、価格を一つのセルに入れる。商品はまとめて読まれ、読み終わってから次の商品に移る。
- 入れ子の表も含めて、すべての表に
role="presentation"を付ける。この役割は表自身の行とセルには及ぶが、その中に入れた表には及ばない。スクリーンリーダーは三つの商品をただの内容として読み、表は読み上げない。
これで二つの修正前の例はどちらも直り、1.3.1と1.3.2を満たします。ただし、外枠、余白、ボタンなど、メールが表で描くものも含め、テンプレートがレイアウトのために書き出す表すべてにこの役割が必要です。
この方法を選ぶ理由:ソースは読む順に書く
どちらも基準を満たします。メールでは、presentation の表を使います。従来版のWindows用Outlookも含め、どのメールソフトでも表示できるレイアウトです。Webページでは、リストを使います。表がいらず、メディアクエリーなしで狭い画面でも縦に並び、スクリーンリーダー利用者に商品の数も伝わります。
thを書き出すフレームワーク。 Foundation for Emails は、各列を役割のない表の中の th として書き出すため、その <columns> タグで作ったメールはすべて一つ目の修正前の例と同じになります。書き出す内容を変えられない場合でも、書き出されるすべての表に role="presentation" を付ければ、Chromeのアクセシビリティツリーではその th がただの内容になります。ただし、F46の文言どおりなら、レイアウト用の表にある th は一つでも失敗にあたるため、テンプレートで変えられるところでは td に置き換えてください。MJML は、書き出す表に自分で role="presentation" を付けます。
presentationとnone。 ARIAは role="none" を role="presentation" と同じ意味の役割として定めています。MJML などのメール用フレームワークは presentation を使っているため、このガイドでもそちらを使います。
メールの中のデータ。 注文確認メールの商品、数量、金額の一覧はデータです。見出しが太字だけのデータ表のとおり、見出しのセルとキャプションを持つデータ表のままにし、presentation は付けません。
罫線でブラウザーの推測が変わる。 Chromeは、th がなくても、セルの間に罫線のある表をデータとみなします。線で区切ったレイアウト用の表にも、見出しのセルがある表と同じく role="presentation" が必要です。
写真。 この例の写真の alt は空です。下の名前が何の写真かを伝えているため、名前を繰り返す alt は二度読まれるだけになります。マグの色のように、言葉にないことを写真が見せている場合は、それを書きます。ファイル名や同じ言葉が読まれる装飾画像も参照してください。
スマートフォンでの縦並び。 メールでは、狭い画面で各セルを全幅にして列を縦に並べることがよくあります。セルはマークアップの順に並ぶため、行ごとに組んだ格子は、写真が三つ、名前が三つ、価格が三つの順に並びます。順序の問題が、見た目にも表れます。
修正の確認
5項目、マウス不要
確認方法: スクリーンリーダー、スタイルを無効化、拡大表示
OS、ブラウザーと支援技術のバージョン、ビルド、実施日、各手順の実際の結果を記録してください。テンプレートを変更した際は、再度確認します。
制限
このサンプルは、どのメールでも同じ結果になることを保証するものではありません。メールソフトによって表示は異なり、Webメールはメールを自分のページの中に表示するため、顧客が使うメールソフトで確認してください。役割のない表が表として読まれるかどうかは、ブラウザーとスクリーンリーダーそれぞれの推測しだいです。表ではなくCSSのレイアウトによって画面の順序が変わるページの読み上げ順序は、見た目と食い違う読み上げ順序で扱っています。
よくある問題を再現した学習用のサンプルです。実在のクライアントの診断結果ではありません。コードは出発点となる実装例のため、実際の製品でも確認してください。ここでは支援技術でのテスト結果は報告していません。
EaseWebのサービス
修正した問題を、次のリリースで再発させない
このガイドのような修正方法を、コーディングエージェントが従うルールと、CIのチェックに組み込みます。あわせて定期的に、キーボードとスクリーンリーダーで手動の再テストを行います。