Multi-Step Form
マルチステップフォーム
マルチステップフォームは一つの長いタスクを小さなページに分けます。送信前に答えを確認します。
もう一つの例
プロジェクトフォームは各回答を保存し、ユーザーが戻ることを可能にします。提出後にはレビュー画面と1つの受領書を表示します。
主な部分
- 01現在のステップ
- 02ページの目的
- 03戻ると続行
- 04保存された下書き
- 05検証とレビュー
- 06送信確認
以下の場合に使用します
タスクが1ページに収まらない場合や、意味のある順序やレビュー手順がある場合に使用します。
以下の場合は使用しないでください
短い形式を手順追加のためだけに分割しないこと。人が戻ったり、リフレッシュしたり、後で戻ってきたときに回答を保持すること。
コードで使用する名前
ordered steps + saved draft + validation + review + one final submit 出荷前に
Give each field a label that code can read. Link hints and errors, and keep entered values. Check autofill, keyboard order, validation timing, submit states, failure recovery, zoom, and languages.
Outcome:Complete the task with マルチステップフォーム (Multi-Step Form)。 User context:プロジェクトフォームは各回答を保存し、ユーザーが戻ることを可能にします。提出後にはレビュー画面と1つの受領書を表示します。 Recommended pattern:マルチステップフォーム (Multi-Step Form)。 Why it fits:タスクが1ページに収まらない場合や、意味のある順序やレビュー手順がある場合に使用します。 Do not use it when:短い形式を手順追加のためだけに分割しないこと。人が戻ったり、リフレッシュしたり、後で戻ってきたときに回答を保持すること。 Product requirements: Define the default, loading, empty, error, success, and recovery states. Keep user input. Give clear feedback after every action. Accessibility and resilience: Use semantic HTML, full keyboard access, and visible focus. Make the layout work when zoomed and support reduced motion. Follow the project’s current rules. Do not add a new UI library unless the project already uses it. Acceptance criteria: The main task works with keyboard only and at 320px width. Focus and status changes are announced. Check loading, failure, retry, cancel, and reduced-motion paths. Evidence and limits (evidence boundary):単一の公式標準が全体の用語を管理するわけではありません。その意味はチーム、プラットフォーム、またはフレームワークによって変わる可能性があります。 Unknowns to confirm: Product wording, data source, analytics events, supported devices and languages, and platform limits.
このリクエストを確認する
Review how マルチステップフォーム (Multi-Step Form) is used now. Definition: マルチステップフォームは一つの長いタスクを小さなページに分けます。送信前に答えを確認します。 Release checks: Give each field a label that code can read. Link hints and errors, and keep entered values. Check autofill, keyboard order, validation timing, submit states, failure recovery, zoom, and languages. Before changing code, list the evidence, gaps, severity, and the smallest safe fix.