AgentKit

Posted on May 11 • Originally published at blog.a11yfix.dev

Date Pickers Are the Most Common Accessibility Failure on Booking Sites — Here's Why

#a11y #webdev

If you take bookings online, your customers are not failing to convert because of your photos or your pricing. They are failing to convert because they can't get past the date picker.

I have audited a lot of small-business booking flows in the last six months — salons, dental clinics, family photographers, dog groomers, tutors, restaurants, mobile mechanics — and the same defect shows up on every single one. Somewhere between "I want to book an appointment" and "thank you, your booking is confirmed," there is a calendar widget that is impossible or painful to use for an enormous share of the people trying to give you money.

This is not a niche problem. The U.S. Census Bureau estimates that around 13% of adults have some form of disability, and the World Bank puts the global figure at 15%. Many of those people use a screen reader, a keyboard instead of a mouse, voice control, a switch device, or a touchscreen with assistive features turned on. All of them try to book appointments. Almost none of them complete the date picker on a typical small-business website without help.

Here is what is going wrong on your site right now and what you can do about it this week — without writing a single line of code.

What screen reader users actually hear

Imagine your booking page is open. A screen reader user — let's call her Tasha — wants to schedule a haircut for next Saturday. She tabs through the page until she lands on your date picker.

On a well-built date picker, Tasha hears something like: "Choose a date, May 11 2026, edit text." She types "5/16/2026" and moves on. Done.

On the typical small-business booking widget, here is what she actually hears:

"Button. Button. Button. Button. Button. Button. Disabled. Disabled. Disabled. Button. Button..."

That's a calendar grid where every date has been built as a button with no label. The little visual numbers ("1", "2", "3"...) are images or background graphics that the screen reader can't read. Past dates are disabled buttons with no explanation. The current month and year are written somewhere on the page but not announced when the calendar opens. The "next month" arrow is an icon font with no accessible name.

Tasha has no idea what date she just selected. She has no idea what month she's looking at. She backs out, tries again, gets the same result, and books somewhere else.

You never see the abandoned booking in your analytics, because the booking never started.

The keyboard test you can run in 30 seconds

You do not need to install anything to find out whether your date picker is accessible. You need a keyboard.

Open your own booking page in any browser.
Click somewhere outside the form to make sure nothing is focused.
Press Tab repeatedly until a visible outline (a colored border, a glow, a box) lands on the date field.
Press Enter or Space to open the calendar.

Now answer three questions:

Can you see where you are? When the calendar opens, is there a clear, visible outline around one specific date — usually today's date or the date you'd previously selected? Or did the outline disappear entirely?
Can you move around with arrow keys? Press the left, right, up, and down arrow keys. Does the outline move from one date to the next, day by day or week by week? Or does nothing happen?
Can you pick a date and continue? Press Enter on the date you want. Does the date appear in the form field and the calendar close? Or does the focus get lost somewhere on the page?

If any of those failed, your date picker has a serious accessibility problem. You are losing customers right now, and you may have a legal compliance issue depending on where you operate. None of this is legal advice; talk to a qualified attorney about your specific situation.

The four ways date pickers fail

There are four patterns that account for almost every broken date picker I see on small-business sites. Knowing which one is on your site tells you what to do next.

1. The "fake calendar made of divs" pattern

This is the most common failure. The developer who built the booking widget used non-semantic HTML — a grid of <div> elements styled to look like a calendar, instead of using real buttons and a date input. The visual result looks identical, but to a screen reader the entire calendar is invisible and to a keyboard user it is impossible to operate.

You can identify this by tabbing into the calendar. If Tab moves to the first date and then jumps right past the rest of the calendar to the next field, you are looking at a fake calendar.

What to do: Ask your booking system vendor (Calendly, Acuity, Square Appointments, GlossGenius, Booksy, Vagaro, etc.) which date picker component they use and whether it conforms to the WAI-ARIA Authoring Practices for the date picker dialog pattern. If they don't know what that is, you have your answer.

2. The "no visible focus" pattern

The calendar works with a keyboard, but you can't see where you are. When you press the arrow keys, the focus is moving silently from date to date — but there is no visible outline, glow, or highlight that tells a sighted keyboard user which date is currently selected.

