Test your booking widget with only a keyboard and with a screen reader. Send what fails to the provider, and put another way to book, a phone number and a short form, above the widget.

A calendar nobody tried without a mouse

The booking page shows a calendar supplied by a scheduling company and embedded with a few lines of code: available dates in green, a column of time slots, a confirm button.

With a mouse it works well. Without one, many widgets fail: the Tab key skips the dates, gets stuck inside the calendar, or loses its place once a date is chosen.

With a screen reader, the dates may be read as a run of numbers with no sign of which are available, or not read at all.

The business rarely finds out. The people who cannot use the calendar cannot use it to say so.

Who meets the problem

The first group is larger than most owners expect, and for some businesses it overlaps heavily with their customers: home care, mobility equipment, anything booked after an injury or a diagnosis.

Why widgets fail

Most failures share one cause. Dates and time slots are built as plain boxes that respond to a click, not as buttons or links, so the keyboard skips them and screen readers do not announce them as controls.

Other failures follow. Availability shown only by colour. Pop-ups that open without moving the keyboard focus into them. A slot held for a few minutes, then silently released. Error messages that appear on screen but are never announced.

The widget usually sits in a frame loaded from the provider's server, so neither you nor your web company can change the code inside it.

What the guidelines expect

WCAG 2.0, the guidelines behind most accessibility rules, sets out the basics at Level A.

Everything works from a keyboard, focus never gets trapped, controls have names a screen reader can announce, colour is never the only signal, and time limits can be extended. Level AA adds that keyboard focus must be visible.

WCAG judges the whole page, widget included, and so do visitors. Ontario's rule for organisations with fifty or more employees there covers web applications controlled through a contract that allows changes.

Testing it yourself

Put the mouse aside. From the top of the booking page, press Tab and try to book a test appointment, from choosing a date to confirming.

At each step, check that you can see where you are, that Shift and Tab move you back, and that Escape closes any pop-up.

Then try a screen reader: VoiceOver is built into every iPhone and Mac, and NVDA is free for Windows. Listen for each date's day and month, and for which dates are available.

Write down each place it fails, with the steps that led there. Specific notes get answers from a provider; a general complaint does not.

Asking the provider

Send your notes to the booking company. Ask whether the widget has been tested against WCAG 2.0 AA, and whether there is a published conformance report, sometimes called a VPAT.

Ask whether your failures are already known and scheduled for a fix, and whether a more accessible version exists, such as a standalone booking page.

Some providers answer well and fix quickly. Others have no plans. Either way, the answer tells you how long you will need another way to book.

A worked example

A company that installs stairlifts and home elevators offers a free in-home assessment, booked through a scheduling widget on its contact page. Many of its customers are older, and some book after a fall or a new diagnosis.

The office manager noticed a pattern: many phone bookings began with the caller saying the website had not worked.

Tested with the Tab key, the calendar could be reached, but not a single date inside it. With VoiceOver on, the dates were read as a string of numbers, with availability shown only in green.

The provider confirmed the problem and said a more accessible calendar was planned, without giving a date.

Within a week, a line above the widget offered the phone number and a four-field request form, both answered the same day, and the frame was given a title that screen readers announce.

The widget is now tested again after each provider update, and accessibility is on the list of questions before the booking contract renews next spring.

Another way to book, above the widget

Put the alternative before the widget, not after it. A keyboard user stuck inside the calendar may never reach anything below it, and a screen reader user hears the page in order.

One line is enough: prefer not to use the calendar, call this number or send this short form and we will book a time with you.

The alternative has to be equal: the same availability, no extra charge and a quick reply. Its form needs proper labels and a working keyboard path, or the problem simply moves.

What you control on your side

The page around the widget is yours, and several fixes live there.

Give the frame a title, such as booking calendar, so screen readers announce what it is. Add a heading and a sentence explaining how booking works and how long it takes.

If the provider offers a standalone booking page that tests better than the embedded version, link to it as well. And check that the confirmation email gives the date and time in words, readable as plain text.

The counter-case

A business that books almost entirely by phone, with the widget as an extra, has less at stake, provided the phone number is prominent above it.

Some widgets already pass a basic keyboard test and need only small fixes on the page around them, and some providers are improving theirs this year.

But a booking calendar is often the most important control on a service business's site. Test it without a mouse, ask the provider, and put another way to book above it.

The test

  1. Put the mouse away and book a test appointment.
  2. Note where the keyboard gets stuck.
  3. Repeat it with a screen reader on.
  4. Send your notes to the provider.
  5. Add another way to book above the widget.
  6. Give the frame a descriptive title.
  7. Test again after every widget update.

Step five is the one fully in your control, and it works today: whatever the provider decides, nobody is turned away by the calendar.

The same principle, a second way in that does not depend on one embedded tool, runs through a map without the address in words.


Frequently asked questions

Why do booking widgets fail keyboard users?

Dates and time slots are often built as plain clickable boxes rather than buttons, so the keyboard skips them and screen readers do not announce them as controls.

How can I test our booking widget?

Put the mouse aside and book a test appointment with the Tab key, then try again with VoiceOver on an iPhone or Mac, or NVDA on Windows.

Can my web company fix the widget?

Usually not the widget itself, which runs from the provider's server. It can fix the page around it, add a title to the frame, and set up an alternative.

What should I ask the booking provider?

Whether the widget has been tested against WCAG 2.0 AA, whether a conformance report exists, whether your failures are known, and when they will be fixed.

Where should the alternative way to book go?

Above the widget. A keyboard user stuck inside the calendar may never reach anything below it, and screen reader users hear the page in order.

Does the alternative need to match online booking?

Yes: the same availability, no extra charge, and an equally quick reply. Its own form needs labels and a working keyboard path, or the problem simply moves.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Booking calendar never tried without a mouse?

Send us the booking page. We will test it with a keyboard and a screen reader and tell you what fails.

Start a Conversation