manual-testing

手動アクセシビリティテストのスキル

正式なソース：mgifford/ACCESSIBILITY.md の examples/MANUAL_ACCESSIBILITY_TESTING_GUIDE.md このスキルはそのファイルを基にしています。判断に迷った場合は、例を正式な基準としてください。

手動アクセシビリティテストを計画またはレビューする際は、以下のルールを適用してください。

---

重大度の尺度（このスキル）

レベル	意味
Critical	1 つ以上の障害者グループにとって、中心的なタスクが完全に実行できなくなる問題
Serious	アクセスが大幅に妨げられ、回避策を利用者に求めるのが妥当ではない問題
Moderate	不便が生じるものの、負担が大きすぎない回避策がある問題
Minor	ベストプラクティスからの逸脱で、アクセスへの影響がわずかな問題

---

基本原則

手動テストでは、自動化ツールでは検出できない問題が明らかになります。 たとえば、次のような問題です。

• スクリーンリーダーの読み上げの質とユーザーエクスペリエンス
• キーボード操作の流れと論理的な順序
• 動的なインターフェースにおけるフォーカス管理
• 支援技術を使うユーザーにとってのコンテキストと方向性
• 強制カラー モード（Windows のハイコントラスト）— 自動化ツールでは OS レベルの色の上書きをシミュレートできません
• 実際の利用環境におけるユーザビリティの障壁

---

重大：手動テストが必須となる場合

次の場合は手動テストを実施してください。

• リリース前 — 重要なユーザーフローを最初から最後までテストする
• UI の変更後 — 影響を受けるすべてのコンポーネントをテストする
• 新機能の場合 — ユーザーワークフロー全体をテストする
• 自動テストに合格した場合 — 実際のユーザーエクスペリエンスを検証する
• アクセシビリティのバグが報告された場合 — 再現して修正を検証する

始め方： まずキーボードのみでテストします（最も始めやすい方法です）。次に、使用するプラットフォームの基本的なスクリーンリーダーのコマンドを覚えます。自分のサイトをテストする前に、よく知っているウェブサイトで練習してください。一度に 1 つのコンポーネントまたはフローに集中します。

---

重大：キーボードのみでのテスト

すべてのインタラクティブ要素は、キーボードのみで到達して操作できなければなりません。

手順：

1. ブラウザーのアドレスバーをクリックし、Tab キーを押してページの先頭から開始します
2. ページ全体で Tab キーを押し、フォーカス可能な各要素を確認します：
   • フォーカスが見えるか（明確なアウトラインまたはハイライトがあるか）
   • フォーカス順序が論理的か（視覚的な順序または読み上げ順序に沿っているか）
   • 要素を実行できるか（リンク／ボタンには Enter、ボタン／チェックボックスには Space）
3. Shift+Tab を押して、要素を逆順にたどります
4. キーボードトラップがないことを確認します（すべての要素から Tab キーで移動できるか）

確認する主なキー操作：

キー	期待される動作
Tab	フォーカスを次に進める
Shift+Tab	フォーカスを前に戻す
Enter	リンクやボタンを実行し、フォームを送信する
Space	ボタンを実行し、チェックボックスを切り替える
Arrow keys	コンポーネント（メニュー、タブ、ラジオボタングループ）内を移動する
Escape	ダイアログを閉じ、操作をキャンセルする
Home / End	コンポーネントの先頭／末尾に移動する

コンポーネントごとの確認事項：

