A booking form is one of the least forgiving interfaces on a website. It combines a date picker, a set of time options, several text fields and a payment step, and each of those is a well-known accessibility trap. If any one of them fails, the whole transaction fails, because there is no partial booking.
This is worth treating as engineering work rather than a compliance box. A booking page that cannot be operated by keyboard is a page that a portion of your potential clients cannot use at all, and unlike most usability problems they will not tell you. They will book somewhere else.
Below is what to check, in the order things usually break: the date picker, the time slots, colour, target size, errors and timing. It pairs closely with the mobile booking experience, since many of the same fixes help everybody using a phone in bright sunlight.
Keyboard Navigation Through A Date Picker
Date pickers are the single most common failure point. A calendar grid built from clickable elements that are not real buttons cannot be reached by keyboard at all: pressing Tab skips straight past the whole month.
What a keyboard user needs from a date picker:
- Tab reaches it, and Tab moves past it without trapping focus inside.
- Arrow keys move between dates, left and right by a day, up and down by a week, which is what people expect from a grid.
- Page Up and Page Down change month, or at minimum the previous and next month controls are themselves reachable and clearly labelled.
- Enter or Space selects, and Escape closes an overlay picker and returns focus to the field that opened it.
- Focus is visible. The currently focused date must have an outline that survives whatever the site stylesheet does to focus rings. Removing focus outlines to make a design look tidier is the most common self-inflicted accessibility bug on the web.
- Unavailable dates announce why. A date that is simply not clickable leaves the user pressing keys with no feedback. It should be marked as disabled so assistive technology can say so.
A plain text date field alongside the calendar is an inelegant fallback that works.
Screen Reader Labelling Of Time Slots
A grid of buttons reading "9:00", "9:30", "10:00" makes sense visually because the heading above it says which day it is. Read aloud in isolation, it is a list of numbers with no context, and the user cannot tell which day they are choosing, whether a slot is taken, or what timezone anything is in.
Fixes that cost very little:
- Give each slot an accessible name carrying the full context, for example "Tuesday 14 October, 9:30 in the morning, available", rather than relying on nearby text.
- Mark unavailable slots as disabled or remove them entirely. Showing a greyed-out slot with no programmatic state tells a sighted user something and tells a screen reader user nothing.
- State the timezone in text near the slots, not only in a subtle line at the bottom of the page. This matters for everybody, and there is more on the underlying problem in timezone handling in scheduling.
- Announce the change when someone picks a new date and the slot list reloads. If the page updates silently, a screen reader user does not know new content has appeared.
- Group the slots under a real heading naming the selected date, so the structure is navigable rather than a flat pile of buttons.
Colour Contrast, And Never Colour Alone
Booking pages lean on colour more than most interfaces: available in one colour, booked in another, selected in a third. For anyone with a colour vision deficiency, or anyone looking at a phone outdoors, that distinction may not exist.
Two rules apply. First, text and interface elements need enough contrast to be read, including the pale grey used for unavailable slots, usually the worst offender on the page. Second, colour must never be the only signal:
- Available slots as outlined buttons, unavailable ones with the time struck through or replaced with the word "booked".
- The selected slot marked with a tick or a filled state as well as a colour change.
- Errors marked with an icon and a text message, not a red border on its own.
- Required fields marked in words rather than by a coloured asterisk alone.
Check contrast with a tool rather than by eye. Designers have good monitors and good lighting, and neither is typical.
Touch Targets Big Enough To Hit
Time slots tend to be small, because there are a lot of them and they must fit on a screen. Small targets are hard for anyone with a tremor, anyone using a phone on a moving train, and anyone with larger fingers than the designer.
Give each slot a generous tappable area with spacing between adjacent slots, and never rely on a hover state to reveal what a control does, since hover does not exist on touch. If slots cannot fit at a usable size, show fewer of them: a morning and afternoon split beats a dense grid nobody can hit accurately.
Error Messages Tied To The Field That Caused Them
The classic failure is a red banner at the top saying "Please correct the errors below" while the actual problem is an unmarked field three screens down. That is annoying for everybody and close to unusable with a screen reader.
What a good error does:
- Appears next to its field, and is programmatically associated with it so it is read out when the field receives focus.
- Says what is wrong and what to do. "Enter a phone number including the area code" is useful. "Invalid input" is not.
- Moves focus to the first field with a problem when the form is submitted, so the user is taken to the work rather than told to go looking.
- Preserves everything already typed. Clearing a form on a validation error is the fastest way to lose a booking.
- Is announced when it appears, for errors that show up as the user types rather than on submission.
Be careful with over-strict validation too. Phone number and postcode fields that reject legitimate formats are an accessibility problem in practice, since the user has no way of knowing what shape you wanted.
Do Not Put A Time Limit On A Booking
Many booking systems hold a slot for a few minutes and then release it. The intent is sensible, since two people should not book the same time. The implementation often is not: a countdown that expires while someone is finding their card, or looking up a reference, or using a screen reader to work through the form at a different pace.
If you need to hold slots, be generous with the window, warn before it expires, and offer a way to extend it. Never expire the session silently and never discard the entered details when it happens. Someone who has to start the whole form again will usually not.
Common Barriers And Their Fixes
| Barrier | Who It Affects | Fix |
|---|---|---|
| Date grid not reachable by Tab | Keyboard and screen reader users | Real buttons, arrow key navigation, visible focus |
| Focus outline removed by CSS | Anyone not using a mouse | Keep a visible focus style everywhere |
| Time slots labelled only "9:30" | Screen reader users | Full accessible name including day and status |
| Availability shown by colour alone | Colour vision deficiency, bright sunlight | Add text, strike-through or icons |
| Low contrast grey for unavailable | Low vision, older screens | Meet contrast requirements or use text |
| Tiny slot buttons packed together | Motor impairment, large fingers, movement | Larger targets and spacing between them |
| Generic error banner at the top | Screen reader users, everybody | Field-level messages, focus moved to the first one |
| Slot hold expires silently | Anyone working slowly, for any reason | Longer hold, warning, option to extend |
| Placeholder text used instead of a label | Screen reader users, anyone who forgets | Visible persistent labels on every field |
| Timezone shown only in small print | Everyone booking across regions | State it near the slots in plain text |
WCAG And Where Obligations Come From
When a client, an employer or a procurement team asks whether your booking page is accessible, they are usually referring to the Web Content Accessibility Guidelines, known as WCAG. It is the standard most public sector and enterprise requirements point at, and it is organised into levels, with the middle level being the one most commonly named in contracts.
Two honest caveats. First, no software vendor can hand you conformance for your whole page, because accessibility depends on the surrounding site, your own content, your colour choices and your field labels as much as on any embedded component. Treat any blanket conformance claim, from anyone, with scepticism, and test your own page as it is deployed. Second, whether you have a legal obligation, and which one, depends on your jurisdiction, your sector and your contracts, and those rules differ significantly between countries. This article is general operational guidance and not legal advice, so take the compliance question to your own adviser.
A Test Pass You Can Run In Twenty Minutes
You do not need a specialist to catch the majority of these problems. Set aside twenty minutes and do this on your live booking page:
- Put the mouse away. Complete a booking end to end using only Tab, arrow keys, Space and Enter. Note every point where you get stuck or cannot see where you are.
- Zoom the browser to two hundred percent. Check nothing overlaps and nothing scrolls sideways.
- Turn on the screen reader already installed on your machine and listen to the time slots. If you cannot tell which day you are on, neither can anyone else.
- Submit the form with fields deliberately wrong and see whether the errors tell you what to fix.
- Run an automated checker for contrast and missing labels. It will not catch everything, and it catches enough to be worth the two minutes.
- Do all of it on a phone as well as a desktop.
Fix what you find, then repeat the pass after any redesign. Accessibility regressions arrive through style changes far more often than through feature work.
Building On Something That Already Handles The Hard Parts
The hardest pieces to get right, the keyboard-navigable date picker and the labelled time slots, are the ones you inherit rather than build when you use a hosted booking page. That does not remove your responsibility for the surrounding page, your colours or your own content, but those two components are not yours to maintain.
appntmnts.io booking pages ship with a keyboard-operable picker, labelled slots, visible field labels and field-level errors, and the intake questions you add are your own to word well, which is covered in intake form design. The features page outlines what the hosted page includes before you customise it.