forms-inputs-checkout

フォーム、入力項目、チェックアウト

目的

エージェントが、明確でアクセシブル、かつ高いコンバージョン率を実現するフォーム、入力項目、バリデーション、チェックアウトフローを設計、評価、実装できるよう支援します。

すべてのフォームは、人と目標の間にある障壁として捉えてください。エージェントの役割は、不適切なデータを収集したり、重要な選択肢を隠したり、アクセシビリティ、プライバシー、法務、ビジネス上の要件を損なったりすることなく、その障壁を取り除くことです。

このスキルを使用する場合

次のような場合に、このスキルを使用します。

• チェックアウト、カート、支払い、配送、請求、プロモーションコード、アカウント、登録、サインイン、オンボーディング、サブスクリプション、リード獲得、サポート、アンケート、設定、プロフィール、アップロード、データ入力フォーム。
• フォームを含むスクリーンショット、ワイヤーフレーム、Figma の説明、HTML/CSS/React コンポーネント、デザインシステムのコンポーネント、プロダクトフローの評価。
• ラベル、入力コントロール、グループ化、進行状況インジケーター、初期値、バリデーション、エラーメッセージ、ヘルプテキスト、送信状態、成功状態の選定。
• セマンティックな HTML フォーム、アクセシブルな名前、フォーカス、キーボード操作の流れ、バリデーション、レスポンシブ動作に関するフロントエンド向けガイダンスの作成。

このスキルを使用しない場合

次のような場合は、このスキルを使用しないでください。

• 一般的なページレイアウト、ランディングページ、ナビゲーション、マーケティングコンテンツ、ビジュアルブランドに関する作業。ただし、ページにフォームやチェックアウトに関する選択が含まれる場合を除きます。
• バックエンドのデータモデリング、不正検知、税務、法務、PCI／セキュリティの実装、支払い処理業者との連携に関する詳細。ただし、UX／フロントエンドへの影響は除きます。
• フォーム以外の一般的なコンバージョン向けコピーの作成。
• ユーザーが、資料で扱っていないプラットフォームガイドラインを明示的に求めている場合の、ネイティブなプラットフォーム固有のフォームコントロール。その場合は、適切なプラットフォームのスキル／資料を確認するか、ユーザーに尋ねてください。

基本原則

1. 外側から内側へ考えます。 組織が求めるデータベース項目ではなく、ユーザーの目標と利用の流れにおける現在の段階から始めます。
2. 新しい項目を設計する前に、削除、後回し、推定、初期値の設定を検討します。 質問はどれも手間を生み、間違いの可能性を高めます。
3. 完了までの道筋を視覚的に明確にします。 フォームでは、タイトルから最初の質問、最後のアクションまで、目で追いやすい流れを作る必要があります。
4. 質問に合ったコントロールを使います。 ネイティブでセマンティックなフォームコントロールを優先し、選択肢が少ない場合は選択肢を見える形で示します。
5. ラベルを一貫して使える文脈として提供します。 単純で、なじみがあり、項目が1つだけのやり取りでない限り、プレースホルダーだけのラベルに頼らないでください。
6. 叱責ではなく、助けとなるバリデーションを行います。 ユーザーが回答を終えてから検証し、避けられるエラーを防ぎ、適切な場面で解決方法を提示します。
7. 間違いが起きる前提で設計します。 ユーザーは手順を飛ばしたり、誤った操作を選んだり、入力を間違えたり、ラベルを誤解したり、ストレス下で情報を見落としたりします。
8. 色だけに頼らないでください。 エラー、成功、必須／任意、無効状態、支払い／セキュリティの手掛かりには、色に加えてテキストや形状も必要です。
9. チェックアウトに集中できるようにします。 注意をそらすものを取り除き、アカウント作成を強制せず、費用とその結果を明確に示し、主なアクションを購入者の目標に沿わせます。
10. 進行状況を正確に示します。 手順と範囲が十分に定まっており、インジケーターが誤解を招かない場合にのみ、進行状況インジケーターを使用します。

