Before Filling Out A VPAT
Define product scope, supported platforms, user roles, critical workflows, third-party components, and documentation included in the review.
Gather evidence from automated checks, keyboard testing, screen reader review, design-system documentation, and remediation tickets.
Common Gaps
Teams often lack evidence for authenticated workflows, PDF exports, keyboard traps, error messages, charts, tables, and custom widgets.
A VPAT should not hide known issues. It should describe support levels and planned fixes accurately.
Procurement Answer Pack
Prepare a current accessibility statement, support contact, roadmap summary, exception list, testing method, and escalation owner for buyer questions.
Standards Scope Examples
A procurement-ready ACR should identify whether the review maps to WCAG 2.2, Section 508, EN 301 549, or buyer-specific requirements.
Define included environments such as web app, public marketing site, mobile web, native app, admin console, exported documents, help center, and embedded third-party services.
Evidence Artifacts To Keep
Keep dated test plans, workflow lists, browser and assistive-technology combinations, automated scan exports, manual keyboard notes, issue tickets, screenshots, and remediation decisions.
For buyer follow-up, prepare plain wording for partially supported criteria, known exceptions, expected remediation timing, and the support channel that receives accessibility issues.
Frequently asked questions
Is a VPAT the same as an accessibility audit?
No. A VPAT reports conformance status, while an audit produces evidence, findings, and remediation recommendations.
Should a startup publish a VPAT before testing?
No. First gather evidence and understand exceptions so the report is accurate and credible.