アクセシビリティ（実装観点）

アクセシビリティ（Accessibility、a11y）はすべてのユーザーが平等にサービスを利用できるよう保証する実装責務である。視覚障害・運動障害・認知障害など様々な特性を持つユーザーが存在し、支援技術（スクリーンリーダー・キーボード操作・スイッチアクセス等）を通じてWebを利用している。アクセシビリティ対応は「障害者のため」という限定的な視点ではなく、状況的な制約（画面をまぶしい屋外で見る・片手が塞がっている等）を持つ全ユーザーへの品質保証として捉えるべきである。

セマンティックHTMLはアクセシビリティの基盤である。<button>・<a>・<h1>〜<h6>・<nav>・<main>・<form> 等の意味論的な要素は、スクリーンリーダーが要素の役割・状態を自動的に解釈できる情報を持つ。<div> や <span> に onClick をつけてボタンとして使う実装は、キーボード操作やスクリーンリーダーからのアクセスを壊すため、特別な理由がない限り避けるべきである。

WAI-ARIA（Web Accessibility Initiative - Accessible Rich Internet Applications）はHTMLのネイティブなセマンティクスで表現できない複雑なUIパターン（タブ・モーダル・コンボボックス等）に意味論を追加するための仕様である。role属性でUIの役割を定義し、aria-* 属性で状態（aria-expanded・aria-selected等）やラベル（aria-label・aria-describedby等）を提供する。ARIAの第一原則は「ネイティブのHTMLで表現できる場合はARIAを使わない」ことであり、不適切なARIAの付与はアクセシビリティを悪化させることがある。

コードレビューで着目するポイント

<div>や<span>にonClickを付けてインタラクティブな要素として使っていないか（<button>・<a>を使うべき）
インタラクティブな要素が Tab キーでフォーカス可能であり、Enter・Space キーで操作できるか
フォームの入力フィールドに <label> が正しく関連付けられているか（for属性またはラップ）
モーダル・ダイアログが開いた際にフォーカスがモーダル内に閉じ込められ（Focus Trap）、閉じたら元の要素にフォーカスが戻るか
画像に意味のある alt テキストが設定されているか（装飾的な画像は alt=""）
エラーメッセージが aria-describedby 等で入力フィールドと関連付けられているか
axe-coreやESLint jsx-a11y等の自動テストが CI に組み込まれているか

典型的なアンチパターン

<div> ボタン: クリックハンドラーを <div> に設定してボタンとして使う実装は、キーボードフォーカスが当たらず（Tab で到達できない）、スクリーンリーダーがボタンとして認識しない。<button> 要素を使えばフォーカス・Enterキー操作・セマンティクスが標準で得られる。

フォーカスの消滅: outline: none を全要素に適用してフォーカスリングを消すと、キーボードユーザーが「今どこにいるか」を失う。フォーカスリングはデザインを損なわない形（カスタムスタイル）で維持するか、:focus-visible を使ってマウス操作時のみ非表示にすべきである。

ARIA の過剰な付与: <button role="button"> のように、ネイティブのセマンティクスを持つ要素に同じ意味のARIAを重ねる実装は冗長だが無害である。しかし <nav role="navigation"> に aria-label なしで複数のナビゲーションを配置したり、aria-live を広いコンテナに無差別に設定するなど、誤ったARIAは支援技術のユーザーに混乱を引き起こす。

参考リソース

標準: WAI-ARIA 1.2 - ARIAのロール・プロパティ・ステートの公式仕様
標準: WCAG 2.1 - Webアクセシビリティのガイドライン（A・AA・AAAの3段階）
ツール: axe-core - ブラウザ拡張・Jest・Playwrightで使えるアクセシビリティ自動テストエンジン
ツール: ESLint jsx-a11y - Reactのアクセシビリティ問題を静的解析で検出するESLintプラグイン
ツール: Radix UI - キーボード操作・フォーカス管理・WAI-ARIAが適切に実装されたヘッドレスUIコンポーネント