各原則を再利用可能なカードとしてまとめたものは、references/principle-cards.md を参照してください。

既定の推奨事項

ユーザーがプロダクト固有の制約を提示している場合、またはこのスキルの判断プロンプトによって確認が必要だと示される場合を除き、以下を既定として使用します。

フォームの目的と範囲

既定：ユーザーの現在の目標を達成するうえで必要な、信頼できる最小限のデータで、正常に完了できるよう最適化します。

例外：規制、セキュリティ、不正対策、本人確認、利用資格、サポート、履行に関する要件により、追加データが必要な場合。その要件と、データを収集する理由を確認してください。

質問セット

デフォルト：重要でない質問は削除し、任意またはマーケティングに関する質問は、基本的な入力が済んでから尋ねます。確信度が高い場合は、既知のコンテキストから回答を推測します。

例外：任意の回答が、パーソナライズ、利用資格、料金、コンプライアンス、運用上の振り分けに不可欠な場合。

構成

デフォルト：一貫性のあるトピックが少数の短いフォームには単一ページを使用します。長いフォーム、分岐するフロー、モバイルを優先するフロー、または高い集中力を要するタスクには、複数ページまたは1ページにつき1項目の構成を使用します。

例外：ユーザーが関連する回答をまとめて確認したり、選択肢を比較したり、情報量の多い専門的なワークフローを完了したりする必要がある場合。

ラベル

デフォルト：各フィールドの上に、簡潔で自然な言葉によるラベルを表示します。上部に配置するラベルは、通常、入力時間を最小限に抑え、多言語対応に適しており、モバイルでも使いやすいです。

例外：デスクトップの情報量が多いフォームで縦方向のスペースに厳しい制約がある場合、または複雑な設定フォームで入力速度よりもラベルの一覧性が重要な場合。

必須項目と任意項目

デフォルト：任意項目は避けます。ほとんどの項目が必須の場合は、「任意」などのテキストで少数の任意項目を示します。ほとんどの項目が任意の場合は、「必須」などのテキストで少数の必須項目を示します。すべての項目を必須と表示しないでください。

例外：組織の標準でアスタリスクの使用が求められる場合。それでも凡例を用意し、記号をラベルに関連付けてください。

入力コントロール

デフォルト：ネイティブコントロールとセマンティック HTML を使用します。少数の選択肢から1つ選ぶ場合はラジオボタン、はい／いいえまたは複数選択にはチェックボックス、自由記述にはテキスト入力を使用します。選択／コンボボックスのパターンは、選択肢が多い場合に入力の負担を減らせる場合に限って使用します。

例外：デザインシステムに、キーボード、スクリーンリーダー、フォーカス、エラーの動作を維持する、テスト済みのアクセシブルなカスタムコントロールがある場合。

選択ボックス

デフォルト：選択ボックスは最後の手段として使用します。短いリストでは表示されたラジオボタンの選択肢、検索可能な長いリストではオートコンプリート／コンボボックス、回答が予測できる場合は適切な初期値を優先します。

例外：プラットフォームの慣例やスペースの制約により、選択コントロールが最もシンプルでアクセシブルな解決策となる場合。

入力幅

デフォルト：郵便番号やセキュリティコードなど、回答の長さが決まっている場合は、フィールド幅で想定される回答の長さを示します。長さに意味がない場合は、実用的で一貫した幅を使用します。

例外：レスポンシブ対応、多言語対応、自動フォーマットによって、正確な幅が誤解を招く場合。

ヘルプテキスト

デフォルト：データに馴染みがない場合、プライバシー／セキュリティ上の懸念がある場合、形式が特殊な場合、質問がセンシティブな場合、必須／任意の例外がある場合、または推奨される回答形式がある場合に限り、近くに簡潔なヘルプを表示します。

