Skip to main content
WCAGrules
Quick navigation

Guides · Building it right

Somebody Else's Code Is Still Your Problem

Chat bubbles, payment frames, review widgets, consent banners, and whatever your visitors posted this morning. You did not write any of it, and all of it is on your domain.

Last reviewed August 31, 2026

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

WhatWhat usually breaksFirst thing to check
Consent bannerFocus never moves to it, no keyboard rejectTab once on a fresh load
Chat widgetA focusable bubble with no name, opens without moving focusTab to it and listen
Payment iframeUntitled frame, errors not announced across the boundaryFail a payment deliberately
Embedded videoPlayer controls unreachable, autoplay with soundReach play and pause by keyboard
MapsKeyboard trap inside the map canvasTab in, then try to tab out
Review widgetStar ratings as unlabeled images, carousel autoplayTurn images off and read it
Social embedsUnlabeled iframes, tiny tap targetsCheck the frame has a title
Common embeds and what to check on each

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 isWho can change itWhat happens to the finding
The markup around the embedYou, alwaysAn ordinary finding with an ordinary fix. The frame's title, the heading above it, where it sits in the source order.
The vendor's configurationYou, through their settingsA 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 codeOnly the vendorReported, 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 publishNobody, in advanceThe only case the standard writes a provision for, and it is a condition rather than an exclusion.
Four kinds of third-party barrier, and who can act on each

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:

  1. 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.
  2. Give every iframe a title. That one is yours. The title attribute sits on your markup, not theirs.
  3. Use the configuration you have. Most consent platforms and chat widgets expose more styling and behavior options than teams use.
  4. Ask for a conformance report before you renew. A vendor who cannot produce one is telling you something.
  5. 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.
  6. Replace it. For consent banners especially, the market is wide and the products differ a lot.
  7. 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.

  1. 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.
  2. 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.

Common questions

Am I responsible for third-party widgets on my site?
In practice, yes. The barrier is on your domain and your visitor meets it, and complaints do not distinguish between code you wrote and code you pasted in. What differs is the fix, which is often to configure, escalate, or replace rather than to patch.
Why did my accessibility scan miss the cookie banner?
Most scanners load the page and report before third-party scripts have injected their markup. If your site has a banner or a chat widget and the scan is silent about them, they were probably never examined.
Do iframes need a title?
Yes. Without one, a screen reader announces it as an unnamed frame. The title attribute sits on your own markup, so this is one third-party problem you can fix directly.
What if the vendor will not fix it?
Document it, name it in your accessibility statement with the date you reported it, and weigh it at renewal. A vendor who cannot produce a conformance report is a risk you are carrying on their behalf.
Are user comments, reviews and forum posts included in an accessibility audit?
The parts that produce them are, and those are the parts worth auditing. Your posting form, your editor, your upload control, your moderation queue and the template that renders whatever somebody typed. A sample of real contributions goes in too, because the sample shows what your form currently lets through. What nobody can audit is a post that has not been written yet.
Does user-generated content get an exemption from WCAG?
No. The standard has a section for content you do not control, and it offers two routes rather than an exclusion. Either you monitor and repair within two business days and claim conformance as normal, or you publish a statement of partial conformance, which states that the page does not conform. It also says plainly that no conformance claim can be made at all if it is not possible to monitor or correct the content. There is no third door.
We moderate every post before it goes live. Where does that leave us?
In a better position and a narrower one. The second route requires the content not to be under your control, and content you approve before publication is hard to describe that way. The same queue is what makes the first route reachable, because monitoring and repair within two business days is what a staffed queue already does. So moderation moves you toward claiming conformance rather than toward disclaiming it.

Sources

Keep reading

More on building it right

Reading about it is the cheap part.

Find out where your site actually stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, keeps its 27 best-practice checks separate from WCAG findings, and names the rule behind every finding. The full audit adds an expert review and a real blind screen-reader user. From $499, with the report in 5 business days on Rapid and 10 on Standard, and the clock starting at cleared payment.

Go somewhere useful

Find tools, resources and your workspace.

29 destinations