How to Use Vendor VPATs in Your Accessibility Statement (2026 Guide)

A step-by-step guide to requesting, evaluating, and incorporating third-party accessibility documentation into your organization’s accessibility statement.

Your website’s accessibility statement probably says something about your commitment to WCAG 2.2 AA conformance. But here’s the question most organizations never ask: does that statement account for the third-party tools embedded across your site?

The chatbot in the corner. The payment processor on checkout. The video player on your training pages. The analytics scripts running in the background. The form builder powering your contact page. Every one of these tools either supports or undermines your accessibility posture — and if you haven’t looked at their VPATs, your accessibility statement has a blind spot.

This guide walks you through the full process of identifying the third-party tools on your site, requesting their VPATs (Voluntary Product Accessibility Templates), evaluating what those documents actually tell you, and translating that information into meaningful language for your accessibility statement.

What Is a VPAT and Why Does It Matter for Your Accessibility Statement?

A VPAT is a standardized document where a vendor self-reports how their product conforms to accessibility standards. The document follows a template maintained by the Information Technology Industry Council (ITICl) and typically maps a product’s features against WCAG 2.x success criteria, Section 508 requirements, and sometimes EN 301 549 (the European standard).

The completed version of a VPAT is called an Accessibility Conformance Report, or ACR. You’ll hear both terms used interchangeably, but technically, the VPAT is the blank template and the ACR is the filled-in version. For this guide, we’ll use “VPAT” as the common shorthand since that’s what most people search for and what most vendors call their documentation.

Here’s why this matters for your accessibility statement: your website isn’t just your code. It’s every piece of functionality a user interacts with, including third-party components. When a screen reader user hits a chatbot widget that traps keyboard focus, that’s your accessibility problem — regardless of who built that widget. When a payment form lacks proper labels, the user doesn’t care whether it was coded by your team or embedded via a third-party script.

Your accessibility statement should reflect reality, not aspiration. And reality includes the accessibility posture of every third-party tool your visitors interact with.

Step 1: Inventory Every Third-Party Tool on Your Site

Before you can request VPATs, you need a clear picture of what’s actually running on your website. Most organizations significantly undercount their third-party integrations.

Start with a systematic audit. Walk through your site as a visitor would and document every tool, widget, embed, or integration that comes from an external vendor. Here’s a framework for categorizing what you find:

User-facing interactive tools — These are your highest priority because users interact with them directly. Think chatbots, live chat widgets, appointment schedulers, payment processors, form builders, video players, social media feeds, and comment systems.

Functional embeds — Maps, calendars, document viewers, survey tools, learning management system (LMS) embeds, and CRM-connected forms. These appear as integrated parts of your pages but are served by a third party.

Content delivery tools — CDN-hosted fonts, icon libraries, and media players. These affect how content renders and whether assistive technologies can interpret it correctly.

Analytics and tracking scripts — While these are mostly invisible to users, some create cookie consent banners, notification bars, or preference centers that users must interact with. Those UI elements need to be accessible.

Authentication and identity tools — Single sign-on widgets, CAPTCHA systems, identity verification tools. These are often gatekeepers to critical functionality, making their accessibility especially important.

Create a simple spreadsheet with columns for the tool name, the vendor, what it does, where it appears on your site, and whether it has direct user interaction. That last column helps you prioritize — user-facing tools with direct interaction are where VPAT documentation matters most.

Step 2: Request VPATs from Your Vendors

With your inventory complete, it’s time to reach out to each vendor. Some make this easy. Others make it surprisingly difficult.

Check the vendor’s website first. Many established vendors publish their VPATs or ACRs publicly, often under headings like “Accessibility,” “Compliance,” or “Trust Center.” Look in the footer navigation, the legal section, or a dedicated accessibility page. If the company serves government or education clients, they’re more likely to have this documentation readily available.

If it’s not published, send a direct request. Here’s a template you can adapt:

Subject: Request for VPAT / Accessibility Conformance Report

Hi [Vendor Name] team,

We’re updating our website’s accessibility statement and reviewing the accessibility conformance of all third-party tools integrated into our site. We currently use [Product Name] for [brief description of use case].

Could you provide your current VPAT or Accessibility Conformance Report (ACR) for [Product Name]? Specifically, we’re looking for documentation covering WCAG 2.1 AA or WCAG 2.2 AA conformance.

