feedback-and-status

フィードバックとステータスの設計

画面を見られるか、音声を聞けるか、振動を感じられるかにかかわらず、すべてのユーザーに伝わるフィードバックを設計します。単一の感覚だけを伝達手段にしてはいけません。

基本原則

ステータスを単一の感覚だけで伝えてはいけません。ユーザーが画面を見られなかったらどうなるでしょうか。音声を聞けなかったら？振動を感じられなかったら？

マルチチャネルのルール

すべてのフィードバックは、少なくとも2つのチャネルで機能する必要があります。

フィードバックの種類	視覚	テキスト	音声	触覚
成功	緑色のチェックマーク	「正常に保存しました」	確認音	短い振動
エラー	赤色の強調表示	具体的なエラーメッセージ	警告音	2回の振動
読み込み中	スピナー／バー	「読み込み中…」	なし（無音）	なし
警告	黄色のバナー	警告テキスト	任意の音	任意の振動

スクリーンリーダーは重要な第3のチャネルです。すべての視覚的なフィードバックを支援技術に読み上げさせる必要があります。

デザインパターン

色だけに頼らない

• 色覚異常の男性の8％には、赤と緑の違いが見えません
• 色には必ず、アイコン、テキストラベル、パターン、または位置を組み合わせます
• エラー状態：赤色＋エラーアイコン＋テキストによる説明
• 成功状態：緑色＋チェックアイコン＋テキストによる確認
• テスト：グレースケールでも同じ情報が伝わりますか？

即時のフィードバック

• ボタンを押したとき：100ms以内に視覚的な変化を表示する（押下状態）
• フォーム送信時：1秒以内に読み込みインジケーターを表示する
• 完了時：完了から2秒以内に成功メッセージを表示する
• エラー時：上部のバナーだけではなく、該当するフィールドを強調表示する

一時的なフィードバックと継続的なフィードバック

• 一時的（トースト／スナックバー）：重要度の低い確認にのみ使用します。少なくとも5秒間表示します。見逃したメッセージを確認する方法も用意します。
• 継続的（インライン）：エラー、警告、その他ユーザーの対応が必要なものに使用します。エラーメッセージを自動的に非表示にしてはいけません。
• スクリーンリーダーのユーザーは一時的なメッセージを見逃します。緊急性のない更新には aria-live="polite" を、重要な警告には aria-live="assertive" を使用します。

視覚に頼らないステータスの伝達

• すべてのステータス変更をスクリーンリーダーに読み上げさせる必要があります
• 動的なコンテンツの更新には aria-live 領域を使用します
• ステータスの伝達を視覚的な位置だけに頼ってはいけません （たとえば、カンバンボードで移動した項目は、テキストでも通知する必要があります）
• エラーメッセージは、プログラムで該当するフィールドに関連付ける必要があります（aria-describedby）

評価の質問

1. ステータスの指標として色だけを使っている箇所はありますか？
2. スクリーンリーダーのユーザーは、すべてのステータス変更を認識できますか？
3. エラーメッセージは解決するまで表示され続けますか？
4. 一時的なメッセージは、読めるだけの時間表示されますか？
5. ユーザーのすべての操作に、認識できるフィードバックがありますか？