Third-party content in a VPAT is disclosed in the scope section. Components outside the vendor’s control are noted, and conformance is rated only for what the vendor owns. Common examples include embedded payment processors, chat tools, video players, and analytics scripts. The ACR states what was evaluated, what was excluded, and why, protecting both buyers and vendors.
| Item | How It Appears in the ACR |
|---|---|
| Scope statement | Lists what was evaluated and what was excluded by name |
| Embedded components | Disclosed and excluded if vendor cannot modify the code |
| Payment processors | Typically excluded with a note pointing to the processor’s own ACR |
| Video players | Player chrome evaluated, but uploaded content quality is content owner responsibility |
| Conformance rating | Applies only to in-scope items; third-party items get a remarks note |
What Counts as Third-Party Content in a VPAT?
Third-party content is any code, asset, or functionality the vendor did not build and cannot modify. The vendor embeds it but does not own it.
Common examples include payment processors like Stripe checkout, embedded video players, live chat tools, social media feeds, map embeds, analytics scripts, advertising tags, and font services. Each of these renders inside the product but lives behind an external API or iframe.
The distinction matters because WCAG conformance assumes the responsible party can fix what fails. If the vendor cannot fix it, claiming conformance for it misrepresents the product.
Why Disclosure Matters in an ACR
An ACR is a procurement document. Buyers use it to evaluate risk, and silence on third-party components creates risk on both sides.
If a vendor claims full WCAG 2.1 AA conformance and the embedded chat tool has keyboard trap issues, the buyer assumes the vendor is responsible. The vendor is then exposed to claims they cannot resolve without removing the tool. Disclosure protects everyone.
The Voluntary Product Accessibility Template was designed with this in mind. Each criterion has a remarks column where vendors can note exactly what is excluded and why.
How to Write the Scope Section
The scope section sits near the top of the ACR. It should name the product, the version evaluated, the environments covered, and any components excluded.
For third-party items, list them by name. Generic phrases like “some embedded content” do not give buyers enough information. A scope statement might read: “This evaluation covers the application interface and user-facing features. The Stripe payment iframe, Intercom chat component, and YouTube video embeds were not evaluated as part of this report. Buyers should consult those vendors’ ACRs directly.”
That single paragraph removes ambiguity. The buyer knows what is covered, what is not, and where to look for the rest.
How Auditors Address Third-Party Components
During a VPAT and ACR engagement, the auditor identifies third-party components early. The conversation happens before evaluation begins, not after.
Generally, content that is a part of the product or service should be reflected in the ACR and that can result in documenting partial conformance with a note that the component is third-party and outside the vendor’s remediation control.
An accessibility evaluation informs the ACR, and the audit report itself can call out third-party issues separately so the vendor has a record even when those items are not part of the conformance claim.
What About iframes the Vendor Configures?
An iframe is third-party code, but the vendor still controls how it is embedded. Missing title attributes, poor placement, or focus management around the iframe are vendor issues. The content inside is not.
This is where the line gets practical. The iframe wrapper is in scope. The rendered content from another domain is not. A good ACR makes this distinction in the remarks for relevant criteria.
How Does This Apply to White-Labeled or OEM Products?
White-labeled products and OEM integrations add another layer. If a vendor resells software built by another company, the responsible party for accessibility depends on who controls the codebase.
The cleanest approach is for the resold component to come with its own ACR. The reseller’s ACR can then reference that document instead of duplicating the work. If no upstream ACR exists, the reseller has to decide whether to commission an evaluation of the component or exclude it with disclosure.
FAQ
Should I exclude third-party content from my VPAT entirely?
Not entirely. List it in the scope section so buyers know it exists. Exclude it from the conformance evaluation only if you cannot modify the code. The disclosure itself is what protects the document’s accuracy.
What if the third-party vendor has their own ACR?
Reference it. A line like “The payment processor maintains its own ACR, available from the vendor directly” tells the buyer where to go. This is standard practice in procurement.
Can I claim WCAG 2.1 AA conformance if third-party content has issues?
Yes, as long as the scope excludes those components and the remarks make the exclusion clear. The conformance claim applies only to what was evaluated.
Does third-party content count against my legal exposure?
Embedded components and integrations that have accessibility issues that can ultimately be the responsibility of the digital asset owner/operator. Disclosing third-party status in the ACR does not eliminate that exposure.
Who decides what gets included in the scope?
The vendor and the auditor decide together before the evaluation begins. The auditor will recommend an approach based on what is technically feasible and what produces a credible report.
An accurate ACR is a careful one. Third-party content gets named, scoped, and documented so the conformance claim reflects what the vendor can actually stand behind.
Contact Accessible.org to discuss your VPAT and ACR needs: Contact Accessible.org.
