画面を解読させない
ウェブサイト制作の問い合わせフォームを想像してください。訪問者が依頼内容と連絡先を入力して送信したところ、赤い枠だけが表示されました。電話番号が足りないのか、通信が切れたのか、すでに送られたのか。この不確かさは利用者の不注意ではなく、設計の問題です。画面案には、正しく入力された状態だけでなく、入力途中、複数のエラー、待機中、完了も含めましょう。小さな状態の違いが、全体の使いやすさを左右します。
入力前に必要なことを伝える
各項目にはわかりやすいラベルが必要で、WAIは入力要素とラベルを関連付ける方法を示しています。形式の例はラベルの代わりにはなりません。今回の仮想的な依頼フォームなら、メールだけで連絡できる場合は電話番号を任意にできます。最初の相談に不要なら、会社の住所を習慣的に求める必要もありません。画面を描く前に項目を列挙し、一つずつ必要な理由を説明してみてください。理由が見つからない項目は、見直す候補になります。 W3C WAI: Labeling Controls
何が問題なのかを具体的にする
検出されたエラーは、対象項目を特定して文章で説明する必要があります。色だけでは不十分です。単に入力内容が無効と伝えるのではなく、連絡先が空なら「メールアドレスを入力してください」と案内できます。このフォームでは、連絡先の未入力、説明の不足、サービスの停止を別々の文で表すとよいでしょう。一つの赤い帯にまとめると、入力を直すべきなのか、送信の不具合なのかがわからなくなります。 W3C: Error Identification
修正への道筋を用意する
修正方法がわかっていて安全に案内できるなら、その方法を伝えます。文字数に具体的な制限がある場合は、再試行だけを求めずに制限を説明しましょう。長いフォームでは、問題のある項目へのリンクを持つエラー一覧が、項目付近の説明を補えます。入力済みの文字をメッセージで隠さないことも重要です。キーボードで問題の場所を見つけ、修正し、依頼内容を最初から書き直さずに続けられるか確認します。 W3C: Error Suggestion
入力確認と配信は別のこと
ブラウザー側の入力検証は、サーバー側の検証を置き換えません。また、メールアドレスの形式が正しくても、メッセージが配信された証明にはなりません。結果の文章はシステムの実際の応答に合わせる必要があります。問い合わせの保存と送信失敗は別の状態です。実際にその対応手順がないのに、五分以内の折り返しを約束してはいけません。連続クリック、遅い通信、ページを開き直す場合も、個別の状況として考えましょう。 MDN: Client-side form validation
成功する場合だけを試さない
WAIは、送信の成功と失敗の両方を伝えることを勧めています。公開前には、空のフォーム、一つの誤った連絡先、長い説明、修正、成功、サービス障害を試してください。文字の拡大、スマートフォン、キーボード操作に加え、アクセシビリティには支援技術での確認も必要です。この短い一覧は認証ではありません。説明のない赤い枠で立ち止まらせず、利用者を次の一歩へ案内できるかを確かめるための実践的な手順です。 W3C WAI: User Notifications