FAQ
よくある質問
FAQは、人々が決定を下す前や助けを求める前によく尋ねる質問を集めます。回答は、そうした人々が知っている言葉や状況を使います。
Is every example original?
Yes. We made every scene for this guide.
Can I use the prompt?
Yes. Change it to fit your product.
実際の例
料金の FAQ は、キャンセル、請求書、データの書き出し、プラン変更について書かれているよ。詳しい規約へのリンクがあるよ。
主な部分
- 01Trigger or task context
- 02Primary control surface
- 03Feedback, focus, and dismissal
以下の場合に使用します
実際の質問が次々と出てきて、短い回答が疑念を取り除ける場合に使用します。
以下の場合は使用しないでください
簡単な質問を作り出したり、重要な用語を隠してはいけません。FAQはサイトナビゲーションの代わりにはなりません。
コードで使用する名前
<section> / <details> 出荷前に
Before release, check the page structure, keyboard access, visible focus, contrast, and zoom. Also check loading, empty, error, success, cancel, and reduced-motion states.
Outcome：Complete the task with よくある質問 (FAQ)。 User context：料金の FAQ は、キャンセル、請求書、データの書き出し、プラン変更について書かれているよ。詳しい規約へのリンクがあるよ。 Recommended pattern：よくある質問 (FAQ)。 Why it fits：実際の質問が次々と出てきて、短い回答が疑念を取り除ける場合に使用します。 Do not use it when：簡単な質問を作り出したり、重要な用語を隠してはいけません。FAQはサイトナビゲーションの代わりにはなりません。 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 よくある質問 (FAQ) is used now. Definition: FAQは、人々が決定を下す前や助けを求める前によく尋ねる質問を集めます。回答は、そうした人々が知っている言葉や状況を使います。 Release checks: Before release, check the page structure, keyboard access, visible focus, contrast, and zoom. Also check loading, empty, error, success, cancel, and reduced-motion states. Before changing code, list the evidence, gaps, severity, and the smallest safe fix.