ネストされたリストの「アクセシビリティの死角」を埋める:ARIAと構造の正しい作法
フロントエンド開発の現場で、私たちは日々「リスト」をマークアップしています。しかし、`
- `の中に`
- `が入れ子になれば、DOMツリーとして自動的に階層構造を構築します。これは非常に優秀です。しかし、スクリーンリーダーは「今、自分がどの階層にいて、全体の中でどの程度の深さにいるのか」をユーザーに伝える責任があります。
標準的なブラウザの実装では、`
- `がネストされると、スクリーンリーダーは以下のような情報を読み上げます。
- `)またはリストそのもの」 に対して、その階層を数値で指定します。これを適当に設定すると、かえってスクリーンリーダーの挙動を混乱させるリスクがあります。
- まずはネイティブのHTMLタグ(ul, ol, li)で構造を作る。
- 構造が複雑で、ユーザーが階層を見失う可能性がある場合のみ、`role=”tree”` や `aria-expanded` で補強する。
- `aria-level` は、HTMLのリスト構造では通常自動解決されるため、まずはHTMLの入れ子を正しく書くことに集中する。
1. 「リスト、○項目」
2. (入れ子に入った時)「リスト、インデント、○項目」これだけで十分なケースも多いのですが、複雑なナビゲーションや目次構造では、「今、第何階層にいるのか」というコンテキストが欠落することがユーザー体験を損なう原因になります。
—
2. aria-level で階層を明示するべきケース
ここで登場するのが `aria-level` です。実は、HTML標準の`
- `や`
- `には、本来`aria-level`は必須ではありません。しかし、複雑な構造を持つリスト(例えば、CMSで自動生成される多階層のサイドバーナビなど)においては、これを明示することで、ユーザーは「今、全体の中のどの深さにいるのか」を瞬時に把握できるようになります。
注意点:aria-levelを使う際の罠
`aria-level`は、親の`
- `ではなく、「リスト項目(`
基本は「HTMLの構造を正しく保つこと」。その上で、より深いナビゲーションが必要な場合にのみ、ARIAを「補助輪」として使うのがプロの流儀です。
—
3. 実践:コピペで使える「アクセシブルなネストリスト」
以下は、階層構造を明確に定義した、アクセシビリティ対応のサンプルコードです。CSSでの装飾も考慮しつつ、意味的に正しい構造を意識しています。
—
4. シニアエンジニアからのアドバイス:ARIAは「最後の手段」
現場でよくある失敗は、「HTMLの構造がめちゃくちゃなのに、ARIAで誤魔化そうとする」ことです。
例えば、`
`を並べて`role=”list”`を振るような実装は、CSSでの見た目制御を優先するあまり、スクリーンリーダーの標準的な操作(ショートカットキーでのリスト間移動など)を無効化してしまう最悪のパターンです。アクセシビリティ対応は、派手な機能を追加することではなく、「情報を過不足なく、ユーザーの支援ツールに届けること」です。コードを書くとき、一度目を閉じて「この構造で、自分は今どこにいるか理解できるだろうか?」と自問自答してみてください。その一歩が、あなたのフロントエンド・スキルを一段上のレベルへ引き上げるはずです。
もし実装で迷ったら、まずはHTMLのセマンティクスに立ち返る。これが、10年生き残るフロントエンドエンジニアの鉄則です。
- `を入れ子にする、いわゆるネスト構造を作るとき、ただ「見栄えが良いから」という理由だけで組んでいないでしょうか。
中級レベルのエンジニアであれば、「HTMLは意味的に正しく書くべき」という原則は理解しているはずです。しかし、スクリーンリーダー(音声読み上げソフト)がその構造をどう解釈し、ユーザーにどう伝えているかまで踏み込んでいる人は意外と少ないものです。
今日は、ネストされたリストのアクセシビリティを「正しく」実装するための、現場で使える知見を共有します。
—
1. なぜ「入れ子」はブラウザと支援技術にとって重要なのか
ブラウザのレンダリングエンジンは、`
- `や`

コメント