フロントエンドUX・アクセシビリティレビュー
フロントエンドのコードベースを静的解析し、アクセシビリティとUXの改善案を優先度付きMarkdownレポートとして提案する。
分析ワークフロー
レビューは以下の5ステップで実施する。
Step 1: 対象の特定とスコープ確認
- プロジェクトの技術スタックを特定する（React/Vue/Svelte/プレーンHTML等）
- ユーザーが指定したファイル・ディレクトリに絞る。指定がなければ以下を優先的に探索する:
- ページ/ルートコンポーネント
- 共通レイアウトコンポーネント
- フォームコンポーネント
- ナビゲーションコンポーネント
- モーダル/ダイアログコンポーネント
- CSS/スタイルファイルも対象に含める
Step 2: アクセシビリティ分析
references/wcag-checklist.md のチェックリストに基づき、以下の4原則で分析する:
- 知覚可能: テキスト代替、見出し階層、フォームラベル、コントラスト、フォーカス表示
- 操作可能: キーボード操作、フォーカス管理、タッチターゲット
- 理解可能: lang属性、エラーメッセージ、予測可能な動作
- 堅牢: ARIA属性の正確性、カスタムウィジェットのrole
カスタムウィジェットを発見した場合は references/aria-patterns.md と照合して正しいパターンになっているか確認する。
Step 3: UX分析
references/ux-heuristics.md のチェックリストに基づき、コードから検出可能なUX問題を洗い出す:
- ローディング/フィードバック状態の欠如
- エラーハンドリングとリカバリ
- フォームのバリデーションとヒント
- レスポンシブ対応
- 一貫性と標準的なパターンの使用
- 空状態・エッジケースの考慮
Step 4: フレームワーク固有のチェック
技術スタックに応じた追加チェックを行う:
React/Next.js:
keyプロパティの適切な使用useEffectの依存配列の妥当性dangerouslySetInnerHTMLのXSSリスクReact.Fragmentでの不要なDOM要素削減next/imageの使用（Next.jsの場合）
Vue/Nuxt:
v-forのkey属性v-htmlのXSSリスク- コンポーネントのpropsバリデーション
共通:
- コンポーネントのアクセシビリティprops伝搬（
aria-*,role等） - イベントハンドラのキーボード対応
Step 5: レポート生成
分析結果を以下のフォーマットでMarkdownレポートとして出力する。
レポートフォーマット
# フロントエンド UX・アクセシビリティ レビューレポート
**対象**: [プロジェクト名/パス]
**分析日**: [日付]
**技術スタック**: [検出されたスタック]
**分析ファイル数**: [N]件
## サマリー
| カテゴリ | Critical | Major | Minor | 合計 |
|---------|----------|-------|-------|------|
| アクセシビリティ | N | N | N | N |
| UX | N | N | N | N |
| **合計** | **N** | **N** | **N** | **N** |
## Critical（即座に対応すべき）
### [ID] [問題タイトル]
- **カテゴリ**: アクセシビリティ / UX
- **WCAG基準**: [該当する場合]
- **該当ファイル**: `path/to/file.tsx:行番号`
- **問題**: [具体的な問題の説明]
- **修正案**:
[修正前後のコード例]
## Major（早期に対応すべき）
（同じ形式で列挙）
## Minor（改善推奨）
（同じ形式で列挙）
## 良い実践（Good Practices）
既に適切に実装されている点を挙げる（モチベーション維持のため）:
- [良い点1]
- [良い点2]
重大度の判定基準
- Critical: ユーザーがコンテンツにアクセスできない、または操作不能になる問題
- 例: alt属性なし画像、キーボード操作不可、フォーカス表示なし
- Major: 一部のユーザーに大きな不便を与える問題
- 例: 見出し階層の乱れ、不十分なエラーメッセージ、aria-expanded未更新
- Minor: 改善すると体験が向上するが、致命的ではない問題
- 例: prefers-reduced-motion未対応、スキップリンクなし
注意事項
- コード修正案は最小限の変更に留め、既存のコードスタイルに合わせる
- 推測による指摘は避け、コードから確実に検出できる問題のみ報告する
- 同じパターンの問題が複数箇所にある場合、代表例1つ+影響範囲の記載にまとめる
- 「良い実践」セクションで既に適切な実装を認めることで、建設的なレビューにする