Try this on your own site right now: click into a date-of-birth field, a check-in date, an appointment picker, anything with a little calendar icon next to it. Now unplug your mouse (or just don't touch it) and try to pick a date using only Tab, the arrow keys, and Enter.
If nothing opens. If the calendar pops up but your arrow keys scroll the page instead of moving between days. If you get in but can never Tab or Escape your way back out. Congratulations, you've found a date picker built from scratch by someone who never checked whether a documented, correct pattern already existed. It did. It still does. And it's a five-minute read that would have prevented all three of those bugs.
Date pickers are deceptively hard to build well, which is exactly why so many custom ones fail. A calendar grid is visually simple but interactionally dense — you need a text input, a toggle button, a popup dialog, a grid of days, month navigation, and a way to close the whole thing and land focus back where the user started. Get any one piece wrong and the whole widget becomes unusable without a mouse.
The Stat: The W3C WAI-ARIA Authoring Practices Guide publishes a documented "Date Picker Dialog" example: a text input plus a button that opens a dialog containing a calendar grid, where arrow keys move between days and Enter selects a date and closes the dialog, returning focus to the input. (Source: W3C WAI-ARIA Authoring Practices Guide)
Why this widget breaks so often
Most native <input type="date"> fields are actually fine — the browser handles focus, keyboard support, and announcement for you. The trouble starts the moment a team decides the native picker "looks ugly" or doesn't match the brand, and swaps it for a custom-built calendar dropdown made of <div>s. At that point, every single behavior the browser used to give you for free — tabbing in, arrow-key navigation, Enter to confirm, Escape to bail out, focus returning sensibly afterward — has to be rebuilt by hand in JavaScript. Nobody sets out to break it. It just quietly ships incomplete, because it looks correct to a sighted mouse user and nobody re-tests it with a keyboard alone.
This is squarely a WCAG SC 4.1.2 Name, Role, Value (Level A) problem. That success criterion requires every custom UI component — including a date picker — to have a programmatically determinable name, role, and state/value that assistive technology can read and update. A <div> styled to look like a calendar day has none of that by default. Screen readers don't know it's a grid, don't know which day is selected, and don't know that pressing an arrow key should move to the next cell instead of doing nothing.
The pattern you don't have to invent
The good news: nobody needs to design this interaction from scratch, and nobody should. the ARIA Authoring Practices Guide's Date Picker Dialog example documents the entire thing end to end — markup, roles, and exact keyboard behavior — for a text input paired with a button that opens a dialog containing a calendar grid.
The documented flow breaks down into four pieces:
- A text input where a user can type a date directly, for anyone who'd rather not touch the calendar at all.
- A button next to the input that opens the calendar as a dialog. It needs an accessible name like "Choose date" — an icon alone with no label is not a name.
- A calendar grid inside the dialog, marked up as an actual
gridwithgridcellroles for each day, where arrow keys move focus between days (left/right for adjacent days, up/down for the same weekday in the previous/next week), Page Up/Page Down move between months, and Home/End jump to the start/end of the week. - Enter or Space selects the focused date, closes the dialog, and returns focus to the text input — now populated with the chosen date — so the user isn't left stranded inside a dialog that no longer exists on screen.
That last step matters more than it looks. A dialog that closes without returning focus anywhere leaves a keyboard or screen reader user with focus reset to the top of the <body>, forcing them to tab all the way back through the page to figure out what happened.
The five-minute audit
Run this checklist against any custom date picker on your site before you assume it's fine:
- Tab reaches the date input and the "open calendar" button, in that order, with visible focus indicators on both.
- The open-calendar button has a real accessible name (not just an icon), announced by a screen reader as something like "Choose date, button."
- Opening the calendar moves focus into the grid, onto a day cell (today's date or the currently selected date, if any).
- Arrow keys move between days inside the grid; Page Up/Page Down move between months.
- Enter or Space selects the focused day, updates the input's value, and closes the dialog.
- Escape closes the dialog without selecting anything, and returns focus to the input.
- After closing (either way), focus lands back on the input or button — never lost to the top of the page.
If any row fails, that's your bug, and now you know exactly which piece of the documented pattern is missing.
| Failure you'll see | Likely missing piece |
|---|---|
| Calendar icon does nothing on Enter/Space | Button isn't a real, focusable <button> element |
| Arrow keys scroll the page instead of moving days | Grid cells aren't intercepting arrow key events |
| Screen reader says nothing when a day is focused | Missing role="gridcell" and accessible day labels |
| Focus vanishes after picking a date | No focus-return logic on dialog close |
Don't forget the typed-input path
Not everyone wants to use the calendar grid at all — plenty of keyboard users would rather just type 09/09/2026 directly into the input and move on, especially on a checkout or booking form where every extra click costs a conversion. That means your validation and error messaging on the text-input side of the widget matter just as much as the calendar itself. If a typed date gets rejected, the error needs to be announced, specific, and tied to the field — the same fundamentals covered in WebAIM's guide to form accessibility. A perfectly accessible calendar dialog attached to an input with silent, unlabeled validation errors is still a broken form.
If you're building this pattern from scratch rather than adapting the APG example directly, it's worth cross-referencing the underlying roles and states against MDN's documentation for accessible ARIA patterns as you wire up the grid, dialog, and live-region updates — small mismatches between the role you assign and the state you actually update are exactly where custom widgets like this quietly drift out of compliance over time.
Date pickers sit on some of the highest-stakes forms on a site — bookings, check-ins, date-of-birth fields on signup — which makes a broken one an unusually expensive place to lose a user. If you'd like a second pair of eyes on this and the other form widgets most teams never re-test by keyboard, a free scan will find broken form widgets on your own site in minutes.