accessibility-testing-strategy

アクセシビリティテスト戦略

実際のアクセシビリティ上の障壁を見つけるテスト方法を計画します。 自動ツールで見つかる問題はおよそ30％で、残りの70％には人間の判断が必要です。

テストのピラミッド

レイヤー1：自動テスト（約30％を検出）

検出できる問題：

• 代替テキストがない
• 色のコントラスト不足
• フォームのラベルがない
• 言語属性がない
• 見出しやボタンが空
• ID の重複

検出できない問題：

• 代替テキストに意味があるか
• フォーカス順序が論理的か
• コンテンツに意味があるか
• キーボードで操作できるか
• 使いやすい体験か

ツール：axe、Lighthouse、WAVE、Pa11y、jest-axe タイミング：CI/CD パイプラインで、ビルドのたびに 担当：自動 — 人手は不要

レイヤー2：専門家による手動テスト（約50％を検出）

検出できる問題：

• キーボード操作の問題
• フォーカス管理の問題
• 論理的な読み上げ順序の問題
• 代替テキストに意味があるかの評価
• 認知アクセシビリティ上の障壁
• インタラクションパターンの問題

方法：

• すべての操作可能な要素を Tab キーで移動して確認する
• スクリーンリーダー（VoiceOver または NVDA）でテストする
• 200％に拡大してテストする
• システム環境設定を有効にしてテストする
• 平易な言葉が使われているか、コンテンツを確認する

タイミング：各リリース前、大規模な機能変更時 担当：アクセシビリティテストのトレーニングを受けた人

レイヤー3：障害のある人によるユーザーテスト（残り約20％を検出）

検出できる問題：

• 専門家が見落とす、実際の使用環境でのユーザビリティ上の障壁
• 支援技術との互換性の問題
• 想定外のワークフローや回避策
• 認知面および感情面の障壁
• 支援技術の実際の習熟度があって初めて現れる問題

方法：

• 多様な障害のある参加者を募集する
• 参加者自身のデバイスと支援技術を使って、主要なタスクをテストする
• 観察に徹し、誘導や説明はしない
• うまくいったこと、うまくいかなかったこと、困惑させたことを記録する

タイミング：四半期ごと、または大規模なローンチの前 担当：自身の環境を使う、障害のあるユーザー

まずテストすること

優先度1：主要なタスク

• ユーザーは、製品が提供する主なタスクを完了できますか？
• 重要な操作の流れを最初から最後までテストする
• ここで失敗があれば、ローンチを見送る

優先度2：入力とナビゲーション

• 主要な操作の流れをキーボードのみでナビゲーションする
• 主要な操作の流れをスクリーンリーダーでナビゲーションする
• 主要な操作の流れをモバイルでタッチ操作する

優先度3：コンテンツと理解度

• コンテンツは、対象とする読解レベルで理解できますか？
• エラーメッセージは役に立ちますか？
• ヘルプは利用でき、見つけやすいですか？

優先度4：エッジケースと設定

• 200％に拡大する
• システム環境設定（動きを減らす、ハイコントラスト、ダークモード）
• 長いコンテンツ、空の状態、エラー状態

スクリーンリーダーテストの基本

スクリーンリーダーテストに慣れていないチーム向け：

VoiceOver を使い始める（Mac）

• オンにする：Cmd + F5
• ナビゲーション：VO + 矢印キー（VO = Ctrl + Option）
• 見出し：VO + Cmd + H
• リンク：VO + Cmd + L
• フォーム：VO + Cmd + J
• オフにする：Cmd + F5

NVDA を使い始める（Windows）

• nvaccess.org から無料でダウンロードする
• ナビゲーション：Tab、矢印キー
• 見出し：H
• リンク：K
• フォーム：F
• 読み上げを停止：Ctrl

確認すること

• すべての操作可能な要素に名前が付いていますか？
• 状態の変化（展開、選択、チェック）が読み上げられますか？
• 操作後、フォーカスは適切な場所に移動しますか？
• 見出しだけを読んでページの内容を理解できますか？

評価の質問

1. 自動テストはビルドのたびに実行されていますか？
2. 各リリース前に、専門家による手動テストが行われていますか？
3. 障害のある人が製品をテストしていますか？
4. 主要なタスクはキーボードとスクリーンリーダーでテストされていますか？
5. 何を最初にテストするか、明確な優先順位がありますか？