支払いフォームは、購入手続きの中で最も重要な部分です。支払いフォームのデザインが不適切であることは、ショッピング カートの放棄の一般的な原因です。
パソコンでもモバイルでも、ユーザーが支払い情報をできるだけ簡単に入力できるフォームを作成します。フォームが、自動入力、検証、データ入力の制約に関する組み込みのブラウザ機能を最大限に活用できるようにします。
導入方法
以下に、支払いフォームを適切に作成するための最も重要なガイドラインを示します。
意味のある有効な HTML を使用する
フォーム作成用に構築された要素と属性を最大限に活用します。
<form>、<input>、<label>、<button>type、autocomplete、inputmode
これらにより、組み込みのブラウザ機能が有効になり、ユーザー補助が向上し、マークアップに意味が追加されます。
<label> 要素を使用して、データ入力用のフォーム フィールドにラベルを付ける
<input>、<select>、<textarea> にラベルを付けるには、<label> を使用します。ラベルの for 属性に、入力の id と同じ値を指定して、ラベルを入力に関連付けます。
HTML 属性を最大限に活用する
適切な <input> 要素の <type> 属性を使用して、モバイルで適切なキーボードを提供し、ブラウザによる基本的な組み込み検証を有効にすることで、ユーザーがデータを入力しやすくします。
メールアドレスには常に type="email" を、電話番号には常に type="tel" を使用してください。
<!-- type="email"/"tel" gives mobile users the right keyboard and enables built-in validation -->
<input type="email" id="email" name="email" autocomplete="email" required>
<input type="tel" id="phone" name="phone" autocomplete="tel">
すべての <input>、<select>、<textarea> 要素は、ユーザー補助を改善し、ユーザーがデータを再入力しなくて済むように、適切な autocomplete 属性を持つべきです。
ボタンを役立つものにする
ボタンには <button> を使用します。<input type="submit"> を使用することもできますが、div やその他のランダムな要素をボタンとして使用しないでください。ボタン要素は、アクセス可能な動作、組み込みのフォーム送信機能を提供し、簡単にスタイルを設定できます。
各フォームの送信ボタンに、そのボタンの動作を示す値を指定します。購入手続きの各ステップで、進捗状況を示し、次のステップを明確にする、わかりやすい行動を促すフレーズを使用します。たとえば、お届け先住所フォームの送信ボタンには、[続行] や [保存] ではなく、[お支払いに進む] というラベルを付けます。
可能な限り、1 つの名前入力を使用する
名前、姓、敬称、その他の名前の部分を個別に保存する正当な理由がない限り、ユーザーが 1 つの入力で名前を入力できるようにします。名前の入力欄を 1 つにすることで、フォームがシンプルになり、切り取りと貼り付けが可能になり、自動入力が簡単になります。
国際的な名前を許可します。検証では、ラテン文字のみに一致する正規表現を使用しないでください。[Latin-only] を選択すると、ラテン文字以外の文字を含む名前や住所のユーザーが除外されます。代わりに Unicode 文字の一致を許可し、バックエンドが入力と出力の両方で Unicode を安全にサポートするようにします。正規表現の Unicode は、最新のブラウザで十分にサポートされています。
さまざまな住所形式に対応する
支払いフォームに住所のフォーム フィールドを追加する際は、住所の形式が多様であることに注意してください。同じ国でも形式が異なる場合があります。「通常の」アドレスについて、憶測をしないでください。
データ要件の範囲内で可能であれば、住所に単一の <textarea> 要素を使用することを検討してください。これは、さまざまな国内および海外の住所形式に対応できる最も柔軟なオプションです。
請求先住所の予測入力を使用する
デフォルトでは、請求先住所はお届け先住所と同じに設定されます。請求先住所をフォームに表示するのではなく、請求先住所を編集するためのリンクを提供（または概要と詳細の要素を使用）することで、視覚的な煩雑さを軽減します。
配送先住所と同様に、請求先住所にも適切な予測入力値を使用することで、ユーザーがデータを複数回入力する必要がなくなります。異なるセクションで同じ名前の入力に異なる値がある場合は、予測入力属性に接頭辞を追加します。次に例を示します。
<!-- Prefix with shipping or billing; note that the valid token is address-line1 (no hyphen before the digit) -->
<input autocomplete="shipping address-line1" ...>
...
<input autocomplete="billing address-line1" ...>
購入手続きの進行状況を表示する
購入手続きの各ステップで、ページのタイトルとボタンのテキストをわかりやすくして、ユーザーが今すべきことと、次のステップが何であるかを明確にします。
フォーム入力で enterkeyhint 属性を使用して、モバイル キーボードの Enter キーのラベルを設定します。たとえば、複数ページのフォームでは enterkeyhint="previous" と enterkeyhint="next" を使用し、フォームの最後の入力には enterkeyhint="done" を、検索入力には enterkeyhint="search" を使用します。
ユーザーが支払いデータを再入力する手間を省く
支払いカードのフォームに適切な autocomplete 値を追加してください。予測入力がないと、ユーザーは支払いカードの詳細を物理的に記録したり、安全でない方法で保存したりする可能性があります。
<!-- cc-number tells autofill this is a card number, not a generic number field -->
<!-- inputmode="numeric" gives a numeric keyboard without the increment/decrement spinner -->
<!-- DO NOT use type="number" — it adds increment/decrement controls and strips leading zeros -->
<input id="cc-number" name="cc-number" type="text" autocomplete="cc-number"
inputmode="numeric" maxlength="19" pattern="[\d ]{13,19}" required>
<!-- cc-name autofills with the name exactly as it appears on the card; Unicode pattern allows international names -->
<input id="cc-name" name="cc-name" type="text" autocomplete="cc-name"
maxlength="50" pattern="[\p{L} \-\.]+" required>
<!-- cc-exp autofills the full expiry date as MM/YY -->
<!-- MANDATORY: Place format hints above the input so autocomplete popovers or virtual keyboards do not obscure them during editing -->
<span id="exp-hint" class="hint">Format: MM/YY</span>
<input id="cc-exp" name="cc-exp" type="text" autocomplete="cc-exp"
aria-describedby="exp-hint" maxlength="5" required>
<!-- cc-csc autofills the security code; DO NOT use type="password" here -->
<input id="cc-csc" name="cc-csc" type="text" autocomplete="cc-csc"
inputmode="numeric" maxlength="4" pattern="[0-9]{3,4}" required>
入力欄の上に形式のヒントを表示する
フィールドに必須の形式がある場合（MM/YY の有効期限など）、入力欄の上の表示要素にヒントを配置し、上記の cc-exp の例のように aria-describedby で 2 つをリンクします。入力欄の下に表示されるヒントは、ユーザーが必要とするタイミングで、モバイル キーボードや自動入力のポップオーバーによって簡単に隠れてしまいます。
placeholder 属性を唯一の形式ヒントとして使用しないでください。また、<label> の代わりに使用しないでください。プレースホルダ テキストは、ユーザーが入力し始めるとすぐに非表示になるため、編集時に確認できません。プレースホルダは、ラベルや永続的なヒントとともに、追加のヒントとして使用できます。
セキュリティ コードをマスクしない
カードのセキュリティ コードには、type="password" ではなく、inputmode="numeric" を指定した type="text" を使用します。ユーザーは、マスクされた 3 桁または 4 桁のコードの入力ミスを確認できないため、入力ミスは支払いが拒否されるまで検出されません。また、コードはユーザーが持っているカードに印刷されているため、マスクしても保護効果はほとんどありません。
支払いカードと電話番号に単一の入力を使用する
支払いカードと電話番号には、1 つの入力を使用します。番号を分割しないでください。これにより、ユーザーはデータを入力しやすくなり、検証が簡単になり、ブラウザで自動入力できるようになります。PIN や銀行コードなどの他の数値データについても同様にすることをおすすめします。
慎重に検証する
データ入力は、リアルタイムとフォーム送信前の両方で検証する必要があります。これを行う方法の 1 つは、支払いカードの入力に pattern 属性を追加することです。ユーザーが無効な値でお支払いフォームを送信しようとすると、ブラウザに警告メッセージが表示され、入力にフォーカスが設定されます。
ただし、パターン正規表現は、14 桁（またはそれ以下）から 20 桁（またはそれ以上）までの支払いカード番号の長さに対応できる柔軟性を備えている必要があります。カード セキュリティ コード（CSC、CVC、CVV などとも呼ばれます）は 3 桁または 4 桁の数字です。
ユーザーが新しい支払いカード番号を入力する際に、スペースを含めることができるようにします。これは、物理的なカードに番号が表示される方法です。この方法であれば、ユーザーに「入力に誤りがある」と伝える必要がないため、ユーザーにとって親切であり、コンバージョン フローが中断される可能性も低くなります。また、処理前に数字のスペースを削除するのも簡単です。
ユーザーがデータ フィールドを誤って見落とさないようにする
必須フィールドに required 属性を追加します。最新のブラウザでは、不足しているデータに対して自動的にプロンプトが表示され、フォーカスが設定されます。
代替戦略
自動入力はプログレッシブ エンハンスメントです。自動入力に対応していないブラウザでは、ユーザーは支払い情報を手動で入力する必要があります。セマンティック HTML の制約（type、inputmode、pattern、required など）は、ユーザー入力を検証し、適切な仮想キーボードを提供するために、引き続き適切に機能します。