例外：専門的なワークフロー、繰り返し利用するワークフロー、複雑なワークフローで、常時表示されるコンテキストヘルプパネルが必要な場合。

入力検証

デフォルト：ユーザーが入力中ではなく、通常はフィールドからフォーカスが外れたとき、または選択後に、入力検証を行います。エラー率が高いフィールド、形式が厳密に決まっているフィールド、一意性チェックのあるフィールド、入力制限のあるフィールド、または有効な回答の選択肢が多いフィールドには、インライン入力検証を使用します。

例外：文字数制限やパスワード強度など、回答の作成を直接支援するライブカウンターやメーターの場合。入力中も表示し、入力を妨げないようにしてください。

エラーメッセージ

デフォルト：長いフォームや複数のエラーがある場合は、フォーム上部にエラーの概要を表示し、問題のある各フィールドにインラインの解決方法を示します。エラーのあるフィールドは、色だけに頼らず、テキストと視覚的な強調で示します。

例外：非常に短いフォームで、明らかなエラーが1つだけあり、インラインメッセージが表示範囲内にある場合。

送信ボタンと送信中の状態

デフォルト：主要な操作ボタンは常に表示し、有効にしておきます。クリックされたら、処理中であることを明確に示し、重複送信を防ぎます。理由が伝えられ、次に必要な修正が明らかでない限り、送信前に送信ボタンを隠したり無効にしたりしないでください。

例外：破壊的、取り消し不可能、または法的に慎重な対応が必要な操作で、明示的な前提条件が求められる場合。不足している項目を説明し、最初の未完了項目にフォーカスを移します。

チェックアウト

デフォルト：ゲストとしてのチェックアウト、または購入後のアカウント作成に対応し、注文概要と合計金額を常に表示して、離脱につながる要素を最小限に抑え、配送情報と支払い情報を適切な順序で尋ね、アカウントやプロフィールに関する質問は後回しにします。

例外：アカウント、本人確認、利用資格、または保存された顧客関係がなければ、製品やサービスを提供できない場合です。

進行状況インジケーター

デフォルト：短いフォーム、不確定なフォーム、または動的に分岐するフォームでは、プログレスバーを省略します。安定した複数ステップのフローに限り、範囲、現在位置、保存状況やステータスを表示します。

例外：長いフォームで安心感が必要でも、ステップが動的に変化する場合は、正確なステップ数ではなく、「もうすぐ完了です」やセクションの完了状況など、一般的な進行状況を示す表現を使用します。

アクセシビリティのレベル

デフォルト：WCAGに準じた要件に沿って設計します。具体的には、セマンティックなコントロール、常に表示されるラベル、キーボード操作への対応、わかりやすいフォーカス表示、十分なコントラスト、代替テキスト、色だけに頼らない手がかり、拡大可能なテキスト、支援技術に通知されるエラーメッセージを備えます。

例外：アクセシビリティのレベルを下げてはいけません。リスクの高い分野では、追加のアクセシビリティ要件、テスト、または法令への適合が必要かどうかを確認します。

フロントエンドの実装

デフォルト：まずセマンティックなHTMLを使用し、可能な場合はネイティブコントロールをスタイル設定します。ネイティブのセマンティクスを維持するデザインシステムのコンポーネントを優先し、フィールドの値、操作済み／変更済みの状態、バリデーションの状態、送信の状態、サーバーエラーの状態を基にフォームの状態を構築します。

例外：カスタムのインタラクションが必要な場合は、それを推奨する前に、キーボード、フォーカス、スクリーンリーダー、モバイル入力での動作を必須要件として確認します。

必須のユーザーへの質問

回答によって推奨するフォーム設計が変わる場合に限り、焦点を絞った質問をします。一般的なベストプラクティスについては、定型的な質問をしないでください。

以下のいずれかが不明で、作業に実質的な影響を及ぼす場合は質問します。