• フォーム： すべてのフィールドに到達できること、ラベルと必須状態が読み上げられること、エラーが表示され読み上げられること、Enter で送信できること、該当する場合はキャンセル／リセットできること
• ボタン： Enter と Space の両方で実行できること、実行時に視覚的なフィードバックがあること、実行後にフォーカスが適切な位置に移動すること
• リンク： Enter で実行できること、リンクテキストからリンク先が明確に分かること、スキップリンクが機能すること
• ドロップダウン／選択メニュー： 矢印キーで項目間を移動できること、Escape で閉じられること、選択中の値が読み上げられること
• モーダルダイアログ： 開いたときにフォーカスが内部に移動すること、フォーカスが内部に留まること（フォーカストラップ）、Escape で閉じられること（重要な場合を除く）、閉じたときにフォーカスが起動元に戻ること
• カスタムウィジェット（タブ、アコーディオン、カルーセル）： WAI-ARIA のキーボード操作パターンに従うこと、矢印キーと Home/End が仕様どおりに機能すること、状態の変化が明確であること

---

重要：スクリーンリーダーのテスト

推奨するプラットフォームの組み合わせ：

• NVDA + Firefox または Chrome（Windows）
• JAWS + Chrome または Firefox（Windows）
• VoiceOver + Safari（macOS / iOS）
• TalkBack + Chrome（Android）

基本的なテスト手順：

1. スクリーンリーダーを起動します（NVDA：Ctrl+Alt+N、VoiceOver macOS：Cmd+F5）
2. 見出しから移動します（NVDA/JAWS：H / Shift+H）。論理的なアウトラインになっていますか？
3. ランドマークから移動します（NVDA/JAWS：D / Shift+D）。<nav>、<main>、<header> が識別されますか？
4. フォームコントロールから移動します（NVDA/JAWS：F / Shift+F）。ラベルが読み上げられますか？
5. すべてのコンテンツを読み上げます。順序は論理的ですか？読み上げ漏れや、わかりにくい読み上げはありませんか？

コンポーネントごとのスクリーンリーダーの確認事項：

• 画像： 装飾画像は無視される（空の alt / aria-hidden）。情報を伝える画像には説明的な代替テキストがある。複雑な画像には、より詳しい説明がある
• リンク： 読み上げだけで目的がわかる。テキストに意味がある（「ここをクリック」ではない）。外部リンクや新しいウィンドウが示される
• ボタン： ラベルが操作内容を説明している。押下状態や切り替え状態が読み上げられる。無効状態が読み上げられる
• フォームフィールド： フィールドの種類より先にラベルが読み上げられる。必須状態、操作方法やヒント、エラーメッセージ、成功メッセージがすべて読み上げられる
• 動的コンテンツ： コンテンツの追加や削除がライブリージョンを通じて読み上げられる。読み込み状態や進行状況が伝わる
• テーブル： 行やセルを使って移動できる（NVDA/JAWS では Ctrl+Alt+Arrow）。各セルとともに列見出しと行見出しが読み上げられる。テーブルの目的が明確である（キャプションまたは aria-label）
• カスタムウィジェット： ロールが読み上げられる（例：「タブ」「メニュー」「ダイアログ」）。状態が読み上げられる（例：「選択済み」「展開済み」）。複雑なウィジェットには操作方法が示される

各インタラクティブ要素について、次の項目を確認してください：

• 要素の種類が読み上げられる（ボタン、リンク、見出しなど）
• ラベルや名前が明確で、説明的である
• 現在の値が読み上げられる（フォームフィールド）
• 状態が読み上げられる（チェック済み、選択済み、展開済みなど）
• 変更が読み上げられる（動的な更新、ライブリージョン）

重大：強制カラー表示モードのテスト

自動ツールで見逃される理由： 強制カラー表示は、作成者が定義したすべての色を制限されたシステムパレットに置き換える OS レベルの設定によって有効になります。自動ツールでは、OS レベルの上書きをシミュレートしたり、カスタムカラーが取り除かれたときにどの要素が見えなくなるかを検出したり、フォーカスインジケーター、アイコン、カスタムコントロールが置き換え後も表示されるかを評価したりできません。

有効にする方法：

