アクセシビリティテスト実践ガイド：自動検査・手動検査・支援技術テスト・CI導入・受け入れ基準づくりまで

概要サマリー（先に要点）

• アクセシビリティは“知識”より“検証の習慣”で守られますの。自動検査＋手動検査＋支援技術テストを小さく回すのが最短ルートです。
• 自動ツールは便利ですが、色だけの意味や文脈に合う代替テキスト、エラー文の優しさなどは検出できません。
• まずは 5分スモークテストで事故を防ぎ、次に リリース前の重点項目、最後に 回帰に強いCIへ段階的に育てます。
• 受け入れ基準は「WCAG番号」だけでなく、具体的な操作結果（例：Tabで完遂できる、エラー要約に飛べる）として定義すると強いです。
• 本記事は、現場でそのまま使える チェックリスト・テストケース例・レポートテンプレを含む“実務の教科書”としてまとめました。

対象読者（具体）：QA／テスター、フロントエンドエンジニア、UI/UXデザイナー、PM／ディレクター、アクセシビリティ担当、CMS運用者、制作会社のレビュー担当
アクセシビリティレベル：WCAG 2.1 AA 準拠を目標（プロジェクトによりA→AA→AAAの段階導入を推奨）

1. はじめに：アクセシビリティは“テストで守る品質”

アクセシビリティは、最初に頑張って整えても、改修や新機能で簡単に崩れます。とくにナビゲーション、フォーム、モーダル、表、動画……私たちがこれまで書いてきた分野ほど、UIの変更が頻繁で、回帰バグが起こりやすいですの。
だからこそ重要なのは、設計の知識だけではなく、いつでも同じ品質を再現できる検証の仕組み。
本記事では、個人でもチームでも無理なく回せるように、

• 自動検査（Lighthouse/axe 等）
• 手動検査（キーボード、コントラスト、文言）
• 支援技術テスト（スクリーンリーダー等）
• CI導入（回帰防止）
  を、段階的に実務へ落とし込む方法を丁寧にまとめますね。

2. テストの全体像：3層で考えると失敗しない

2.1 層1：自動検査（機械が見つけられるもの）

• alt の欠落
• ラベルの欠落
• コントラストの不足（一定範囲）
• ARIAの誤用
• 見出し階層の一部
• フォーカス可能要素の基本チェック
  自動検査にはUUUが便利です

メリット：高速・大量ページに強い
限界：文脈・言葉の優しさ・意味の妥当性は判断できない

2.2 層2：手動検査（人間が必ず確認すべきもの）

• キーボードで主要タスクが完遂できるか
• フォーカス可視・順序
• エラー文が「どこで・なぜ・どう直す」になっているか
• 色だけで意味を伝えていないか
• 代替テキストが文脈に合っているか
• レスポンシブでリフローが破綻しないか

2.3 層3：支援技術テスト（最終的な体験確認）

• スクリーンリーダー（NVDA/VoiceOver）
• 画面拡大（OS拡大鏡）
• 音声入力（可能であれば）
• スイッチ操作（可能であれば）

ここは“完璧”を狙うより、代表的なユーザー体験を再現し、事故を防ぐことが目的ですわ。

3. まずはこれだけ：5分スモークテスト（毎回やる）

目的：重大事故（操作不能・読み上げ不能・迷子）を最短で潰す

1. Tabのみで主要機能を完遂できる
   • ナビ → 一覧 → 詳細 → 戻る
   • 検索 → 結果 → フィルタ
   • フォーム → 送信 → エラー修正 → 完了
2. フォーカスが見える（ライト/ダーク両方）
3. スキップリンクで本文へ入れる
4. モーダルは 開く→操作→Esc→復帰 が成立
5. 画像の意味要素に alt があり、装飾は alt=“”
6. テーブルは <th> と scope がある（少なくとも基本表）
7. 動画は字幕がオンにでき、操作がキーボードで可能
8. 200%拡大で横スクロールが出ない（表・コード以外）

この8点が通るだけで、アクセシビリティ事故の大半は防げますの。

4. 自動検査：導入しやすいツールと使い分けの考え方

4.1 自動検査で狙うべきもの

• 壊れたARIA（不正な属性）
• ラベル不足（フォーム事故の早期発見）
• コントラスト不足（簡易）
• 見出し飛び（一部）

4.2 CIで回すと強い

• Pull Request ごとに実行
• “重大違反が1つでもあれば失敗”より、**段階導入（警告→失敗）**が現場に優しい

4.3 自動検査の限界を知る

• altが「画像」でも“存在する”ので合格してしまう
• 色だけで意味を伝えるUIは検出できないことが多い
• 文章のわかりやすさ（平易さ）は検出できない

だからこそ、手動検査のチェックリストが必要ですわ。

5. 手動検査：観点別チェックリスト（実務用）

5.1 キーボード操作

• すべての操作がTab/Enter/Spaceで可能
• フォーカス順序が論理的（DOM順）
• ドロップダウン、タブ、メニューが矢印で操作できる（必要な場合）
• Escで閉じる、閉じたら元の要素に戻る

5.2 フォーカス可視

• :focus-visible が十分太い
• コントラストが十分（非テキスト3:1）
• 背景画像の上でも見える

5.3 テキストとコントラスト

• 4.5:1（通常）/3:1（大きい文字）
• リンクが色だけで判別されない（下線等）
• エラーや警告が色だけになっていない

