入力エラーを利用者が直せる文章にする
入力エラーは、利用者の失敗ではなく、システムが次の行動を伝える場面です。「不正な値です」「エラーが発生しました」だけでは、どこを直せばよいか分かりません。場所、理由、直し方を短い文章で揃えます。
問題がある項目の近くに出す
送信後にページ上部だけへエラーを出すと、入力欄との対応が分かりにくくなります。項目の近くへ説明を置き、複数の問題がある場合は上部にも一覧を出します。一覧から該当項目へ移動できると修正が速くなります。
色だけで状態を伝えず、文章とアイコンなどを組み合わせます。スクリーンリーダーが入力欄と説明を関連付けられる構造にし、エラーが追加されたことも通知します。
起きたことと直し方を書く
良い文章は、問題と次の行動を具体的に示します。
悪い例: 入力エラーです
良い例: パスワードは12文字以上で入力してください
悪い例: 日付が不正です
良い例: 終了日は開始日以降の日付を選んでください
W3CのWCAG解説では、エラーが検出されたときに問題のある項目を特定し、内容を文章で説明する必要があるとされています。入力形式の例だけでなく、利用者がどう直せばよいかまで書きます。
入力した内容を消さない
一つの項目で失敗したときに、ほかの入力まで消えるとやり直しが増えます。パスワードやカード情報など保持すべきでない値を除き、安全に再表示できる内容は残します。
通信失敗と入力内容の問題も分けます。通信失敗なら再試行できること、保存が完了していないこと、後で試せるかを示します。同じ操作を繰り返すと二重登録になる場合は、処理状況を確認できるようにします。
実際の失敗で読み直す
正常な入力だけでなく、空欄、文字数超過、形式違い、期限切れ、通信切断を試します。エラーを読んだ人が説明なしで直せるかを確認し、問い合わせで頻出する言葉を文章へ反映します。
技術的な例外名、内部ID、スタックトレースは利用者向け画面へ出しません。調査に必要な識別子がある場合は、秘密情報を含まない問い合わせ番号として分けます。
エラー文を同じ型で書く
項目ごとの文章は、場所、起きたこと、直し方の順にそろえます。
| 状況 | 避ける文 | 直せる文 |
| --- | --- | --- |
| 必須欄が空 | 必須です | メールアドレスを入力してください |
| 形式が違う | 不正な値です | メールアドレスを name@example.com の形式で入力してください |
| 範囲外 | 入力エラー | 人数は1〜20の範囲で入力してください |
| 重複 | 登録できません | このメールアドレスは登録済みです。ログインするか、別のアドレスを入力してください |
| 通信失敗 | 失敗しました | 送信できませんでした。入力内容は残っています。通信を確認して再度お試しください |
条件を満たす例を示せる場合は、禁止事項の列挙だけでなく正しい形式も示します。パスワードのように入力内容を画面へ再表示しない項目では、どの条件を満たしていないかを必要な範囲で伝えます。
実装と文章を一緒に検証する
クライアント側だけでなくサーバー側でも同じ入力条件を検証します。二つの層で条件や文言が食い違うと、画面上では通ったのに送信後に拒否されます。
エラー一覧を置く場合は、一覧から該当項目へ移動でき、移動後も項目名と説明を読み取れるようにします。エラーが直ったら古い状態を解除します。送信失敗、処理中、完了を支援技術にも伝え、見た目だけが変わる実装にしません。