HTML アクセシビリティ（a11y）

Web を「より多くの人が、より多くの状況で」使えるようにする取り組み。 派手な技術ではなく、正しいHTMLを書き、操作と認知の前提を固める地道な作業。 ここでは HTML 周りに絞って、メンタルモデルから実装パターンまでを一通り。

これは何のための話か

Web アクセシビリティ (a11y) は、視覚障害・聴覚障害・運動機能障害・認知/学習障害などのある人だけのためのものではない。「状況的な制約」がある時、誰もがその恩恵を受ける。

• 明るい屋外でコントラスト不足の文字が見えない
• 骨折で片手しか使えない
• 低速回線で画像が読まれない（alt があれば代替表示できる）
• 地下鉄で動画の音を出せない（字幕があれば理解できる）
• 新しい言語の Web を翻訳ツールで読む（セマンティックなマークアップは翻訳されやすい）
• SEO の bot が読む（基本的に支援技術と同じ枠組み）

つまり、a11y を上げる = 全ユーザーの体験を底上げする。
加えて、多くの国で法的要件になっている（米 ADA / EU EAA / 日本の障害者差別解消法など）。

WCAG（基準）と4原則

実務的な基準は WCAG（Web Content Accessibility Guidelines）。最新は 2.2（2023〜）。 4つの原則 POUR がすべての出発点:

適合レベル: A / AA / AAA

達成基準は3段階。実務のターゲットは AA。 AAA は記事・公的サイトなど特定文脈以外では現実的でない要件もある（コントラスト 7:1 等）。

メンタルモデル: アクセシビリティツリー

ブラウザは DOM を読んで アクセシビリティツリーを作る。 スクリーンリーダや音声操作、ブラウザの拡張はこのツリーを介して操作される。

各ノードは典型的に4つの情報を持つ:

• Name — 何の要素か（「メールアドレス」「送信」）
• Role — どういう種類か（「テキスト入力」「ボタン」「見出し」）
• State / Property — 状態（「押下中」「展開済み」「必須」）
• Value — 値（「foo@bar.com」）

正しい HTML を書けば、これらは自動で生成される。 例えば <button>送信</button> は name="送信", role="button" が勝手に付く。

逆に <div onclick>送信</div> はツリー上で「ただの匿名要素」になる。これが a11y の本質的な問題。

3つの優先順位

1. 正しい HTML を書く — 9割の問題はこれで解決する。
2. 必要なところだけ ARIA で補完 — カスタム UI で意味付けが足りない時。
3. テストする — axe / Lighthouse / 手動キーボード / スクリーンリーダ。

知っておくと変わる「3つの誤解」

1. 「うちのサービスに障害のあるユーザーは少ない」

WHO の統計では世界人口の 16% に何らかの障害がある。状況的障害を含めればさらに多い。 加齢で目が悪くなる人、画面の小さいスマホ、明るい屋外、片手で操作中、すべてが a11y の文脈。

2. 「a11y は最後にチェックすればいい」

後付けは常にコストが大きい。マークアップが div だらけの SPA を後から a11y 対応するのは1からやり直すレベル。最初から正しい HTML を書く方が圧倒的に楽。

3. 「a11y = 見た目を地味にすること」

まったく違う。派手なアニメや凝った UI も、ちゃんと作れば a11y 対応できる。 派手さを下げる必要があるのは、点滅・激しい動き・「色しか手がかりがない UI」などの限定された範囲だけ。

このノートの読み方

1. セマンティック HTML — 9割はここから始まる。
2. 画像 と フォーム — 出現頻度が高く、間違いも多いポイント。
3. フォーカスとキーボード — どんな UI でも必須。
4. ARIA — 必要最小限。「使わない判断」が一番難しい。
5. スクリーンリーダ — テスト前に仕組みを知る。
6. 色・コントラスト、動き — 視覚と前庭の配慮。
7. テスト・検証 — 自動チェックの限界も含めて理解する。