5.4 フォーム

• ラベルが可視で <label for> がある
• 必須が文字で明示される
• エラーは要約＋個別があり、修正方法が書かれている
• autocomplete が適切

5.5 画像・図表・動画

• 画像：文脈に合うalt、装飾は空alt
• 図表：本文に要点、必要なら表データ
• 動画：字幕・キャプション・操作可能性

5.6 テーブル

• 見出しセル（th）・scope
• 複雑表は headers/id または分割
• レスポンシブで情報欠落なし

6. 支援技術テスト：最小セットで確実に効果を出す

6.1 スクリーンリーダー（最小）

• Windows：NVDA
• macOS/iOS：VoiceOver

テストの型（短縮版）

1. 見出し一覧でページ構造が把握できる
2. ランドマーク（nav/main/footer）で移動できる
3. フォームでラベル・必須・エラーが読める
4. ボタン・リンクの名前がわかる（「こちら」だけではない）
5. モーダルで背景へ抜けない、閉じたら戻れる

6.2 画面拡大（弱視・高齢者の代表体験）

• 200%〜400%拡大で、重要情報が欠落しない
• 行間・文字サイズが読める
• クリックターゲットが小さすぎない

6.3 モバイル支援（可能なら）

• iOSのVoiceOverで、フォームとナビの操作確認
• ターゲットサイズ（44px目安）

7. テストケース例：よくある画面別の“受け入れ基準”

7.1 ナビゲーション

• Tabでグロナビ→本文→フッターへ論理順に移動
• 現在地が aria-current="page" と視覚表示でわかる
• メガメニューはボタンで開閉でき、Escで閉じられる

7.2 検索と絞り込み

• 検索結果の件数がテキストで表示
• フィルタ適用後は結果領域にフォーカス移動（またはstatus通知）
• “0件”でも代替導線がある

7.3 フォーム

• 未入力送信で、エラー要約へフォーカスが移動
• 個別エラーに aria-describedby が付く
• エラー文に修正方法の提案がある

7.4 モーダル

• 開いたら最初の操作要素へフォーカス
• Tabがモーダル内で循環
• Escで閉じ、トリガへ復帰

8. レポートの書き方：修正につながる指摘にする

アクセシビリティの指摘は「違反です」だけでは直りませんの。
再現手順・期待結果・実際結果・影響・提案のセットが必要です。

レポートテンプレ（例）

• 画面：会員登録フォーム
• 手順：必須未入力で送信
• 期待：エラー要約にフォーカス、エラー項目へジャンプできる
• 実際：画面上部に戻らず、どこがエラーか分からない
• 影響：キーボード利用者・SR利用者が修正できない
• 提案：role="alert"の要約＋tabindex="-1"でフォーカス移動、各項目にアンカー

9. CI/CD 導入：回帰を防ぐ“仕組み”の作り方

9.1 段階導入が現場に優しい

• 初期：計測のみ（失敗させない）
• 次：重大違反だけ失敗
• 最終：基準達成をゲート化

9.2 “守るべきページ”を決める

全ページを完璧に検査しようとすると破綻します。
まずは

• トップ
• 一覧
• 詳細
• フォーム（登録/購入/問い合わせ）
• マイページ
  の“主要動線”を代表として固定します。

9.3 デザインシステムとセットで回す

コンポーネント単位でテストできると、回帰が激減しますわ。
（例：ボタン、フォームフィールド、モーダル、タブ、テーブル、アラート）

10. よくある落とし穴と回避策

11. 対象読者にとっての価値（具体）

• QA/テスター：観点が整理され、短時間で“重大事故”を検出できる。
• エンジニア：受け入れ基準が具体化し、実装の迷いが減る。
• デザイナー：フォーカス・ラベル・色依存を早期に修正できる。
• PM/ディレクター：品質ゲートが明確になり、説明責任が果たしやすい。
• 利用者：更新が入っても操作不能になりにくく、安心して使い続けられる。

12. アクセシビリティレベルの評価（本記事の到達点）

• WCAG 2.1 AA の主要観点を網羅
  • 1.1.1 非テキスト
  • 1.3.1/1.3.2/1.3.5 構造と入力目的
  • 1.4.1/1.4.3/1.4.10/1.4.11 色・コントラスト・リフロー
  • 2.1.1/2.1.2 キーボード
  • 2.4.1/2.4.3/2.4.6/2.4.7 ナビ・フォーカス
  • 3.3.1/3.3.3/3.3.4 エラーと誤入力防止
  • 4.1.2 名前・役割・値
• “テストで守る”運用まで含めてAA準拠を継続可能にする内容です

13. まとめ：アクセシビリティは“テストの文化”で育つ

1. まずは 5分スモークテストで重大事故を防ぐ。
2. 自動検査は“早期警報”、手動検査は“品質確認”、支援技術は“体験保証”。
3. 受け入れ基準はWCAG番号だけでなく、操作結果の文章で定義する。
4. CIは段階導入し、代表ページとコンポーネント単位で回帰を潰す。
5. 指摘は再現手順と提案までセットにし、修正につながる言葉にする。

アクセシビリティは、誰か一人の頑張りでは守れません。
小さなテストの習慣を積み重ねることで、更新のたびに“やさしさ”が維持されます。
あなたのチームが、無理なく続けられる形でアクセシビリティ品質を育てられますように。わたしも心を込めてお手伝いしますね。