By Nilesh Gadekar, Founder · Last reviewed .
How to use this term in a district project
A VPAT is a reporting template. The completed report, often called an ACR, should be evaluated for the product version, standards, dates, methods, and explanations it contains. The template’s name does not establish product accessibility or replace district evaluation of important tasks. Ask follow-up questions where coverage or a response is unclear.
A district example
Purchasing receives a report with a vendor proposal and checks whether it describes the product version being offered.
A useful review question
Does the completed report cover the actual product, criteria, and tasks we plan to use?
Continue with a practical guide
Explore the related DistrictProof guide or service, or return to the full accessibility glossary. Technical criteria and legal obligations should be checked against the applicable primary references and the agreed review scope.
Understand the document you are requesting
VPAT stands for Voluntary Product Accessibility Template, developed by the Information Technology Industry Council. It is a reporting template used to describe how a product addresses accessibility criteria. A completed report is commonly called an Accessibility Conformance Report, or ACR. District purchasing teams should distinguish the blank template, the completed report and the actual product evaluation. The name of the document alone does not identify the tested product version, the quality of the evaluation or the experience of a family using the product. Reading the details is part of the procurement review.
District example: selecting a board portal
Imagine a fictional district comparing two board portal proposals. Each vendor supplies a completed accessibility report. The purchasing team checks the report date and whether the named product version matches the offered portal. Technology staff review explanations for keyboard operation, document access and forms. The board office asks the vendor to demonstrate finding an agenda and opening its attachments. A strong procurement discussion connects the report with those actual tasks. The district also considers responsibility for uploaded PDF packets, because a portal report does not automatically describe every document the district will publish through it.
Read the scope before comparing ratings
Identify the product, version, edition of the template, standards covered and evaluation methods. Review the remarks for criteria that affect your intended tasks. Broad rating labels are more useful when accompanied by specific explanations of supported behavior, limitations and workarounds. Ask whether the evaluation covered configuration choices or third-party components relevant to your deployment. If the report is old, request an explanation of changes since that evaluation. A document filed during purchasing should remain connected to the version and configuration that the district actually receives and accepts.
Turn unresolved points into procurement questions
Keep a list of the tasks that matter: enrollment, permission forms, agenda navigation, payment steps or document retrieval. Map relevant report explanations to those tasks and request a demonstration where needed. Ask who owns a finding, what correction is planned and how the district will receive an updated report or retest evidence. Distinguish a vendor’s product work from the district’s content responsibilities. Purchasing can place agreed delivery and follow-up requirements in the contract, while the technical team keeps a reproducible issue record for acceptance and later review.
Use reports throughout the product relationship
An accessibility report is useful beyond the initial purchase when it is kept current and connected to product changes. Record who will request updates, review major releases and track unresolved issues. Keep actual user feedback in the same review process so reported barriers reach an owner. For document services, ask for evidence identifying the reviewed files and methods rather than assuming a product-template report is the right deliverable. DistrictProof’s procurement and quality pages explain its document evidence approach. The practical goal is a traceable account of the offered product or completed work, with enough detail for district staff to assess the next decision.