購入を妨げずに先に買えるようにする
注文の配送にアカウントが不要な場合、ゲスト購入を明確なデフォルトにしてください。Google のフォームに関するガイダンスもこの方法を推奨しています。サインインは再訪客向けの目立つ二次経路として残し、注文確定後に注文履歴など具体的な利点を提示してアカウント作成を案内します。規制製品、会員制、または不正対策ポリシーでログインが必須の場合は、フォーム開始前にその要件を説明してください。
ポリシーが許す場合、新しい購入者はパスワードを作らずに支払いまで進めるべきです。
支払い前の通行料としてではなく、注文後にアカウント作成を促しましょう。
配送が不明瞭にならない範囲で項目数を減らす
履行、支払い、税、または必須の連絡に影響する場合にのみ情報を求めてください。標準的なコントロール、常時表示されるラベル、安定した name と id 値、適切な autocomplete トークンを使用します。請求先が配送先と同じ場合はデフォルトで一致させ、別住所を選ぶのを簡単にしてください。W3C は、同じプロセス内で既に入力された情報は自動入力するか選択可能にするべきだとし、セキュリティや無効データのような限定的な例外を除くとしています。
各入力に運用上の目的を持たせ、目的がなければ削除または延期してください。
消えるヒントテキストを唯一のラベルにせず、入力中も目に見えるラベルを残してください。
エラーを回復の道筋に変える
簡単なローカルの問題は入力中またはフォーカス離脱時に検証し、全てのキーストロークで中断しないでください。簡潔な訂正案内を示し、エラー後は安全な非機密エントリを保持します。送信失敗後はフォームの前にリンク付きのエラーサマリを表示し、各フィールドには対応するメッセージを出してください。W3C は各サマリ項目がコントロールを特定し、問題を説明し、訂正方法を示すことを推奨しています。支払いデータは URL、ログ、エラー文面から除外してください。
「無効な入力」だけでなく、何が問題でどう直すかを示してください。
フォーカスを回復ポイントに移し、動的フィードバックを支援技術にアナウンスしてください。
支払い選択を提示するときは支払いページのコントロールを弱めない
ビジネスが承認、返金、突合、サポートできる支払い方法を表示してください。各方法を平易に名付け、コミット前に重要な条件を明示します。成功購入、支払い拒否、返金やキャンセル経路をテストしてください。PCI SSC の e-skimming に関するガイダンスは承認済みの支払いページ用スクリプト、整合性チェック、改ざん検出に焦点を当てています。タグ、ウィジェット、実験、iframe、カードコントロールを追加する前にプロバイダと適切なセキュリティまたは PCI レビュー担当者を巻き込んでください。本記事はコンプライアンス判断ではありません。
支払いに影響する可能性のあるページ用資産と所有者の承認済みインベントリを維持してください。
見た目は小さな変更でもブラウザで実行される支払いページコードを変える可能性があります。
モバイルとアクセシブルな経路を標準経路にする
狭いビューポートで画面キーボードを開いた状態でテストしてください。適切な input type を使い、仮想キーボードの候補を示すために有用な場合は inputmode を使ってください（MDN は inputmode 自体は入力を検証しないと注記しています）。カード番号では、Google は number コントロールよりも numeric inputmode を持つテキスト入力を推奨します。関連ラベルを視覚的に示し、論理的なキーボードフォーカスを確保し、エラーや選択には色以外のテキスト表現も提供してください。自動スキャンだけではすべての支援技術でチェックアウトが動作することを立証できません。
Tab、Shift+Tab、Enter、Space、Escape を使ってフローを完了できること。
保存されたブラウザの住所やカード情報、別の請求先住所を含めてテストしてください。
費用、配送、コミットメントを常に見えるようにする
アイテム、数量コントロール、割引、配送の選択、これまでの請求額、合計を支払い時に表示してください。配送、税、定期請求が後の情報に依存する場合は推定であることを明示し、確定したらサマリを即座に更新します。注文アクションの文言は金銭的コミットメントに一致させ（例：'支払いと注文確定'）、購入者がアイテム、住所、配送選択を変更できるようにしてチェックアウトを放棄させないでください。
サマリは読みやすく、各支払いステップで更新可能にしてください。
配送、税、割引、定期請求がいつ確定するかを明示してください。
実験は制御された信頼性改善として行う
アカウント作成を注文後に移すなど、書面化した仮説に対して意味のある1点だけを変更してください。対象、完了指標、ガードレールをリリース前に定義します。ガードレールには支払いエラー、送信失敗、サポートへの問い合わせ、返金、アクセシビリティの回帰、パフォーマンス問題などを含めてください。購入経路と依存関係のテストに SIU を使い、ロールバックを文書化し、ガードレールが破られたら既知の正常バージョンに戻します。コンバージョン結果はセキュリティ、アクセシビリティ、法令順守、普遍的適合性を証明するものではありません。
まず現状のステップ完了率、エラーカテゴリ、技術的挙動を記録してください。
どの失敗パターンでリリースを一時停止または逆転させるかを決めておきます。