Key takeaways
- Third-party tools on your site, such as chat widgets, booking systems, maps, review feeds, payment forms and video players, are generally treated as part of your website when someone cannot use them.
- Federal rules say so directly for some organizations. The Justice Department’s Title II rule applies to content “provided or made available” through vendors and licensors, and the HHS Section 504 rule covers content provided through contracts and licenses.
- Even accessibility widgets can add risk: UsableNet counted more than 1,400 lawsuits in 2025 against companies that had them installed.
- Vet vendors before you sign: request an Accessibility Conformance Report, test the tool yourself and write WCAG 2.1 AA requirements into the contract.
- Keep an inventory of every embedded tool, test each one by keyboard and screen reader and replace tools that block core tasks.
Your website includes elements you did not build: embedded maps, chat widgets, social feeds, booking systems, payment processors, video players, review widgets and analytics consent banners. Visitors do not see the difference between your code and a vendor’s. If a screen reader user cannot book an appointment because the scheduling widget is inaccessible, the barrier is on your site. This Emulent guide covers your exposure for third-party content, how to vet and test tools, what to put in contracts and how to fix problems. It is general guidance, not legal advice; speak with counsel about your specific obligations.
Are you responsible for third-party tools on your website?
In most cases, assume yes for anything visitors need to complete a task. Plaintiffs typically name the business whose website they visited, not the vendor behind a widget, and courts have generally looked at the experience of the site as a whole.
- Core tasks: booking, checkout, payment, contact, account login and quote requests carry the most risk because failure stops a visitor completely.
- Government and HHS-funded organizations: the Title II and Section 504 rules adopt WCAG 2.1 Level AA and reach content provided through vendors, though both agencies pushed their compliance dates back by one year in 2026.
- Limited exceptions: some rules exempt certain user-posted content or archived material, but these do not cover tools you chose to embed for business purposes.
- Contracts shift costs, not visibility: an indemnification clause can help with expenses, but the inaccessible tool still sits on your site.
Which third-party tools cause the most accessibility problems?
Some categories fail more often than others. Start your review here.
| Tool type | Common problems |
|---|---|
| Chat widgets | launchers without accessible names, chat windows that trap focus and new messages that are never announced. |
| Booking and scheduling tools | calendar grids that cannot be used by keyboard and time slots with no screen reader labels. |
| Payment and checkout iframes | unlabeled card fields and error messages that are not announced. |
| Embedded maps | no text address or directions alongside the map, and controls that need a mouse. |
| Social feeds and review widgets | images without alt text, endless scrolling and low-contrast star ratings. |
| Cookie and consent banners | keyboard traps, hidden close buttons and banners that cover focused content. |
| Video players and carousels | missing captions, unlabeled controls and autoplay with no pause option. |
| Popups and marketing forms | modals that cannot be closed with Escape or reached by keyboard. |
How do you vet and test third-party tools?
Check accessibility before you buy, then test again after the tool is installed, since configuration and styling can change how it behaves.
- Request an Accessibility Conformance Report (ACR), usually based on the VPAT template, and read the “partially supports” and “does not support” entries.
- Ask the vendor what standard they target, how they test, how often and how they handle reported issues.
- Test a demo yourself: complete the main task with only a keyboard, then with NVDA, VoiceOver or TalkBack.
- Run axe DevTools or WAVE on the page with the tool loaded.
- Build an inventory listing every embedded tool, the pages it appears on, its owner, its contract renewal date and its accessibility status.
- Retest after vendor updates, which can change markup without notice.
What should vendor contracts and fixes include?
Contracts and fallbacks protect you when a vendor’s product falls short.
- Require conformance with WCAG 2.1 Level AA, or 2.2 AA for new agreements, and an updated ACR at each renewal.
- Set timelines for fixing reported accessibility defects, ranked by severity.
- Include indemnification for claims caused by the vendor’s product and the right to terminate if issues are not fixed.
- Provide an alternative path while fixes are pending, such as a phone number or email for booking, and show it near the widget.
- Replace tools that block core tasks and will not improve; there is usually an accessible competitor.
- Remove tools you do not need. Every widget adds risk and page weight.
Accessible third-party tools also help performance and search. Fewer heavy scripts can speed up pages, and accessible embeds with text alternatives give search engines and AI answer engines more to read, which supports your SEO. On WordPress sites, audit plugins as carefully as embedded scripts, since a single plugin can add inaccessible markup across the site. For ecommerce, we recommend Shopify; its checkout is platform-managed, but theme apps still need the same review. Results vary by tool and site.
How the Emulent team can help
Emulent inventories and tests every third-party tool on your site by keyboard and screen reader, reviews vendor ACRs and recommends accessible replacements where needed. Our website design team can implement alternatives, add fallback contact paths and fix the styling and configuration that break vendor tools. To find out which embeds put your website at risk, contact the Emulent team.