• フォームのビジネス上またはユーザー上の目的が曖昧である。
• フローに、チェックアウト、支払い、本人確認、法的同意、医療、金融、行政、未成年者、アクセシビリティへの適合、または取り消し不能な結果が関係する。
• フィールドが多く、どれが必須、任意、推測可能、または後回しにできるのかが明確でない。
• 対象ユーザー、ロケール、言語、使用デバイスの構成、または支援技術のニーズによって、ラベルの長さ、入力形式、キーボードの動作、信頼を促すメッセージが変わる可能性が高い。
• 1ページにまとめるか複数ページにするか、速さを優先するか慎重な確認を重視するか、選択肢を表示するかコンパクトなコントロールにするか、ゲストとしてチェックアウトするかアカウントを作成するか、というトレードオフがある。
• 離脱率、エラー率、またはコンバージョンの問題を診断するために、既存の分析データや調査結果が必要である。

references/decision-prompts.mdにある、質問ツールですぐに使えるプロンプトを使用します。

既存フォームを批評するワークフロー

次の順序で確認します。

1. 目的との適合性： ユーザーは何を達成しようとしているのか、フォームが不必要にその妨げになったり、遅らせたりしていないかを確認します。
2. 質問の必要性： 削除できる、推測できる、デフォルト値を設定できる、任意にできる、または後回しにできる項目はどれかを確認します。
3. 流れと順序： 質問の順序は、ユーザーのタスクの考え方に合っているかを確認します。信頼関係や背景情報が得られるまで、機微な質問や回答に手間がかかる質問を後回しにできているかを確認します。
4. 構成とグループ化： 関連する質問が、必要最小限の視覚的ノイズでまとめられているかを確認します。分岐によってユーザーが混乱しないようにできているかを確認します。
5. 視線の流れとレイアウト： ラベル、入力欄、アクションの間を、ジグザグに動いたり、列を飛び越えたり、重要な情報を見落としたりせず、スムーズに進めるかを確認します。
6. ラベルとコントロール： ラベルが常に表示され、簡潔で、長期的に使えるものであり、適切なセマンティックコントロールと関連付けられているかを確認します。
7. ヘルプとマイクロコピー： ヘルプが文脈に沿っていて、最小限に抑えられているかを確認します。デザインだけでは明らかにできないことだけを説明しているかを確認します。
8. バリデーションとエラー： 可能な限りエラーを防ぎ、適切なタイミングで表示し、次に取るべき行動がわかる修正方法を記載しているかを確認します。
9. 送信と完了： 主なアクションが明確かを確認します。読み込み、重複送信の防止、完了、次の手順に対応できているかを確認します。
10. アクセシビリティと実装： キーボード、スクリーンリーダー、タッチ操作、モバイルキーボード、ズームに対応し、色だけに頼った手がかりを使わずにフォームを利用できるかを確認します。
11. 測定： 完了率、離脱箇所、エラーの発生箇所、完了までの時間、サポートへの問い合わせ、ユーザーが感じる不満について、テストや分析を推奨します。

批評を提示する際は、指摘事項を深刻度別に分類します。ブロッカー、操作上の大きな負担、アクセシビリティの問題、コンバージョン向上の機会、仕上げの改善。

フォームを作成または改善するワークフロー

