Webフォームで入力エラーが起きたとき、利用者が必要とするのは「入力内容に誤りがあります」という通知だけではありません。どの項目に問題があり、なぜ受け付けられず、どう直せばよいのかまで分かる案内が必要です。
エラーに対する提案とは、入力の誤りを示すだけでなく、利用者が次に取るべき行動を具体的に伝えることです。視覚や認知に障害のある利用者を含め、誰もが迷わず修正できるフォームを作るための基本になります。フォーム全体の設計は、関連記事の入力支援とエラー設計の基本でも解説しています。
エラーに対する提案で伝える3つの情報
分かりやすいエラー案内は、場所、原因、修正方法の3つを順に伝えます。ウェブコンテンツアクセシビリティガイドライン（WCAG）の考え方を知りたい場合は、WCAG 2.2の基礎解説も参考になります。
- エラーの場所：どの入力項目を修正するのかを、項目名とともに示します。
- エラーの原因：未入力、桁数、形式など、受け付けられなかった理由を具体的に示します。
- 修正方法：正しい桁数や入力例を示し、次に何をすればよいかを伝えます。
たとえば「入力内容にエラーがあります」だけでは、利用者はフォームを見直して原因を探さなければなりません。「郵便番号は数字7桁で入力してください（例：1234567）」なら、対象、原因、修正後の形を一度に確認できます。
伝わるエラーメッセージの書き方
エラーメッセージは短くするだけでは足りません。利用者がメッセージを読んだ直後に修正できる具体性が必要です。
| 状況 | 分かりにくい表示 | 修正につながる表示 |
|---|---|---|
| 郵便番号の桁数 | 入力内容が正しくありません | 郵便番号は数字7桁で入力してください（例：1234567） |
| 日付の形式 | 日付エラー | 日付はYYYY/MM/DD形式で入力してください |
| パスワードの条件 | パスワードが無効です | パスワードは8文字以上で、大文字と小文字を含めてください |
責めるような表現や、原因を示さない専門用語は避けます。利用者の操作を評価するのではなく、受け付けられる入力条件を説明すると、修正方法が明確になります。
エラー表示を実装する4つのポイント
1．入力欄とエラーメッセージを結び付ける
画面上で近くに置くだけでなく、コード上でも入力欄と説明を対応させます。次の例は、郵便番号の入力エラーが発生した状態を表しています。
<label for="postal-code">郵便番号</label>
<input
type="text"
id="postal-code"
name="postal-code"
aria-invalid="true"
aria-describedby="postal-code-error">
<p id="postal-code-error" class="error" role="alert">
郵便番号は数字7桁で入力してください（例：1234567）。
</p>labelは入力欄の名前を示し、aria-describedbyは入力欄とエラーメッセージを対応させます。aria-invalid="true"は、その入力値がエラー状態にあることを示します。
2．色だけに頼らず、言葉でも状態を示す
赤い枠や警告アイコンは、エラー箇所を見つける助けになります。ただし、色の違いが分かりにくい利用者や、画面を見ずに操作する利用者には、色だけでは内容が伝わりません。「エラー：郵便番号は数字7桁で入力してください」のように、文字でも状態と修正方法を示します。
3．エラーの発生を読み上げで伝える
送信後にエラーメッセージを追加する場合は、スクリーンリーダーでも変化を把握できるようにします。短く、すぐに対応が必要なエラーには、前の例のようなrole="alert"を利用できます。複数の通知をまとめて穏やかに伝えたい場合は、通知領域にaria-live="polite"を指定する方法もあります。
<p id="form-status" aria-live="polite">
入力内容を確認してください。
</p>「入力内容を確認してください」という全体通知だけで終わらせず、各入力欄にも具体的なエラーメッセージを表示します。
4．入力例を操作中も確認できる場所に置く
電話番号や日付の形式は、エラーが起きる前に例を示すと理解しやすくなります。入力例をプレースホルダーだけに入れるのではなく、入力欄の近くに見える説明として置けば、入力中も確認できます。
<label for="phone">電話番号</label>
<p id="phone-hint">入力例：090-1234-5678</p>
<input
type="text"
id="phone"
name="phone"
aria-describedby="phone-hint">修正しやすいフォームの流れ
エラー案内は、個々の文言だけでなく、利用者が修正を終えるまでの流れで確認します。
- 送信後、エラーがあることを利用者に知らせます。
- エラーのある入力欄を、項目名と文字による説明で特定できるようにします。
- 各メッセージで原因と修正方法を示します。
- キーボードだけでも対象の入力欄へ移動し、値を直せるようにします。
- 修正後に再送信でき、同じエラーが残っているか確認できるようにします。
この流れが途中で切れると、メッセージ自体が分かりやすくても修正にたどり着けません。特に長いフォームでは、エラーを知らせたあとに、対象の入力欄を見つけられるかまで確かめます。
エラー提案をテストする方法
スクリーンリーダーで確認する
- 送信後にエラーの発生が読み上げられるか
- 入力欄の名前、エラーの内容、修正方法を確認できるか
- 複数のエラーがある場合も、どのメッセージがどの入力欄に対応するか分かるか
キーボードだけで確認する
- Tabキーなどでエラーのある入力欄へ移動できるか
- 現在のフォーカス位置を見失わないか
- 修正から再送信まで、マウスを使わずに完了できるか
フォーカスの見え方や移動順序は、キーボード操作とフォーカス表示の確認方法で詳しく整理しています。
画面表示と文章を確認する
- 色を見分けなくてもエラー箇所が分かるか
- エラー表示と背景の区別がつき、文字を読み取れるか
- メッセージが「どこが」「なぜ」「どう直すか」に答えているか
- 入力例と実際に受け付ける形式が一致しているか
実装前後のチェックリスト
- 入力欄には、内容が分かるラベルがある
- エラー箇所を色だけで示していない
- 原因と修正方法を具体的な文章で伝えている
- 入力例を入力中も確認できる
- 入力欄とエラーメッセージが対応している
- スクリーンリーダーでエラーの発生と内容を確認できる
- キーボードだけで修正と再送信を完了できる
迷わず修正できるエラー案内を目指す
フォームのエラー案内は、誤りを知らせるためだけの表示ではありません。場所、原因、修正方法を一続きで伝え、利用者が自力で入力を完了できるようにする支援です。まずは既存フォームの曖昧なメッセージを一つ選び、「どこが」「なぜ」「どう直すか」が伝わる文章に直すところから始められます。
当社では、ウェブアクセシビリティを導入しやすくするUUU ウェブアクセシビリティウィジェットツールを提供しています。アクセシビリティ向上に関心のある方は、サービスの詳細をご覧ください。