• Windows 11： 設定 → アクセシビリティ → コントラストテーマ → テーマを選択 → 適用
• Windows 10： 設定 → 簡単操作 → ハイコントラスト → 有効にする（または Alt+Left Shift+Print Screen）
• Chrome/Edge DevTools： F12 → その他のツール → レンダリング → 「CSS メディア機能の強制カラーをエミュレート」→ active
• Firefox： about:config → ui.forcedColors → 1 に設定（リセットするには -1）
• Polypane には強制カラー表示のエミュレーションパネルが含まれています

リリース前に、必ず実際の OS 設定で確認してください。DevTools のエミュレーションは便利ですが、完全に同等ではありません。

確認する項目：

• すべてのテキストが背景に対して読みやすい（Canvas 上の CanvasText）
• ボタンの境界が見えること、リンクが本文と区別できること、フォームフィールドの境界線が見えること
• キーボードフォーカスのアウトラインが見えること（outline は保持されますが、box-shadow は保持されない場合があります）
• SVG アイコンが見えること（fill／stroke には currentColor を使用）
• カスタムのチェックボックス／ラジオボタンが引き続き見えて区別できること。切り替え状態は色だけでなく、テキスト、ARIA、アウトラインで示すこと
• エラー状態が色だけに頼らず識別できること。必須フィールドは色だけでなく、テキストまたはアイコンで示すこと
• 意味を伝える背景画像に、テキストまたは ARIA による代替情報があること
• グラフ／データの視覚化に、パターン、テクスチャ、ラベルによる代替手段があること

よくある修正方法：

問題	修正方法
box-shadow のフォーカスリングが消える	outline に置き換える
SVG アイコンが見えない	fill／stroke に currentColor を使用する
カスタムのチェックボックスが見えない	見える境界線を追加し、forced-color-adjust で上書きする
エラーが色だけで示されている	アイコン、テキストラベル、または aria-invalid を追加する
入力欄が見えない（border: none）	@media (forced-colors: active) 内で border: 1px solid ButtonBorder を追加する
背景画像が削除される	見えるテキスト、キャプション、または aria-label を追加する

パッチ適用用の CSS システムカラーキーワード：

@media (forced-colors: active) {
  :focus-visible {
    outline: 3px solid Highlight;
    outline-offset: 2px;
  }
  .custom-checkbox::before {
    forced-color-adjust: none;
    border: 2px solid ButtonBorder;
    background-color: ButtonFace;
  }
  .custom-checkbox[aria-checked="true"]::before {
    background-color: Highlight;
  }
}

関連キーワード：Canvas、CanvasText、ButtonFace、ButtonText、 ButtonBorder、Highlight、HighlightText、LinkText、VisitedText、GrayText。

forced-color-adjust: none は最後の手段としてのみ使用してください。これを使うと要素が強制カラー表示の対象外となり、ユーザーのアクセシビリティ設定が無効になる場合があります。

---

中程度：視覚的なアクセシビリティの確認

色のコントラスト

• 通常のテキスト（18 pt 未満または太字で 14 pt 未満）：最小 4.5:1
• 大きなテキスト（18 pt 以上または太字で 14 pt 以上）：最小 3:1
• UI コンポーネントとグラフィック：最小 3:1
• フォーカスインジケーター：隣接する色に対して 3:1

テストには WebAIM Contrast Checker、ブラウザーの DevTools を使用してください。ライトモードとダークモードは個別にテストしてください。

SC 1.4.4 テキストのサイズ変更と SC 1.4.10 リフロー — 混同しないでください

これらは異なるテスト方法を持つ、別個の達成基準です。一方に適合して他方に適合しないページもあり、200％のズームで横スクロールが発生しても、必ずしもどちらかに不適合というわけではありません。

SC 1.4.4 テキストのサイズ変更（AA）： コンテンツは、コンテンツや機能を損なうことなく、最大200％まで拡大できなければなりません。これは特にテキストの拡大を確認するものであり、それ自体は横スクロールの解消を求めるものではありません。

1. ブラウザーのズームを200％に設定します（Ctrl/Cmd + +）
2. すべてのコンテンツが読みやすく、切り取られたり重なったりしていないことを確認します
3. 200％でも機能（メニュー、フォーム、コントロール）が動作することを確認します
4. OS レベルの画面拡大機能（Windows 拡大鏡、macOS Zoom）でもテストします

