必要最低限を尋ね、要求の理由を説明する
まずユーザーの即時タスクを確認し、それを完了するために必要なデータだけを要求する。ニュースレターにはメールアドレス、配送には住所が必要だが、どちらも自動的に生年月日、役職、またはまとめて提供されるマーケティング同意を必要としない。最初の成果に不要な追加質問は後回しにする。
フォーム上で、誰がデータを受け取り何のために使うかを示し、全文のプライバシー通知への分かりやすいリンクを付ける。UK GDPR の対象組織は、目的や保持期間などの透明性義務がある。これは普遍的な法的助言ではないので、対象市場向けの収集と通知文を適切な担当者に承認してもらうこと。
送信前に必須フィールドや特殊な形式を明示する。アスタリスクや色だけでは不十分。
マーケティング同意などの任意の選択は、注文、リクエスト、アカウントの送信に必要なアクションとは別にする。
ラベルとネイティブコントロールに仕事をさせる
すべてのフィールド、チェックボックス、ラジオグループ、セレクト、ボタンには目的を説明する名前が必要。通常は input の id と一致する for 値を持つ label 要素で可視ラベルを関連付ける。これによりラベルのクリック領域が広がり、支援技術が正しいコントロールを識別できる。ラベルは入力の近くに置く。
ヒントテキストはフィールド名ではない。入力後に消える唯一の指示にしないこと。視覚的文脈でラベルが冗長に見えても、コード上はアクセシブルな名前を残しテストする。W3C は title テキストが主要ラベルの代替としては信頼性が低いと指摘している。
メール、tel、date、radio、checkbox、select のような適合するネイティブを、汎用テキストフィールドで模倣する代わりに使う。
Submit より Create account や Place order のような行動ラベルを使うと分かりやすい場合がある。
訂正を助ける検証を行い、ルールはサーバーで強制する
安定したチェックにはネイティブの制約を使う：適切な input type、required、長さ、範囲、適切な pattern。エラーになる前に有用な形式の例を示す。クライアント側のチェックは回復を助けるが、セキュリティ境界ではない。リクエストはこれらを回避し得るため、サーバー側でも処理前に関連する構文やビジネスルールを検証する必要がある。
送信が失敗したときは、受け入れ済みの値を保持する。フォーム前にエラー概要を置き、各フィールドを特定し、問題と修正方法を説明してそれにリンクする。フィールド横に簡潔なメッセージを繰り返す。コントロールに関連付け、不適切な状態を示すときは明示し、フォーカスは最初のエラーまたは概要に予測可能に移動させる。成功は明示的に確認する。
入力中の検証は、ユーザーにとって安定し有益なフィードバック（例：ユーザー名の利用可否）に限定する。入力途中で必然的に失敗する形式チェックは、多くの場合フォーカスが離れた後か送信時に行う方が良い。動的メッセージはスクリーンリーダーでテストすること；ライブ更新は助けになるが、常時の中断は摩擦になる。
サーバー側で許可される日付、選択肢、長さ、形式を定義する。疑わしい文字の拒否リストは主要な制御としては頼りにならない。
タイムアウトや重複送信では、リクエストが受け取られたかどうかを伝え、安全な次の行動を示す。
ブラウザの自動入力とモバイル入力に対応する
given-name、family-name、email、tel、shipping street-address、billing postal-code、username、new-password のような具体的な autocomplete トークンを追加する。これらのトークンはブラウザとパスワードマネージャが類似するフィールドを区別するのに役立つ。自動入力は支援であって約束ではない；挙動は変動し、使いやすいフォーム、name や id、送信コントロールに依存することがある。
適切なモバイルキーボードや基本的なブラウザ検証を提供できる input type を使う。パスワードフィールドで貼り付けをブロックしたりパスワードマネージャを妨げたりしない。モダンブラウザはログインフォームで autocomplete をオフにしていても資格情報の自動入力を提案することがあるので、実際に利用されるブラウザでのジャーニーをテストする。
同一ページに請求先と配送先がある場合、対応するグルーピングトークンを使い同じフィールドが混同されないようにする。
ラベルが見え続け、スクリプトがブラウザで自動入力された値を空と誤判定しないことを確認する。
キーボードだけで完結できる経路にする
ポインターがなくてもフォームを完了できる必要がある。キーボード操作は音声入力や他の支援技術が生成するキーストロークもサポートする。フォーム前から後まで Tab で移動できること：順序はタスクに沿い、フォーカスは見やすく、いかなるコントロール、ダイアログ、日付ピッカー、エラーリンク、ヘルプパネルもフォーカスを閉じ込めてはいけない。
ネイティブコントロールは多くを提供する。カスタムドロップダウン、マスクされた日付、住所検索、CAPTCHA の代替、モーダルは意図的なキーボード動作、フォーカスマネジメント、アクセシブルな名前が必要だ。カスタムコンポーネントが使いやすいネイティブ代替に匹敵できないなら、簡素化する。狭い幅や高倍率でテストする。
Tab、Shift+Tab、Enter、Space、Escape、関連する矢印キーで通常・エラー・条件付きのフローを完了する。
ガードレールとロールバックで改善をリリースする
価値の高いフォームを変更する前に、確定送信数、フィールドカテゴリ別のエラー、技術的失敗、完了までの時間のベースラインを記録する。メトリックを改善するために生の値を収集したり機微データを再生したりしない。集計信号をアクセシビリティとキーボードチェックと組み合わせること：単一のレートは人がなぜ困っているかを説明できないことが多い。
実行可能なら、ラベル文言、任意フィールドの削除、回復改善など、１つの重要な変更を同時にリリースする。テスト前にガードレールを定義する：決済承認エラー、サポート連絡先、アクセシビリティの後退などが関連し得る。安全なアカウントと決済テスト環境で本番設定を検証する。決済スクリプト、データ処理、コンプライアンスには有資格のセキュリティ、決済、法務のレビューが必要であり、本稿は準拠を保証するものではない。
SIU（Status Is UP）はローンチ前のプレフライトでこれを安全にする：依存関係、クライアント挙動、サーバー応答、確認、ロールバックを確認する。これはプロアクティブな修復であり、チームのライブステータスや障害監視プロセスの代替ではない。
欠落や不正な値、セッションの期限切れ、応答遅延、ルックアップ失敗、最終アクションのダブルクリックなどを試す。
以前の構成、オーナー、そして可逆的なデプロイ手順を、露出が増える前に用意しておく。