Your Booking Widget might be the reason you're not ADA Compliant

Your practice didn't write a single line of code for your online booking tool. That won't matter if a patient can't use it.

Most practices treat ADA compliance as something that lives entirely inside their own website. It doesn't. The booking widget, the patient portal, the bill-pay embed, the chat plugin, every one of those is a piece of software your practice chose, and every one of them carries your liability if it isn't accessible.

Vendor software doesn't come with a liability waiver

Imagine you lease a wheelchair-accessible entrance ramp installed by a contractor, but the contractor installs it at the wrong grade, making it too steep to use. You didn't pour the concrete, yet you're still the one a patient sues, because it's your building.

Your booking widget works the same way.

You didn't build it, but it's sitting on your domain, under your name, doing the work of getting a patient into your care.

This isn't a hypothetical extension of the law; courts have already ruled that digital tools don't get a pass just because they're not brick-and-mortar. In Robles v. Domino's Pizza, the Ninth Circuit held that Domino's website and app were covered under Title III because they function as a gateway to the company's goods and services, the same reasoning that applies to a healthcare practice's own website. The Supreme Court declined to hear Domino's appeal in 2022, leaving that ruling intact.

That case addressed a company's own digital properties, not a vendor's embedded tool. But the exposure doesn't stop there. The Department of Justice's own technical guidance on digital accessibility programs recommends that organizations review vendor contracts, require proof of accessibility conformance before signing, and build indemnification into agreements- standard risk management, not just best practice. Courts have consistently treated a business's digital storefront, regardless of who built it, as covered under Title III when it functions as the gateway to that business's goods or services. Vendor-built doesn't mean vendor-liable. It means yours to vet.

What a VPAT actually tells you

A Voluntary Product Accessibility Template (VPAT) is a vendor's self-disclosure of how their product meets WCAG 2.1 AA. It's not a marketing document; it's a technical one.

Ask for it before you sign, not after a complaint.

• Does the vendor have a current VPAT, or a five-year-old one?
• Does the document address keyboard navigation and screen reader compatibility specifically, or is it vague?
• Has the vendor patched known issues, or is the VPAT aspirational?

If a vendor can't produce one, that's your answer. And if they can, don't just file it, read it. A VPAT that says "partially supports" next to keyboard navigation tells you exactly where the barrier is before a patient finds it for you.

The tools most likely to be the problem

In our audits, three categories surface repeatedly:

• Booking widgets: often embedded via iframe, frequently untestable by keyboard alone
• Bill-pay portals: third-party payment processors rarely built with healthcare accessibility in mind
• Chat plugins: real-time support tools that trap keyboard focus or lack screen reader labeling

None of these live in your codebase. All of them are your exposure. And because they're outside your CMS, they're also the tools most practices forget to include when they audit "their website."

What to do if a vendor won't fix it

Compliance isn't leverage you have to build on your own. Document the gap, request a remediation timeline in writing, and if the vendor won't commit to one, that's a contract renewal decision, not just a compliance one.

Treat this the same way you'd treat any other vendor risk: put it in writing, set a date, and escalate internally if the date passes. A paper trail showing you identified the issue and pushed for a fix carries real weight if a complaint is ever filed; courts and regulators consistently look more favorably on documented, good-faith remediation efforts than on silence.

Questions practice owners ask us about vendor liability

Am I really responsible for a tool I didn't build?

‍Yes. Courts have treated a business's digital storefront as covered under Title III regardless of who built it; if it's the gateway patients use to reach your care, the accessibility of that gateway is your responsibility.
‍

What is a VPAT, and why should I ask for one?‍

A Voluntary Product Accessibility Template is a vendor's technical disclosure of how their product measures against WCAG 2.1 AA. It tells you exactly where a tool falls short before a patient, or a plaintiff's attorney, finds out for you.
‍

Can my practice actually be sued over a vendor's accessibility gap?

Yes. The lawsuit names your practice, not the vendor, because the barrier appears on your patient-facing gateway. Your contract with the vendor doesn't change who a patient interacts with.
‍

What if my vendor won't provide a VPAT or fix a known issue?

Document the gap in writing, request a remediation timeline, and treat a vendor's refusal as a decision on contract renewal. A documented, good-faith effort carries real weight if a complaint is ever filed.
‍

Does this apply to my patient portal and telehealth platform too?‍

Yes. Booking widgets, bill-pay portals, chat plugins, patient portals, and telehealth platforms are all vendor-built tools sitting on your domain. None of them are exempt because you didn't write the code.
‍

How often should I ask vendors for an updated VPAT?

‍At minimum, at every contract renewal, and any time the vendor pushes a major product update. A VPAT from five years ago tells you nothing about the tool your patients are using today.
‍

The bottom line

You are not exempt from ADA liability because you didn't write the code. You chose the vendor. That choice is now part of your compliance posture, whether you audited it or not.

Have you ever asked any of your website vendors for a VPAT, or have you been assuming their tool is your problem to worry about later?

Download the ADA compliance white paper