SC 1.4.10 リフロー（AA）： ビューポート幅が320 CSS ピクセル相当の場合、情報や機能を損なわず、2次元のスクロールを必要とせずにコンテンツを表示しなければなりません（デスクトップで一般的なテスト方法は、幅1280pxのビューポートを400％にズームすることです。この2つは同等です）。

1. ビューポートの幅を320 CSS ピクセルに設定します（または、幅1280pxのビューポートを400％にズームします）
2. 例外に該当しないコンテンツを読むために横スクロールが必要ないことを確認します。例外については以下をご覧ください
3. コンテンツが切り取られたり、重なったり、隠れたりしていないことを確認します
4. インタラクティブ要素を引き続き操作できることを確認します
5. 元の視覚的なレイアウトに頼らずに、読み上げ順序、関係性、操作性が保たれていることを確認します

例外の正確な内容： SC 1.4.10で例外となるのは、使用や意味のために2次元レイアウトを必要とするコンテンツの一部分のみであり、ページ全体ではありません。規範的な例には、データテーブル、地図、図表、ビデオプレーヤー、ゲーム、プレゼンテーション、ツールバーを常に表示しておく必要があるインターフェースがあります。例外となるコンポーネントがあっても、ページの残りの部分は例外になりません（データテーブルの上にある見出し、フィルター、検索、ページネーションは、引き続きリフローできなければなりません）。例外となるコンポーネント内でも、個々のセクションにはリフローが必要な場合があります。「必要とする」とは、意味に基づく判断であり、利便性に基づく判断ではありません。情報や機能を損なわずにリフローできるのに、幅の広い固定レイアウトのほうが見栄えがよいというだけのコンポーネントは、例外にはなりません。

400％のズーム（または320px相当）で横スクロールが発生するページは、リフローが達成されていない可能性を示す重要な指標です。ただし、不適合と結論づける前に、はみ出したコンテンツが例外に該当するかを調べてください。再利用可能でテスト済みの Playwright リフローリスク指標と、その文書化された制限については、Behavioral Accessibility Automation（skills/behavioral-a11y/SKILL.md）をご覧ください。これは指標であり、リフローへの適合性を確認するテストではありません。例外に該当するかの判断、コンテンツが切り取られていないことの確認、400％のズームでの実際のコンテンツのテストには、引き続き人による判断が必要です。

フォーカスインジケーター：3つの異なる適合基準

SC 2.4.7 フォーカスの可視化（AA）： キーボードでフォーカス可能なすべての要素には、視認できるフォーカスインジケーターが必要です。二択で確認します。視認できるインジケーターがあるか、ないかです。

• すべてのフォーカス可能な要素でフォーカスインジケーターが視認できる
• より優れた代替手段に置き換える場合を除き、フォーカスインジケーターが削除されていない
• フォーカスインジケーターが他のコンテンツに隠されていない

SC 1.4.11 非テキストのコントラスト（AA）： UI コンポーネントのフォーカスインジケーターは、隣接する色とのコントラスト比が少なくとも 3:1 である必要があります。これはコンポーネントの通常状態ではなく、インジケーター自体に適用されます。

• フォーカスインジケーターのコントラストは、インジケーターの色と隣接する背景色またはコンポーネント色を基準に測定して、隣接する色との比率が 3:1 以上である
• カスタムのフォーカススタイルがコントラスト要件を満たしている（デフォルトのアウトラインだけではない）

SC 2.4.13 フォーカスの外観（AAA）： SC 2.4.7 より厳格です。フォーカス可能な要素の周囲長 × 2 CSS ピクセル以上の最小面積、フォーカス状態と非フォーカス状態の間の 3:1 のコントラスト比を要求し、作成者が追加したコンテンツによってインジケーターが完全に隠されてはなりません。AA を目標とするプロジェクトではこれを満たす必要はありませんが、満たすことでアクセシビリティがさらに向上します。プロジェクトがこれを目標とするかどうかを記録してください。

