Is Your Booking Widget Accessible? Five Checks You Can Run Without a Developer

If you run a service business — a tutoring center, an auto repair shop, a therapist’s office, a wedding photographer, a salon, a dental practice, a tax preparer — there is a good chance the page on your website that gets the most use is the one with your booking widget on it. It is also likely to be the least accessible thing you have shipped, and you almost certainly did not write a line of it.

We want to be straight about what we do and do not know here. We have not reviewed a corpus of demand letters, and we are not going to tell you the booking widget is the most-cited failure point in ADA complaints — we have not seen data that establishes that, and neither, as far as we can tell, has anyone who says it. What we can show you is structural and checkable in ten minutes: the interaction pattern these widgets use is one of the hardest to get right, most of the popular ones get it wrong in the same specific ways, and the failures land on your domain rather than the vendor’s. That is enough reason to look.

This article explains, in plain English, why booking widgets fail accessibility audits so reliably, what a passing one actually looks like, and what you can do about it without becoming a developer.

Why Booking Widgets Fail So Often

The popular booking platforms — Calendly, Acuity Scheduling, SimplyBook.me, Setmore, vCita, Square Appointments, Bookeo, BookSteam, MindBody, JaneApp, Cliniko, Chiro8000, ClassPass for studios — were not built with accessibility as a foundational requirement. Most of them were built around 2014–2018 by small teams optimizing for one thing: the conversion rate of a person with a mouse on a desktop computer.

That trade-off shows up in three places.

First, the date picker. The little calendar grid where you choose the day of your appointment is built almost universally as a mouse-driven component. You hover over a date, click it, and the time slots appear. If you can’t use a mouse — because you have a tremor, because you have low vision, because you use a screen reader, because you’re on a phone — the calendar grid is often a wall. Tab might land you somewhere random. Arrow keys might not move between dates. The “next month” button might not have a label that any assistive technology can understand.

Second, the time slots. After you pick a date, you see a row or grid of available times. Critical detail: in most widgets, time-slot status is conveyed entirely through color. Available slots are blue. Unavailable slots are gray. There is no text label, no icon, nothing programmatic. A blind user listening to the page through a screen reader hears “9:00 AM, button. 9:30 AM, button. 10:00 AM, button.” All the slots sound identical. They have no way to know which ones are actually available without trying every single one and getting an error.

Third, the form itself. Once you’ve picked a time, you fill in your name, email, phone, and any service-specific details. Booking widgets are notorious for using placeholder text instead of labels. The greyed-out “Your name” text inside the input box looks like a label, but it disappears the moment you start typing, and screen readers don’t always announce it. So a screen reader user who tabs into the form hears nothing — they have no idea what they’re supposed to type into that empty box.

What “Color Alone” Means, and Why It Fails a Booking Flow Specifically

WCAG 2.1 Success Criterion 1.4.1, “Use of Color,” is short. The text is two sentences: color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

The reason this single criterion shows up so often in booking-widget complaints is that color-only status is genuinely unfixable from outside the widget. You can’t write CSS that adds a screen-reader-readable label to a third-party iframe. Either the vendor exposes proper text and ARIA, or they don’t. And many of them don’t.

A widget that conveys availability with color alone fails 1.4.1. It also typically fails 4.1.2 (“Name, Role, Value”) because the buttons don’t expose their availability state programmatically. It often fails 2.1.1 (“Keyboard”) because you can’t get to the buttons with a keyboard at all. So a single design decision — using color to mean “available” — frequently chains into three or four separate WCAG failures, each of which is independently litigable.

How to Tell, Without a Developer, Whether Your Widget Passes

You don’t need DevTools and you don’t need to read the WCAG guidelines yourself. Here are five things you can check in about ten minutes on your own booking page.

1. Unplug your mouse and try to book an appointment.

Use only the Tab key, the arrow keys, and Enter. Try to navigate from your name field, through the calendar, into the time-slot grid, and complete the booking. If you get stuck — if Tab skips past the calendar entirely, or if you can’t move between dates, or if you can’t tell which time slot is currently focused — that is a failure of WCAG 2.1.1 (Keyboard) and 2.4.7 (Focus Visible). It is also one of the most commonly cited failure patterns in published web-accessibility complaints.

2. Turn on your phone’s screen reader and try to book.

On iPhone: Settings → Accessibility → VoiceOver. On Android: Settings → Accessibility → TalkBack. Both will start reading the screen aloud as you swipe. Open your booking page. Swipe through the calendar. Listen to what the dates and time slots sound like. If the time slots all sound identical regardless of whether they’re available, that’s a 1.4.1 failure. If form fields read as “edit text, blank” with no label, that’s a 3.3.2 failure.