1. タスクを明確にします。 ユーザーの目標、ビジネス上の目標、必要な成果物、対象ユーザー、利用デバイスの構成、制約を特定します。
2. 送信を成功させるための最小要件を定めます。 項目を必須、任意、推測可能、デフォルト設定可能、後回し可能に分類します。
3. フローの形式を選びます。 単一ページ、複数ステップ、1ページ1問、段階的な開示、または段階的なエンゲージメントを選択します。
4. 質問の順序を決めます。 負担が少なく、背景情報を得るための質問から始めます。アカウント情報、機微な情報、法的な質問、回答に手間がかかる質問は、必要性が明らかになるまで後回しにします。
5. 項目をユーザーのトピック別にまとめます。 見出し、余白、フィールドセット、凡例を使い、視覚的なノイズを増やす装飾的な区切り線は避けます。
6. コントロールとラベルを選びます。 質問に合う、最もシンプルなネイティブコントロールを選びます。常に表示されるラベルと、想定に合った入力属性を使います。
7. デフォルト値とヘルプを追加します。 多くのユーザーにとって正しい可能性が高い場合にのみデフォルト値を設定します。ヘルプは近くに配置し、簡潔で具体的なものにします。
8. バリデーションとエラーを設計します。 エラーを防ぎ、適切なタイミングでバリデーションを行います。必要に応じて概要を示し、各項目に修正方法を提示します。
9. 送信時の状態を設計します。 主なアクション、副次的なアクション、読み込み、重複送信の防止、完了、次の手順を明確にします。
10. アクセシビリティとフロントエンドでの実現可能性を確認します。 セマンティック HTML、フォーカス、キーボード操作の順序、必要に応じた ARIA、レスポンシブ動作、デザインシステムとの適合性を確認します。
11. トレードオフを説明します。 選んだデフォルトの方針と、それが適切な理由を述べ、制約が異なる場合に何が変わるかを説明します。

意思決定のフレームワーク

複雑さを加える前に、次の優先順位に従います。

1. 削除： 質問を削除します。
2. 推測： 既知の背景情報やシステムデータから回答を推測します。
3. デフォルト設定： ほとんどのユーザーの目標に合い、簡単に変更できる場合は、デフォルト値を設定します。
4. 後回し： 中心となるタスクの後、または回答が必要になるまで質問を後回しにします。
5. 質問： できる限りシンプルな方法で質問します。
6. 説明： ユーザーが疑問や不安を感じたり、背景情報が不足していたりする可能性がある場合は、質問が必要な理由を説明します。
7. バリデーション： 最も妨げにならないタイミングでバリデーションを行います。
8. 復旧： 回答がない、間違っている、またはサーバーに拒否された場合も、適切に復旧できるようにします。

実践的なルール

構成と流れ

• フォームのタイトルには、内部データベースのオブジェクト名ではなく、ユーザーが想定するタスクに合った名前を付けます。
• 購入手続きでは、サインインを必須にしないでください。可能であれば、ゲストとして購入を進められるようにするか、購入後にアカウントを作成できるようにします。
• 長いフォームは意味のあるトピックごとに分けます。短いフォームを、エンゲージメントを高めているように見せるためだけに複数のページへ分割しないでください。
• 概要を一目で把握できることよりも、集中しやすさ、分岐、モバイルでの使いやすさ、理解しやすさが重要な場合は、1ページに1つの項目を配置します。
• 進捗インジケーターは、作業の範囲、現在の位置、状態を正確に伝えられる場合にのみ使用します。
• 長時間かかる手間の多いフォームでは、保存して再開できるようにします。

ラベルと質問

• ユーザーの言語で、短く具体的な質問または名詞句としてラベルを書きます。
• 大文字の使い方を統一します。限定的な警告の場面を除き、すべて大文字にするのは避けます。
• ユーザーが入力した後もラベルが表示されるようにします。プレースホルダーテキストはラベルを補足できますが、代わりにはなりません。
• 同じフォーム内でラベルの配置を混在させないでください。
• 使い慣れた情報の入力やモバイルファーストの作業では、上揃えのラベルを優先します。
• 見慣れない項目や多数の任意項目をすばやく確認することが、入力速度より重要な場合にのみ、左揃えのラベルを優先します。

グループ化と視覚的階層

• 線、パネル、交互の背景色を使う前に、近接性と余白を活用します。
• ラジオボタン、チェックボックス、関連するコントロールのグループには、fieldset と legend を使用します。
• 主要なアクションが、送信対象のフィールドと視覚的に明確につながるようにします。
• タブ順序、レスポンシブ時の折り返し、一覧性が明確に保たれる場合を除き、2列レイアウトは避けます。