動作テストにおけるスクリーンショット差分の検証： CWAC プロジェクトの FocusIndicatorAudit は実際に Tab キーを押し、各キー押下の前後でページ全体のスクリーンショットを比較します。ピクセルに変化がない場合は、指摘事項を報告します。この方法では、コントラスト（SC 1.4.11）の測定、検出された変化がフォーカスされた要素の局所的なものかどうかの確認（比較対象はページ全体です）、インジケーターが十分に認識しやすいかどうかの判定、インジケーターがない状態と他のコンテンツに隠されている状態の区別はできません。このリポジトリ独自の再利用可能な実装（skills/behavioral-a11y/SKILL.md、focus-visible-risk.mjs）は、文書化された方法を独立して再実装したもので、各要素の周囲に余白を加えた領域を対象に、フォーカスのない状態とフォーカスされた状態のスクリーンショットの組を新たに取得します。これにより CWAC のページ全体を比較する方法の制約の一部を解消する一方、独自のトレードオフも生じます。どちらの実装も、また、スクリーンショット差分による方法だけでは、SC 1.4.11（コントラスト）や SC 2.4.13（最小面積）への適合を検証できません。スクリーンショット差分の検証は、フォーカスインジケーターの唯一のテスト方法としてではなく、手動検証と併用する補助的な確認方法として利用してください。

---

コンポーネントの種類ごとのテストワークフロー

フォーム： キーボードのみでフォームに移動 → すべてのフィールドに入力（Tab の順序を確認）→ 検証エラーを発生させる → エラーが表示され、読み上げられることを確認 → 修正して再検証 → Enter/Space で送信 → 成功メッセージが読み上げられることを確認します。スクリーンリーダーでも、フィールドのラベル、説明、種類が読み上げられること、エラーが論理的な読み上げ順で表示されることを確認してください。

モーダルダイアログ： トリガーを有効にする → フォーカスがモーダル内に移動することを確認 → すべての要素を Tab で移動する → Tab でモーダルの外に出ないことを確認（フォーカストラップ）→ Escape または閉じるボタンで閉じる → フォーカスがトリガーに戻ることを確認します。スクリーンリーダーでも、モーダルが読み上げられること（role="dialog"、aria-labelledby）と、コンテンツが論理的な読み上げ順になっていることを確認してください。

シングルページアプリケーション： ナビゲーションリンクをクリック → コンテンツが変わることを確認 → フォーカスがメインの見出しまたはコンテンツに移動することを確認 → ページタイトルが変わることを確認 → ルートの変更が読み上げられるか、フォーカスによって状況が伝わることを確認します。戻るボタンが機能すること、新しいページの構造（ランドマーク、見出し）が明確であることも確認してください。

---

テスト結果の記録

見つかった問題ごとに、テストしたコンポーネントまたはページ（URL または名前）、問題の説明、期待される動作、再現手順（番号付き）、支援技術の名称とバージョン、ブラウザーの名称とバージョン、OS の名称とバージョン、重大度を記録してください。必要に応じて、スクリーンショットや録画、違反している WCAG 達成基準も記載します。

## Accessibility Issue: [Brief Description]

