Online appointment booking is the highest-stakes accessibility surface on a healthcare practice's public website. It's also among the most-cited surfaces in ADA Title III complaints against healthcare organizations.

This is a focused checklist for verifying that your appointment booking flow meets WCAG 2.1 AA, organized by what plaintiff firms most often cite.

Why appointment booking specifically

Three reasons:

  1. It's a primary task. Patients trying to book appointments who can't are denied service in a meaningful sense — that's the kind of issue that produces both complaints and bad outcomes.
  2. It's complex. Date pickers, dropdowns, conditional fields, multi-step flows. Each component is a potential failure.
  3. It's frequently third-party. Many practices use Zocdoc, NexHealth, Solv, or EHR-integrated booking widgets. The vendor's accessibility posture becomes yours.

Labels and instructions

Every input must have a programmatically associated label. Placeholder-only patterns fail.

  • [ ] Patient name fields have explicit labels (<label for="patient-name">Patient name</label>)
  • [ ] Date of birth field has a clear group label (use <fieldset> + <legend>)
  • [ ] Phone number field labeled (and format expectation stated, e.g., "(XXX) XXX-XXXX")
  • [ ] Insurance section has clear group labeling
  • [ ] Reason-for-visit field has label and is described as optional/required appropriately
  • [ ] Symptom checker (if present) has accessible structure

The date and time picker

Date and time pickers are the single most common accessibility failure on appointment booking. Most third-party pickers are inaccessible by default.

  • [ ] Picker is keyboard-operable (arrow keys to navigate, Enter to select)
  • [ ] Picker has a manual text-entry fallback
  • [ ] Available vs. unavailable times are programmatically distinguishable (not just visually grayed)
  • [ ] Selected date/time is announced to screen readers
  • [ ] Day-of-week and time-zone are explicit (not relying on visual layout)
  • [ ] Closing the picker doesn't lose focus

If your picker fails any of these, replace it. Modern accessible date-picker libraries exist (react-day-picker, react-aria, Adobe Spectrum). There's no good reason to use an inaccessible one.

Provider selection

Selecting which provider to see is often a complex multi-faceted UI:

  • [ ] If a list, list items have clear labels with provider name + specialty
  • [ ] If a dropdown, dropdown is keyboard-operable
  • [ ] Provider photos have meaningful alt text or are marked decorative
  • [ ] "Filter by specialty" controls are properly labeled
  • [ ] "No results" state announces to screen readers

Insurance and payer information

Insurance entry is often a complex pattern with conditional fields:

  • [ ] Insurance carrier dropdown is keyboard-operable and searchable
  • [ ] When "self-pay" is selected, payment-method fields appear with announcement
  • [ ] Member ID format requirements are stated (often varies by carrier)
  • [ ] "Don't see your insurance?" alternative is keyboard-accessible

Multi-step flow

If booking spans multiple pages or steps:

  • [ ] Each step has a unique <title> and <h1>
  • [ ] Progress indicator is programmatically perceivable
  • [ ] Browser back/forward works correctly
  • [ ] Saving progress is possible or clearly stated as not possible
  • [ ] On submit error, focus moves to the error summary
  • [ ] Final confirmation is announced and includes appointment details

Conditional logic

Many booking flows show fields conditionally (e.g., "if new patient, show registration fields"):

  • [ ] When fields appear/disappear, the change is announced
  • [ ] New fields receive proper focus management (focus moves to the new section, not nowhere)
  • [ ] Hidden fields are not in the tab order
  • [ ] Conditional logic doesn't break browser back behavior

Confirmation and reminders

After booking:

  • [ ] Confirmation page or email is accessible
  • [ ] Time, date, location, and provider are explicit (not just embedded in an image)
  • [ ] Add-to-calendar links work with assistive technology
  • [ ] Reminder texts/emails are accessible

Multilingual handling

For practices serving multilingual populations:

  • [ ] Page lang attribute is set
  • [ ] If multilingual support is offered, the language switcher is keyboard-accessible
  • [ ] Language switcher labels are in the user's current language (not the destination language)
  • [ ] Form field labels translate appropriately
  • [ ] Error messages translate appropriately

Testing your flow yourself, in 15 minutes

  1. Keyboard-only test: open your appointment booking flow. Use only Tab, Shift+Tab, Enter, Escape, and arrow keys. Note every place focus disappears, every place you can't tell what field you're on, every interaction that requires a mouse.
  2. Screen reader test: turn on VoiceOver (Mac), NVDA (Windows), or TalkBack (Android). Try to book an appointment. Note every place announcement is wrong, missing, or confusing.
  3. Mobile test: do the same on a phone. Mobile screen readers often expose issues desktop doesn't.

If your booking has more than 5 issues across these tests, you have remediation work — and meaningful exposure.

What to do about third-party widgets

If your booking widget is third-party (Zocdoc, NexHealth, Solv, EHR-integrated):

  1. Request the vendor's VPAT (Voluntary Product Accessibility Template). Reputable vendors publish these.
  2. Test the embedded experience anyway — vendor VPATs document the standalone product, not your specific embed.
  3. File issues with the vendor for any failures you find. Document the requests.
  4. Have a fallback path — a phone number prominently displayed for users who can't complete the digital booking. This is good practice regardless of vendor accessibility.

How does our scanner help here?

Our healthcare vertical scanner audits the public booking landing page and the form structure. We don't navigate multi-step flows or test interactive states (like opening date pickers) — those require manual testing. But we surface the labels, contrast, focus, and structural issues in the static markup, which catches a meaningful share of failures.

What does the typical complaint cite?

Common patterns from public ADA complaints against healthcare practices:

  • Date picker fully inaccessible to keyboard.
  • Insurance dropdown that requires mouse-only interaction.
  • "New patient" toggle that hides/reveals fields without screen reader announcement.
  • Confirmation page that displays appointment details only as an image.
  • Booking flow that loses focus when transitioning between steps.

Each is mechanically detectable; each is fixable.

What's the realistic budget for remediation?

For a typical practice with a third-party booking widget plus surrounding marketing pages:

  • Surrounding pages remediation (your CMS): 1–3 dev days.
  • Widget vendor pressure: ~6 months to materially improve, requires sustained engagement.
  • Fallback path setup (visible phone number, contact form): a few hours.
  • Continuous monitoring: $15–$99/month.

The fallback path is the highest-leverage near-term move while you work on the widget itself.

Run a free scan of your appointment-booking page →