Booking Flow Audit: Date Pickers Are Where Bookings Die

What We Keep Finding

Start with the reason date pickers vary so wildly. W3C publishes 30 reference patterns for the components everyone builds, and a date picker is not one of them. Neither is a toast, which is how half of these flows confirm. So every team that has ever built a calendar has invented one, and the results are exactly what you would expect from a component with no canonical answer. Calendars that only respond to clicks. Days that announce as bare numbers with no month attached. Time slots rendered as unlabeled buttons in a grid.

Two beliefs about the greyed-out dates are worth correcting before your developer spends a week on them. A switched-off control has no contrast requirement at all, so a faint unavailable date was never a contrast failure. And removing a fully-booked date from the keyboard order entirely is worse than leaving it reachable and marked unavailable. Take it out of the tab order and a screen reader user has no way to tell a booked date from a date that does not exist.

Then the end of the journey quietly finishes the job. A summary the screen reader cannot parse, and a success message nobody hears. Whether that last one is even a rule depends on how your flow ends, which is worth knowing. A booking that lands on a separate confirmation page is outside the announcement rule, because the page change carries the news. A booking that confirms in place needs a live region, and needs it in the page before the message arrives.

And the half everyone forgets carries its own Level AA rule. Cancelling a booking deletes data the customer controls, and where a deposit is involved it is a financial transaction, so the standard wants it reversible, checked, or confirmed before it goes through. Rescheduling is the same. That is not a nice-to-have and it is almost never tested.