Date Pickers
Last updated:
Practical patterns for date entry with keyboard support, manual fallback, and sensible mobile behaviour.
01 — Foundation
Date entry should feel easy
Handled badly, date pickers become one of frontend’s most consistent accessibility disasters.
Date pickers help users enter dates accurately. They should never feel like operating booking software from 2004 — mouse-only grids, tiny targets, and mystery formats create errors and support tickets.
02 — Fallback
Always offer a simple fallback
Users should always have a straightforward way to enter a date without wrestling a calendar widget.
- manual text entry with a clear format hint — “DD/MM/YYYY” or locale-appropriate pattern
-
native
input type="date"where support and design allow — often better on mobile - custom calendars as enhancement, not the only path
- visible labels — see Accessible Forms; placeholder is not a label
<label for="start-date">Start date</label>
<input id="start-date" name="start_date" type="date" />03 — Interaction
Keyboard, touch, and navigation
Predictable navigation beats decorative calendar chrome.
- full keyboard support — arrow keys, Enter, Escape, Tab order that makes sense
- large enough targets on touch; avoid tiny day cells
- visible focus on the active day and control buttons
- constrain min/max dates when the business rules require it — explain why in help text
04 — Avoid
What to avoid
Custom widgets that look pretty in demos and fail in production.
- mouse-only interaction and inaccessible custom widgets
- impossible mobile behaviour — test on real devices, not only desktop Chrome
- locale surprises — 01/02/2026 means different things in different regions
05 — Review
Before you approve
A short checklist for date pickers in code review.
- labelled input with manual entry or native date support
- keyboard, screen reader, and touch paths all work
- custom calendar is optional enhancement, not a trap