Date Picker
Also called calendar input, datepicker, date field, day selector
A field for entering a date, with a calendar for choosing one by sight.
Example
Type it: 15/08/2026, 2026-08-15 and 15 Aug 2026 all work.
Resolved value
2026-08-15 · 15 August 2026
The grid is one tab stop: the focused day carries tabindex="0" and the other thirty carry -1. Arrows move by day and by week, PageUp and PageDown by month, Escape closes and hands focus back to the field with whatever was typed still there.
When to use it
- The day of the week or the shape of the month matters — bookings, deliveries, anything with weekends or blackout dates.
- The date is near today and easier to recognise than to recall: “next Thursday”.
- Some dates are unavailable, and showing which is part of the job.
When not to
- The date is known exactly and far away. A date of birth is typing, not forty clicks back through the years.
- Only a month or a year is needed. A month picker is a much smaller control than a calendar with the days ignored.
- The field is one of many in a fast form. Opening a panel per field turns a two-minute form into a five-minute one.
Trade-offs
- Shows structure a field cannot: weekends, month boundaries, availability.
- Removes format ambiguity — nobody has to guess whether 03/04 is March or April.
- Constrains the value to a real date, so validation is mostly about range rather than parsing.
- Slow for dates the user already knows, and slower still for distant ones.
- One of the heaviest keyboard contracts around: a grid with its own arrow model plus month and year navigation.
- Locale-dependent in ways that break quietly — first day of the week, month names, right-to-left layouts.
Accessibility
What this pattern needs in order to work for everyone.
- Keyboard
- Typing must work. A field that only accepts calendar clicks is unusable for anyone fast, and hostile on a screen reader.
- Inside the calendar, arrows move by day and by week, PageUp and PageDown by month, Home and End to the ends of the week.
- The grid holds one tab stop: the focused day has `tabindex="0"`, the rest `-1`. Tab leaves the grid rather than walking 31 cells.
- Escape closes the calendar and returns focus to the field, leaving whatever was typed intact.
- Roles and state
- The calendar is a `grid` of `gridcell`s, one row per week, with the weekday names as column headers.
- Mark the chosen day with `aria-selected`, and unavailable days with `aria-disabled` — not by removing them, which breaks the grid's shape.
- Announce the month and year as the grid's name, and update it when navigation changes the month, or the user is moving through an unnamed grid.
- Say the format next to the field — “DD/MM/YYYY” — and accept more than one. Rejecting “15 Aug 2026” is a choice, not a requirement.
- Focus
- Opening the calendar moves focus to the selected day, or today when nothing is selected. Changing month keeps focus in the grid on the equivalent day, so the user is not thrown back to the field on every step.
In the wild
- GOV.UK date input — Three separate number fields and no calendar at all — for dates of birth, that is the right answer.
- Booking.com — Calendar first because availability is the point, with the month shape doing real work.