3. Zoom your browser to 200% and try to book.

In any desktop browser, hold Cmd (Mac) or Ctrl (Windows) and press the plus key several times until the page is at 200%. WCAG 1.4.4 (Resize Text) requires that all functionality remain available. Watch what happens to the calendar. Many widgets become unusable at 200% — the date grid scrolls horizontally and you can’t see the buttons, or pieces overlap, or the “next” button moves off-screen.

4. Look at the slot colors and ask: would I know which ones are available if I were color blind?

Take a screenshot of your time-slot grid and run it through a free color-blind simulator (search “color blindness simulator” — they’re free, browser-based, and don’t require an account). If, in any of the simulated views, you can no longer tell available slots from unavailable ones, your widget fails 1.4.1.

5. Look for an “Accessibility” or “VPAT” link in the vendor’s footer.

Every reputable booking platform should publish a Voluntary Product Accessibility Template — a self-assessment of how their product conforms to WCAG. If your vendor doesn’t publish one, that itself is a yellow flag. If they do publish one, read the “Does Not Support” rows. Many widget VPATs explicitly admit that the calendar grid does not support keyboard navigation or that time-slot status is conveyed by color. That admission is what plaintiffs’ firms cite in demand letters.

What to Do If Yours Fails

You have three realistic paths.

Path one: switch vendors. We are deliberately not going to publish a ranking of which booking vendors get sued most, because we do not have that data and the claim would be unfair to name-checked companies if we got it wrong. Judge vendors on what you can verify yourself: run the five checks above against each candidate’s own live demo booking page, and read their published VPAT. A vendor whose demo passes a keyboard-only booking and whose VPAT is current and specific is a better bet than one that markets accessibility without either. That comparison takes an afternoon and it is evidence you can point to later. (Nothing here is legal advice.)

Path two: build a custom flow. Most modern frameworks have well-documented accessible date-picker patterns. A developer can build a server-rendered form with a date input that uses native browser controls (which are accessible by default on every modern OS) and a list of time slots rendered as actual buttons with text labels. This is a one-to-three-day job for a competent web developer and removes the third-party-widget dependency entirely.

Path three: provide a documented accessible alternative. ADA Title III allows for “auxiliary aids and services” as long as they provide equivalent access. For a booking widget, that means: a clearly published phone number AND an email contact form, both staffed during the same hours as your online widget, with the same scope of services available. The published-phone-number approach alone is not sufficient — courts have rejected “call us” as an alternative to an inaccessible web flow when the website otherwise allows the user to do everything else online. But phone plus email plus a documented commitment to remediate the widget itself is a defensible interim posture while you do path one or path two.

How These Complaints Typically Get Built

The mechanics of these letters are widely described by defense-side firms writing publicly about their own caseloads, and the shape is consistent: a plaintiff’s firm scrapes service-business websites with an automated checker (axe-core, ARC Toolkit, or a custom crawler), logs whatever the crawler flags, pulls a handful of failures into a complaint with screenshots attached, and sends a demand. We are not going to put a dollar figure on that demand — reported settlement ranges vary widely by jurisdiction and by firm, and we have no case data of our own. For what the published filing statistics do and do not show, see what an ADA lawsuit actually costs.

What defense-side practitioners generally recommend having ready is a documented remediation record: evidence that you identified the failures, that they sit in a third-party component, and that you had already committed to a dated plan to fix or replace it. We cannot tell you what that is worth in settlement terms and we have not seen data that quantifies it. What is clear enough from the published commentary is which postures do not help. “We didn’t know” is not a defense. “Our budget is small” is not a defense. “Our customers haven’t complained” is the one judges most often dismiss out of hand, because the complaint is being brought specifically by a customer.

The Quiet Part: Most Widgets Will Get Better, Slowly

The honest forecast: vendors are responding, unevenly, and mostly because the European Accessibility Act took effect in June 2025 and applies to any of them with EU customers. Some publish a VPAT and a roadmap; some publish an accessibility page with no dates on it. You can tell which is which in about five minutes, and that check is worth more than any forecast we could give you.

But “responding” is still slow, and the timeline is the vendor’s, not yours. If you are operating today with a booking flow a keyboard user cannot complete, waiting for the vendor is not a strategy — the exposure sits on your domain in the meantime, and so does the lost booking from every customer who could not finish.

Want to know what is actually broken on your site? Get an accessibility report.