フレームワーク活用ガイド
押さえておきたい用語
- アクセシビリティ（a11y）: 障害の有無や利用環境に関わらず、すべてのユーザーがプロダクトを利用できること
- フォーカス管理: キーボード操作時に、どの要素が選択状態にあるかを明示し適切に制御すること
- スクリーンリーダー: 画面の内容を音声で読み上げる支援技術。VoiceOver、NVDA、JAWSが代表的
- aria属性: Accessible Rich Internet Applicationsの略。HTMLだけでは伝えきれない意味や状態を支援技術に伝える属性
1
デザイン段階でa11y要件を定義
コントラスト・フォーカス・読み上げ順序をデザインに含める → セマンティックHTMLで実装
こんな悩みに効く#
- 「アクセシビリティを『実装の最後に対応する追加作業』として扱ってしまっている」
- 「デザイナーとエンジニアの間でa11yの責任が曖昧」
- 「何をどこまで実装すればアクセシブルと言えるか分からない」
使い方#
デザイン段階でa11y要件を含める
Figmaのデザインファイルに、コントラスト比・フォーカス順序・タッチターゲットサイズ（最低44×44px）・色以外の情報伝達手段を注記する。デザインハンドオフ時にこれらの情報がエンジニアに渡る仕組みを作る。
セマンティックHTMLを徹底する
<div>と<span>の乱用を避け、<button>、<nav>、<main>、<article>、<heading>など意味のあるHTMLタグを使う。セマンティックHTMLだけで多くのa11y問題は解決する。aria属性は「HTMLだけでは足りない場合の補足」と位置づける。キーボード操作とフォーカス管理を実装する
すべてのインタラクティブ要素にTabキーでアクセスでき、Enter/Spaceで操作できることを確認する。モーダルにはフォーカストラップを実装し、閉じたときに元の要素にフォーカスを戻す。カスタムコンポーネントにはWAI-ARIA Authoring Practicesに準拠したキーボード操作を実装する。
自動テストと手動テストを組み合わせる
axe-coreをCI/CDに組み込み、PRごとに自動チェックを実行する。加えて、月1回のキーボード操作テストとスクリーンリーダー検証を手動で行う。可能であれば障害のある当事者によるユーザーテストも実施する。
具体例#
SaaS — デザインプロセスへのa11y統合
状況: リリース後にa11y問題が発覚し、毎回大規模な修正が発生。修正コストがリリース前の5倍に膨れ上がっていた。
適用プロセス:
- デザインテンプレートに「a11y注記欄」を追加。コントラスト比、フォーカス順序、読み上げテキストをデザイナーが記入する運用に
- コンポーネントライブラリの全コンポーネントにa11y仕様を追加し、Storybookにaxeテストを組み込み
- PRのマージ条件にaxeテストの合格を必須化
成果: リリース後のa11y修正が月平均12件→2件に減少。修正コストが年間で推定60%削減された。
ECサイト — キーボード操作の全面対応
状況: 上肢に障害のあるユーザーから「マウスなしでは購入手続きができない」とフィードバック。商品フィルター、カート操作、決済フローのすべてがマウス前提の実装だった。
適用プロセス:
- 全画面のキーボード操作テストを実施。68箇所でTab操作不能またはフォーカス不可視を検出
- カスタムドロップダウンをネイティブ
<select>に置き換え、商品フィルターにキーボードショートカットを追加 - 決済フローにフォーカスインジケーター（3pxの青枠）を全インタラクティブ要素に表示
成果: キーボードのみでの購入完了率が0%→89%に改善。同時にTabキーナビゲーションの改善が全ユーザーの操作効率を向上させた。
行政サービス — スクリーンリーダー対応の体系化
状況: 電子申請システムがスクリーンリーダーで操作できず、視覚障害のある住民は窓口に来庁する必要があった。法改正で合理的配慮が義務化され、早急な対応が求められた。
適用プロセス:
- VoiceOverとNVDAで全申請フローを検証。フォームのラベル欠落、エラーメッセージの未読み上げ、進捗状況の不明が主要な問題
- 全フォームフィールドに
<label>を紐づけ、エラー時はaria-liveリージョンで即座に通知。ステップ表示にaria-currentを追加 - 視覚障害のある当事者3名にテストを依頼し、操作フロー全体を検証
成果: スクリーンリーダーでの申請完了率が12%→91%に改善。来庁不要になった視覚障害者の利便性が大幅に向上し、窓口対応コストも月40時間分が削減された。
うまくいかないパターン#
| パターン | 問題点 | 対処法 |
|---|---|---|
| リリース後に対応する | 修正コストが設計段階の5〜10倍になる | デザイン段階からa11y要件を含める |
| aria属性を過剰に使う | 意味が矛盾し支援技術が混乱する | まずセマンティックHTMLで解決し、足りない部分だけariaで補う |
| 自動テストだけで安心する | キーボード操作やスクリーンリーダーの問題を見逃す | 手動テストと当事者テストを併用する |
| 一度対応して終わり | 新機能でリグレッションが発生する | CI/CDに組み込み継続的に監視する |
まとめ#
アクセシビリティ・デザイン実践の核心は「後付け」ではなく「プロセスへの統合」にある。デザイン段階でコントラスト・フォーカス・読み上げ順序を定義し、セマンティックHTMLで実装し、自動＋手動テストで検証するサイクルを回す。アクセシビリティは障害のあるユーザーだけのものではなく、キーボード操作の改善は全ユーザーの効率向上に、コントラストの改善は屋外利用時の可読性向上につながる。