edge-case-identification について
障害のある人には日常的でも、見落とされがちな状況を特定するデザインスキルです。入力、出力、コンテンツ、状況、タイミングの観点から確認し、検討用の演習を示します。
主な機能
- 01入力と出力の状況チェックリスト
- 02コンテンツ・状況・時間のケース
- 03「もしも」の検討演習
- 04通常経路の前提を反転するテスト
- 05チーム向け評価項目
活用シーン
- 01アクセシビリティテスト計画の拡充
- 02多様な入力方法を想定したフォーム確認
- 03ユーザーフローの問題点の発見
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ owl-listener/ inclusive-design-skills --skill edge-case-identificationインストール後、Claude Code で/edge-case-identificationを入力して読み込まれたか確認します。
詳細
エッジケースの特定
チームが「エッジケース」として片付けているものの、障害のあるユーザーにとっては日常的に起こるシナリオを特定します。チームにとってのエッジケースは、ある人にとっては主要なケースであることがよくあります。
基本原則
「それはエッジケースです」は、アクセシビリティが後回しにされる最も一般的な理由です。障害のある人に影響するなら、それはエッジケースではなく、満たせていない設計要件です。
見過ごされがちなエッジケースのカテゴリ
入力に関するエッジケース
- ユーザーがマウスを使えない(キーボードのみ)
- ユーザーがキーボードを使えない(音声入力またはスイッチのみ)
- ユーザーが両手を使えない(片手での操作)
- ユーザーが入力する代わりにコンテンツを貼り付ける
- ユーザーがオートコンプリートやパスワードマネージャーを使ってフィールドに入力する
- ユーザーが異なる文字体系や言語でコンテンツを入力する
- ユーザーが句読点を声に出して読み上げながら音声入力する
出力に関するエッジケース
- ユーザーが画面を見られない(スクリーンリーダー)
- ユーザーが画面のごく一部しか見られない(拡大表示)
- ユーザーが色を区別できない
- ユーザーが音声を聞けない
- ユーザーが画面をグレースケールモードまたはハイコントラストモードにしている
- ユーザーがテキストを200%に拡大している
- ユーザーがアニメーションを無効にしている
コンテンツに関するエッジケース
- 非常に長い名前(ハイフン付き、複数語、文化的な命名規則)
- 名前や住所のフィールドに含まれるラテン文字以外の文字
- データがまだ存在しない空の状態
- あらゆることが一度にうまくいかないエラー状態
- 前提となる情報がない初回利用
- 文脈を忘れた状態で、数か月ぶりに戻ってきた場合
- ユーザーにとって適切でない言語のコンテンツ
利用状況に関するエッジケース
- 長いフォームの途中でセッションがタイムアウトする
- 作業の途中で接続が切れる
- 重要な操作の途中でバッテリーが切れそうになる
- 操作中に画面の向きが変わる
- システムのフォントサイズが最大に設定されている
- ブラウザーのズームが200%以上になっている
- 広告ブロッカーやプライバシー拡張機能がページを書き換える
タイミングに関するエッジケース
- ユーザーの操作が想定より大幅に遅い(スイッチユーザー、認知処理の遅延)
- ユーザーの操作が想定より大幅に速い(スクリーンリーダーの熟練ユーザー)
- ユーザーが作業の途中で数時間、または数日間中断する必要がある
- ユーザーが完了する前に時間制限付きのセッションが終了する
- ユーザーが読んでいる間にコンテンツが更新される
エッジケースを見つける方法
「もしも」の演習
フローの各ステップについて、次のように問いかけます。
- ユーザーがこれを見られないとしたら?
- ユーザーがこれをクリックできないとしたら?
- ユーザーがこれを理解できないとしたら?
- ユーザーの所要時間が想定の10倍だとしたら?
- ユーザーがその場を離れ、明日戻ってくるとしたら?
- このフィールドに予想外のコンテンツが入っているとしたら?
逆転テスト
想定どおりに進むシナリオを取り上げ、それぞれの前提を逆にします。
- 「ユーザーはデスクトップを使っている」→モバイル、タブレット、またはスクリーンリーダー
- 「ユーザーのインターネットは高速」→低速、不安定、またはオフライン
- 「ユーザーは英語を流暢に読める」→識字能力が低い、または第二言語
- 「ユーザーは色の変化を見られる」→色覚異常、または視覚障害
- 「ユーザーは一度に作業を完了する」→中断され、後で再開する
「それはエッジケースです」への対応
誰かがこう言ったら、次のように尋ねます。
- 影響を受けるユーザーは何人ですか?(多くの場合、想定より多いです)
- 影響はどれほど深刻ですか?(操作できなくなるユーザーのほうが、多少不便になるユーザーより深刻です)
- 一部のユーザーにとって恒常的な状況ですか?(そうであれば、それは日常的な体験であり、エッジケースではありません)
- これを修正すると、ほかのユーザーの体験も向上しますか?(ほとんどの場合、向上します)
評価の質問
- チームは想定どおりに進むシナリオ以外のエッジケースも洗い出しましたか?
- 入力、出力、コンテンツ、利用状況、タイミングに関するエッジケースを検討しましたか?
- 障害のあるユーザーにとって日常的な現実であるにもかかわらず、片付けられている「エッジケース」はありますか?
- テスト計画には、支援技術を使うユーザーのシナリオが含まれていますか?
コメント
Markdown 対応