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

アクセシビリティ（Accessibility）とは、障害の有無や身体的特性に関わらず、すべての人がシステムを利用できるように設計することである。法的義務（日本の障害者差別解消法・米国の ADA・EU の欧州アクセシビリティ法など）であるとともに、より広いユーザー層への対応と UX 品質全体の向上をもたらす。インクルーシブデザインは「障害者のための特別仕様を後付けする」のではなく、多様な能力・状況・文脈を設計の最初から考慮することを原則とし、ユニバーサルデザインの「すべての人に一律の解を提供する」という考え方より柔軟なアプローチをとる。

WCAG（Web Content Accessibility Guidelines）は W3C が定める国際的なウェブアクセシビリティの基準であり、現在の主流は WCAG 2.1・2.2 である。4つの原則（POUR）として、知覚可能（Perceivable）・操作可能（Operable）・理解可能（Understandable）・堅牢（Robust）が定義されており、適合レベルは A・AA・AAA の3段階がある。多くの法規制や調達基準では AA レベルへの適合が求められる。

障害種別ごとのニーズを理解することは設計の前提となる。視覚障害（全盲・弱視・色覚特性）のユーザーにはスクリーンリーダー対応（ARIA ラベル・適切なセマンティック HTML）と十分なコントラスト比が必要である。聴覚障害のユーザーには動画への字幕・音声コンテンツのテキスト代替が必要である。運動障害のユーザーにはキーボードのみでの完全な操作・フォーカス管理が必要で、認知障害のユーザーには平易な言語・一貫したレイアウト・エラーの分かりやすい説明が助けになる。アクセシビリティは専門チームだけでなく、UX プロセスの各フェーズ（設計・実装・テスト）に組み込むことで後付けコストを最小化できる。

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

img 要素に適切な alt テキストが設定されているか（装飾目的の画像は alt="" で空に設定されているか）
フォームの入力フィールドに label が正しく関連付けられているか
キーボードのみでの操作フロー（Tab 順序・フォーカスの可視性）が確認されているか
カラーコントラスト比が WCAG AA 基準（テキスト 4.5:1、大きなテキスト 3:1）を満たしているか
色だけで情報を区別していないか（例: エラー表示が赤色のみで他の視覚的区別がない）
スクリーンリーダーで意味が伝わるよう ARIA 属性が適切に実装されているか
アクセシビリティテスト（axe・Lighthouse・NVDA等）がCI/CDパイプラインに組み込まれているか

典型的なアンチパターン

アクセシビリティの後付け対応: 開発完了後にアクセシビリティ監査を実施し、大量の修正コストが発生するパターン。設計フェーズから WCAG を考慮することで後付け修正コストを大幅に削減できる。

ARIA の誤用: セマンティック HTML で対応できる箇所に ARIA を誤った形で付与し、スクリーンリーダーが混乱する状態になるパターン。「ARIA を使わないことが最善のアクセシビリティ」（First Rule of ARIA）を原則とし、まずネイティブ HTML 要素の利用を検討すべき。

フォーカストラップのない Modal: Modal ダイアログ表示中にキーボードフォーカスがモーダル外に逃げてしまい、スクリーンリーダーユーザーがバックグラウンドコンテンツを操作してしまうパターン。Modal は必ずフォーカストラップを実装する。

参考リソース

WCAG 2.2（https://www.w3.org/TR/WCAG22/）
“Inclusive Design Patterns” Heydon Pickering（Smashing Magazine）
“Accessibility for Everyone” Laura Kalbag（A Book Apart）
axe DevTools（https://www.deque.com/axe/）
WebAIM（https://webaim.org/）