inclusive-user-stories

インクルーシブなユーザーストーリー

アクセシビリティを後から別のチケットとして追加するのではなく、最初から受け入れ基準に含めたユーザーストーリーを書きます。

問題

多くのユーザーストーリーは、次のように書かれています。 「ユーザーとして、必要なものを見つけられるよう、検索結果を絞り込みたいです。」

これは、フィルターが見えて、小さなターゲットをクリックでき、ラベルを読めて、結果を視覚的に把握できるユーザーを想定しています。異なる方法で操作する人々を、気づかないうちに除外しています。

解決策

別個の「アクセシビリティストーリー」を書くのではなく、すべてのストーリーの受け入れ基準にインクルージョンを組み込みます。

ストーリーの構成

ストーリー

標準的な形式を維持します。 「[ユーザー]として、[アクション]したいです。[成果]を得るためです。」

必要に応じて、ユーザーを具体的にします。

• 「キーボードのみを使うユーザーとして、マウスを使わずに検索を絞り込めるよう、矢印キーと Enter キーで結果をフィルターしたいです。」
• 「スクリーンリーダーを使うユーザーとして、結果が更新されたことがわかるよう、フィルターの変更を読み上げてほしいです。」

インクルーシブな受け入れ基準

すべてのユーザーストーリーについて、次の確認項目を受け入れ基準に追加します。

キーボード：

• キーボードだけで機能を完全に操作できる
• フォーカスの順序が論理的である
• すべてのインタラクティブ要素でフォーカスが見える

スクリーンリーダー：

• すべてのコントロールにアクセシブルな名前がある
• 状態の変化が読み上げられる
• 動的なコンテンツの更新に aria-live を使用する

視覚：

• 情報を色だけで伝えない
• テキストが最低限のコントラスト比を満たす（通常のテキストは 4.5:1、大きなテキストは 3:1）
• コンテンツを 200% のズームでも読める

運動：

• タッチターゲットが少なくとも 44×44px である
• 代替手段のない時間制限付きの操作がない
• 代替手段のない精密な操作がない

認知：

• 説明が平易な言葉で書かれている
• エラーメッセージが、何が問題だったかだけでなく、どうすればよいかを説明している
• ユーザーが操作を取り消したり、誤りから回復したりできる

よくあるストーリーのパターン

「ユーザーとして、フォームに入力したい」

追加項目：

• ラベルが見える場所にあり、フィールドに関連付けられている
• 必須フィールドが視覚的にもプログラム上も示されている
• エラーがバナーだけでなく、フィールドの横にインラインで表示される
• キーボード、タッチ、音声でフォームを入力できる

「ユーザーとして、ダッシュボードを見たい」

追加項目：

• データを色だけで伝えない（パターン、ラベル、値を使う）
• グラフにテキストの要約がある
• 論理的なタブ順序で、キーボードを使ってダッシュボードを操作できる
• 主要な指標がスクリーンリーダーで読み上げられる

「ユーザーとして、通知を受け取りたい」

追加項目：

• 通知が視覚的に表示され、かつプログラム上も読み上げられる
• ユーザーが通知の設定を管理できる
• 読み終わる前に通知が消えない
• 通知によってほかの操作が妨げられない

既存のストーリーを監査する方法

1. 各ストーリーを読み、次のように問いかけます。このストーリーは誰を除外しているでしょうか？
2. 受け入れ基準に、キーボード、スクリーンリーダー、視覚、運動、認知に関する要件が含まれているか確認します
3. 単一の入力方法や感覚を前提としているストーリーに印を付けます
4. 不足している基準を追加します。別個のストーリーは作りません

評価の質問

1. 受け入れ基準に、キーボード、スクリーンリーダー、認知に関する要件が含まれていますか？
2. アクセシビリティ基準は完了の定義に含まれていますか？
3. 各ストーリーについて、能力に関する前提を確認しましたか？
4. 1つの入力方法でしか機能しないストーリーはありませんか？