問い合わせフォームで、送信ボタンを押した後に画面上部へまとめてエラーが出るだけだと、ユーザーはどこを直せばよいか分かりにくくなります。
特にスマホでは、入力欄とエラーメッセージの位置が離れるほど、修正の負担が増えます。
そこで役立つのが、入力中や入力後にエラーや補助メッセージを出す即時バリデーションです。
ただし、すべてをリアルタイムに確認すると、入力途中で何度も注意されるフォームになってしまいます。大切なのは、項目ごとに確認タイミングと文言を分けることです。
この記事では、入力欄の状態が変わった時に、どの判定結果を表示するかを扱います。送信後の通信失敗や受付処理、エラー文言全体の設計は、問い合わせフォームのエラーメッセージ設計を参照してください。
フォームの全項目を入力中に確認する必要はありません。
即時バリデーションが向いているのは、形式が明確で、入力ミスに気づきやすい項目です。
入力中、入力欄を離れた時、送信時で表示内容を分けます。
原因だけでなく、修正例や入力形式も短く添えます。
基本は該当項目のすぐ下。送信前の要約は補助として使います。
ブラウザ側だけで終わらせず、サーバー側チェックも残します。
即時バリデーションを入れるなら、まずは形式が決まっている項目から始めます。
メールアドレス、電話番号、郵便番号などは、入力後すぐに確認しても違和感が出にくい項目です。
| 項目 | 確認内容 | 表示タイミング |
|---|---|---|
| メール | 標準のメール形式と、サービスで追加する受付条件。必須かどうかは別に決める。 | 入力欄を離れた時。送信時にも再確認。 |
| 電話番号 | 国内・海外の対象範囲、許可する表記、桁数。ハイフンや全角数字を変換する場合は、変換後の値で確認する。 | 入力後。入力中は例だけ表示。 |
| 郵便番号 | 日本国内向けなら数字7桁を基本に形式確認。住所候補の検索結果とは区別する。 | 7桁の入力が確定した時、または入力欄を離れた時。 |
| 自由記述 | 文字数上限、必須入力など。文字数の数え方は画面とサーバーで一致させる。 | 入力中は文字数表示、送信時に最終確認。 |
標準の input type="email" は、ドットを含まないドメインのアドレスも形式上は受け付けます。そのため「ドメイン部分にドットがない」という理由だけで、標準仕様のエラー例にはできません。独自の受付条件がある場合は、条件を明示してサーバーでも同じ確認を行います。形式の確認だけでは、実在するアドレスやメールの到達を保証できません。MDNのメール入力の仕様説明も確認してください。
任意項目の空欄はエラーにせず、値がある時だけ形式を確認します。条件付き必須項目は、どの選択で必須になるかを明示し、条件が変わったら以前のエラーや成功表示も更新します。
即時バリデーションでよくある失敗は、入力の途中で赤いエラーを出しすぎることです。
メールアドレスを1文字目から入力している最中に「形式が違います」と表示されると、ユーザーは責められているように感じます。
入力中は、エラーではなくヒントを出す方が向いています。次は、電話番号のハイフン有無を許可し、国内住所検索と500文字の上限を設定した場合の文言例です。
| 入力欄の状態 | 表示例 | 更新する条件 |
|---|---|---|
| まだ操作していない | 入力例・必須表示 | 画面を開いただけでは未入力エラーを並べない。送信操作時には必須項目を確認する。 |
| 初回入力・日本語変換中 | 入力方法の補助 | 未完成の文字列でエラーを確定しない。変換確定後に項目ごとのタイミングで確認する。 |
| 確認の結果、条件に合わない | 原因と修正方法 | 現在の値に対する判定結果を表示する。 |
| エラーを修正している | 修正方法・再確認中の表示 | 現在の値を再判定し、条件を満たしたらエラーを消す。古い原因を現在の結果として表示し続けない。 |
| 通信で確認している | 確認中です | 現在の入力値に対応する結果が届くまで、成功・失敗を決めない。 |
| 確認済み | 入力形式に問題ありません | 値や関連する選択項目が変わったら、以前の成功表示を解除して再確認する。 |
日本語入力では、変換途中の文字を確定した入力として扱わない設計が必要です。実装時には compositionstart・compositionend や InputEvent.isComposing で変換状態を扱い、対象のブラウザーとキーボードで確認します。変換中に文字を切り捨てたり、エラー欄へフォーカスを移したりする動作は避けます。変換状態の定義はMDNの isComposing の説明を参照してください。
エラー文言は、短いだけでは足りません。
ユーザーが直せる情報になっている必要があります。
「入力エラーです」「正しく入力してください」だけでは、何を直せばよいか分かりません。
項目名、原因、修正例を短く入れるだけで、入力欄に戻る負担が減ります。
即時バリデーションでは、メッセージの場所も重要です。
基本は、該当項目のすぐ下に表示します。画面上部にまとめて出すエラー一覧は、送信時の補助として扱うのが現実的です。
赤い枠だけで状態を伝えず、原因と直し方を文字でも表示します。実際のフォームでは、入力欄と説明を aria-describedby などで関連付けます。入力中にフォーカスを奪わず、送信後にエラーが残る場合は、要約や最初のエラー項目から修正できるようにします。詳細はW3Cのフォーム通知ガイドを参照してください。
以下の画面は説明用の静的な表示例です。氏名・入力値・件数は架空で、実際に入力や送信はできません。お名前・メールアドレスを必須、電話番号を任意とした例であり、すべてのフォームで同じ必須項目にするものではありません。
スマホでは、フォームが縦に長くなります。
項目下にエラーを出すだけでは、送信ボタンまで進んだ時に、どの項目を直せばよいか分かりにくい場合があります。
そのため、送信ボタン付近には「未入力が2件あります」「メールアドレスの形式をご確認ください」のような短い要約を出すと親切です。
ただし、要約だけに頼らず、各入力欄の下にもメッセージを残します。
実際の要約は該当する入力欄へのリンクにし、修正したら件数も更新します。動的な通知に aria-live="polite" を使う場合も、同じ文言を一文字ごとに再通知しないよう、結果が変わる時に更新します。キーボード操作や画面読み上げで、要約から対象項目へ移動できることを確認します。
@が2つあります。メールアドレスをご確認ください。
1件、確認が必要な項目があります。
該当項目へ戻る成功表示では、何を確認した結果なのかを伝えます。「OK」だけでは、形式の確認が終わったのか、送信や予約まで完了したのかを区別できません。
成功表示は、ユーザーの次の操作を助ける場面で使います。日付・人数・メニューなど、判定の条件となる値が変わった時にも、古い結果を解除して再確認します。
即時バリデーションは、あくまで画面上の補助です。
ブラウザ側で形式を確認していても、送信時にはサーバー側で再確認する必要があります。
項目の形式チェックだけで、すべての安全対策が完了するわけではありません。ファイルの一時保存や閲覧条件は添付ファイルの管理・運用設計、送信後の結果不明や二重送信の扱いはエラーメッセージと受付処理の設計で扱います。
郵便番号から住所候補を探す場合や、予約枠を確認する場合は、入力後にサーバーとの通信が発生します。入力値Aの確認中にユーザーがBへ変更すると、Bの結果より後にAの結果が届く場合があります。遅れて届いたAの結果で、Bの表示を上書きしない設計が必要です。
通信を中止する実装だけに頼らず、結果を表示する時点でも現在の値と照合します。また、画面で一度確認できても、送信時にはサーバーで受付条件を再確認します。ここでの照会失敗と、送信後に受付結果が分からなくなる状態は別に扱います。
即時バリデーションは、JavaScriptでエラーを出すだけの話ではありません。
どの項目を対象にするか、いつ表示するか、どんな文言にするか、送信時にどう再確認するかまで設計します。
メール、電話、郵便番号など、形式が明確な項目から選びます。
例や入力形式を出し、赤いエラーは急いで出しすぎないようにします。
入力欄を離れた時に形式を確認し、必要な場合だけエラーを出します。
未入力や未修正があれば、ボタン付近にも短く表示します。
最終的な受付可否は、サーバー側でも確認します。
公開前には、正常な入力だけでなく、次の操作でも表示が矛盾しないか確認します。
問い合わせフォームの即時バリデーションは、入力ミスを早く見つけてもらうための補助です。
すべての項目を厳しくリアルタイム確認するのではなく、メールアドレス、電話番号、郵便番号など、形式が明確な項目から始めるのが現実的です。
最初の1文字目から赤いエラーを出さず、例や入力形式を補助として表示します。
入力欄を離れた時に、必要な項目だけ形式チェックを行います。
画面上のチェックだけで終わらせず、送信時にも必ず再確認します。
設計時には、項目ごとに「判定条件」「確認するタイミング」「入力中・確認中・結果表示の文言」「通信失敗時の次の操作」を記録します。これを基に、画面とサーバーで条件が一致しているか、値を修正した後に表示が更新されるかを確認します。