A polished website can still fail at the moment that matters
A customer reaches your website, finds the service, chooses a date, and opens the booking calendar. The calendar traps keyboard focus. A payment form announces fields without labels. A chat window appears, but the screen reader never announces the new message. The rest of the website may be well structured. The customer still cannot complete the task.
That is the practical answer: no, a website is not genuinely accessible for that customer if the third-party provider controls an essential step and that step is inaccessible. The provider may be a separate company, but the booking, payment, or chat function is part of the service you chose to offer online.
WCAG treats the full web page as the unit of conformance. Embedded content, including content supplied by another system, is part of the page. WCAG 2.2 does allow a statement of partial conformance when content comes from an uncontrolled source, but that statement is an admission that the page does not conform. It is not a certificate that the customer journey is accessible. (w3.org)
Keep the provider with a fallback, or replace it?
| Criterion | Keep the provider and add an accessible fallback | Replace the provider |
|---|---|---|
| Speed | Usually faster if the vendor can fix a specific barrier or you can add phone and email alternatives. (better) | Slower because data, contracts, branding, and customer workflows may need to move. |
| Control | Limited. You remain dependent on the vendor’s code, releases, and support process. | Greater control if the replacement gives you usable markup, documentation, and testing access. (better) |
| Customer experience | Can work when the fallback is prominent, staffed, and genuinely equivalent. It fails when it means waiting for office hours. | Better long term when the main path works with keyboard navigation, screen readers, zoom, and mobile input. (better) |
| Risk | Lower immediate disruption, but the same inaccessible tool remains in the core journey. | Higher migration risk, followed by less vendor-dependent accessibility risk. (better) |
The provider does not take the whole responsibility away
For United States businesses open to the public, the ADA requires equal access to goods, services, and privileges. The Department of Justice has not issued a single detailed technical standard for every private business website, but its guidance is clear about the underlying obligation: online services must be accessible, and an inaccessible feature can prevent equal access to the business’s goods or services. (ada.gov)
The distinction matters. “Our booking company is responsible for the widget” may describe a contract. It does not necessarily solve the customer’s problem or remove the business’s exposure. A service provider can be responsible to you under a contract while you remain the organization the customer is trying to deal with.
The federal position is even more explicit for state and local governments. The Department of Justice says that calendars, scheduling tools, maps, reservation systems, and payment systems supplied by outside technology companies generally do not escape accessibility requirements when the public entity places them on its website. A public entity cannot simply delegate away the obligation. (ada.gov)
For a private business, treat that as a useful operating rule even where the legal details differ: if the tool is the route to your service, select it, test it, monitor it, and provide a workable alternative when it fails.
The scale is large, and the testing gap is real
World Health Organization, “Disability and Health.”
World Health Organization, “Disability and Health.”
WebAIM Million 2026 report, analysis of one million homepages.
WebAIM Million 2026 report.
What practitioners see is usually a critical-path failure
Accessibility practitioners tend to focus less on whether a vendor has a reassuring badge and more on whether a person can complete a real task. That is the right test for small businesses.
A booking tool may have strong color contrast but fail when the customer moves through dates with a keyboard. A payment processor may label its card fields but make error messages invisible to a screen reader. A chat provider may advertise accessibility while its close button is unreachable, its messages are not announced, or its conversation disappears when the page changes.
These failures are difficult to catch with a homepage scan because they occur after interaction. W3C guidance says automated tools cannot determine accessibility on their own. Human judgment is required, especially for keyboard operation, focus order, dynamic updates, and whether a task can actually be completed. WAI-ARIA guidance makes the same point for interactive widgets: static checks are not enough; developers need to test device-independent operation and changes exposed through accessibility APIs. (w3.org)
The WebAIM Million result gives useful context, but do not misuse it. In its February 2026 analysis, WebAIM found an average of 56.1 detectable errors per homepage across one million pages. That does not prove every page is unusable, and a clean automated result does not prove accessibility. It does show why “the scan passed” is a weak answer when the customer’s booking or payment task has not been tested. (webaim.org)
The unobvious point is that the most important accessibility issue may be one barrier, not the largest error count. If a customer cannot move past the date picker, signature field, verification step, or payment error, the rest of the page becomes irrelevant.
How to assess a third-party provider before it costs you customers
-
Map the complete customer task
Test the path from the first call to action through confirmation, cancellation, receipt, follow-up, and error recovery.
-
Ask for evidence, not a promise
Request an accessibility conformance report, known limitations, supported browsers and assistive technologies, test dates, and a route for reporting defects.
-
Test the live implementation
Use keyboard-only navigation, browser zoom, a screen reader, mobile accessibility features, and a manual check of focus, labels, errors, dialogs, and dynamic messages.
-
Test failure states
Enter an invalid date, leave required fields empty, trigger a declined payment, close and reopen chat, and confirm that every error is perceivable and actionable.
-
Set a replacement or fallback rule
Define what happens if the provider cannot fix a critical barrier, and who owns the decision, customer communication, and alternative booking or payment route.
-
Re-test after vendor changes
A provider can change the embedded experience without changing your website code, so accessibility review belongs in ongoing site maintenance.
A fallback is only accessible if it preserves the customer’s choice
Many businesses respond to an inaccessible provider by adding “Call us if you need help.” That can be a reasonable backup. It is not automatically an equivalent alternative.
The phone route must be visible before the blocked step, available during the hours customers need it, and staffed by someone who can complete the same booking or payment task without making the customer repeat the entire process. If the online route is available all night but the alternative exists only during weekday office hours, the business has created a different service for people who cannot use the widget.
The same principle applies to chat. A visible phone number, email address, or staffed text option may be better than an inaccessible chat window, but only if a person can get a timely answer and complete the underlying task. Measure those actions, not just website sessions. The site’s useful outcome is the booking, payment, call, or message, which is also the practical case made in When Google Finishes the Search, Measure the Customer Action.
If the provider is central to revenue, replacement is often the cleaner long-term answer. That does not mean rebuilding every external service immediately. It means treating accessibility as a procurement and maintenance requirement, alongside security, uptime, data handling, and support. A maintainable stack gives you room to change a failing provider, as discussed in Choose the Website Stack Your Business Can Maintain.
The honest answer is operational, not cosmetic
A website can be accessible around an inaccessible provider, but it cannot honestly claim that the complete online service is accessible when the provider blocks an essential customer task.
The practical decision is straightforward. If the third-party tool is optional, remove it or provide the same information and function another way. If it is essential, test it as part of the website, require evidence from the vendor, monitor changes, and keep an equivalent fallback ready. If the vendor will not cooperate, replace the provider when the business can do so responsibly.
Accessibility is not finished when the homepage looks clean. It is finished when a customer can find the service, operate the interface, recover from an error, complete the transaction, and receive confirmation without needing a different path because the business selected an inaccessible tool.
