accessibility-review

アクセシビリティレビュー

概要

このスキルでは、WCAG 2.1／2.2 レベル AA 基準に照らして、Web コンテンツ、コンポーネント、アプリケーションのアクセシビリティを手動でレビューできます。実用的で最新のアクセシビリティ要件に重点を置き、過度に細かい指摘は避けます。

このスキルを使用するタイミング

ユーザーから次のような質問をされた場合に、このスキルを使用します。

• 「これはアクセシブルですか？」
• 「色のコントラストをレビューしてもらえますか？」
• 「このコンポーネントにアクセシビリティ上の問題がないか確認してください」
• 「アクセシビリティ基準を満たしていますか？」
• アクセシビリティのレビュー、確認、検証を依頼された場合

レビュープロセス

1. 対象を特定する

レビュー対象を特定します。

• 特定のコンポーネント（ボタン、フォーム、モーダルなど）
• ページ全体またはアプリケーション
• コードファイルまたは複数のファイル
• デザインモックアップまたはスクリーンショット

2. 手動でレビューする

references/wcag-checklist.md の WCAG チェックリストを使用して、最新のアクセシビリティ基準に照らし、対象を体系的にレビューします。

最もよくある影響の大きい問題に重点を置きます。

• 知覚可能：色のコントラスト、テキストによる代替、セマンティックな構造
• 操作可能：キーボード操作、フォーカス管理、インタラクティブ要素
• 理解可能：明確なラベル、エラー処理、一貫したナビゲーション
• 堅牢：有効な HTML、ARIA の使用、互換性

3. 指摘事項に優先順位を付ける

各問題を次のように分類します。

重大 - ユーザーが主要な機能にアクセスできなくなる問題：

• 意味のある画像に代替テキストがない
• キーボードで操作できないインタラクティブ要素
• 色のコントラストが不十分（通常のテキストで 4.5:1 未満、大きなテキストで 3:1 未満）
• 適切なラベルがないフォーム
• フォーカスインジケーターがない
• アクセシブルでないモーダル／ダイアログのパターン
• コントロールなしでメディアが自動再生される

警告 - アクセスを完全に妨げるわけではないものの、使いにくさを生む問題：

• 見出し階層が最適でない（レベルが飛ばされている）
• ARIA ランドマークがない
• 文脈から切り離すと意味が不明瞭なリンクテキスト
• 冗長または不要な ARIA
• タッチターゲットが 44x44px 未満
• スキップリンクがない
• 説明が不十分なエラーメッセージ

4. 段階的なレビュー（問題を一度に 1 つずつ）

重要：指摘事項を一度にすべて提示しないでください。問題を 1 つずつレビューし、次に進む前にユーザーの判断を待ってください。

4.1 概要から始める

まず、見つかった問題の数をユーザーに伝えます。

Found [X] accessibility issues ([Y] critical, [Z] warnings).

Let's review them one at a time. I'll present each issue with a recommended fix, and you can decide to:
- **Fix** — I'll implement the change
- **Ignore** — Tell me why, and I'll note it

Starting with critical issues first.

4.2 各問題を提示する

各問題を、次の形式で 1 つずつ提示します。

───────────────────────────────────
Issue [1/X]: [Critical/Warning]
───────────────────────────────────

**Problem**: [Clear description of the issue]

**Location**: `file_path:line_number`
[Show the relevant code snippet]

**Impact**: [How this affects users — be specific about who and how]

**Recommended Fix**:
[Specific code change or approach]

───────────────────────────────────
Fix this issue, or ignore? (If ignoring, please share why)

4.3 ユーザーの返答に対応する

ユーザーが「修正」と言った場合：

1. 修正を実施する
2. 「修正しました。［変更内容の簡単な説明］」と伝える
3. 次の問題に進む

ユーザーが理由を添えて「無視」と言った場合：

1. 「承知しました。次の理由で無視します：［ユーザーの理由］」と応答する
2. 判断内容を記録する（4.4 を参照）
3. 次の問題に進む

ユーザーが理由を添えずに「無視」と言った場合：

1. 「承知しました。参考までに、簡単に理由を教えていただけますか？（今後の参考にします）」と尋ねる
2. どのような返答でも受け入れて、次に進む

4.4 判断内容を記録する

問題を確認する間、判断内容を継続して記録します。すべての問題のレビューが終わったら、概要を提示します。

5. 最終概要

すべての問題をレビューした後、概要を提示します。

## Accessibility Review Complete

**Reviewed**: [X] issues ([Y] critical, [Z] warnings)

### Fixed ([N])
- [Issue description] — `file:line`
- [Issue description] — `file:line`

### Ignored ([N])
- [Issue description] — Reason: [user's reason]
- [Issue description] — Reason: [user's reason]

### Remaining Concerns
[Any patterns noticed, suggestions for future, or issues that were ignored but warrant reconsideration]

レビューのガイドライン

実用性を重視する：ユーザーに実際の影響がある問題に重点を置きます。現代の WCAG 2.1／2.2 レベル AA を基準とし、過剰な実装や、あまり知られていない例外的なケースの指摘は避けてください。

具体的にする：可能な場合は、file_path:line_number 形式で実際のコード箇所を示します。

建設的にする：問題を指摘するだけでなく、実行可能な修正案を提示します。役立つ場合は、コード例も含めてください。

文脈を考慮する：パターンによっては、アクセシビリティとのトレードオフが生じる場合があります。その点を認識し、ユースケースに応じて最もアクセシブルな方法を提案します。

確認すべき一般的なパターン

インタラクティブ要素

• すべてのインタラクティブ要素をキーボードで操作できる必要があります（Enter／Space キーで有効化）
• 明確なインジケーターでフォーカスが見える必要があります
• カスタムコントロールには、適切な ARIA ロールと状態が必要です

フォーム

• すべての入力に関連付けられたラベルが必要です（明示的なラベルまたは aria-label）
• エラーメッセージは、プログラムでフィールドに関連付ける必要があります
• 必須フィールドは明確に示す必要があります

色とコントラスト

• テキストのコントラスト比：通常のテキストは最低4.5:1、大きなテキスト（18pt以上または太字で14pt以上）は3:1
• UI コンポーネント：インタラクティブな要素とその状態には3:1のコントラスト比
• 情報を伝える際に色だけに頼らないでください

画像とメディア

• 意味のある画像には、内容を説明する代替テキストが必要です
• 装飾用の画像には空の代替テキストを設定してください（alt=""）
• 動画にはキャプションが必要です。音声コンテンツには文字起こしが必要です

構造

• セマンティック HTML（nav、main、article など）を使用してください
• 見出しの階層は論理的にしてください（h1 → h2 → h3）
• ARIA ランドマークはスクリーンリーダーでのナビゲーションに役立ちます

リソース

このスキルには次の内容が含まれています。

references/wcag-checklist.md

原則（知覚可能、操作可能、理解可能、堅牢）ごとに整理された、WCAG 2.1/2.2 レベル AA の要件を網羅したチェックリストです。アクセシビリティ基準を漏れなく確認できるよう、レビュー時に参照してください。