A booking calendar should work for someone who cannot or does not use a pointer. If a guest can read the property page but cannot select dates, the booking journey is incomplete regardless of how polished the calendar looks.
Treat keyboard operation as part of the interaction design from the beginning. Retrofitting it after a custom calendar has been built can expose assumptions that affect the entire component.
Start with the user's current position
When a guest opens the calendar, they need to know what the control is for, which date is selected and where keyboard focus has moved. Closing it should return them to a sensible place in the page.
A date-picker dialog involves both a dialog and a calendar grid. The W3C date-picker example illustrates the interaction pattern and warns that examples require testing before production use. Copying markup alone is not a substitute for testing the implemented component.
Use the pattern as a reference, then verify the behaviour with the technologies and devices the site needs to support.
Make restrictions understandable
A disabled date can mean several things: the property is occupied, arrival is not permitted that day or the selected stay length is invalid. A grey square does not explain which rule applies.
Provide useful text and preserve context when a choice cannot be accepted. If selecting an arrival changes the possible departure dates, make the relationship clear. Do not make the guest infer a minimum stay from a series of unexplained failed clicks.
For a hypothetical cottage with Friday arrivals, the interface should help the guest understand that restriction before they try every weekday. The underlying booking rules still need validating against the provider's current response.
Test more than opening and closing
Move through months using the keyboard, select a date, change the selection and exit without choosing. Check what happens at month and year boundaries. Confirm that the visible focus indicator remains easy to locate against the actual theme colours.
Test the full journey with a screen reader as well as keyboard-only navigation. A control can be focusable while its name, state or relationship to the selected dates remains unclear.
Also inspect touch targets and the narrow layout. A calendar that only fits comfortably in a desktop modal may need a different presentation on a phone, while keeping the same underlying meaning and validation.
Keep an alternative where it helps
Depending on the requirements, clearly labelled date inputs can provide another route into the same search. If the interface allows typing, explain the expected format and handle invalid values without discarding the rest of the search.
The alternative must connect to the same rules. A text input that accepts dates the calendar rejects creates a confusing discrepancy and may shift the error to checkout.
A useful acceptance script follows the guest from property page to dates, result and booking handoff without relying on a mouse. Record the browser and assistive technology used, along with any remaining limitations. Our SuperControl website work treats that complete journey as the feature, so accessibility is reviewed alongside live availability and the visual design.