フォームの必須・任意

フォームの項目に迷ったら、「未入力だと、誰のどの作業が止まるか」を確かめます。「後で使うかもしれない」だけでは、申込時に答えてもらう理由が決まりません。

この記事は、申込フォームを設計・レビューする人向けの解説です。架空の勉強会を例に、必須・条件付き・任意・聞かないの4つへ整理します。作例のルールは記事側の提案で、申込率などの改善を実測したものではありません。

項目の使い道を決める

GOV.UK Design Systemは、各質問をする理由を把握し、本当に必要な情報だけを尋ねるよう勧めています。Question pages

その考え方を使い、項目ごとに次の3点を書いてみます。

1. 誰が使うか：受付担当、進行役など、実際の担当者。
2. 何に使うか：参加案内の送付、当日の質問選びなど、具体的な作業。
3. 空欄ならどうするか：申込を受け付けられないのか、別の方法で進められるのか。

「運営で使う」だけなら、担当と作業をもう一段具体化します。誰も使い道を説明できなければ、任意欄として残す前に、項目自体を置く必要があるか検討します。

作例：勉強会の申込

この作例では、会場参加とオンライン参加を選べる勉強会を考えます。参加案内はメールで送り、会場参加者には受付用の名札を用意する運用です。

名前は本名を要求せず、名札に載せたい表記でよい、という設定です。会社名は「任意なら残してよい」とはしていません。一方、名札が不要なイベントなら、名前を必須にする理由も見直します。

メール以外の受付を設けるなら、その経路でも参加案内を受け取れるか確認します。表の必須項目を、すべてのイベントにそのまま当てはめるための例ではありません。

条件を切り替えるとき

会場参加を選んだときだけ名前を求めるなら、途中でオンライン参加へ変更した場合も決めます。この作例では次の案にします。

• オンラインへ変えたら、名前は未入力でも進める。
• 会場へ戻したら、再び名前が必要になる。
• オンラインで確定するとき、入力済みの名前は申込データへ保存しない。

隠れた欄が空だから先へ進めない、という状態を作らないようにします。画面の必須表示と、サーバー側の受付条件を揃えることも確認対象です。

入力済みの値を切り替え中に保持するか、消すかは別の判断です。保持するなら画面に残す期間、消すなら再入力が必要になることまで決め、確認画面でも最終的に送る内容を確かめます。

必須・任意を言葉で伝える

W3C WAIのフォーム解説は、必須・任意や入力形式を伝え、項目のラベルにも必要な説明を含める方法を示しています。入力すると消えるプレースホルダーは、ラベルの代わりにはなりません。Form Instructions

GOV.UKでは、多くの場合に任意項目へ「optional」を付け、必須項目にアスタリスクを使わない方針です。これは同デザインシステムの方針で、あらゆるフォームの唯一の表記法ではありません。

この日本語の作例では、必須と任意をそれぞれ文字で示す案にします。

メールアドレス（必須）
参加案内を送ります。

名札に載せる名前（会場参加では必須）
当日呼ばれたい名前を入力してください。

事前に聞きたいこと（任意）
空欄でも申し込めます。

赤色や記号だけに意味を持たせず、入力前にも入力後にも区別できるようにします。任意は「空欄で進める」という意味です。入力された場合の文字数や形式に条件があるなら、その条件とエラー時の直し方は別に示します。

項目の採否を残すメモ

次は、仕様の打ち合わせに持ち込む記入例です。「必須」の一語だけで終わらせず、使う人と空欄時の扱いを残します。

項目：名札に載せる名前
利用者：会場の受付担当
使い道：参加者が指定した表記で名札を印刷する
必要になる条件：会場参加を選んだとき
空欄の扱い：会場参加は入力を求める。オンライン参加は受け付ける
条件変更時：オンラインで確定した場合、名前は保存しない
未決事項：会場→オンライン→会場と戻ったときの入力値の保持
確認担当：受付担当と開発担当

最後に、任意欄を空にした場合、条件を行き来した場合、入力後にエラーになった場合を試します。目で見た表示だけでなく、キーボード操作や読み上げでも項目名・必要条件・説明が分かるか確かめます。

入力を求める項目が決まったら、フォームのエラー表示で修正の案内を、受け入れ条件の書き方で確認する結果を具体化できます。