VPAT (Voluntary Product Accessibility Template)

A VPAT (Voluntary Product Accessibility Template) is a standardized document format used to describe how well a technology product — software, hardware, web application, or digital service — conforms to established accessibility standards. The completed document is formally called an Accessibility Conformance Report (ACR), though the terms VPAT and ACR are often used interchangeably in the industry. The VPAT was created by the Information Technology Industry Council (ITI) in partnership with the U.S. General Services Administration (GSA) to provide a consistent format for vendors to communicate their product's accessibility status. The template is organized around specific accessibility criteria from several standards, and for each criterion, the vendor must indicate the level of conformance and provide explanatory remarks. The current VPAT template (version 2.5) supports reporting against four standards: - **WCAG 2.2** (Web Content Accessibility Guidelines) — the international web accessibility standard published by the W3C - **Revised Section 508 Standards** — U.S. federal accessibility requirements that reference WCAG 2.0 Level AA - **EN 301 549** — the European accessibility standard for ICT products and services - **International edition** — combines all three for products sold globally VPATs are primarily used in procurement contexts. When a federal agency, state government, university, or large enterprise evaluates technology products for purchase, they request VPATs from vendors to assess accessibility. A VPAT that shows strong conformance gives a vendor a competitive advantage; one that reveals significant accessibility gaps can disqualify a product from consideration.

Section 508 of the Rehabilitation Act requires that U.S. federal agencies ensure their electronic and information technology is accessible to people with disabilities. This applies to everything the government buys, builds, maintains, and uses — from enterprise software platforms and cloud services to mobile apps and internal tools. Federal procurement officers are legally obligated to consider accessibility when making purchasing decisions, and VPATs are the standard mechanism for this evaluation. The scope extends well beyond the federal government. The refresh of Section 508 in 2017 (which aligned it with WCAG 2.0 Level AA) increased the rigor of accessibility requirements. State governments in at least 40 states have their own accessibility mandates, many of which reference Section 508 or WCAG. Universities receiving federal funding must meet Section 504 requirements, and they increasingly require VPATs from educational technology vendors. Large corporations building out procurement policies also demand VPATs as part of vendor evaluation. For technology vendors, VPATs represent both a business opportunity and a competitive necessity. The federal government is the largest buyer of technology in the world, spending over $100 billion annually on IT products and services. State and local government technology spending adds hundreds of billions more. A vendor without a current, credible VPAT may be excluded from consideration for these contracts. VPATs also serve an internal function. The process of creating a VPAT forces an organization to systematically evaluate its product against accessibility criteria. This evaluation often reveals issues that were not previously known, creating a roadmap for accessibility improvements.

**The template structure.** The VPAT template is organized into tables, each corresponding to a set of standards. For each criterion (e.g., WCAG 2.1 Success Criterion 1.1.1 Non-text Content), the vendor provides: - **Conformance Level**: One of four values — Supports (fully meets the criterion), Partially Supports (some functionality meets it), Does Not Support (fails to meet it), or Not Applicable (criterion is irrelevant to the product). - **Remarks and Explanations**: A description of how the product meets or fails to meet the criterion, including details about specific features, known issues, and workarounds. **Conducting the evaluation.** Creating an accurate VPAT requires a comprehensive accessibility evaluation performed by qualified professionals. This typically involves: 1. **Automated testing** using tools like axe, WAVE, or Lighthouse to identify programmatically detectable issues. 2. **Manual testing** by accessibility experts who evaluate keyboard navigation, screen reader compatibility, content structure, color contrast, and interaction patterns. 3. **Assistive technology testing** using JAWS, NVDA, VoiceOver, and other tools that reflect real user scenarios. 4. **Functional evaluation** of all major product features against each WCAG criterion. **Filling out the template.** Based on the evaluation results, assessors rate each criterion and write detailed remarks. Good VPATs are specific: instead of simply writing "Supports," a thorough VPAT states "All form inputs have programmatically associated labels using the `<label>` element. Error messages are associated with the relevant inputs using `aria-describedby`." **The difference between honest and inflated VPATs.** A common criticism of VPATs is that they are self-reported — there is no mandatory third-party verification. Some vendors inflate their conformance levels, claiming "Supports" for criteria where their product has known issues. Procurement professionals increasingly recognize this and look for specific, detailed remarks as evidence of credibility. Vague VPATs with mostly "Supports" ratings and no explanatory details are a red flag. **VPAT editions.** ITI publishes several editions of the template: - **WCAG edition** — for products evaluated against WCAG only - **Section 508 edition** — for U.S. federal procurement - **EU edition** — for products evaluated against EN 301 549 - **International edition** — combines all standards in one document

**Enterprise SaaS product.** A project management software company creates a VPAT for its web application. The evaluation reveals that most interface components support keyboard navigation and screen reader interaction, but the drag-and-drop Kanban board does not have a keyboard-accessible alternative. The VPAT rates WCAG 2.1.1 (Keyboard) as "Partially Supports" with the remark: "All primary functions including task creation, editing, and status changes are keyboard accessible. The Kanban board view requires mouse interaction for reordering; keyboard-accessible reordering is planned for Q3 2026." **Video conferencing platform.** A video conferencing product creates a VPAT that addresses WCAG 1.2.4 (Captions - Live). The product offers automatic captioning but with imperfect accuracy. The VPAT rates the criterion as "Partially Supports" with the remark: "Automatic live captioning is available in all meetings. Accuracy ranges from 80-95% depending on audio quality, speaker accent, and background noise. Users can also enable CART (Communication Access Realtime Translation) services via third-party integrations for higher accuracy." **Inflated VPAT.** A vendor submits a VPAT that rates every WCAG criterion as "Supports" with minimal remarks. During a product demo for a federal agency, the agency's Section 508 coordinator tests the product and finds missing form labels, no keyboard navigation for key features, and images without alt text. The agency rejects the vendor's bid and flags the VPAT as unreliable. This damages the vendor's credibility for future procurement opportunities.

**Self-evaluating without expertise.** Having a developer or product manager fill out the VPAT without formal accessibility knowledge leads to inaccurate ratings. The evaluation requires understanding WCAG criteria interpretation, assistive technology behavior, and accessibility testing methodology. Use trained accessibility professionals, either internal or external. **Inflating conformance levels.** Marking criteria as "Supports" when the product has known issues is the fastest way to lose credibility with procurement officials. Honest VPATs that acknowledge gaps and provide remediation timelines are more trusted than perfect-looking VPATs that do not match the product's actual accessibility. **Creating the VPAT once and never updating it.** Products change with every release. A VPAT from two years ago does not reflect the current product. New features may have introduced new accessibility issues, or old issues may have been fixed. Update VPATs with each major release cycle or at minimum annually. **Vague remarks.** "This criterion is supported" tells the procurement officer nothing. Specific remarks like "All images include descriptive alt text generated by content authors. Decorative images use empty alt attributes. The image upload workflow includes a mandatory alt text field" provide evidence of genuine evaluation and commitment. **Evaluating only part of the product.** A VPAT should cover all functionality that users will encounter, including onboarding, settings, help documentation, error states, and administrative interfaces — not just the primary user-facing features. Procurement officers expect comprehensive coverage. **Not including a product description.** The VPAT should clearly state what product and version was evaluated, what components are included (web app, mobile app, desktop client), and any dependencies or environmental requirements. Without this context, the report's scope is ambiguous.