Third-Party Embedded Content: When You Inherit Someone Else's Accessibility Failures

The Failure You Didn't Build

Here is a situation that happens to municipal contractors more than almost any other accessibility problem. You build a city website. You do it right — semantic markup, keyboard navigation, color contrast, alt text, the whole WCAG 2.1 AA checklist. You run it through a scanner, it comes back clean, you ship it. Six months later the city forwards you an accessibility complaint, and every barrier in it traces back to something you did not build: the Granicus video player that won't expose captions to a screen reader, the Tyler payment widget that traps keyboard focus, the embedded ArcGIS map with no text alternative, the Facebook feed in the sidebar that renders as an unlabeled iframe.

You inherited those failures. You did not write a line of their code, you cannot patch them, and in most cases you cannot even see their source. But the deliverable is yours, the contract is yours, and the indemnification clause you signed may very well be yours too. This is the single most common unfixable-by-the-contractor problem in municipal digital delivery, and the federal deadline extension did nothing to make it go away.

This post is the playbook for third-party embedded content: why Title II makes it your problem even when you didn't build it, which embeds actually break municipal sites, what a Statement of Partial Conformance does and doesn't buy you, and a four-step process for handling inherited failures so they don't land on your invoice as a remediation cost or on your firm as a liability.

Why a Vendor's Bad Widget Becomes Your Contractor Problem

Title II of the ADA covers what a public entity "provides or makes available" to the public through its web content and mobile apps. That phrase is doing a lot of work. It does not say "content the entity wrote." It does not say "code the entity controls." It says provides or makes available — which means that the moment a city embeds a third-party payment portal, video player, or map into a page it publishes, that content is part of what the city is offering the public, and the city's Title II obligation attaches to it.

The city cannot delegate that obligation away. It remains responsible for the accessibility of the embedded content regardless of who built it. And because the city is responsible, it pushes that responsibility down its supply chain through two mechanisms: the procurement language in your contract, which almost certainly requires your deliverable to conform to WCAG 2.1 AA, and the indemnification clause, which may make you liable for accessibility claims arising from the work you delivered. If your statement of work says "the website will conform to WCAG 2.1 Level AA" and you embedded a non-conformant Tyler widget into that website, a strict reading of your own contract says you failed to deliver — even though the widget is Tyler's code, not yours.

This is the trap. You are contractually on the hook for the accessibility of a system you assembled from parts, some of which you did not manufacture and cannot repair. The federal Title II exception for third-party content is narrow and does not rescue you here: the regulation exempts third-party content that is not posted by or on behalf of the public entity, and not subject to a contractual arrangement. A payment portal the city contracted for, a video platform the city pays for, a map service the city licensed — those are posted on behalf of the entity under a contractual arrangement, which means they are squarely inside the obligation, not exempt from it.

The Five Embeds That Actually Break Municipal Sites

In practice, inherited accessibility failures cluster around a handful of widget categories. If you maintain municipal sites, these are the five to inventory first.

| Embed category | Common vendors | Typical failure mode | |---|---|---| | Video / streaming | Granicus, Swagit, YouTube, Vimeo | Missing or auto-generated-only captions, no audio description, player controls not keyboard-operable, no screen-reader labeling of play/pause/seek | | Payment / forms | Tyler Technologies, Stripe, Square, PayGov | Keyboard focus traps, unlabeled form fields, error messages not announced to assistive technology, time-outs without warning | | Maps / GIS | ArcGIS (Esri), Google Maps | No text alternative for map data, interactive controls not reachable by keyboard, color-only information coding | | Social feeds | Meta/Facebook, X, Instagram | Renders as unlabeled iframe, embedded media without alt text, dynamic content not announced | | Chat / accessibility overlays | Intercom, Drift, plus overlay widgets | Focus management failures, content not exposed to assistive tech, and — for overlays specifically — false conformance claims |

The pattern across all five: they are the parts of the page a contractor is least able to fix and most likely to be blamed for. A video player's caption handling is controlled by the platform, not by your markup. A payment widget's focus behavior is inside an iframe you cannot style. The map's keyboard support is Esri's engineering decision. You assembled the page; you did not build the engines inside it.

