Vendor and Third-Party Accessibility Field Guide

Vendor accessibility can feel like something the team either has or does not have.

In practice, it is usually messier than that.

A vendor may have a VPAT. They may have an accessibility statement. They may have testing notes, known issues, roadmap items, or a support answer that sounds reassuring. Those things can help. They do not automatically tell you whether the version, configuration, integration, workflow, or content you are shipping will work for people.

Use this page when a third-party product, platform, widget, document, embedded service, or purchased tool is part of the experience your users will touch.

The goal is not to make every team a vendor-accessibility auditor. The goal is to ask enough practical questions that accessibility risk is visible before the tool is already selected, configured, launched, or submitted for review.

Start with the part users actually touch

Before asking for evidence, get clear about the user path.

What will someone actually do with the vendor tool?

That might include:

• signing in
• searching
• completing a form
• uploading a document
• reading instructions
• receiving errors
• using a dashboard
• signing or approving something
• downloading a file
• getting help when something does not work

A VPAT for the whole product is useful context. It is not the same as evidence for the exact workflow you are shipping.

If the team cannot describe the user path, the vendor probably cannot give useful accessibility evidence for it yet.

What to ask

Ask questions that connect the vendor's claim to your use case.

Useful questions sound like this:

• Which product version, module, and configuration does your accessibility documentation cover?
• Does the VPAT cover the feature or workflow we plan to use?
• Were customized screens, embedded widgets, themes, documents, forms, or integrations included in testing?
• What assistive technologies and browsers were used during testing?
• What known accessibility issues affect the workflows we are using?
• Which issues are already fixed, which are planned, and which are not currently scheduled?
• Are there setup choices that can make the experience more or less accessible?
• Can you provide sample test results, issue summaries, or remediation notes for this workflow?
• If we configure the tool differently, does the accessibility evidence still apply?
• Who owns accessibility fixes when the issue is caused by configuration, content, integration, or vendor code?

These questions are not meant to trap the vendor.

They are meant to make the risk specific enough that the project team can make a better decision.

What to request

Depending on the tool and risk level, useful evidence may include:

• a current VPAT or accessibility conformance report
• the product version and date covered by the report
• testing scope and excluded areas
• known accessibility issues
• remediation status or roadmap notes
• assistive technology/browser combinations used during testing
• screenshots or examples from the tested workflow
• configuration guidance for accessible setup
• documentation for keyboard support, headings, labels, error handling, and dynamic updates
• support contacts or escalation paths for accessibility defects

The more public-facing or user-critical the tool is, the more specific the evidence should be.

A low-risk internal scheduling widget and a public benefits application flow do not need the same level of evidence. But both should be understood well enough that the team is not surprised later.

What the team still owns

Vendor accessibility does not remove team ownership.

A vendor may own the product code. The project team may still own:

• procurement questions
• requirements and acceptance criteria
• configuration choices
• content entered into the system
• documents generated by the system
• integrations with other services
• testing the workflow as users will encounter it
• tracking known issues and workarounds
• deciding whether a risk is acceptable before launch

This is where teams sometimes get stuck. They treat the vendor claim as the end of the conversation when it should be the beginning of a more specific one.

If the team is shipping the experience, the team needs enough evidence to understand what it is shipping.

When to escalate

Escalate the conversation when:

• the vendor cannot explain what their accessibility evidence covers
• the VPAT is old, vague, incomplete, or for a different version
• the product requires heavy customization before users see it
• the tool handles critical tasks, benefits, payments, legal notices, identity, or time-sensitive actions
• known issues affect task completion, keyboard access, screen reader use, errors, or documents
• the vendor says accessibility depends on configuration but cannot provide configuration guidance
• ownership is unclear between the vendor, project team, implementation partner, and content owner
• the workaround shifts the burden to disabled users

Escalation does not always mean stopping the work.

Sometimes it means getting the right decision-maker to see the risk while there is still time to choose, configure, contract, remediate, or plan support around it.

How this connects to the vendor notes

The related notes are short on purpose. Each one covers a pattern teams run into:

• A VPAT Is Not a Magic Shield — a VPAT is context, not automatic proof that your workflow works.
• Accessibility Evidence Should Match the Thing You Are Shipping — evidence needs to match the version, configuration, and user path.
• Ask Vendors How Accessibility Works in Your Configuration — configuration can change the accessibility reality.
• Vendor Accessibility Still Needs Ownership — someone still has to own decisions, evidence, and follow-through.
• Known Issues Are Better Than Surprise Issues — known issues are easier to manage than late surprises.
• A Vendor Claim Is Not the Same as a Tested Workflow — claims need to be connected to actual task completion.

Use the Vendor Accessibility Questions Checklist when you need a working prompt list instead of the full explanation.

Related Field Guide pages

• Intake Accessibility Questions
• Accessibility Requirements Checklist
• Review Readiness
• Review Readiness Checklist

What to do next

• Ask the vendor for evidence that matches your actual configuration, not only their general product claim.
• Use the Vendor Accessibility Questions Checklist during procurement, renewal, implementation, or review.
• If the vendor tool is part of a larger user task, include it in the Review Readiness Checklist.
• Keep ownership clear: note what the vendor owns, what the team owns, and what still needs verification.