The Date Picker That Only Works With a Mouse

The Situation

A regional outpatient provider runs a patient portal where people book, move and cancel appointments. Most patients use it on a phone or laptop. A meaningful share are older adults, people managing long-term conditions, and people who use a keyboard, switch device, voice control or screen reader to get around.

Booking is the most important task in the portal. If it fails, the patient calls the clinic, waits on hold, or skips the appointment.

The Challenge

The booking screen used a custom-built date picker. It looked polished: a monthly grid, available days highlighted, unavailable days grayed out. The team assumed it was accessible because it was built from a well-known component library and passed an automated scan.

But the reports coming in were consistent. A keyboard user could tab to the calendar and then could not move through the days. A screen reader user heard “button, button, button” with no dates. A voice control user could say “click 14” and nothing would happen. Someone using a switch device could get stuck in the grid.

What We Found

Our manual review surfaced a short list of recurring defects:

• Days were not real controls. Each date was a styled div with a click handler. It could not be reached or activated reliably with the keyboard (WCAG 2.1.1 Keyboard).
• Names and states were missing. Screen readers did not announce useful information for each day, so users could not tell which dates were available, unavailable, or selected (4.1.2 Name, Role, Value).
• Focus had no clear path. Arrow keys did nothing, so users had to tab through every day in the month. Focus was not moved into the grid when it opened and was not returned to the trigger when it closed (2.4.3 Focus Order).
• Availability was shown by color alone. Grayed-out days differed from available days primarily by shade (1.4.1 Use of Color).
• Month changes were silent. Moving to the next month updated the grid without telling screen reader users that anything had changed (4.1.3 Status Messages).
• There was no plain alternative. The only way to choose a date was the custom widget, so one broken component blocked the entire task.

How We Approached It

The first decision was whether the custom picker was worth keeping.

A native input type="date" is not perfect everywhere, but it inherits built-in keyboard and assistive technology support and provides a sound baseline. In this case, the team needed to keep the custom calendar, so we used the ARIA Authoring Practices Guide date picker dialog pattern as a reference for roles, keyboard behavior, and focus handling.

The remediation centered on a few things: using real buttons for days inside a grid with the correct roles, supporting arrow keys, Home, End, Page Up, and Page Down, moving focus in and out of the dialog predictably, adding non-color cues for unavailable days, announcing month changes politely, and offering a typed date field as a second route.

We then retested each fix with keyboard-only navigation, NVDA, VoiceOver, and voice control, and checked the date entry step as part of the complete booking journey rather than in isolation.

The Outcome

Following remediation, the healthcare provider saw measurable improvements in appointment booking accessibility, task completion, and patient independence.

In usability testing with 32 participants using keyboards, screen readers, voice control, and switch devices, successful appointment bookings increased from 56% to 91%. The median time required to complete the booking process dropped from 4 minutes 10 seconds to 2 minutes 35 seconds, representing a 38% reduction in completion time.

The improvements extended beyond usability testing. Over comparable six-week periods, accessibility-related booking support requests decreased by 29%, from 62 to 44 requests per 1,000 booking attempts.

Patients could now navigate available dates, understand selection states, and complete appointments without relying on mouse interactions or assistance from clinic staff.

For the healthcare provider, the changes resulted in a more inclusive digital booking experience, fewer accessibility-related support requests, and a smoother path from appointment selection to confirmation.

Next Step

If your scheduling flow depends on a custom calendar, a focused review of the date entry step and the booking journey around it is a good place to start. You can book a call with an accessibility expert, or read how we approached banking security flows as an accessibility barrier.