Skip to main content
Simkins and Elgazar

What Is a VPAT? A Complete Guide to VPATs and ACRs

Ahmed Elgazar, Simkins & Elgazar
VPATACRSection 508Federal Procurement

If you deliver software, websites, or electronic documents to the federal government, you have likely encountered a request for a VPAT. In federal procurement, this document is not a formality, it is the primary evidence a contracting officer uses to evaluate whether your product meets Section 508 accessibility requirements.

This guide explains what a VPAT is, how it becomes an ACR, what the conformance levels mean, and what separates a credible report from a liability.

What Is a VPAT

A Voluntary Product Accessibility Template (VPAT) is a standardized document published by the Information Technology Industry Council (ITI) that vendors use to describe the accessibility characteristics of a product. The name is somewhat misleading: while the document itself is a template, completing it for federal procurement is functionally required, not voluntary.

The VPAT provides a structured format for reporting how a product conforms, or does not conform, to established accessibility standards. It is the starting point, not the finished product.

How a VPAT Becomes an ACR

A blank VPAT is just a template. When a vendor or evaluator fills it out with product-specific test results and conformance determinations, the completed document becomes an Accessibility Conformance Report (ACR).

The distinction matters. A VPAT is the form. An ACR is the evidence. When a prime contractor or contracting officer asks for a "VPAT," they are almost always asking for a completed ACR. The terms are used interchangeably in practice, but understanding the difference clarifies what is actually being requested: a documented evaluation, not a blank template.

The ACR is what government buyers compare across vendors. It is the document that travels through procurement, gets reviewed by Section 508 program managers, and ultimately supports a buying decision.

The VPAT 2.5 Format

The current version is VPAT 2.5, released in 2023. It offers four edition variants:

  • WCAG Edition, covers WCAG 2.x success criteria only
  • Section 508 Edition, covers WCAG 2.0 AA plus additional Section 508 ICT standards (hardware, software, support documentation, closed functionality)
  • EU Edition, covers EN 301 549, the European accessibility standard
  • INT Edition, covers all three standards in a single document, intended for products sold across jurisdictions

For federal contractors, the Section 508 Edition is the correct choice. Using an outdated VPAT template, versions 1.x or early 2.x, or the wrong edition is a common and avoidable mistake. Always download the current template from the ITI VPAT repository before beginning an evaluation.

The Four Conformance Levels

Every criterion in the VPAT is evaluated against one of four conformance levels. Understanding what each level actually means is essential to reading or producing a credible report.

Supports means the product fully meets the criterion with no known defects. Every user with a disability who relies on that feature can access it without a workaround.

Partially Supports means the product meets the criterion for some functionality or under some conditions, but not all. This level requires a remark explaining what works, what does not, and for which user populations the gap exists.

Does Not Support means the product does not meet the criterion. The feature is inaccessible. This level requires a remark describing the failure.

Not Applicable means the criterion does not apply to this product. A product with no time-based media, for example, would mark all audio/video-related criteria as Not Applicable. This designation also requires a justification, it cannot be used as a blanket default.

A fifth designation, Not Evaluated, is permitted in the VPAT but is not acceptable for federal procurement. It signals that the vendor simply did not test those criteria.

Who Needs a VPAT or ACR

The following categories of organizations are routinely required to produce ACRs:

  • Federal contractors delivering software, web applications, SaaS platforms, or electronic documents under a federal contract
  • Commercial software vendors seeking placement on federal schedules (GSA Multiple Award Schedule, for example)
  • Subcontractors whose deliverables are integrated into a prime contractor's federal product
  • State and local government agencies receiving federal funding, particularly those subject to Title II of the ADA
  • Higher education institutions that procure technology through federal grant-funded programs

Even organizations that are not directly contracting with the federal government may need to produce an ACR if a prime contractor requires one as part of their supply chain compliance program.

Common Mistakes in Self-Reported VPATs

The majority of VPATs in circulation are self-reported, produced by the vendor's own team without independent testing. This is the single largest source of credibility problems in federal accessibility procurement.

Marking criteria as "Supports" without testing. Many vendors complete a VPAT based on developer familiarity with the product rather than structured testing against defined criteria. The result is a document that reflects intent, not reality. Automated scans or keyboard spot-checks do not constitute a complete evaluation.

Vague or missing remarks. "Partially Supports" without a remark explaining what is broken and why is not useful to anyone. VPAT guidance requires that any non-"Supports" designation include a clear explanation. Remarks that say "some issues may exist" without specifics fail this requirement.

Using outdated templates. The Section 508 standards were refreshed in 2017 to incorporate WCAG 2.0. A VPAT completed against the pre-refresh standards is no longer valid for current federal procurement.

Omitting applicable criteria. Products with video content, for example, must address success criteria related to captions and audio description. Leaving these rows blank or marking them "Not Applicable" without justification is a red flag that evaluators are trained to identify.

Confusing "Not Evaluated" with "Not Applicable." These are not the same. "Not Evaluated" means no testing was done. Submitting a VPAT with rows marked "Not Evaluated" to a federal agency is functionally an admission that the evaluation is incomplete.

How an Independent Evaluator Strengthens Your ACR

When a vendor self-certifies their own product, there is an inherent conflict of interest. The development team has strong incentives, financial and reputational, to minimize the severity or frequency of accessibility failures. Contracting officers and Section 508 program managers are aware of this dynamic.

An independent evaluator has no relationship with the product's development history. The evaluation is conducted against defined test criteria without prior knowledge of the product's architecture or known issues. This produces findings that reflect the product as a user actually encounters it, not as the development team believes it to behave.

