decision-documentation

アクセシビリティに関する意思決定の記録

アクセシビリティに関する意思決定を記録し、今後のチームが何を決めたかだけでなく、その理由も理解できるようにします。理由が誰にも覚えられていないために、良い決定が覆されるという悪循環を防ぎます。

重要な理由

アクセシビリティの障壁は、デザイン変更、フレームワークの更新、スタッフの入れ替わり、慌ただしい締め切りを通じて、気付かないうちに積み重なります。最もよくある原因は、悪意や無知ではありません。新しいチームメンバーが、その設計の理由を知らずに変更してしまうことです。

ドキュメントは免疫システムです。その場にいなかった人によって、良い決定が覆されるのを防ぎます。

意思決定記録の形式

重要なアクセシビリティに関する決定について、以下を記録します。

タイトル

明確で検索しやすい名前。 「フォームの入力検証：概要バナーではなくインラインエラー」

日付と作成者

いつ、誰が決定したか。

背景

どのような状況がこの決定のきっかけになりましたか？どのような制約がありましたか？ 「ユーザーテスト中、認知障害のある参加者5人のうち3人が、ページ上部にあるエラー概要バナーを見落としました。個々のフィールドは修正しましたが、バナーを見るために上へスクロールしなかったため、フォームが送信されていないことに気付きませんでした。」

決定

具体的に何を決定したか。 「フォームの入力検証エラーはすべて、修正が必要なフィールドのすぐ下にインラインで表示します。エラー概要バナーは削除します。各フィールドの aria-describedby を使って、スクリーンリーダーにエラーを通知します。」

検討した代替案

他にどのような選択肢を評価し、なぜ却下したか。 「概要バナーをインラインエラーと併用する案も検討しましたが、テストで混乱が生じることが分かりました。ユーザーが、どちらのエラー表示に従えばよいか分からなかったためです。」

アクセシビリティへの影響

誰に、どのようなメリットがあるか。 「認知障害のあるユーザー（どのフィールドにエラーがあったかを覚えておく必要がありません）、スクリーンリーダーのユーザー（状況に応じてエラーが通知されます）、すべてのユーザー（エラーをより早く修正できます）にメリットがあります。」

リスクとトレードオフ

何がうまくいかない可能性があるか、または何を犠牲にしたか。 「エラーが多いフォームでは、ユーザーはすべてのエラーを一度に確認するのではなく、フィールドを順に進めながら一つずつ確認します。長いフォームでは、スクロールの回数が増える可能性があります。テストでは状況に即したエラーのほうが修正率が高かったため、このトレードオフを受け入れます。」

根拠

この決定を裏付ける調査、テスト、または標準規格。 「2024-03-15 のユーザーテスト（参加者5人、うち3人は認知障害あり）。WCAG 2.2 SC 3.3.1（エラーの特定）。」

記録するタイミング

次の場合は、決定を記録します。

• 2つ以上のアクセシビリティ対応案から選択した
• ある領域のアクセシビリティを下げて、別の領域を改善するトレードオフを行った
• 何かを修正しないと決めた（その理由も記録します）
• 正当な理由により、WCAG の達成方法と異なる方法で実装した
• アクセシビリティ上の理由から、特定のデザインパターンを選択した
• ユーザーテストで、方針を変えるきっかけとなるアクセシビリティ上の知見が得られた

保存場所

• コードベース内のコードと並べて保存する（推奨 — 実装とともに移動します）
• 共有の意思決定ログ（Wiki、Notion、Confluence）に保存する
• デザインシステムのドキュメントに保存する（システムレベルの決定の場合）
• 誰かの記憶や Slack のスレッドにだけ残すことは避けてください

評価の質問

1. アクセシビリティに関する決定とその理由が記録されていますか？
2. 新しいチームメンバーが、特定の方法で構築された理由を確認できますか？
3. トレードオフが明確に記録されていますか？
4. ドキュメントは失われない場所に保存されていますか？