If you have a published accessibility statement or roadmap for upcoming accessibility improvements, that would also be helpful.

Thank you for your time.

What the response tells you beyond the document itself:

A vendor’s response to a VPAT request is revealing. Companies that take accessibility seriously will respond quickly with current documentation. Companies that don’t may take weeks, provide outdated reports, or respond with confusion about what you’re asking for. That signal matters — it tells you something about how that vendor prioritizes accessibility in their product development cycle.

If a vendor can’t provide a VPAT at all, that’s important information. It doesn’t automatically mean their product is inaccessible, but it means they haven’t formally assessed or documented their conformance. You’ll need to decide what that means for your organization’s risk tolerance and whether to document that gap in your accessibility statement.

Step 3: Evaluate What the VPAT Actually Tells You

Having a VPAT in hand is a starting point, not a finish line. These documents vary enormously in quality, honesty, and usefulness. Here’s how to read them critically.

Check the basics first

Date and version. A VPAT from 2019 evaluating WCAG 2.0 isn’t particularly useful in 2026. Look for reports that are less than two years old and that evaluate against WCAG 2.1 AA at minimum, ideally WCAG 2.2 AA.

Product version. The VPAT should specify which version of the product was evaluated. If you’re running a different version — especially a significantly newer or older one — the findings may not accurately reflect what’s on your site.

Evaluation method. Some VPATs are based on internal self-assessment. Others involve third-party auditors. Third-party evaluations generally carry more weight, though a thorough internal assessment from a company with a dedicated accessibility team can be credible.

Understand the conformance levels

VPATs use specific language to describe how well a product meets each success criterion:

Supports — The product fully meets this criterion.
Partially Supports — Some aspects of the product meet this criterion, but others don’t.
Does Not Support — The product doesn’t meet this criterion.
Not Applicable — This criterion doesn’t apply to the product.
Not Evaluated — The vendor hasn’t tested this criterion.

Pay special attention to “Partially Supports” entries. The remarks column should explain what works and what doesn’t. Vague language like “some issues may exist” without specifics is a red flag — it often means the vendor knows there are problems but hasn’t characterized them.

Focus on what matters for your use case

You don’t need to evaluate every line of a VPAT equally. Focus on the WCAG success criteria most relevant to how the tool appears on your site. For example:

If the tool is a form builder, pay close attention to: 1.3.1 (Info and Relationships), 1.3.5 (Identify Input Purpose), 2.4.6 (Headings and Labels), 3.3.1 (Error Identification), 3.3.2 (Labels or Instructions), and 4.1.2 (Name, Role, Value).

If the tool is a video player, focus on: 1.2.1 through 1.2.5 (time-based media alternatives), 2.1.1 (Keyboard), and 4.1.2 (Name, Role, Value).

If the tool is a chatbot or interactive widget, pay close attention to: 2.1.1 (Keyboard), 2.1.2 (No Keyboard Trap), 2.4.3 (Focus Order), and 4.1.2 (Name, Role, Value).

Red flags in vendor VPATs

Watch for these warning signs that suggest a VPAT may not be reliable:

The document claims full “Supports” across nearly every criterion. Very few complex software products fully support every WCAG success criterion. Universal claims of full conformance should trigger skepticism, not confidence.

The remarks column is empty or contains only generic language. A credible VPAT includes specific, detailed explanations of how each criterion is met or where gaps exist.

The evaluation doesn’t distinguish between different product components or user flows. A payment form has different accessibility considerations than a reporting dashboard. Blanket assessments across an entire product suite are less useful than component-specific evaluations.

Step 4: Translate VPAT Findings into Accessibility Statement Language

Now comes the practical part — turning what you’ve learned into language that belongs in your accessibility statement. The goal is transparency, not perfection. An accessibility statement that honestly acknowledges known limitations from third-party tools is far more useful (and legally defensible) than one that pretends those tools don’t exist.

Structure for third-party tool disclosures

Your accessibility statement should include a dedicated section addressing third-party content. Here’s a framework:

Open with your general approach. Explain that your site integrates third-party tools and that you’ve reviewed their accessibility documentation.

