Checkout Delivery Date Picker: The Calendar Keyboard Users Cannot Use

A delivery date picker is a calendar, and a calendar is a grid of buttons, which means it is a keyboard test that most checkouts fail. The picker opens, the shopper cannot move between dates with the arrow keys, cannot hear which date is selected, and cannot close it with Escape. They pick a date with the mouse or they leave, and on mobile the picker is a small grid that cannot be tapped without zooming.

A calendar is a keyboard test

A delivery date picker looks like a small thing, a calendar that pops up and lets the shopper pick a day. But a calendar is a grid of buttons, and a grid of buttons is a keyboard test that most checkouts fail. The picker opens, the shopper cannot move between dates with the arrow keys, cannot hear which date is selected, and cannot close it with Escape. They pick a date with the mouse or they leave, and on mobile the picker is a small grid that cannot be tapped without zooming.

Baymard's research puts delivery too slow as the second abandonment reason at 20 percent, after extra costs at 40 percent, and the date picker is the place where delivery speed is promised. A picker that cannot be used is a delivery promise that cannot be kept, and the shopper reads it as a store that does not want their order.

The pattern, in plain terms

The picker should open on Enter or Space, move between dates with the arrow keys, jump by week, and close with Escape, returning focus to the field that opened it. The selected date should be announced, and disabled dates should be marked as disabled, not just greyed out, because a greyed-out date that can still be selected is a trap. The picker should also announce the month and year as the shopper moves, so a screen reader user knows where they are in the calendar, not just which day is focused.

That is the whole pattern, and it is the same pattern as any grid control: real buttons, real names, real states, and focus that comes back where it started. The date picker that is built from divs with click handlers fails every one of those, and it fails them invisibly, because it looks finished on a screenshot.

Test it the way the shopper will hit it

Open the picker with a keyboard only, no mouse, and Tab into it. If you cannot reach a date, it fails. If you can reach a date but the arrow keys do nothing, it fails. If Escape does not close it and return focus to the field, it fails. That is the whole test, and it takes a minute per picker. Then do the same test on a phone, because more than 70 percent of e-commerce traffic is mobile and the picker is the control most likely to be too small to tap.

The mobile test is three things: the dates are big enough to tap without zooming, the picker does not cover the field it came from, and the selected date stays visible after the picker closes. If any of those fail, the picker is costing mobile orders, and the fix is a bigger grid, not a different calendar.

The delivery promise is the conversion lever

A date picker that works is a delivery promise the shopper can trust, and a delivery promise is the second-biggest conversion lever in the checkout after the price itself. Baymard's data says 20 percent of abandoners leave because delivery is too slow, and a picker that lets the shopper choose their day is the cheapest way to answer that. A picker that cannot be used is the opposite: it is a delivery promise that the store cannot keep, and the shopper knows it before they have typed their address.

Fix the picker before you add more delivery options, not after. The cheapest fix is to make the dates real buttons with real names, then to add the arrow-key movement, then to test it on a phone. Each of those is a small change, and together they are the difference between a delivery date the shopper can pick and one they cannot.

Frequently asked questions

How should a delivery date picker work with a keyboard?

The picker should open on Enter or Space, move between dates with the arrow keys, jump by week, and close with Escape, returning focus to the field that opened it. The selected date should be announced, and disabled dates should be marked as disabled, not just greyed out.

Why do so many date pickers fail keyboard testing?

Because it is a calendar, and a calendar is a grid of buttons that the developer often builds from divs with click handlers. Visually it is a complete control, and to a keyboard it is nothing. Test with Tab alone and the failure shows itself in ten seconds.

Is a date picker that only works with a mouse a WCAG failure?

Yes. A date picker that cannot be used with a keyboard is a control that cannot be operated by keyboard alone, which is a 2.1.1 failure. On a checkout that offers delivery dates, it is also a conversion failure, because the shopper who cannot pick a date cannot complete the order.

How do I test a delivery date picker on mobile?

Open the picker on a phone and check three things: the dates are big enough to tap without zooming, the picker does not cover the field it came from, and the selected date stays visible after the picker closes. If any of those fail, the picker is costing mobile orders.