問い合わせフォームを組む

パターン ／ パターン集トップ

フォームは入力・検証・確認・完了の4画面で1セットです。入力欄の見た目より、迷いと不安を減らす順序が仕事の大半を占めます。図を大きく見る

画面の並びと使うパターン#

塗りのボタンは1画面に1つ#

フォームのパターンは、1枚だけ貼っても成立するように、それぞれが自分の送信ボタンを持っています。入力画面は、そのうちの1つだけを残す画面です。基本形・章分け・エラー表示・サマリーを順に足すと、同じ強さのボタンが4つ縦に並びます。読み手はどれが本当の送信なのか決められません。

残す1つは、確認画面を挟むかどうかで決まります。

• 確認画面を挟むなら、確認画面 の1画面目が持つ「確認へ」を残す
• 1画面で送り切るなら、ボタン行 の塗りを残し、文言を「送信する」に書き換える

ほかのパターンから付いてきた button--primary は、貼ったその場で消してください。各パターンのHTMLには、消す目印としてコメントを入れてあります。

「入力内容を消す」のような取り消しは置きません。押し間違いで全部消える操作に、得るものがないためです（ボタンとリンク）。

見出しは骨格が持つ#

ボタンと同じことが h1 にも起きます。入力画面の h1 は、骨格が1つだけ持ちます。骨格は 基本形 と 章分け のどちらか一方です。両方を貼ると h1 が2つ並びます。

あとから足すエラー表示・サマリー・1行グループ・同意・ボタン行は、見出しを持ちません。入力画面に足す部品なので、上に立つ見出しは骨格のものを使います。

画面が入れ替わる確認と完了は別です。確認画面は 確認画面 の2画面目が「この内容で送ります」を、完了画面は 送信完了画面 が「お問い合わせを受け付けました」を、それぞれ自分の h1 として持ちます。3画面とも、見出しを読めばいまどの画面にいるかが分かります。

名前は1系統でそろえる#

4枚を順に足しても命名が割れないように、欄まわりの名前は全パターンで同じです。自分の項目を足すときも、この5つの外に新しい名前を作らないでください。

横に並べる欄は .field に .field--inline を、不備のある欄は .field--error を重ねます。派生を足すだけなので、章分けでも1行グループでも欄の姿は変わりません。同意チェックも1つの項目なので、.field と .field__error に乗せています。

.field__error は、横に並べた欄にも1つずつ置きます。1行グループ の姓・名・郵便番号・住所には、空の置き場と aria-describedby が入っています。サマリーの markFields() は .field を順に見て、その中の .field__error へ文言を書きます。置き場のない欄は、一覧に名前が出るだけで、欄のそばには何も出ません。

凡例は項目が3つのフォームでも置きます。印だけを出して凡例を省くと、「必須」が何を指すのかを読み手が推測することになります。凡例の言葉は印と同じ「必須」にそろえてください。

必須が多くて任意が少ないなら、印を付けるほうを入れ替えます。そのときは凡例も「「任意」の付いた項目は空のままで送れます。」に書き換えます（入力）。

検証は貼るだけでは動かない#

エラーサマリー には、一覧を組み立てる showErrors() と、欄の側へ同じ文言を出す markFields() に加えて、それを呼ぶ submit ハンドラまで入れてあります。貼って「送信する」を押せば、その場で一覧が出て、焦点がそこへ移ります。

自分で書き換えるのは validate() の中だけです。

• 項目を足したら、その欄をどう見るかを validate() に足します
• 「7桁の数字」「今日より後の日付」のような案件固有の規則も、書き足す先はここです
• ラベルから定型で作れない文言は、欄に data-error="…" を書いて上書きします。同意チェックがこの形です
• novalidate は外しません。外すとブラウザの吹き出しが先に出て、自作の一覧まで届きません

画面に出す検証は、サーバー側の検証の代わりにはなりません。送られてきた値は、受け取る側でもう一度見ます（フォームの検証）。

組む順序#

1. 出発点のCSS を貼る
2. フォームの基本形 に自分の項目を入れる。項目は減らせるだけ減らす（入力）
3. 7項目を超えたら 章分け へ、姓名などは 1行グループ へ。どちらも欄の名前は .field のまま
4. エラー表示 と サマリー を足し、validate() に自分の項目の規則を書く。文言は「次に何をすればよいか」で書く（フォームの検証）
5. 同意 → ボタン行 → 確認 → 完了 の順に足す
6. 入力画面に残った塗りのボタンを数え、1つになるまで消す

確認画面は入力画面の使い回しにしない#

確認画面 は、入力画面にステップ表示を足したものではありません。送るものを読ませる画面なので、操作できる入力欄を置きません。値は文章として見せ、<input type="hidden"> で持ち回します。

• 入力欄を残したまま disabled にすると、その値は送信されません
• ステップ表示は、いま出している画面の項目にだけ aria-current="step" を付けます。見た目だけを切り替えると、画面と読み上げがずれます
• ステップ表示は完了画面まで出します。最後の1枚で目印が消えると、読み手は自分がどこにいるのか分からないまま終わります
• 戻り道は「入力へ戻る」で、押しても入力した値が消えないようにします

ダミー文は1つの店で書いてある#

フォームのダミー文も、LPや記事と同じ「つばめ珈琲焙煎所」でそろえてあります。章分けの選択肢は定期便・豆選び・見学の3つ、確認画面に出る内容は「深煎りの豆を200g、月に2袋で申し込みたいです。」です。言葉を差し替えるときは、選択肢・確認画面の値・完了画面の案内を通しで直してください。選択肢だけ自分の業種にして、確認画面に珈琲の文が残ると、そこで話者が入れ替わります。

確認する#

• 塗りのボタン（--primary）が1画面に1つ。入力は「確認へ」、確認は「送信する」
• 「送信する」を押すと、実際にエラーの一覧が出て焦点がそこへ移る（箱が空のまま残っていない）
• 一覧の各項目の # リンクが、その欄の id として実在する
• 同じ id が1画面に2つない
• 不備を直して送り直すと、欄のエラー文と一覧の両方が消える
• 横に並べた欄も含めて、すべての .field に .field__error の置き場がある
• Tab だけで最後まで入力・送信できる
• エラーが色だけでなく文言とアイコンでも分かる
• 必須の印が凡例つきで統一されている（凡例は項目が3つのフォームにも置く）
• 欄の名前が .field と .req の1系統になっている
• h1 が1画面に1つ（入力は骨格、確認は確認画面、完了は完了画面が持つ）
• 確認画面に操作できる入力欄がなく、aria-current="step" が「確認」に移っている
• 完了画面にも入力・確認・完了の3段が出ていて、aria-current="step" が「完了」にある
• 完了画面に「受け付けた」と「この後どうなるか」の両方がある
• 4画面を通して、選択肢・値・案内の言葉が1つの案件でそろっている

関連#

• LPを組む
• 記事一覧と記事を組む
• フォームの検証