The overlay row deserves its own warning, because it is the one case where a vendor actively markets the widget as a solution to accessibility rather than a source of problems. It is not. The FTC's 2025 enforcement action against accessiBe (Docket No. C-4817, a unanimous Commission order) made clear that marketing an automated widget as making a site WCAG-conformant can be a deceptive practice — and the order specifically noted that such widgets do not correct barriers on third-party domains that are part of the overall user experience. An overlay cannot fix your inherited Granicus or Tyler problem. It can, however, add a false conformance claim on top of a real failure, which is worse than the failure alone. We covered this at length in Why Accessibility Overlay Widgets Will Cost You the Contract; the short version is that an overlay is never the answer to an inherited-embed problem.

What a Statement of Partial Conformance Actually Buys You

WCAG has a mechanism built for exactly this situation. It is called a Statement of Partial Conformance, and it exists because real-world pages routinely include content the page author does not control. Understanding what it does — and does not — do is the difference between a defensible deliverable and an empty disclaimer.

A Statement of Partial Conformance lets you claim conformance for a page as if the uncontrolled third-party content were not there, provided you meet specific conditions: the content must be genuinely outside your control, it must be identified, and the page must still be monitored. The "due to third-party content" variant covers content injected by parties the author does not control. This is the honest, standards-based way to say "the page I built conforms; the embedded payment widget the city licensed does not, and here is exactly where the boundary lies."

What it buys you: a clear, documented line between your work and the inherited content. That line is your defense. If a complaint arrives, the difference between "the contractor delivered a non-conformant site" and "the contractor delivered a conformant site and formally documented the specific third-party components outside their control, with the city's knowledge" is enormous — legally, contractually, and reputationally.

What it does not buy you: it does not make the city compliant. The city's Title II obligation still attaches to the embedded content. A Statement of Partial Conformance is not a magic exemption that makes the inaccessible map disappear from the city's legal exposure. It documents your boundary; it does not erase the city's problem. That distinction is what you have to communicate clearly to your client, because a city that thinks a partial-conformance statement solved its problem is a city that will be surprised by a demand letter — and will look for someone to blame.

Reading a Vendor's ACR Like a Contractor

Before you embed a third-party component, you should be reading its Accessibility Conformance Report — the document, usually in VPAT format, where the vendor states how their product conforms to WCAG. Granicus, Tyler, CivicPlus, Esri, and the major platforms all publish ACRs. Most contractors never read them. Reading them like a contractor — skeptically, looking for the gaps — is one of the cheapest risk-reduction moves available.

