accessibility-debt-tracking

アクセシビリティ負債の追跡

技術的負債を追跡するのと同じように、アクセシビリティ負債を追跡します。時間の経過とともにコストが膨らむ、既知の負債として扱います。

アクセシビリティ負債とは

アクセシビリティ負債とは、製品に存在しているものの、まだ修正されていない既知のアクセシビリティ上の問題すべてです。次のようなものが含まれます。

• 優先度を下げられた監査で見つかった問題
• アクセシビリティ対応を先送りしたトレードオフ
• 十分なアクセシビリティ対応をせずにリリースされた新機能
• アップデートや再設計によって生じたリグレッション
• 支援技術への対応に関する既知の不足

なぜ膨らむのか

ただ待つだけの機能リクエストとは異なり、アクセシビリティ負債は増大します。

• アクセシビリティに問題のある基盤の上に新機能を作るたびに、その機能もアクセシビリティ上の問題を引き継ぎます
• 障害のあるユーザーが回避策を身につけると、いずれ期待とは異なる方法で問題を修正した際に、その回避策が使えなくなります
• 時間の経過や認知度の高まりとともに、法的リスクが増大します
• 問題が長く残るほど、修正にかかるコストが増えます（周辺のコードが増えているためです）
• 問題が存在する理由についてのチームの知識が薄れていきます

負債の記録形式

既知のアクセシビリティ上の問題ごとに、次の項目を記録します。

問題： アクセシビリティ上の障壁を明確に説明します
重大度： critical（タスクを妨げる）／major（大きな困難がある）／ minor（不便がある）
影響を受ける人： 具体的なユーザーグループ
場所： ページ、コンポーネント、またはフロー
WCAG の達成基準： 違反している達成基準
発見日： 発見日と発見方法（監査、ユーザーからの報告、テスト）
延期した理由： すぐに修正しなかった理由
回避策： 影響を受けるユーザー向けの一時的な代替手段
修正にかかる推定工数： small／medium／large
修正期限： 修正が必要な期限
担当者： 修正の責任者

負債の管理

トリアージのルール

• Critical（タスクを妨げる）： 例外なく、現在のスプリント内に修正します
• Major（大きな困難がある）： 30 日以内に修正します
• Minor（不便がある）： 90 日以内に修正します
• 期限を過ぎた問題はすべてエスカレーションします

新たな負債の予防

• すべてのストーリーにアクセシビリティの受け入れ条件を設けます
• マージ前にアクセシビリティをチェックします（自動＋手動）
• 以前修正した問題をリグレッションテストします
• 重大なアクセシビリティ負債を残したまま新機能をリリースすることはできません

負債の返済

• 各スプリントの一定割合を負債の削減に割り当てます （10～20% が一般的です）
• コンポーネントに手を加える際に、関連する負債を修正します
• 次の基準で優先順位を付けます：重大度 × 影響を受けるユーザー数
• 負債の削減を祝い、見える形にします

リグレッションの追跡

• 以前修正した問題が再発した場合、それはリグレッションです
• リグレッションは、原則として重大な問題として扱います
• 再発を防ぐため、修正のたびに自動テストを追加します
• 品質指標としてリグレッション率を追跡します

評価の質問

1. 既知のアクセシビリティ上の問題が、文書化された一覧になっていますか？
2. 各問題に重大度、担当者、期限が設定されていますか？
3. アクセシビリティ負債を各スプリントで返済していますか？
4. リグレッションを検出し、重大な問題として扱っていますか？
5. 負債の傾向は時間とともに改善していますか、それとも悪化していますか？