The Map, the Payment Portal, the Embedded Video: Who Is Responsible When the Inaccessible Part Isn't Yours?

You have done the hard part. Your pages are tagged, your headings are in order, your colour contrast passes. Then someone runs a scan and the failures come back from the places you do not control: the interactive map on the parks page, the payment portal your utility billing runs through, the video embedded from a platform you do not own, the chat widget procured three years ago by a department that no longer exists.

The instinct is to treat these as someone else’s problem. They are on someone else’s servers, written by someone else’s developers, governed by someone else’s roadmap. That instinct is wrong, and the regulation is unusually clear about why.

What does the rule actually say about third-party content?

The ADA Title II web rule lists its exceptions at 28 CFR § 35.201. One of them covers third-party content, and it is worth reading in its literal form, because the second half is where most people stop too early:

Content posted by a third party, unless the third party is posting due to contractual, licensing, or other arrangements with the public entity.

That clause draws a line, and the line is control through a relationship, not authorship and not hosting.

On the exempt side sits content posted by people who have no arrangement with you: a member of the public commenting on your forum, a resident posting on your message board, community-contributed entries on a wiki you host. You did not commission it, you do not pay for it, and you cannot dictate how it is written.

On the covered side sits essentially everything you procured. If a vendor operates a payment portal on your behalf, that portal is delivering your service. If you license a mapping widget and embed it on your facilities page, you have a licensing arrangement. If a contractor builds and hosts your permit application system, the fact that the domain belongs to them changes nothing. The content is posted because of an arrangement with you, so the exception does not reach it.

The practical test is short: did money, a contract, or a licence pass between you and whoever put that content there? If yes, assume it is yours.

Why does “it’s the vendor’s widget” fail as a defence?

Because the obligation under Title II attaches to the service, program or activity, not to the server it happens to run on. A resident paying a water bill is participating in your program. Whether the payment form is rendered by your CMS or by a processor’s iframe is an implementation detail from the resident’s perspective, and the regulation follows the resident’s perspective.

This is the same reasoning that runs through the rest of Title II. A public entity cannot contract its way out of an access obligation by outsourcing the function. Delegating the work delegates the work; it does not delegate the duty.

Which of the compliance regimes applies to you, and on what timeline, is set out in our ADA Title II deadline post — that post is the single place we keep those dates, so it is always current.

Which third-party components actually fail most often?

In practice the recurring offenders cluster into a handful of categories, and they fail in predictable ways.

Interactive maps. Almost universally a problem. Pan-and-zoom controls that cannot be operated by keyboard, location markers conveyed only by colour and position, and no text equivalent for the information the map conveys. The fix is rarely to make the map itself conformant — it is to provide the same information in an accessible form alongside it: a list of facilities with addresses, hours and accessibility features, marked up as real text.

Payment and billing portals. High stakes, because failure here blocks a transaction rather than a browse. Typical failures are unlabelled form fields, error messages announced only visually, session timeouts that give no warning or extension, and CAPTCHA with no non-visual alternative.

Embedded video. Auto-generated captions are not captions for compliance purposes — they are a draft. They routinely mangle proper nouns, technical terms and anything spoken with an accent, and they do not include speaker identification or non-speech audio. Where video carries information not available in the audio track, audio description is also in scope. Our accessible video page covers what a compliant caption and description deliverable actually contains.

Document viewers and repositories. Agenda-management systems, records portals and e-signature tools frequently render documents into an inaccessible viewer, or serve untagged PDFs that were untagged when uploaded. The viewer and the document are two separate failures and need two separate fixes.

Chat, calendar and survey widgets. Usually procured fast, often by a single department, and almost never with an accessibility requirement in the purchase order.

How do you fix something you did not build?

You have four real options, and the order matters.

1. Check the contract you already have. Many vendor agreements contain an accessibility or compliance warranty that nobody has invoked. If the vendor promised conformance and did not deliver it, that is a commercial conversation, not an engineering project, and it is by far the cheapest route.

2. Ask for the ACR, and read it properly. Request a current VPAT or Accessibility Conformance Report for the specific version you are running. A report that is undated, covers a different product line, or marks everything “Supports” with no remarks is not evidence. What a VPAT actually is explains how to read one critically and what a credible one contains.

3. Provide an accessible equivalent. Where the component cannot be fixed on your timeline, supply the same information and the same ability to transact through a route that works — a text listing beside the map, a downloadable accessible form with a staffed processing path beside the portal, a transcript beside the video. Document that the equivalent exists, where it is, and that it is kept current.

4. Replace it, and write the requirement into the next purchase. The permanent fix is procurement. A component bought without an accessibility requirement will be inaccessible roughly as often as chance allows. Writing accessibility into an RFP or scope of work covers the clause language that makes this the vendor’s problem before you sign rather than yours afterwards.

What about the multilingual layer?

Here is the failure we see most often in entities that are otherwise doing well. An agency procures a translation widget or a translated portal, ships it, and inherits two problems at once: the translated content does not carry per-passage language markup, so a screen reader reads Spanish with English pronunciation rules, and the vendor’s translated interface strings were machine-generated and never reviewed.

That is a Title VI exposure and a WCAG exposure arriving in the same component. Title VI of the Civil Rights Act remains the correct authority for language access obligations, and it is untouched by the revocation of the executive order that used to be cited alongside it — we cover that change here. The accessibility side is WCAG 3.1.2 and the language-of-parts problem.

A vendor who handles one of these rarely handles the other. Checking both at procurement time costs an afternoon; discovering both after go-live costs a rebuild.

Where to start this week

Inventory before you remediate. List every embedded, iframed or vendor-hosted component across your site, and for each one record: what service it delivers, which contract or licence covers it, whether an ACR exists, and whether an accessible equivalent is currently available. Most entities find far more components than they expected, because nobody had ever thought of a map or a chat box as content.

Then sort by consequence. A component that blocks a payment, an application or an emergency notification outranks a component that decorates a landing page, regardless of how each one scores in a scan.

Have a third-party component you are not sure you are responsible for? Send us the list — the component, what service it delivers, the vendor’s ACR if you have one, and the languages you publish in — and request a quote. We will tell you which items the exception genuinely covers, which ones do not, and what an accessible equivalent would take to produce. Our accessibility and compliance services page covers how we handle the accessibility and language-access sides as one engagement.