Accessibility Field Guide

Vendor Accessibility Questions Checklist

A practical checklist for asking vendors what their accessibility evidence actually covers.

Photo: Notebook and clipboard with papers placed on desk with folders and pens via Pexels — https://www.pexels.com/photo/notebook-and-clipboard-with-papers-placed-on-desk-with-folders-and-pens-5668469/

View full screen Download image

Use this checklist when a vendor product, platform, widget, document tool, or third-party service will be part of the experience users rely on.

This is not a replacement for formal accessibility review. It is a way to ask better questions before the team assumes a vendor claim covers the thing being shipped.

1. Identify the actual user path

[ ] What product, platform, module, widget, or service are we using?
[ ] Which version or release are we using?
[ ] What configuration, theme, template, integration, or customization will users actually see?
[ ] What tasks will users complete in this tool?
[ ] Which parts are public-facing, required, time-sensitive, or tied to important decisions?
[ ] Are documents, PDFs, emails, exports, or notifications generated by the tool?
[ ] Are there alternate paths if the tool does not work for someone?

2. Ask what the accessibility evidence covers

[ ] Does the vendor have a current VPAT or accessibility conformance report?
[ ] What date, product version, and scope does the report cover?
[ ] Does it cover the module or workflow we plan to use?
[ ] Does it cover our configuration, theme, template, or embedded setup?
[ ] Does it cover mobile, responsive, or small-screen behavior if users may need that?
[ ] Does it cover generated documents or exported files?
[ ] What parts of the product were excluded from testing?

3. Ask how the vendor tested

[ ] Was testing automated only, manual only, or both?
[ ] Which assistive technologies were used?
[ ] Which browsers and operating systems were used?
[ ] Were keyboard-only workflows tested?
[ ] Were screen reader workflows tested through actual task completion?
[ ] Were form errors, validation, status messages, modals, file upload, search, or dashboards tested if we use them?
[ ] Were real content and realistic data included, or only sample screens?

4. Ask about known issues

[ ] What accessibility issues are currently known?
[ ] Which issues affect task completion?
[ ] Which issues affect keyboard access, focus, screen reader output, errors, documents, or timing?
[ ] Are any issues specific to certain configurations, browsers, or assistive technologies?
[ ] Which issues are fixed, scheduled, accepted, or not currently planned?
[ ] Is there a workaround, and does it put extra burden on disabled users?
[ ] Who will communicate known issues and workarounds to the project team?

5. Ask about configuration and implementation

[ ] Are there accessibility settings we need to turn on?
[ ] Are there settings, themes, templates, widgets, or plugins we should avoid?
[ ] Does the vendor provide accessible implementation guidance?
[ ] Does the vendor provide examples of accessible configuration?
[ ] Can our content choices make the experience less accessible?
[ ] Can our integration choices break keyboard support, focus order, labels, headings, or status messages?
[ ] If an implementation partner configures the tool, who verifies the configured result?

6. Clarify ownership

[ ] Who owns vendor-code defects?
[ ] Who owns configuration issues?
[ ] Who owns content entered into the system?
[ ] Who owns generated documents and templates?
[ ] Who owns integration issues between systems?
[ ] Who tracks known issues before launch?
[ ] Who decides whether an unresolved issue is acceptable, needs remediation, or needs a different path?
[ ] Who will answer accessibility questions after launch?

7. Capture evidence for review readiness

Before review or launch, try to keep these together:

[ ] VPAT or accessibility conformance report
[ ] report date, product version, and scope notes
[ ] vendor responses to workflow/configuration questions
[ ] known issues and remediation status
[ ] configuration guidance used by the team
[ ] internal notes about what was tested in the configured workflow
[ ] screenshots or examples when they clarify scope
[ ] unresolved risks and ownership decisions
[ ] support or escalation contacts

The point is not paperwork for its own sake.

The point is to make sure the evidence matches the thing the team is actually asking users to use.

A VPAT Is Not a Magic Shield
Accessibility Evidence Should Match the Thing You Are Shipping
Ask Vendors How Accessibility Works in Your Configuration
Vendor Accessibility Still Needs Ownership
Known Issues Are Better Than Surprise Issues
A Vendor Claim Is Not the Same as a Tested Workflow

Vendor and Third-Party Accessibility Field Guide
Intake Accessibility Questions
Accessibility Requirements Checklist
Review Readiness Checklist

What to do next

Save the vendor answers with the procurement, implementation, or review record.
Ask for clarification when evidence does not match your configuration, user flow, or version.
Use Vendor and Third-Party Accessibility Field Guide when the team needs more context for the conversation.
If the vendor piece is part of a release, include it in the Review Readiness Checklist.