A surprising share of what we report in audits was not written by the client. It arrived as a snippet: a chat widget, an embedded map, a booking frame, a review carousel, a consent banner.
The visitor cannot tell the difference. Neither does the standard, which defines conformance for whole pages and does not let you carve a piece out.
Why Third-Party Code Fails More Often
- It loads last, after your page is built, so it lands on top of everything and often steals focus.
- It was tested on its own, not inside your page, so its focus handling and yours disagree.
- It is frequently in an iframe, which is its own document with its own focus behavior and, very often, no title.
- Nobody on your team owns it. It was added once, by whoever ran the campaign, and never looked at again.
- Scanners miss it. Many report before the script has injected anything, so a clean scan can mean the widget was never examined.
The Usual Suspects
| What | What usually breaks | First thing to check |
|---|---|---|
| Consent banner | Focus never moves to it, no keyboard reject | Tab once on a fresh load |
| Chat widget | A focusable bubble with no name, opens without moving focus | Tab to it and listen |
| Payment iframe | Untitled frame, errors not announced across the boundary | Fail a payment deliberately |
| Embedded video | Player controls unreachable, autoplay with sound | Reach play and pause by keyboard |
| Maps | Keyboard trap inside the map canvas | Tab in, then try to tab out |
| Review widget | Star ratings as unlabeled images, carousel autoplay | Turn images off and read it |
| Social embeds | Unlabeled iframes, tiny tap targets | Check the frame has a title |
Sorting the Barriers by Who Owns the Fix
Every third-party barrier on your page belongs to one of four owners, and sorting them is worth doing before anything else, because it decides what happens next. Three of the four are yours to act on, and no provision anywhere excuses any of them. The fourth is the one the standard writes rules for, and those rules are conditions rather than a way out.
| What it is | Who can change it | What happens to the finding |
|---|---|---|
| The markup around the embed | You, always | An ordinary finding with an ordinary fix. The frame's title, the heading above it, where it sits in the source order. |
| The vendor's configuration | You, through their settings | A finding with a settings change attached. You chose the product and you set the options, so this is a decision rather than a limitation. |
| The vendor's own code | Only the vendor | Reported, named, and marked report-and-escalate. It is still on your page and it is still in the claim. |
| What a visitor posts after you publish | Nobody, in advance | The only case the standard writes a provision for, and it is a condition rather than an exclusion. |
That leaves the question owners actually ask, which is what an audit covers. It covers what a visitor meets. If the consent banner is the first thing a keyboard user hits, the consent banner is in the report, whether or not anybody at your company wrote a line of it. There is no third-party column in a finding list that means the same thing as excluded.
What changes is the row's ending rather than its presence. A finding on somebody else's code names the vendor, names the version and configuration we saw it in, and names the route out, which is configure, escalate, replace, or disclose. That is more useful to you than a bare defect, because those are the four things you can actually do on Monday.
What we do and do not do here
We audit and we report. We do not repair third-party code, we do not monitor it for you, and we do not manage your vendors. The two-business-day repair commitment further down this page is an operational promise you make, not a service anybody sells you.
What You Can Actually Do
You usually cannot edit the vendor's code. You can do all of this:
- Test it, and write down what fails. A precise report is worth more to a vendor than a complaint, and it is what you need internally either way.
- Give every iframe a title. That one is yours. The
titleattribute sits on your markup, not theirs. - Use the configuration you have. Most consent platforms and chat widgets expose more styling and behavior options than teams use.
- Ask for a conformance report before you renew. A vendor who cannot produce one is telling you something.
- Load it later, or behind a click. A chat widget summoned by a button is a smaller surface than one that appears on its own.
- Replace it. For consent banners especially, the market is wide and the products differ a lot.
- Say so in your accessibility statement. Naming a barrier you cannot fix, with the vendor and the date reported, is a much better position than silence.
The Standard Has an Answer for This
Almost nobody uses it, and it is the most practical thing in the conformance requirements. WCAG gives content you do not control exactly two routes, and you have to pick one.
- Monitor and repair within two business days, and you may claim conformance for the page as normal. That is a concrete operational target, and for a marketplace or a review widget it is achievable.
- Publish a statement of partial conformance, in WCAG's own shape. It reads that the page does not conform, but would conform at your level if the named parts from uncontrolled sources were removed. Describe those parts well enough that a user can recognize them, because "everything we do not control" is not allowed unless it is clearly marked.
Note what is not on that list. Excluding the widget from your claim and calling the rest conformant is not available, because conformance covers whole pages and never part of one. And note what closes the first route. If it is not possible to monitor or correct the content, no conformance claim can be made at all. The standard says that outright. Both routes are conditions you meet, and neither is an exemption you qualify for.
When Your Own Visitors Write the Content
WCAG's provision for content you do not control was not written for the chat bubble at all, and its own examples say so. It names an email program, a blog, an article that allows users to add comments, applications supporting user-contributed content, a portal or news site composed of content from multiple contributors, and sites that insert advertising dynamically. Comment threads, forums, marketplaces, review sections. The places where your visitors are the authors.
What all of those share is one property, and it is the property that decides whether the provision reaches you. The content is unknown at the time you publish the page. A chat widget you chose, configured and pasted in was entirely known when you published, which makes it a procurement decision rather than uncontrolled content. A seller listing that goes live on Tuesday genuinely was not.
The Machine Is Yours, the Words Are Theirs
That split does most of the work on a forum or a marketplace, and it is the reason a report on a user-generated site spends more of its length on your forms than on your posts.
- Yours. The posting form, the rich-text editor, the upload control, the image field and its default, the reply and quote controls, the sort and filter controls, the moderation queue your team works in, the pagination, and the template that renders whatever somebody typed.
- Theirs. The words in the post, the alt text they did or did not write, the heading levels they chose, the color they picked in the editor, the video they linked.
- Both, and this is the interesting part. The template decides how badly a bad post can break. A review body rendered into a heading element inherits your outline problem. An upload control that makes a description mandatory produces a site full of alt text repeating the title above the photo, which is a barrier you built out of good intentions.
W3C makes the same point in one sentence, and it is the sentence that stops anybody treating contributions as a sealed compartment. Uncontrolled content can affect the accessibility of the controlled content as well. So the fix that scales is almost never reviewing what was posted. It is changing what the form permits, what the editor produces by default, and what the template does with it.
Moderated Content Is a Different Question
Before you reach for either route, settle one thing, because it decides which of them you are even eligible for. The second option carries a condition that the content is not under your control. Content a person or a filter approves before it appears in public is harder to describe that way, and a site with a working pre-publication queue is closer to owning what it publishes than to hosting what it cannot see.
That cuts both ways, and the second way is the useful one. A moderation queue is also how the first route becomes achievable, because monitoring and repair within two business days is exactly what a queue does when it is staffed. So the real decision on a user-generated site is not whether you are exempt. It is whether you can look at what went up, and act on it, inside two working days. Answer that honestly and the route picks itself.
If you can, you claim conformance as normal and you keep the staffing that makes the claim true. If you cannot, you publish the statement of partial conformance, which says on its face that the page does not conform, and you describe the contributed parts well enough that a reader can tell which is which. Marking user content as user content is what makes the second condition satisfiable, and it is a design decision more than a legal one.
For a platform where thousands of people write the content, the auditing question follows the same shape. A marketplace audit tests the templates and the listing form and samples real listings, so the sample tells you what your platform currently permits rather than what any one seller did. That is the only version that scales, and it is also why nobody can promise you that every future post will be fine.
A Federal Regulator Has Already Named the Third-Party Gap
In April 2025 the US Federal Trade Commission finalised a consent order against an accessibility overlay vendor, and one provision in it is about your problem rather than theirs. It is headed Required Disclosure of Domain Limitations. The company may not say its product corrects accessibility barriers on a website unless it discloses one thing first, clearly and conspicuously, before the customer takes on any financial obligation. The disclosure is that the product will not correct barriers on third-party web domains or subdomains that may be part of the overall user experience, unless those domains are running it too.
Read that against your own checkout. If your booking step, your payment page or your ticketing flow is hosted somewhere else, a federal regulator has already decided the gap is material enough to disclose at the point of sale. That is not a WCAG argument, it is a consumer protection one, and it puts the boundary between your domain and your vendor's on a regulator's desk rather than in a developer's backlog.
The Commission's complaint says why the boundary matters, in ordinary language. Some of those websites linked out to a third-party domain to complete a purchase or a reservation. Those pages did not carry the product and were not accessible, so the item could not be bought and the booking could not be made. The barrier sat on somebody else's domain and the customer was still stuck on the doorstep.
One more sentence from the same complaint is worth keeping on file for a different reason. The Commission stated that according to web accessibility experts, including the W3C and the developers of the WAVE evaluation tool, no automated testing tool alone can determine if a website meets accessibility standards. Manual human testing is required instead. When a vendor tells you their script settles the compliance question for the embed sitting on your page, that is the sentence to put in front of them.
Say what this is, though, and not a word more. The company neither admitted nor denied the allegations, and the matter closed by consent order rather than by a judge. The $1 million it paid is money the Commission may use to refund consumers, not a fine. What it establishes is a federal regulator's stated position about code you did not write, running on a page you did.
The scan trap
If your automated scan comes back clean and your site has a chat widget and a cookie banner, the likely explanation is that the scanner finished before they loaded. That is a reason to check by hand, not a reason to relax.
One honest limit
Some of this genuinely is not fixable from your side. When we find a barrier inside a third-party frame, we say so, name the vendor, and mark it as a report-and-escalate item rather than a fix. Pretending you can patch somebody else's iframe would make the report less useful, not more.