Note: this article is not legal advice. Your jurisdiction, industry and contracts will shape how liability is allocated, so review these points with your own legal team.
You can’t edit your vendor’s code, but you can still test it, and you should. Skipping accessibility testing on third-party tools because you can’t fix them is one of the most common and costly mistakes in digital accessibility.
“We can’t change it, so why test it?“
You will hear this in almost every accessibility kickoff meeting. The scope is drawn, and then someone says it: “The chat widget, the payment form, the booking engine and the cookie banner are all third-party. We can’t edit them, so let’s leave them out of the audit.”
It feels pragmatic. It is actually a decision to stay ignorant, and ignorance is the most expensive position you can take on accessibility. This article explains why third-party solutions belong in your accessibility testing scope, what you gain by testing them, and how to turn the results into smart business decisions.
Why teams avoid testing what they can’t fix
The reluctance is understandable. It usually comes from four places:
- “It’s the vendor’s problem.” Responsibility feels like it travels with the code, so if someone else wrote it, someone else must own it.
- “Findings we can’t fix are just liability.” A written report of known defects feels like handing opposing counsel a gift.
- “It will blow up the budget and timeline.” Testing more components means more findings, and more findings mean more uncomfortable conversations.
- “We already bought it.” Sunk cost and contract terms make a replacement feel off the table before anyone has asked what it would cost.
Each of these reasoning errors treats testing as the cause of the problem. Testing does not create defects. It only reveals the ones your users are already experiencing.
The legal reality: your users don’t see a vendor boundary
A person using a screen reader, voice control or keyboard alone does not know or care which parts of your checkout were written in-house. They experience one product, under one brand, at one web address. So does the law, in practice.
- Complaints and demand letters target the site owner. When a barrier blocks a purchase, a booking or a sign-up, the business whose name is on the page is the one that receives the letter, not the vendor behind the widget.
- Regulations apply to the service you deliver. Laws and standards such as the Americans with Disabilities Act, Section 508, and the European Accessibility Act are generally framed around the service or product provided to the public, regardless of whose code powers each part of it.
- “We didn’t know” is a weaker defense than “we knew and acted.” Documented testing, a remediation plan and a vendor escalation trail show good faith. Silence shows neither effort nor intent.
The common fear is that a test report becomes evidence against you. In reality, a report paired with a credible plan is evidence of diligence. An untested checkout is just an unmanaged risk waiting for someone else to test it for you.
Knowledge is power, and in accessibility, power means control
You may not control a vendor’s source code. You do control whether you keep the product, how you configure it, where you place it, what you tell your users, and what you demand of the vendor. Every one of those decisions gets better with data.
Testing a third-party solution turns an unknown into a set of choices:
| What testing tells you | What you can decide |
|---|---|
| It is largely accessible, with minor issues | Keep it, log the issues, and send them to the vendor |
| It has serious barriers, but the vendor is responsive | Keep it with a dated remediation commitment in writing |
| It has serious barriers on a core user journey, and the vendor will not act | Replace it, or remove it from that journey |
| It has barriers, but you can configure around them | Adjust settings, themes or integration patterns to reduce harm |
| It is a nice-to-have feature with barriers | Remove it, or offer an accessible alternative |
Without the test, every row in that table collapses into one option: hope for the best. With it, you are choosing among them on purpose, which is exactly what a risk-aware business is supposed to do.
What to do with the results
A test report is the start of a process, not the end of one. A practical approach looks like this:
- Prioritize by user journey, not by vendor. Rank findings by how badly they block key tasks such as logging in, paying, booking or getting support.
- Send findings to the vendor in writing. Include the WCAG success criteria, reproduction steps and the assistive technology used. Ask for a response and a timeline.
- Request the vendor’s Accessibility Conformance Report (ACR). Compare their VPAT claims against your own test results. Gaps between the two tell you how far you can trust the vendor’s other statements.
- Mitigate what you can control. Configuration options, theming, labeling, page placement, and fallback paths often fix more than you would expect.
- Provide an accessible alternative where needed. A phone number, an accessible form or an equivalent service path can reduce harm while a fix is pending, though it should never be treated as a permanent substitute.
- Set a decision date. If the vendor has not improved by then, replace the tool, or remove it from the journeys that matter most.
- Document everything. Test dates, findings, vendor correspondence and decisions form your good-faith record.
Build accessibility into procurement and contracts
The best time to test a third-party tool is before you sign. The second best time is now, ahead of renewal. Either way, the leverage is real: vendors respond to customers who ask.
- Test during evaluation. Make an accessibility trial part of any proof of concept, and treat results as a scoring criterion next to price and features.
- Ask for evidence, not promises. Request a current ACR, a remediation roadmap and the date of the vendor’s last independent audit.
- Write requirements into the contract. Look for a conformance target such as WCAG 2.2 AA, a remediation timeline for reported defects, notification of significant UI changes, and a termination or credit clause if accessibility commitments are missed.
- Re-test after major releases. Vendors update their products constantly, so an accessible widget last year can be a barrier today.
- Share the load. Ask your legal team to review indemnification language, understanding that it may not protect your reputation or your users.
The business case goes beyond legal risk
Lowering legal exposure is the headline, but it is not the only return on testing third-party tools.
- More customers can complete their tasks. Every inaccessible form, payment step or support widget is a place where someone gives up and goes to a competitor.
- Better vendor decisions. Accessibility data becomes one more factor in renewals, negotiations and replacements.
- Fewer surprises. Finding a barrier in a planned test is cheaper than finding it in a demand letter or a public complaint.
- Stronger brand trust. Customers, partners and procurement teams increasingly ask for accessibility evidence.
Don’t choose ignorance
The argument for leaving third-party solutions untested is that you can’t fix them. But testing was never only about fixing. It is about knowing, and knowing is what lets you keep, configure, escalate, replace or remove with confidence.
If a component is part of your digital product, it is part of your accessibility scope. Put every third-party tool in your next audit, and start making decisions with real information.
Ready to find out what’s hiding in your third-party stack? Add your vendor tools to your next accessibility audit, and ask your vendors for their conformance reports today.
Resources
- ADA.gov: the US Department of Justice’s home for the Americans with Disabilities Act, including Title III regulations for public accommodations.
- Section508.gov: GSA guidance on buying, building and testing accessible technology, including its testing resources.
- Creating an ACR using a VPAT: how vendors document conformance, useful when you request one.
- WCAG 2.2 and the How to Meet WCAG 2.2 quick reference: the W3C standard and its testing guidance.
- European Accessibility Act: the European Commission overview, with the directive text.