**Component:** [URL or component name]
**Issue:** [Description of what doesn't work]
**Expected:** [What should happen]
**Severity:** [Critical/High/Medium/Low]

**Steps to Reproduce:**
1. [Step 1]
2. [Step 2]

**Testing Environment:**
- **Screen Reader:** [Name and version]
- **Browser:** [Name and version]
- **OS:** [Operating system and version]

**WCAG Criterion:** [If applicable]
**Suggested Fix:** [If you have one]

（構造化された指摘事項には、skills/bug-reporting/SKILL.md を使用してください。）

---

障害のある人の参加を促す

障害のある人は、障壁を特定し、解決策を検証する専門家です。実体験を通じて、自動化ツールや障害のないテスターが見落とす問題を明らかにし、修正が実際に機能することを検証できます。

• 参加の障壁を取り除きます。専門用語を使わない明確な説明、柔軟な期限、非同期のフィードバック、テストにかかった時間への報酬、アクセシブルな問題報告形式を用意します
• 多様なテスターを招きます。スクリーンリーダーの利用者、キーボードのみで操作する利用者、音声コントロールの利用者、認知障害のある利用者、複数の障害のある利用者を招きます
• テスターに適切な謝意を示し、公正に報酬を支払います。継続的に参加できる機会を設けます

---

クイックリファレンスチェックリスト

30分間のキーボードのみのテスト： Tab キーで最初から最後まで移動します。すべての場所でフォーカスが見えることを確認します。すべてのボタン（Enter／Space）とリンク（Enter）を操作します。フォームに入力して送信します。モーダルを開閉します。カスタムウィジェットを使います。メニューを操作します。キーボードトラップがないことを確認します。

30分間のスクリーンリーダーテスト： 見出し、ランドマーク、フォームフィールドを使って移動します。ページ全体の内容を読み上げます。ボタンとリンクを操作します。フォームに入力して送信します。カスタムウィジェットをテストします。画像に代替テキストがあることを確認します。動的コンテンツの更新が読み上げられることを確認します。

視覚的なアクセシビリティの簡易チェック： 200％ズーム、フォーカスインジケーターの視認性、テキストと UI コンポーネントのカラーコントラスト、色だけに頼らずコンテンツを読み取れること、ライトモードとダークモード、強制カラーモードを確認します。

---

完了の定義チェックリスト

• キーボードのみのテストを完了し、すべての操作にアクセスして実行できる
• キーボードトラップがないことを確認済み
• フォーカス順序が論理的である
• 少なくとも 1 つのプラットフォームの組み合わせでスクリーンリーダーテストを完了済み
• すべての画像、アイコン、グラフに適切なテキストによる代替情報がある
• 動的コンテンツの変更がスクリーンリーダーで読み上げられる
• テキストと UI コンポーネントのカラーコントラストを確認済み
• すべてのカスタム UI コンポーネントで強制カラーモードをテスト済み
• 200％ズームでテストし、コンテンツが切れたり、横スクロールが発生したりしない
• 該当する場合、フォーム、モーダル、SPA のナビゲーションに関するコンポーネントのワークフローテストを実行済み
• URL、要素、WCAG 成功基準、重大度、再現手順を記録済み

---

主な WCAG 成功基準

• 1.1.1 非テキストコンテンツ（A）
• 1.3.1 情報及び関係性（A）
• 1.4.1 色の使用（A）
• 1.4.3 コントラスト（最低限）（AA）
• 1.4.11 非テキストのコントラスト（AA）
• 2.1.1 キーボード（A）
• 2.1.2 キーボードトラップなし（A）
• 2.4.3 フォーカス順序（A）
• 2.4.7 フォーカスの可視化（AA）
• 2.4.11 フォーカスの外観（AA — WCAG 2.2）
• 4.1.2 名前、役割、値（A）
• 4.1.3 ステータスメッセージ（AA）

---

参考資料

• ガイド全文
• skills/behavioral-a11y/SKILL.md — リフローリスクとフォーカスの可視化リスクを示す自動インジケーター、およびその制限事項の記録
• WebAIM：NVDA を使ったテスト
• WebAIM：VoiceOver の使用
• WebAIM：スクリーンリーダーのテスト
• Deque：スクリーンリーダーのキーボードショートカット
• WAI-ARIA オーサリングプラクティスガイド
• W3C：簡易チェック — 初回レビュー
• MDN：forced-colors メディア機能

標準の動向： これらのルールは WCAG 2.2 AA を対象としています。 監視対象：https://www.w3.org/TR/wcag-3.0/