Three red flags to look for. First, a self-attested ACR with no third-party evaluation. A vendor grading its own homework is the weakest form of conformance evidence, and some state procurement regimes (Virginia's HB 2541, for one) explicitly require third-party-evaluated ACRs and reject self-attestation. If the vendor's ACR was produced in-house with no independent evaluator named, treat its "Supports" ratings as marketing until proven otherwise.

Second, missing test scope. A credible ACR states what was tested, with what assistive technologies, on what platforms. An ACR that claims full WCAG 2.1 AA support but never mentions which screen readers, browsers, or operating systems were tested is hiding its scope. The gap between "we support WCAG 2.1 AA" and "we tested with NVDA and JAWS on current Chrome and Firefox and here are the results" is where inherited failures live.

Third, "Partially Supports" ratings without remediation timelines. Every honest ACR has some "Partially Supports" or "Does Not Support" rows — that is normal. What matters is whether the vendor commits to fixing them and by when. A "Partially Supports" with no roadmap is a permanent failure the vendor has decided to live with, and if you embed that component, you have decided to live with it too. We are covering how to read and write these reports in depth in the upcoming VPAT and ACR deep-dive; for inherited embeds specifically, the ACR is your early-warning system, and reading it before you embed is far cheaper than discovering the gaps in an audit.

The Four-Step Inheritance Playbook

When you take on a municipal site that includes third-party embeds — or when you are about to add one — run this four-step process. It converts an unbounded liability into a documented, bounded, and shared one.

Step one: inventory every embed. Walk the site and list every piece of third-party content: video players, payment portals, maps, social feeds, chat widgets, scheduling tools, document viewers, anything served from a domain you do not control or rendered inside an iframe. You cannot manage what you have not catalogued, and the inventory itself is a deliverable that demonstrates diligence. For each embed, record the vendor, the function, and the page locations.

Step two: demand the ACR for each one. For every embed in the inventory, obtain the vendor's current Accessibility Conformance Report. If the city has a contract with the vendor, the city can request it; if you are specifying the embed, request it before you commit. Read each ACR for the three red flags above. An embed whose vendor cannot or will not produce an ACR is an embed you flag to the city in writing as an unquantified risk before you integrate it.

Step three: document partial conformance with the boundary drawn explicitly. Where an embed falls short, write a Statement of Partial Conformance that names the specific component, the specific failures, and the boundary between your conformant work and the inherited content. This is not a generic disclaimer buried in a footer. It is a specific, component-level record that says: this page conforms; this named widget from this named vendor does not, in these named ways; this is documented as of this date. Pair it with a plain-language note in the site's accessibility statement so a member of the public — and a plaintiff's attorney — sees that the gap is known and disclosed, not hidden.

Step four: flow the obligation down to the embed vendor in writing. This is the step contractors skip, and it is the most protective one. The accessibility obligation should not stop at you; it should continue to the party that actually controls the code. When you integrate a third-party component, get it in writing — in the city's contract with the vendor, or in your own subcontract — that the vendor is responsible for the accessibility of their component and will remediate failures within a defined window. Massachusetts has published required digital-accessibility contract language that does exactly this for state vendors, and it is a usable template: it requires conformance reporting, remediation roadmaps, cooperation with testing, and a prohibition on overlays. Adapt that language so that when a Tyler widget fails, the remediation obligation runs to Tyler, not to you.

The combined effect of the four steps is that you have transformed "the contractor delivered a non-conformant site" into "the contractor inventoried all third-party content, obtained conformance documentation, formally documented the boundaries of their own conformant work, and flowed the remediation obligation to the responsible vendor." That is a defensible position. The bare deliverable was not. Keep the whole record in your audit defense log so it is retrievable the day a complaint arrives.

Sample Language to Keep On Hand

Two short pieces of language worth keeping in your templates. Neither is legal advice — have your own attorney adapt them — but both give you a starting point that is far better than improvising under deadline pressure.

For the site's accessibility statement, a third-party-content disclosure:

Portions of this website include content and functionality provided by third parties, including [video streaming, online payment, and mapping services]. While we have built this site to conform to WCAG 2.1 Level AA and have requested conformance information from these providers, the accessibility of third-party components is controlled by those providers. If you encounter a barrier in any embedded service, please contact [accessibility contact] so we can assist you and relay the issue to the responsible provider.

For your statement of work, an assignment-of-risk clause:

Contractor's WCAG 2.1 Level AA conformance obligation applies to content and code developed by Contractor. Third-party components specified or supplied by [Client] or its other vendors — including but not limited to embedded payment, video, mapping, and social-media services — are the responsibility of their respective providers. Contractor will inventory such components, obtain available conformance documentation, and document conformance boundaries, but does not warrant the accessibility of third-party code Contractor does not control.

The accessibility statement disclosure protects the public's understanding and the city's transparency posture. The SOW clause protects you — it draws the contractual boundary before the dispute, not after. A contractor who has both of these in place, plus the four-step record, has done what can reasonably be done about a problem that is, by its nature, only partly within their control.

The Bottom Line

Third-party embedded content is the accessibility problem you are most likely to be blamed for and least able to fix yourself. Title II's "provides or makes available" framing pulls it onto the city's plate, and procurement and indemnification language pulls it from the city onto yours. The federal deadline extension changed none of that — the obligation is live today, and so is the litigation channel.

The move is not to pretend you can fix code you do not control, and it is definitely not to paper over the gap with an overlay that adds a false conformance claim. The move is to inventory, document, draw the boundary explicitly, and flow the obligation down to the vendor who actually controls the component. Do that, keep the record, and you convert an open-ended liability into a bounded and shared one. That is the difference between assembling parts and owning every defect in every part you did not build.

For the contract-language side of this — the indemnification, flow-down, and remediation-trigger clauses to watch before you sign — that is the next post in this series. And for the conformance-reporting mechanics that make step two of the playbook work, the VPAT and ACR deep-dive is coming up. Together they form the documentation backbone that keeps inherited failures from becoming your failures.