問い合わせformのerrorは色だけで知らせず項目と直し方を本文で示す

問い合わせformで入力errorを見つけたら、赤い枠や赤い文字だけを出して終わりにしません。送信できなかったこと、直す必要がある項目、何をどう直すかをtextで示します。入力した人がすぐに分かることと、受ける側が正しい内容を受け取れることは同じ問題です。error表示を飾りとして扱わず、送信までの案内として作ります。

利用者は、送信buttonを押して画面が変わったとき、必ずしもerrorの場所を見つけられるとは限りません。画面の下にある入力欄だけが赤くなっても、何が間違っているか、必須なのか、書式が違うのか、どのように直せばよいかが分からなければ、問い合わせを途中でやめることがあります。formを公開する前に、わざと入力を誤り、利用者が一度で直せるかを確認します。

WCAG 2.0のSuccess Criterion 3.3.1は、input errorを自動的に検出した場合、errorの項目を特定し、errorをtextで説明することを求めています。W3Cのfailure exampleも、required fieldやerror fieldを色の違いだけで示すと、色を区別しにくい利用者がerrorを見つけられない場合があると説明しています。色は補助として使えますが、意味を伝える本文を置き換えません。

error表示は三つの答えを返す

error messageは、警告らしく見せる文章ではありません。利用者の次の操作を決める文章です。少なくとも「送信できたか」「どの項目か」「どう直すか」の三つへ答えます。この順にすると、長い説明を足さなくても、必要な内容を落としにくくなります。

説明用の仮例として、氏名、email address、問い合わせ内容を受けるformを考えます。氏名が空欄なら「氏名を入力してください」と表示します。email addressに@がないなら「メールaddressはname@example.jpの形式で入力してください」と示します。問い合わせ内容を選んでいないなら、選択欄の名前を含めます。「入力が正しくありません」だけでは、利用者は三つのうちどれを直すのか分かりません。

項目のlabelとerror messageで、違う呼び名を使わないことも大切です。画面のlabelが「お電話番号」なのに、errorで「連絡先を入力してください」と書くと、email addressを指すのか電話番号を指すのか迷います。formの項目名、error summary、個別error、確認画面で同じ言葉を使います。担当者が受け取る通知mailの項目名もそろえると、利用者の画面と受信内容を照合しやすくなります。

色は補助にしてtextと位置で伝える

errorがあるinputへ赤いborderを付けること自体は問題ではありません。色を見てすぐ気付く利用者もいます。問題は、赤いborderだけで、errorの項目や直し方を伝えようとすることです。色を見分けにくい画面、明るい場所で見るmobile、画面を拡大した状態では、色だけの違いを見落とすことがあります。

個別の入力欄には、labelの近くへ短いerror messageを置きます。送信後にpageの上部へerror summaryを出すなら、「入力内容を確認してください」だけで終えず、どの項目がerrorかを列挙し、各項目へ移動できるようにします。summary、input、個別messageの位置関係が決まっていれば、長いformでも修正する場所を追えます。

required fieldの表示も同じです。赤い*だけを置くと、*が必須を示すと知らない利用者や、色を見分けにくい利用者には意味が伝わりません。「必須」とtextで書くか、formの冒頭で記号の意味をtextで説明します。optional fieldが少ないformなら、必須を並べるより「任意」の項目だけを明記する方が読みやすい場合もあります。どちらを選ぶかより、利用者が送信前に必要な入力を判断できることを優先します。

入力欄をredにしたことは、serverが正しい入力を検査したことの証明にもなりません。browserのJavaScriptでerrorを表示しても、送信経路やbrowserの条件によっては同じ検査が動かないことがあります。画面上の案内とserver側の検査を分け、serverが受け取る前にも必要な項目、形式、許可する値を確認します。

入力内容を消さずに修正できるようにする

formのerrorで利用者を困らせる原因は、messageの曖昧さだけではありません。氏名、会社名、問い合わせ内容を入力したあと、email addressの一文字を間違えただけで全項目が空欄へ戻れば、利用者はもう一度書く必要があります。errorを返すときは、問題のない入力内容を残し、直す場所へ戻れるようにします。

ただし、すべてのinputを再表示すればよいわけではありません。password、card番号、本人確認に使う秘密の情報などは、画面へ再表示しない方がよい場合があります。問い合わせformで何を残すかは、入力の手間と情報の性質を分けて決めます。氏名や問い合わせ本文を残すことと、秘密の情報を保存または表示することを同じ方針にしません。

server側でerrorを検出してformを再表示する場合は、入力済みの値、error summary、個別error、formのaction、tokenやsessionの扱いを一組でtestします。JavaScriptで送信前に検査する場合も、JavaScriptを使わない状態やnetwork errorが起きた状態で、利用者が何を見るかを確かめます。完了画面が出ない、入力内容が消える、errorがformの外に出るといった状態では、利用者は送信できたか判断できません。

問い合わせを受ける側の確認とつなげる

formのerror表示を直す目的は、見た目を整えることではありません。利用者が必要な入力を終え、事業側が内容を受け取って対応できる状態を作ることです。必須項目を増やしすぎれば、errorを減らすどころか入力をやめる理由が増えます。問い合わせの初回対応に本当に必要な情報だけを必須にします。

たとえば、見積りに必要な条件を最初から全て聞きたい場合でも、問合せの入口で住所、予算、詳細な仕様、希望日時を全て必須にする必要があるとは限りません。まず連絡先と相談内容を受け、足りない情報は返信で確認できる場合があります。反対に、受付できない地域や必須の予約日時があるなら、その条件を送信前に明記します。requiredを増やす判断と、errorを分かりやすくする判断は別です。

公開前のtestでは、正常送信だけを試しません。必須項目を空欄にする、email addressの形式を変える、選択項目を未選択にする、長い本文を入れるなど、想定される入力errorを一つずつ試します。PCとmobileで、summary、個別message、入力済みの内容、送信button、問い合わせ先が読めるかを確認します。最後に正しい入力で送信し、完了画面、事業側への通知、返信先がそろうかを確認します。

最初の一手は、現在の問い合わせformで必須項目を一つ空欄にして送信し、送信が完了していないこと、項目名、直し方がtextで分かるかを読むことです。赤い表示があるかではなく、初めて見る人が迷わず直せるかで判断します。