Can customers choose a booking date without using a mouse?

Define the booking task before choosing a calendar

A date picker is useful only if customers can complete the booking it supports. A clinic, repair shop or class organiser may ask for a day, a time slot, a branch and sometimes a service length. The calendar may show unavailable dates, public holidays or cut-off times. Write down what the customer must know before choosing: the booking time zone, the earliest bookable day, whether weekends are offered, and whether a chosen date is final or merely the start of a slot search. Those are product rules that need clear text. A visually polished month grid cannot explain an unstated business rule, and an accessible control cannot compensate for a wrong availability calculation.

W3C's WCAG keyboard criterion calls for functionality to be operable through a keyboard interface, subject to its stated exception for inherently path-dependent input. Its related technique asks authors to identify every function and then check that it can be used by keyboard. For a booking date, that means more than reaching the calendar icon with Tab. The customer must be able to open it, navigate dates, understand which date is focused and selected, choose or cancel, leave the control, and submit a valid booking. If one step needs a pointer, the task is still blocked. A mouse-only shortcut in the month grid is not saved by a keyboard-friendly submit button later.

Begin with the simplest input that fits the service. W3C's forms tutorial notes that HTML date input can provide browser-supported date handling and that older browsers may show a plain text field. Native controls often save a small team from maintaining a custom calendar's focus and keyboard behaviour, but their display and assistive-technology experience should still be tested in the browsers customers actually use. If the booking rules need a richer custom picker, keep a clear date-entry path where practical and specify exactly how it behaves. Choosing a component library is an implementation decision; the acceptance test is whether a customer can complete the real appointment task.

Make opening, movement and closing predictable

For a custom popup, the opening button needs a useful name such as 'Choose appointment date'. A visible date-format hint should be linked to the input so assistive technology can announce it. The W3C date-picker dialog example uses a date field, an opening button and a calendar inside a dialog. When a valid date is already present, opening the dialog focuses that date; otherwise its example focuses today. It provides keyboard movement within the grid, month and year controls, a way to select, and Escape to close. This is an illustrative pattern, not production code to copy blindly. W3C warns that support gaps remain in some browser and assistive-technology combinations, especially on mobile.

Tell users how to move without making them discover hidden commands by trial and error. In a grid pattern, arrow keys may move between days and Tab may move among the calendar's other controls; a short on-screen instruction makes that model understandable. Show a visible focus indicator on the active date, a separate selected-state cue, and text or another non-colour cue for unavailable days. A day that cannot be booked should not silently behave like an available day until the final submit. If the customer moves to a new month, announce the new month and year in a way a screen reader can detect. If the picker closes, return focus to a sensible location and confirm the selected date in text.

Keyboard exit matters as much as entry. A user should be able to cancel without changing the existing value, switch to another field, and return later to edit the date. Test opening the picker when the field is empty, when it contains a valid day, and when the typed text is invalid. If the grid opens on a surprising month after an invalid value, the customer may lose their place. Do not trap Tab inside a non-modal popup or let the background remain active behind a modal dialog in a confusing way. The precise focus pattern depends on the chosen component, but the observed task should remain understandable and reversible.

Connect availability and validation to the date

A date can be valid as a calendar date and still unavailable as an appointment. Keep those meanings separate. If a branch is closed on a Monday, mark the day unavailable before selection and explain the rule nearby. If availability depends on service type or staff, change the displayed options when those inputs change and state that the selected date may need review. Avoid silently clearing a previous date when a customer changes branch; say what changed and where the focus should go next. The server must validate the final booking against current availability, because another customer may take the last slot while the first customer is filling in the form.

W3C's forms guidance recommends clear required-field labels, accommodating reasonable input formats, and server-side validation as well as client-side feedback. For a Hong Kong booking, write the displayed format and time zone explicitly; do not assume that 03/04 means the same date to every customer. If typed entry is offered, consider how separators and leading zeros are handled, then normalise to an unambiguous stored date after validation. If a date is rejected, tell the customer whether the format is invalid, the day does not exist, or the service is unavailable. Preserve other answers so the customer can fix the one issue rather than start again. This is about date-specific recovery, distinct from general form error handling.

Consider an example: a customer chooses a repair visit for a Saturday in a Hong Kong branch. The calendar shows Saturday as available, but a weekday-only technician is selected on the next step. The form must either prevent that service combination before confirmation or explain the conflict and offer valid dates without erasing the customer's contact details. If a screen reader user returns to change the date, they need to hear the current selected day and the newly available choices. If the branch uses a cut-off time, state the time zone and show the rule before the customer tries an excluded day. No example date here is a promise of actual appointment capacity.

Test the full journey with real input methods

A useful acceptance session begins with the keyboard unplugged from the mouse or with the pointer deliberately unused. Start at the booking page and reach the date input with Tab. Open the picker, move to another week and month, choose a date, change it, cancel once, and complete the booking. Then repeat with a screen reader and a mobile device or external keyboard that your audience may use. Note the browser and assistive-technology combination tested; one successful combination does not prove universal support. W3C's example itself says it requires assistive-technology testing before production use. Ask the tester to narrate what they believe is focused and selected, rather than merely checking that keys cause movement.

Include awkward states in the test. Try a date near the end of a month, a year change, a day that has just become full, a closed branch, an invalid typed date and a booking that the server rejects because availability changed. Confirm that the error names the field, the customer can correct it, and their earlier answers remain. Check zoomed layout so the popup and its action buttons remain reachable. Verify that instructions and status are present in both the English and Traditional Chinese editions of the service. This is an editorial recommendation for a product acceptance checklist, not a claim that one test run certifies WCAG conformance.

An owner can make the next step concrete by asking the developer to demonstrate one ordinary booking and one failed booking with keyboard only, then showing how the selected date is announced and corrected. Save the scenarios as repeatable acceptance cases for future changes to availability rules or the calendar component. Decide who maintains branch closures and cut-off times, and who answers customers when no date works. Technology can offer the dates accurately and make them reachable, but the business must own the schedule behind them. A completed task is a booking that the customer understood and could correct before submission, not a calendar widget that merely appeared on the page.

A team also needs a decision when the calendar component cannot meet the acceptance test before launch. The immediate product choice may be to keep a labelled, validated date field available while postponing the custom popup, or to use a simpler native control and retest the complete flow. Record which browser and input methods the temporary approach was tested with, and keep the booking rules visible in text. Do not hide an unusable picker behind an alternative that is harder to discover. If the chosen date feeds pricing or a cancellation window, show those consequences before final confirmation and make the date easy to revise. A booking receipt should repeat the final date, time zone, branch and service so the customer can detect a mismatch. Support staff should have a clear procedure for correcting a mistake without asking the customer to repeat an inaccessible step. The calendar choice should serve the appointment, rather than dictate it.