アクセシビリティ（a11y）

アクセシビリティとは

**アクセシビリティ（accessibility、略して a11y）**とは、障害の有無や利用環境に関わらず、誰もが情報やサービスを使えるようにする考え方です。Web では、視覚・聴覚・運動・認知などさまざまな条件の人が対象になります。

具体的には、スクリーンリーダー（画面読み上げ）の利用者、マウスが使えずキーボードだけで操作する人、色の見え方が異なる人、強い光がつらい人などです。配慮は彼らだけでなく、全員にとっての使いやすさを底上げします。

• 字幕は、聴覚障害者だけでなく騒がしい場所の利用者にも役立つ。
• キーボード操作は、パワーユーザーの効率も上げる。

セマンティック HTML が土台

アクセシビリティの 8 割は、正しいタグを正しく使うことで達成できます。見た目を <div> で作り込むのではなく、意味に合った要素を選ぶことが出発点です。

• ボタンは <button>、リンクは <a>、見出しは <h1>〜<h6> を使う。
• フォーム部品には <label> を関連付ける。
• ページ構造は <header> <nav> <main> <footer> などのランドマークで表す。

<!-- 良い例：意味のあるタグ。読み上げ・キーボード操作が標準で効く -->
<button type="button">送信する</button>

<label>
  メール
  <input type="email" name="email" />
</label>

<!-- 避けたい例：見た目だけのボタン。フォーカスも Enter も自前実装が要る -->
<div class="btn" onclick="submit()">送信する</div>

正しいタグには、フォーカス可能・キーボードで操作可能・スクリーンリーダーが役割を読み上げるといった機能が初めから備わっています。<div> で代用すると、それらを全部自前で実装する羽目になり、抜けが事故につながります。

ARIA：足りない部分を補う

**ARIA（Accessible Rich Internet Applications）**は、HTML だけでは意味を伝えきれない部分を補う属性群です。役割を表す role、状態を表す aria-* などで、支援技術に情報を渡します。

属性の例	役割
role	要素の役割を明示（例: role="dialog"）
aria-label	見えるテキストが無い要素に名前を与える
aria-expanded	開閉状態（アコーディオン等）を伝える
aria-hidden	支援技術から要素を隠す

ARIA はカスタムUI（自作のモーダル、タブ、メニューなど）で力を発揮します。ただし最後の手段です。<button> で済むものに role="button" を足すのは無駄で、かえって壊しやすくなります。

キーボード操作とフォーカス

マウスを使えない利用者は、Tab キーで要素を移動し、Enter / Space で操作します。すべての機能がキーボードだけで完結することが必須です。

• すべて操作可能：クリックできるものは、キーボードでも到達・実行できる。
• フォーカスが見える：いまどこにいるか分かるよう、フォーカスリング（枠）を消さない。
• 論理的な順序：Tab で移る順番が、画面の見た目と一致している。
• キーボードトラップを避ける：モーダルなどから Tab で抜け出せる（または閉じられる）。

ネイティブな <button> や <a> を使っていれば、これらの多くは自動的に満たされます。ここでもセマンティック HTML が効いてきます。

色とコントラスト

文字と背景の**コントラスト（明暗差）**が不足すると、読みづらく、人によっては読めません。指針 WCAG では、通常サイズの文字で 4.5:1 以上のコントラスト比が推奨されています。

• 薄いグレーの文字を白背景に置くなどの「おしゃれだが読めない」配色を避ける。
• 色だけで情報を伝えない：エラーを赤色だけで示さず、アイコンや文言も添える（色覚特性への配慮）。
• リンクは色の違いだけでなく、下線などでも区別できるとよい。

土台となるタグの使い方は HTML を、操作を組み立てる側は JavaScript や DOM もあわせて読むと理解が深まります。