Third-party embeds usually sit outside the claimant's control

What it is

CAPTCHAs, ads, maps, payment iframes, chat widgets, and social cards run someone else's code. You can change your own header; you cannot change that iframe's accessibility tree. Third-party content conformance is a fact about the claim: site-wide conformance cannot count nodes you cannot edit as “we pass,” and it cannot pretend to the user that the barrier is not there. “Out of control” is not a spell of immunity — which vendor you chose is still a control point.

Why it happens

The author makes the claim, and can underwrite only nodes they can change. The standard allows uncontrolled third-party content to be marked as partial conformance, provided it is named, explained, and not folded into a site-wide green light. The second layer is that “uncontrolled” is false for the user: a keyboard that enters a CAPTCHA and cannot leave still fails the task. Choosing the vendor, allowing the script, and offering a first-party alternative when it fails remain in scope. Tags you yourself ticked in a tag manager are not a mysterious third party. Once control is outsourced, the claim's scope must shrink, and the procurement contract must treat the channel as a deliverable.

Studying it

Draw a responsibility map: source of each embed, who can change the code, where the user gets stuck on failure, whether a first-party alternative exists. Walk critical paths that include embeds with keyboard and a screen reader, and tag each failure as first-party / vendor / configuration. Check whether the claim names those embeds.

Independent variables: whether the embed is listed in the claim; whether a first-party alternative exists; whether the contract has accessibility clauses. Dependent variables: whether the embed blocks a critical path; whether the claim counts that block as site-wide pass; whether the failure vanishes after a vendor change.

Do not rely on crawlers across cross-origin iframes — many never enter, and the green result is the shell.

Where it stops holding

First-party code you wrote into a third-party shell is still your scope. An open-source widget merged into the repository has already come back under control and cannot be filed as third-party. Browsers and operating systems are not “embedded content”; compatibility is a different layer. A content-delivery network that only ships your bytes does not create a separate conformance object. Inability to control is not permission to stay silent: partial conformance has to be readable.

Applying it

• Keep irreplaceable steps of a critical path out of uncontrolled embeds where you can. If payment, sign-in, or verification must use a vendor, write channel requirements into the contract and keep a first-party or second-vendor fallback.
• List third parties item by item in the claim: product name, purpose, known barriers, alternatives (order by phone, human review).
• Treat a new script in the tag manager as a scope change. Untested scripts do not enter claimed pages.
• How to check: finish checkout and sign-up with the display off. When you stick in a CAPTCHA, chat, or payment iframe, open the claim and see whether that item is named and whether an alternative is given. If the claim still says the site conforms and does not list the embed, the scope was written too wide. Then read the vendor's docs to see whether you truly cannot change it — an unfixed configuration you could have changed is not loss of control.

Related

• Same group: J1.10.1 A page-level claim and a site-level claim can reach different conclusions · J1.10.2 Passing almost every check is not overall conformance · J1.10.3 Dynamically generated content must be retested after each update
• Nearby: J1.12 Accessibility Statements and Conformance Documentation · J5.07 Compatibility Testing
• Search terms: third-party content conformance · partial conformance · CAPTCHA