For a dental clinic, a hair salon or a restaurant, the booking form may be the only form on the site that people truly need. Everything else is reading. When that form fails, a customer who uses a keyboard or a screen reader is pushed onto the phone, which may be just as hard for them, or gives up and books somewhere else.
An accessible booking form is not a special version for disabled visitors. It is one form that works whether someone clicks, taps, tabs or listens. Appointment booking accessibility usually breaks in the same few places: the calendar, the time slots, the move between steps, and the confirmation at the end. Here is how to check each one.
Why booking forms break more often than contact forms
A contact form is a handful of text fields and a button. A booking flow is a small application. It loads availability, hides and shows options, changes as you pick a service or a staff member, and often spreads across several steps. Each change on screen needs to be passed on to a screen reader as well, and that hand-off is exactly where booking plugins and custom builds tend to cut corners.
In plain words, the failures sound like this:
- “I could not pick a date with the keyboard.”
- “It said nothing when the times loaded.”
- “I pressed Next and did not know where I was.”
- “I am not sure if my booking went through.”
Date pickers
The calendar is usually the hardest part to get right. A good one lets someone move between days with the arrow keys, move between months with clear buttons, and choose a date with Enter or Space. Each day should be announced with the full date and whether it is available, for example “Tuesday, March 4, available”, not just “4”.
Signs of trouble:
- Days are drawn as plain table cells or images that only respond to a mouse click.
- Pressing Tab skips the calendar entirely or moves through every single day one by one with no arrow key support.
- Booked days are shown only in a different color.
- Month arrows are icons with no name, read as “button”.
The simplest safe pattern is a labeled text field where people can type the date, with a hint showing the format (“MM/DD/YYYY”), and an optional calendar button beside it. If you keep the calendar only, test it thoroughly. WCAG 2.1.1 Keyboard expects every part of it to work without a mouse.
Clinics booking older patients should also check zoom. At 200 percent, a calendar that opens as a floating panel often runs off the side of the screen.
Time slots and service choices
After a date, most flows show a grid of times. These should behave like a set of choices:
- Each slot is a real button or radio option, reachable with Tab or the arrow keys.
- Its name includes the full time with AM or PM, not a fragment like “10:30”.
- Taken slots are either removed or marked “unavailable” in text.
- The chosen slot is shown with a border, check mark or text, not color alone, and is announced as selected.
- The slots have a heading or group label such as “Available times for Tuesday, March 4”, so a screen reader user knows what the list is.
When the times load after the date is chosen, a short status message such as “8 times available” tells screen reader users that something changed (WCAG 4.1.3 Status Messages). If no times are free, say so plainly and suggest the next open day.
Service and staff choices work the same way. A row of photo cards for each stylist or doctor needs a name on each card, and the card should be a single control, not an image with a tiny “Select” link under it.
Multi-step booking flows
Many booking forms split into steps: service, date and time, your details, review. Steps are fine. They just need to keep people oriented.
Show where people are
A step indicator like “Step 2 of 4: Date and time” in real text helps everyone. A row of numbered circles with only the current one colored helps nobody using a screen reader.
Move focus on purpose
When someone presses Next, keyboard focus should land at the top of the new step, usually its heading. If focus stays on a button that no longer exists, screen readers may jump back to the top of the page, and the user has to find their place again.
Let people go back without losing data
A Back button that clears what they typed is frustrating for everyone and worse for someone who types slowly. WCAG 3.3.7 Redundant Entry, new in 2.2, asks that information already entered in the same process is filled in again or available to select, rather than typed twice.
Watch for timeouts
Some systems hold a slot for a few minutes and then release it. If yours does, say so before the timer starts, and warn people before it runs out with a way to ask for more time. Silent timeouts hit people who use assistive technology hardest, because each step takes them longer.
If you are building a flow with several steps on WordPress, our guide to a multi-step form in WordPress covers the setup side.
The details step
This is a normal form, so the usual rules apply: visible labels, clear required markers, correct input types, and autocomplete for name, email and phone so browsers can fill them. When something is wrong, the message should name the field and say how to fix it. Our post on accessible error messages covers that part in depth, and the wider form fixes live on our accessible web forms page.
For clinics, keep health questions short and plainly worded. Long intake questionnaires are usually better as a separate step, or a separate form after the booking is made.
Confirmation: the part people forget to test
A booking is only done when the customer knows it is done. After the final button:
- Show a confirmation heading and move focus to it, so a screen reader reads it right away.
- Repeat the key details in text: service, date, time, location, and how to cancel or change.
- Avoid a confirmation that is only a green check icon or a brief message that fades after a few seconds.
- Make sure the confirmation email has the same details in real text, not only in an image or a calendar attachment.
Restaurants often send people to a third-party reservation widget. That widget is still part of your site in the customer’s eyes. Test it the same way, and if it fails, tell the vendor exactly what broke.
Checking your accessible booking form in twenty minutes
- Book a real test appointment using only the keyboard, from the service choice to the confirmation.
- Do the same booking again while a screen reader talks you through it. The free NVDA works on a Windows PC; Apple devices have VoiceOver built in. Note anything that changes without being spoken.
- Zoom to 200 percent and repeat the date and time steps on a laptop. Then try it on a phone.
- Leave a required field empty and check the error message.
- Cancel the test booking and check that the cancel link works the same way.
Keep a note of what you found. An accessible booking form depends on the plugin as much as on your settings, so if you use a booking plugin, much of what you find will be in the plugin itself, so the note becomes your report to its developer. If you are planning a new system, our booking website development page covers the build side, and if you also sell online, booking is one step in the wider path covered by our online shopping accessibility guide. Site-wide audits, fixes and ongoing checks are described on the page for our website accessibility services.
Frequently asked questions
Should a booking form use a calendar or a plain date field?
Either can work. A calendar widget is fine if it can be operated fully with a keyboard and announces dates clearly. Many sites also let people type the date into a labeled field, which is often the easiest option for screen reader and voice control users. Offering both is a sensible choice when the widget is not well built.
What makes time slot buttons accessible?
Each slot should be a real button or radio option that can be reached by keyboard and is announced with its full time, such as 10:30 AM. Unavailable slots should say so in text, not only by graying out. The selected slot should look different in more than color and be announced as selected.
Is a phone number enough as an alternative to online booking?
A visible phone number or email is a helpful fallback and worth keeping, but it does not replace a booking form that works. Some people cannot use the phone easily, including many deaf and hard of hearing customers. Aim for an online form that works, and keep the other contact options as backup.
Do booking plugins on WordPress handle accessibility for me?
Some booking plugins pay attention to accessibility and some do not, and the result also depends on your theme and settings. Test the plugin’s front-end form on your own site with a keyboard and a screen reader before relying on it, and check again after plugin updates.
Some businesses take bookings and payments through WooCommerce, with booking extensions adding the calendar to product pages. If that is how your site works, our WooCommerce accessibility page explains how we test and fix those flows along with the rest of the store.
Next in this series: WordPress Contact Form Accessibility: What to Check