コントロール

• 少数の選択肢から1つを選ぶ必要があり、すべての選択肢を表示すべき場合は、ラジオボタンを使用します。
• 個別に選択できる項目や、単一のはい／いいえ形式の同意・選択には、チェックボックスを使用します。
• 選択肢が少ない場合は、選択ボックスを避けます。選択肢が隠れ、操作の負担が増えるためです。
• 長い一覧では、アクセシブルなキーボード操作と有効な候補の明確な表示に対応したオートコンプリート／コンボボックスを検討します。
• 選択肢のラベルをクリック可能にし、入力欄とラベルが同じ操作対象になるようにします。
• モバイルに適した入力タイプと属性を使用します。email、tel、url、数値の入力が本当に適切な場合に限るnumber、autocomplete、inputmode、autocapitalize、spellcheck、必要に応じてaria-describedbyを使用します。

必須、任意、後回しにできる入力項目

• ユーザーまたはビジネスにとって明確な目的がない限り、任意の項目は削除します。
• 少数派の項目を明示します。ほとんどが必須なら任意項目を、ほとんどが任意なら必須項目を示します。
• 明確さを優先し、記号ではなくテキストを使用します。アスタリスクを使う場合は、説明とアクセシブルなラベルを付けます。
• プロモーションコード、アカウント作成、マーケティング設定、プロフィール情報の追加は、文脈上有用な場合にのみ尋ねます。それ以外の場合は後回しにします。

デフォルトとパーソナライズ

• デフォルト値が正しい可能性が高く、変更可能で、ユーザーの利益に沿う場合にのみ、作業を減らすために使用します。
• 隠れた費用、マーケティングへの同意、プレミアムプラン、リスクのある権限をデフォルトにしないでください。
• リピーターについては、情報が安定している可能性が高く、簡単に変更できる場合に、デフォルトをパーソナライズします。
• 国、配送、支払いのデフォルトには注意してください。誤ったデフォルトは、コストのかかるミスにつながる可能性があります。

ヘルプテキスト

• 見慣れない用語、機微なデータ、プライバシー／セキュリティに関する安心材料、特殊な形式、回答の上限、項目が必要な理由について説明する場合に、ヘルプを使用します。
• ヘルプは該当するラベル／入力欄の近くに配置するか、複雑で繰り返し使うフォームでは一貫したヘルプエリアに配置します。
• フォームの前に長い説明を置かないでください。ユーザーは入力欄へ直接進むことがよくあります。
• 不適切なラベル、誤ったコントロール、恣意的な形式、不要な質問を補うためにヘルプテキストを使わないでください。

検証、エラー、成功

• 可能な限り、電話番号やクレジットカード番号のさまざまなスペースの入れ方など、柔軟な入力を受け付け、入力後に正規化します。
• 一意性、利用可能かどうか、厳密な形式、上限は、確認するのが適切なタイミングで検証します。
• ユーザーが通常の回答を入力している間は、エラーを表示しません。
• 問題の内容、発生箇所、解決方法を説明します。
• 長いフォームでは、エラーの概要を表示し、各フィールドのエラーへのリンクを設けるか、該当フィールドにフォーカスを移します。
• エラーにはテキスト、アイコンや図形、スタイルを使用します。赤色や警告アイコンはエラーに限定し、意味が伝わるようにします。
• 送信に成功したら、何が行われたかを確認し、次に進むための適切な操作を提示します。行き止まりになる成功画面は避けます。

チェックアウト固有のルール