For federal procurement, an ACR produced by a third-party firm that uses DHS Trusted Tester methodology carries significantly more weight than a self-reported document. It signals that the vendor is confident enough in their product to allow an outside party to document its conformance, and that the resulting report reflects an objective evaluation.

Independent evaluation also benefits the vendor. A third-party evaluation surfaces issues that internal teams have missed or normalized, creating an opportunity to remediate before the report is delivered to the agency.

How the DHS Trusted Tester Methodology Applies to VPAT Evaluations

The Department of Homeland Security developed the Trusted Tester process as a standardized, repeatable methodology for evaluating Section 508 conformance. It is the closest thing the federal government has to an official evaluation protocol for software and web content.

Trusted Tester version 5.x (aligned with the 2017 Section 508 refresh) defines 63 test conditions organized into 10 test process categories. Each test condition maps to one or more WCAG success criteria and specifies exactly how the test is to be performed, including the assistive technologies to be used and the expected outcomes.

This specificity matters for VPAT production. When a VPAT remark states that testing was conducted using DHS Trusted Tester methodology, a reviewing Section 508 program manager can be reasonably confident that each criterion was tested against a defined procedure, not an ad hoc spot-check. This is what distinguishes a tested ACR from an opinion document.

The primary assistive technologies used in Trusted Tester evaluations are:

  • JAWS (Job Access With Speech), the most widely used screen reader in federal agency environments
  • NVDA (NonVisual Desktop Access), an open-source screen reader used as a secondary reference
  • Keyboard-only navigation, testing all functionality without a mouse to evaluate focus management, tab order, and keyboard traps

Evaluations are conducted in specific browser and assistive technology combinations to reflect the environments that federal employees and contract users actually work in. A VPAT produced without documenting the test environment cannot be meaningfully verified or reproduced.

Understanding the Section 508 ICT Standards Beyond WCAG

WCAG success criteria are the most familiar component of Section 508 requirements, but the ICT Accessibility Standards cover significantly more ground. The Section 508 Edition of the VPAT includes conformance tables for several additional standard sets that are often overlooked in evaluations:

Chapter 3 (Functional Performance Criteria) covers accessibility for users with a broader range of disabilities, including those affecting vision, hearing, speech, and cognition. These criteria apply when a product does not conform to the technical requirements but needs to meet functional accessibility requirements instead.

Chapter 4 (Hardware) applies to physical ICT products. If you are delivering hardware, kiosks, document scanners, multi-function printers, this chapter applies.

Chapter 5 (Software) addresses accessibility requirements specific to software applications, including interoperability with assistive technology, documented accessibility features, and authoring tools that produce accessible content.

Chapter 6 (Support Documentation and Services) requires that user documentation, help content, and technical support be accessible. This is frequently overlooked: a product may pass all software criteria while its user manual is a PDF with no tags, no alt text, and no reading order.

For most software and web products delivered to the federal government, Chapters 3, 5, and 6 are the most directly relevant beyond WCAG. An ACR that addresses only the WCAG criteria and leaves the ICT-specific chapters blank is incomplete.

What to Expect from a VPAT Preparation Engagement

A structured VPAT preparation engagement typically follows this sequence:

  1. Scope definition, identify the product components, user workflows, and content types to be evaluated. For complex applications, scope agreement is a standalone step that determines what the ACR covers and, importantly, what it does not.
  2. Automated scanning, establish a baseline of detectable issues across the product's pages and views using tools such as axe-core, WAVE, or Deque's axe DevTools. Automated scans identify roughly 30-40% of accessibility issues; they are a starting point, not a conclusion.
  3. Manual testing, evaluate against the full set of applicable WCAG and Section 508 ICT criteria using Trusted Tester methodology, assistive technologies, and keyboard-only navigation. This step takes the majority of the engagement time.
  4. Conformance determination, assign a conformance level to each criterion with supporting evidence. Determinations are based on the worst observed failure across the tested scope, not the average.
  5. Report authoring, complete the VPAT template with conformance levels, specific remarks for all non-"Supports" designations, and full evaluation methodology documentation.
  6. Remediation consultation, identify the highest-priority issues and provide actionable guidance for development teams. For clients with an upcoming contract deadline, this step helps sequence remediation work by impact and effort.

The output is an ACR that accurately represents the product's current conformance posture and can withstand scrutiny from a Section 508 program office.

How Frequently an ACR Should Be Updated

A VPAT is not a permanent document. It reflects the product at a specific point in time, for a specific version, tested under specific conditions. As the product changes, the ACR becomes stale.

General guidance on refresh cycles:

  • Major version releases require a new evaluation. A new version of a product is not covered by an ACR for a prior version.
  • Significant feature additions that affect user interface, navigation, or content presentation may require a partial re-evaluation of affected criteria.
  • Remediation of documented failures should be followed by re-testing and an updated ACR that documents the improvement. An ACR that reflects known failures the vendor has since corrected is unnecessarily damaging.
  • Annual reviews are a reasonable baseline for products that receive ongoing updates but no single major release.

Contracting officers and primes increasingly ask for the date of the most recent evaluation alongside the ACR. An ACR that is two or three years old for a product in active development is a credibility gap, regardless of the conformance levels it documents.

If your organization needs a credible, independently produced ACR for a federal contract or procurement submission, Simkins & Elgazar conducts VPAT evaluations using DHS Trusted Tester methodology. Review our VPAT and ACR preparation service or contact us to discuss your timeline and scope.