divやアイコン、手入力の番号で作った見た目だけのリスト

料金ページに、チームプランのカードがあります。プラン名の下に4つの特長が並び、それぞれの前に緑のチェックマークがあります。プロジェクト数無制限、50 GBのストレージ、共有カレンダー、優先サポートです。その下の「始め方」には、プランを使い始めるための番号付きの手順が3つあります。見える人には、4つの特長のリストと、3つの手順のリストに見えます。スクリーンリーダー利用者には、違って聞こえます。カードを上から読むと、「チームプラン 見出しレベル3」の後、特長が1行ずつ読まれます。最初の項目の前にリストの始まりや長さを伝えるものはなく、最後の項目の後にも終わりを伝えるものはありません。NVDAやJAWSで次のリストへ移動するLキーを押すと、「次のリストはありません」と返ってきます。手順は番号付きで読まれますが、やはり別々の行で、3項目のリストにはなりません。

1.3.1は、見て分かる構造をコードでも伝えることを求めます。チェックマーク、行のそろえ方、番号のすべてが、これらの行がひとまとまりの項目であり、いくつあるかを示しています。ところがマークアップは、次の2つの形で、そのことを何も伝えていません。

• 特長は、インラインSVGのチェックマーク付きの div です。装飾のアイコンとして正しくスクリーンリーダーから隠されているため、残るのは無関係な4つのテキストのかたまりです。
• 手順は、番号をテキストに手入力した p です。番号は読まれますが、3つの段落はまとまっていないため、項目数もなく、リスト移動で見つかるものもありません。順番は聞いて分かるため、手入力の番号を1.3.1の「テキストで提供されている」場合として認める評価者もいます。しかし、Trusted Testerの手順や多くの診断では認めていません。まとまりと項目数は、やはり伝わらないためです。

カードはどのブラウザーでも正しく見えるため、目で確かめる人は誰も問題に気づきません。影響を受けるのは、マークアップからページの構造を知る人です。

10グループ中2グループに影響

• 全盲 （影響あり）
• 弱視 （影響あり）
• 色覚 （影響なし）
• ろう （影響なし）
• 難聴 （影響なし）
• 発話 （影響なし）
• 手の操作 （影響なし）
• 届く範囲・力 （影響なし）
• 認知 （影響なし）
• 光過敏 （影響なし）

• 視覚を使わない スクリーンリーダーは、リストの項目を読む前にリストであることと項目数を伝え、終わりも伝えます。この例では特長も手順も無関係な行として読まれ、リスト移動では何も見つからず、まとめて読み飛ばすこともできません。
• 視覚が限られる 拡大表示とスクリーンリーダーを一緒に使う人にも、同じばらばらの行が聞こえます。リーダー表示やユーザースタイルシートはマークアップからページを組み直すため、チェックアイコンが消え、行がひとまとまりであることを示すものが残りません。

axe のリストのルールが確かめるのは、すでにあるリストのマークアップです。ul と項目の間の div（list）や、リストの外にある li（listitem）を見つけます。リストのマークアップがまったくないカードでは確かめるものがないため、この例の2つの形はどちらも axe のチェックを通ります。EaseWebの診断は、手入力の行頭記号や連番で始まる行と、リストの項目でない要素にCSSで描いた行頭記号を報告します。アイコンで始まる行は、リンクやツールバーの並びである場合もあるため、報告せずに確認の対象にします。AIによる修正には、別の誤りがあります。手順を ol で囲んで手入力の番号を残すと、どの手順も「1. 1. チームを作成します。」と二重に読まれます。入れ物に role="list" を付けても、各項目を包む div が残っていれば、項目のないリストになります。行のまとまりがリストのつもりか、順番に意味があるかは、ページの表示と照らし合わせて判断する必要があります。