handoff

アクセシビリティ判断の引き継ぎ

エンジニアが実装できる明確な仕様に、アクセシビリティに関する判断をまとめます。「アクセシブルにする」だけでは仕様にならないからです。

プロセス

ステップ 1：判断をまとめる

decision-documentation を使用して、この機能に関するアクセシビリティの判断をすべて集めます。

• インタラクションパターンとキーボード操作
• スクリーンリーダーによる通知と ARIA の要件
• 視覚的な仕様（コントラスト、色への依存の回避、モーション）
• コンテンツの要件（読解レベル、代替テキスト、リンクテキスト）
• 適応動作（ユーザー設定、ズーム、表示密度）

ステップ 2：実装に対応付ける

compliance-mapping を使用して、各設計判断を具体的な実装要件に変換します。

インタラクティブな要素ごとに、次の項目を指定します。

• HTML 要素または ARIA ロール
• キーボード操作（どのキーで何が起きるか）
• フォーカス管理（操作後にフォーカスが移動する先）
• スクリーンリーダーで通知される名前、ロール、状態
• 視覚的な状態（デフォルト、ホバー、フォーカス、アクティブ、無効、エラー）

コンテンツ要素ごとに、次の項目を指定します。

• 見出しレベル
• 代替テキスト（正確な文言または方針）
• リンクテキスト
• 複数の言語を使用する場合の言語属性

適応動作ごとに、次の項目を指定します。

• メディアクエリと期待される応答
• 検出する設定と変更内容
• ブレークポイントとリフローの動作

ステップ 3：テスト基準を定義する

accessibility-testing-strategy を使用して、各要件に対する具体的なテストケースを提示します。

• キーボードテスト：「Tab キーで送信ボタンに移動し、Enter キーを押して、フォーカスが確認メッセージに移動することを確認します」
• スクリーンリーダーテスト：「エラーに移動し、『エラー：メールアドレスが必要です』と通知されることを確認します」
• 視覚テスト：「ライトモードとダークモードの両方で、本文テキストのコントラスト比が 4.5:1 以上であることを確認します」
• ズームテスト：「ズーム倍率 200％ でフォームが 1 列にリフローし、横スクロールが発生しないことを確認します」

ステップ 4：リスクと依存関係に印を付ける

エンジニアが把握しておくべき事項を記載します。

• カスタムのキーボード操作が必要なコンポーネント
• フレームワークのデフォルト設定ではアクセシブルでない箇所
• ラップまたは置き換えが必要になる可能性のあるサードパーティ製コンポーネント
• 自動テストでは問題を検出できない領域

成果物

次の内容を含む引き継ぎドキュメントを作成します。

1. アクセシビリティ仕様 — HTML、ARIA、キーボード操作、視覚的な仕様を含む、要素ごとの要件
2. テストケース — キーボード、スクリーンリーダー、視覚、ズームのテストに関する、具体的かつ実行可能なシナリオ
3. WCAG への対応付け — 各要件が対応する達成基準
4. リスク一覧 — 既知の課題と推奨される対応方法
5. 完了の定義 — 機能のリリース前に合格必須となる、具体的なアクセシビリティ基準