The Accessibility Bugs Hiding in Your Plugins, Not Your Code

ClearPath Team · 2026-08-03 · 7 min read

Open your browser's developer tools on almost any small business site and count the scripts loading on top of the actual page. A review widget. A chat bubble. A cookie banner. Maybe a booking calendar or an email capture popup. Most of that code was never written by anyone on the business's team. It was pasted in from a vendor, and it's often the exact thing named when an accessibility complaint lands.

That's not a coincidence. Third party tools are usually built fast, marketed as plug-and-play, and rarely tested with a keyboard or a screen reader before they ship. The business owner never sees the code, so nobody catches the problem until a visitor does. A tool like ClearPath can help visitors work around some of these gaps on the fly, with keyboard-friendly navigation and other on-page adjustments, though it can't reach into a vendor's script to fix the underlying control itself.

Why third party scripts cause so many of the failures

Third-party ecommerce tools power the modern shopping experience: payment gateways, review widgets, chatbots, marketing pixels, loyalty plugins, shipping calculators, and cookie banners. Each one adds its own interactive controls to the page, and those controls are exactly where things break.

Two WCAG rules get violated over and over by these tools. The first is the requirement that every interactive control needs a programmatic name, role, state, and value where applicable, and vendor widgets often fail here, especially custom controls built from divs and spans. A chat bubble built from a styled div with no label reads as nothing to a screen reader. It's just an unlabeled clickable shape.

The second is keyboard access. All functionality must be operable from the keyboard, and custom modal dialogs, dropdown menus, date pickers, and chat tools from third-party vendors are frequent break points. A booking widget's date picker that only responds to mouse clicks locks out anyone who navigates by keyboard, including a lot of screen reader users.

Cookie banners deserve their own mention because they show up on almost every site now. A common failure pattern is a banner that grabs focus when the page loads and never lets go, or that has a close button with no accessible label. Cookie banners, chat popups, or promotional overlays were often cited for lacking accessible close buttons or focus management. If a keyboard user tabs into that banner and can't tab back out, the entire rest of the page is unreachable to them until they find a mouse or refresh.

Page builder blocks and Shopify apps carry their own version of this problem. Despite being marketed as user-friendly, many Shopify stores lack proper accessibility configurations, particularly when merchants rely on third-party themes or apps that don't meet WCAG guidelines. The builder itself might be fine. It's the block someone dragged in from an app store that introduces the div-soup buttons and unlabeled icons.

The liability doesn't stay with the vendor

Business owners often assume that if a plugin causes the problem, the plugin maker is on the hook. Plaintiffs and their attorneys do not distinguish between first-party code and third-party widgets when filing complaints, and "a vendor caused it" has not been a successful defense in ADA litigation. Whoever's domain the visitor was on when they hit the barrier is the one named in the letter, regardless of who wrote the offending code.

That's the part that catches people off guard. The retailer who hosts the experience is responsible for the experience, end to end. A vendor's polished sales page and a VPAT document don't change that. This is also why an accessibility statement matters, and ClearPath generates one automatically, which at least documents that you're paying attention even though it won't rewrite a vendor's broken script.

How to audit which third party scripts are actually on your pages

1. Pull the full script list. Open your site in a browser, view page source, and search for "script src." Better yet, use your browser's developer tools Network tab and filter by JS to see every external domain loading code on your page.
2. Check your tag manager. If you use Google Tag Manager or similar, log in and list every tag that's live. This is usually where forgotten chat tools and old marketing pixels turn up.
3. Tab through each widget by itself. Click into the page, then press Tab repeatedly. Watch whether focus ever gets stuck inside a banner, popup, or chat window and can't move past it.
4. Turn on a screen reader for two minutes. VoiceOver on Mac or NVDA on Windows, both free. Land on the chat bubble and the cookie banner specifically. If the screen reader says nothing useful, that control has no accessible name.
5. Repeat after every plugin update. Vendors push updates without warning, and an accessible version can quietly become inaccessible in a release you didn't ask for.

What to ask a vendor before you install anything

• Do you test this component with a keyboard only, with no mouse at all?
• Does every button and icon have a visible or programmatic label, not just a tooltip?
• Can a screen reader user close this popup, dismiss this banner, or reach the chat form?
• Do you have a current VPAT or accessibility conformance report, and can I see it, not just a marketing page that says "accessible"?
• What's your process and timeline when a customer reports an accessibility bug in your widget?

When the vendor won't fix it

Sometimes you'll report a real bug and get silence, or a "that's on our roadmap" that never moves. You have a few real options, not just complaints:

• Turn the feature off. A missing chat bubble is a worse look than a broken one, but it's not a worse experience for a disabled visitor. If the vendor won't fix a keyboard trap, disable that widget until they do.
• Swap vendors. Most categories (chat, cookie consent, reviews) have several competitors. Price out one that actually answers your accessibility questions.
• Isolate it. Some page builders let you load a widget only on specific pages instead of site-wide, which at least limits your exposure while you look for a replacement.
• Document your effort. Keep the email thread where you flagged the bug. It won't make you immune to a complaint, but it shows you didn't ignore a known problem.

Third party tools aren't going away. They're too useful and too cheap to skip. But treating them as invisible, as if they don't count because you didn't write the code, is exactly how a demand letter ends up quoting your chat bubble instead of your homepage.