This fails WCAG 2.2 success criterion 2.4.7 (Focus Visible) and the new 2.2 criterion 2.4.11 (Focus Not Obscured). It also makes the calendar unusable for the very large group of users who can see but can't reliably use a mouse — people with tremors, repetitive strain injuries, certain motor disabilities, or who simply prefer keyboard navigation.

What to do: If your site is on Squarespace, Wix, Webflow, or another visual builder, check whether the date picker is part of the platform's native form block or a third-party embed. Native blocks usually have a fix (a setting somewhere called "show focus outline" or similar). Third-party embeds usually require you to either contact the vendor or replace the widget entirely.

3. The "month and year are invisible" pattern

You can navigate the calendar, but a screen reader user has no idea what month they're looking at. The month name ("May 2026") is written somewhere in the calendar header but not associated with the calendar in a way the screen reader announces. Or worse, the month is rendered as an image, an icon, or text styled in a way that the screen reader skips.

This is usually fixable without rebuilding the calendar — the platform just needs to use the correct ARIA attributes to label the calendar dialog. But if the vendor hasn't shipped that fix, you can't add it yourself on most no-code platforms.

What to do: This is one of the cases where a workaround beats a fix. Offer customers a plain text alternative right next to the calendar: "Or call/text us at (555) 123-4567 and we'll book you in." That's not a long-term accessibility solution, but it stops you from losing a real booking today.

4. The "mobile pinch zoom blocked" pattern

Your date picker works fine on a desktop, but on a phone it is built in a way that prevents the user from zooming in on the calendar grid to see the dates clearly. People with low vision rely on pinch-zoom to read interfaces, and any site that disables it fails WCAG 1.4.4 (Resize Text). Many booking widgets set user-scalable=no in their viewport meta tag, which silently disables zoom across the entire booking flow.

What to do: This one your developer or platform support team can fix in five minutes. Ask whoever maintains your site to remove user-scalable=no and maximum-scale=1 from the viewport meta tag if they exist.

What to do this week if you can't replace the widget

Replacing a booking system is a big project. You probably can't do it before Saturday. Here are four things you can do this week that meaningfully reduce the damage:

Add a visible phone number and "text us to book" button at the top of every booking page. Customers who can't use the date picker should not have to hunt for an alternative. Many of them won't.
Write a one-sentence accessibility statement linked from the footer that says you are aware of issues with the online booking flow and that you welcome phone, text, or email bookings. This is not a legal shield, but it shows good faith and gives customers a clear path forward. Talk to an attorney before publishing any compliance claim.
Train whoever answers your phone to recognize the call — "Hi, I'm trying to book online but the calendar isn't working for me." Make sure they don't try to send the caller back to the website. Just book the appointment.
Test your booking flow with VoiceOver on an iPhone. It is free, it takes 10 minutes, and it will tell you whether the rest of your booking flow (not just the date picker) is also broken. We wrote a separate guide on how to do this — see the related reading below.

The longer-term fix

The honest answer is that most small-business booking widgets are not great. The platforms know it. Some are better than others — Calendly's date picker has been significantly improved in recent releases, Square Appointments has made progress, and Cal.com is generally one of the most accessible options in the space. Many older booking platforms are still shipping date pickers that fail the keyboard test described above.

If you are choosing a new booking system in 2026, ask three questions before you sign up:

Does your date picker support keyboard navigation with arrow keys?
Does your date picker announce the month, year, and selected date to screen readers?
Have you published an accessibility statement, VPAT, or ACR for your booking widget?

If the vendor can't answer "yes" to question 1 and 2 with specifics, walk away. Question 3 is a nice-to-have that signals the vendor takes accessibility seriously, but the practical answers to 1 and 2 are what determine whether your customers can book.

A note on liability

ADA, EAA, and AODA-related lawsuits against small businesses over inaccessible online booking flows have grown sharply in the last two years. Plaintiffs' firms regularly file demand letters that name specific date pickers and booking widgets. Defending or settling a single demand letter typically costs many thousands of dollars and takes months. Fixing the underlying issue — or moving to a more accessible vendor — usually costs less than the defense.

This is not legal advice. Consult an attorney experienced in digital accessibility law in your jurisdiction before relying on any of the framing above for compliance decisions.

DEV Community