• チェックアウト画面は、商品閲覧時よりも落ち着いた見た目にします。購入完了から注意をそらす無関係なナビゲーション、オファー、リンクを取り除きます。
• カートの状況を維持します。商品数、編集可能な注文概要、送料、請求額、支払い額、判明している場合は税金や手数料、配送予定を表示します。
• ユーザーが想定しやすい順序で質問します。連絡先／メールアドレス、配送先／所在地、配送方法、支払い、確認／確定の順です。商品やサービスの状況に応じて順序を調整します。
• アカウント作成、パスワード、設定、マーケティングに関する手続きは、可能な限り購入後まで後回しにします。
• 支払い／セキュリティに関する安心材料は、一般的な飾り文句ではなく、具体的で検証可能な内容にします。
• 割引がビジネスモデルの中心でない限り、プロモーションコードの入力欄は利用可能にしつつ、視覚的には控えめにします。
• 最終操作の結果が明確に伝わるようにします。「注文する」「支払う」「購読する」「申し込む」「変更を保存する」などです。

アクセシビリティとインクルージョンの要件

必ず確認します。

• すべてのフィールドにアクセシブルな名前が設定されています。できれば、表示される <label> を for／id に関連付けるか、ラベルでフィールドを囲みます。
• 関連するコントロールは、意味的なグループとしてまとめます。ラジオボタン／チェックボックスのグループには <fieldset> と <legend> を使用します。
• エラーやヘルプのテキストは、aria-describedby などを使って、フィールドにプログラム上関連付けられています。
• エラーの概要はフォーカス可能で、読み上げられ、無効なフィールドへのリンクを提供します。
• フォーカス順序は視覚的な順序／タスクの順序に従います。キーボードトラップはなく、すべてのコントロールとヘルプ表示はマウスなしで操作できます。
• フォーカス状態は視認でき、CSS で取り除かれていません。
• フォームは拡大表示や大きな文字でも機能します。モバイルレイアウトでラベルやエラーメッセージが隠れません。
• 色だけを唯一の手がかりにしません。テキスト、アイコンや図形、プログラム上の状態も追加します。
• 動き、点滅、自動変更を最小限に抑えます。動的な検証は控えめに通知し、操作を妨げません。
• タイムアウトが発生する場合は、可能な限り事前警告、延長の機会、入力内容の保持を提供します。
• 「右側の緑のボタン」のように、物理的な位置、色、視覚的な形だけに依存する表現を避けます。
• 重要なフローでは、障害のあるユーザーを含む対象ユーザーでテストします。

フロントエンド実装の指針

JavaScriptを複雑にする前に、セマンティックなHTMLを使用してください。

<form novalidate>
  <fieldset>
    <legend>Delivery method</legend>
    <label><input type="radio" name="delivery" value="ship"> Ship to address</label>
    <label><input type="radio" name="delivery" value="pickup"> Pick up in store</label>
  </fieldset>

  <label for="email">Email address</label>
  <input id="email" name="email" type="email" autocomplete="email" autocapitalize="none" spellcheck="false" aria-describedby="email-help email-error">
  <p id="email-help">We will send your receipt and delivery updates here.</p>
  <p id="email-error" role="alert" hidden>Enter an email address, like [email protected].</p>

  <button type="submit">Continue to payment</button>
</form>

実装ルール：

• キーボードや支援技術での操作性を維持できない限り、ネイティブコントロールをカスタムコントロールに置き換えないでください。
• 特に複数列のレイアウトでは、DOMの順序を視覚的な順序と一致させてください。
• 正の値のtabindexは避け、代わりにDOMの順序を修正してください。プログラムから要約や見出しにフォーカスを移す場合に限り、tabindex="-1"を使用してください。
• フォームの状態を明示的にモデル化してください。値、変更済み／フォーカス後、クライアント側の有効性、サーバー側の有効性、読み込み中／送信中、成功、回復可能な失敗を含めます。
• サーバー側の検証では、ユーザーが入力した値を保持し、安定したフィールド名に対応付けたフィールド単位のエラーを返してください。
• クリック後の重複送信を防止またはガードし、処理中の状態を伝え、ラベルと結果を分かりやすくしてください。
• 検証条件が満たされていないという理由だけで唯一の送信手段を隠さないでください。隠す場合は、UIで妨げとなっている条件とその解決方法も説明してください。
• 一般的なチェックアウト項目には、適切にautocompleteトークンを使用してください。name、email、tel、street-address、address-line1、address-level2、postal-code、country、cc-name、cc-number、cc-exp、cc-cscなどがあります。
• 郵便番号、電話番号、カード番号など、数値のように見えても数値入力にすべきでないテキスト値には、inputmodeを使用してください。
• よく使われる人間向けの形式を拒否するのではなく、可能であれば入力後に書式を整えてください。
• コンポーネントAPIでは、表示ラベル、補足テキスト、エラーテキスト、必須／任意のテキスト、説明に使用するID、間隔や状態に関するデザイントークンを受け取れるようにしてください。