Identify the categories of tools, not necessarily each individual vendor (unless you want to). Grouping by function — payment processing, video playback, chat functionality — often reads more clearly than a vendor-by-vendor list.

State the conformance standard you’ve evaluated against. This should match what your own site targets, typically WCAG 2.2 AA.

Acknowledge known limitations. If a vendor’s VPAT reveals gaps, describe them in functional terms. “Our embedded video player may not provide full keyboard navigation for all playback controls” is more useful to visitors than citing specific WCAG success criteria numbers.

Describe your mitigation approach. What are you doing about identified gaps? This might include working with the vendor on fixes, providing alternative ways to access the same functionality, or evaluating replacement tools.

Before and after: what better disclosure looks like

Before (generic, uninformative):

“We strive to ensure our website is accessible. Some third-party content may not be fully accessible.”

After (specific, transparent, actionable):

“Our website integrates several third-party tools to provide core functionality, including payment processing, live chat, and video playback. We have reviewed the accessibility documentation (VPATs/ACRs) for each of these tools against WCAG 2.2 AA standards.

Based on our review, the following known limitations exist:

Our live chat widget provides keyboard navigation for core functions but has limited screen reader support for chat history. We are working with the vendor on improvements targeted for [timeframe]. In the meantime, users who encounter barriers can reach us at [contact method] for equivalent assistance.

Our embedded video player supports closed captions and audio descriptions but does not currently support full keyboard control of playback speed adjustment. We provide direct download links for all video content as an alternative.

We review vendor accessibility documentation annually and when major product updates are released. If you encounter an accessibility barrier with any feature on our site, including third-party tools, please contact us at [contact information].”

The difference isn’t just length — it’s specificity and accountability. The second version tells visitors exactly what to expect and gives them a clear path to get help.

Step 5: Build an Ongoing Review Process

VPATs aren’t a one-time exercise. Products change, vendors update their tools, and your own site evolves. Build a review cadence into your accessibility practice.

Annually, at minimum, request updated VPATs from all vendors with user-facing tools on your site. Many vendors publish new ACRs when they release major versions. Put this on your calendar alongside your own site’s accessibility review cycle.

When you add a new tool, request the VPAT before integration — not after. Make accessibility documentation part of your vendor evaluation criteria. It’s significantly easier to choose an accessible tool upfront than to remediate or replace an inaccessible one later.

When vendors update their products, check whether the update affects the components used on your site. Major version changes are especially worth reviewing, as they may introduce new accessibility issues or resolve existing ones.

When you update your accessibility statement, cross-reference it against your current vendor inventory. Tools get added and removed from websites all the time. Your statement should reflect what’s actually on your site today.

Putting It All Together: Your VPAT Review Checklist

Here’s a condensed action plan you can start working through today:

Inventory all third-party tools on your site, categorized by type and user interaction level.
Check each vendor’s website for published VPATs or ACRs.
Send formal VPAT requests to vendors without published documentation.
Evaluate each VPAT for currency, evaluation method, and relevance to your use case.
Identify gaps — both where VPATs reveal “Does Not Support” or “Partially Supports” entries and where vendors can’t provide documentation at all.
Draft accessibility statement language that specifically addresses third-party tool limitations.
Define mitigation strategies for each known gap (vendor engagement, alternative access methods, tool replacement).
Set a calendar reminder for annual VPAT re-requests and accessibility statement updates.
Make VPAT requests part of your procurement process for any new tool evaluated going forward.

VPATs Are One Piece of Your Accessibility Picture

Reviewing vendor VPATs and updating your accessibility statement is a meaningful step toward genuine compliance — but it’s important to recognize what VPATs can and can’t tell you. A VPAT is a vendor’s self-reported assessment. It doesn’t replace testing those tools in the context of your actual site, where the interaction between your code and theirs may create accessibility issues that neither party’s documentation anticipates.

The most complete accessibility practice pairs documentation review with real scanning of your site as visitors experience it. Tools like Insi use virtual browser technology to scan your pages the way a real browser renders them — catching issues that emerge from the interplay between your content, your theme, your plugins, and your third-party integrations. That kind of testing can reveal whether a vendor’s VPAT claims hold up in practice or whether there are gaps their documentation doesn’t cover.

Your accessibility statement should be a living document — honest about where you are, clear about where you’re going, and specific enough to actually help the people who need it.