The calendar opens, but a customer cannot reach next month with a keyboard. Or a date can be selected, but the available time quietly changes after the customer chooses a service. That is a booking failure even if the calendar looks finished in a design review. The acceptance test must cover date, time, service, and confirmation together.

First decide whether a calendar is needed

A customer choosing an available appointment often needs to see which dates have slots. Someone entering a known date, such as a date of birth, has a different task. The GOV.UK Design System's date-input guidance explicitly recommends separate date fields for a date users know or can look up, and cautions against that component when they are unlikely to know the exact date. Use the task to choose the control; do not force every date question into a month grid.

Two original studies explain why the task matters. A 2011 peer-reviewed experiment with 172 participants had people copy supplied dates into six types of controls; calendars avoided format errors but took longer and produced more wrong-date selections than some alternatives. The authors explicitly cautioned that repeatedly copying dates was unlike a real booking task. A 2026 US Census Bureau working paper with 1,000 participants tested near dates, sometimes requiring knowledge of the day of the week, and found a calendar more effective than text entry and faster than the other controls for most tasks. It did not test your availability rules or assistive-technology path. Taken together, the evidence supports choosing by the date-selection task and testing it in context, not declaring one control universally best.

For appointment selection, start with the simplest control that lets a person discover a valid slot. A short list of available dates may be easier than a custom calendar when capacity is sparse. If a calendar is justified, check the full keyboard path: open it, move between dates and months, choose a day, close it without choosing, and return focus to the control that opened it. The W3C date-picker example illustrates these interactions and how a selected date can be announced. W3C labels its code illustrative and warns that assistive-technology testing is still necessary before production use.

Treat unavailable dates as information

Do not display a visually muted date as if it were selectable, then reveal “no slots” at the next step. Explain whether a date is full, outside the booking window, or unavailable for the chosen service. If availability depends on location or staff, select those inputs before showing a grid that implies all dates are available. Keep the chosen service and location visible while the customer chooses a time.

Ask the booking provider what happens when another customer takes a slot during checkout. A safe flow should identify that the selected time is no longer available and let the person choose another slot without re-entering unrelated information. The exact reservation behavior depends on the platform; inspect it rather than assuming the front-end calendar guarantees a booking.

Write an acceptance test in customer language

Use an ordinary phone, a keyboard, and where possible a screen reader. Try a date in the next month, a fully booked day, a time near the end of business hours, and an interrupted session. Verify the confirmation repeats the service, date, local time and time zone, location or meeting link, and cancellation route. If customers can book from abroad, a visible time-zone label avoids asking them to infer which clock the slot uses.

This is distinct from sending visitors to the wrong service calendar: the customer may have reached the correct booking tool and still be unable to select or confirm a valid appointment. ARCHV's website service page says functions and QA belong in the agreed scope. Include the booking provider, accessibility test, availability rules, and confirmation behavior in a website estimate; complex booking integration needs a separate review.