品質チェックリスト

推奨内容を確定する前に、次の点を確認してください。

• フォームのユーザー目標と主なアクションが明確である。
• すべてのフィールドに、今設けるべき理由がある。
• 任意のフィールドは削除または後回しにするか、少数派のケースであることを明示している。
• 質問の順序が、ユーザーのタスクに対するメンタルモデルと一致している。
• レイアウトによって、完了までの読みやすい経路が一つに定まっている。
• コントロールがデータ型と判断の種類に合っている。
• ラベルが常に表示され、プログラムから関連付けられている。
• 補足が状況に即して簡潔であり、設計の不備を補うものになっていない。
• 検証のタイミングがユーザーに配慮され、フィールドのエラーから具体的な対応が分かる。
• エラー状態と成功状態が設計され、デフォルト任せになっていない。
• 必須でない限り、チェックアウトでアカウント登録を強制したり、不要な離脱経路を設けたりしていない。
• キーボード操作、フォーカス、スクリーンリーダー、色のコントラスト、ズーム、モバイルキーボードに対応している。
• 実装がデザインシステムとフロントエンドスタックの範囲内で実現可能である。

詳しいチェックリストはreferences/checklists.mdを参照してください。

避けるべきよくある間違い

• ユーザーのタスクではなく、データベースのフィールドを基準に設計する。
• 中核となるタスクの前に、任意項目、プロフィール、マーケティング、アカウントに関する質問をする。
• プレースホルダーをラベルとして使用する。
• 短い選択肢のリストにセレクトボックスを使用する。
• すべてのフィールドを必須にする。
• 通常のラベルや補足に赤いテキストを使い、エラーの意味を弱める。
• ユーザーが入力中に検証する。
• 明確な解決策を示さずに送信を隠す、または無効にする。
• 変動するステップや不明なステップにプログレスバーを使用する。
• 副次的なアクションや破壊的なアクションを、主なアクションと同じ視覚的な強さにする。
• スキャンを妨げる装飾的なグループ分けを追加する。
• 依存関係のあるフィールドを一度にすべて表示し、ユーザーを圧倒する。
• 確認や次のステップを提示しない成功ページで終わる。

アンチパターンの完全なリストはreferences/anti-patterns.mdを参照してください。

推奨事項をユーザーに説明する方法

完了のしやすさ、信頼性、エラーの防止、信頼という観点で説明します。

次のパターンを使います。

1. 推奨事項を伝えます。 「上部に配置した視認性の高いラベルを使い、ヘルプテキストはフィールドの下に置きます。」
2. ユーザーの目標に結び付けます。 「これにより、モバイルでもチェックアウトの流れを簡単に確認でき、入力中に文脈を見失う可能性を減らせます。」
3. トレードオフに触れます。 「縦方向のスペースを多く使いますが、フォームが短いため、密度より明瞭さを優先する価値があります。」
4. 例外を示します。 「専門家向けの項目が密集した設定画面では、編集前にラベルを確認するため、左揃えのラベルのほうが適している場合があります。」
5. 役立つ場合に限り、実装の詳細を伝えます。 「実際の<label>を使い、ヘルプテキストやエラーテキストをaria-describedbyで関連付けます。」