Date Picker
日付ピッカー
日付ピッカーは、カレンダー上の日を入力したり選択したりするためのコントロールです。時刻を選ぶことはできません。
実際の例
旅行者は8月4日以降の日付から選択できますが、利用できない日もあります。キーボードやポインタ入力は 2026-08-12 を返し、制限を説明します。既知のISO日付を入力する方が速い場合、カレンダーは必須ではありません。
主な部分
- 01日付フィールド
- 02カレンダーグリッド
- 03最小および利用不可の日付
以下の場合に使用します
タスクに有効な日付が必要で、カレンダーを見ることがユーザーに役立つ場合にこの用語を使用してください。
以下の場合は使用しないでください
月、年、期間、またはおおよその日付のみを尋ねる場合に、複雑なカレンダーを使用しないでください。
コードで使用する名前
<input type=date> or accessible calendar dialog 出荷前に
Give assistive tools the control’s name (accessible name), purpose (role), value, and state. Check keyboard use, visible focus, target size, disabled and busy states, feedback, and recovery.
Outcome：Complete the task with 日付ピッカー (Date Picker)。 User context：旅行者は8月4日以降の日付から選択できますが、利用できない日もあります。キーボードやポインタ入力は 2026-08-12 を返し、制限を説明します。既知のISO日付を入力する方が速い場合、カレンダーは必須ではありません。 Recommended pattern：日付ピッカー (Date Picker)。 Why it fits：タスクに有効な日付が必要で、カレンダーを見ることがユーザーに役立つ場合にこの用語を使用してください。 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 日付ピッカー (Date Picker) is used now. Definition: 日付ピッカーは、カレンダー上の日を入力したり選択したりするためのコントロールです。時刻を選ぶことはできません。 Release checks: Give assistive tools the control’s name (accessible name), purpose (role), value, and state. Check keyboard use, visible focus, target size, disabled and busy states, feedback, and recovery. Before changing code, list the evidence, gaps, severity, and the smallest safe fix.