How to Evaluate a VPAT Without Treating It as Proof of Compliance starts with understanding what a VPAT is and what it is not. In procurement and vendor management, teams routinely ask software vendors for a Voluntary Product Accessibility Template, expecting it to answer a simple question: is this product compliant? In practice, the document is only a structured self-disclosure about accessibility support against a standard such as WCAG 2.1 AA, Section 508, or EN 301 549. It can be useful, but it is not certification, not an audit report, and not legal protection by itself.
I have reviewed VPATs during enterprise software selections, renewals, and remediation negotiations, and the pattern is consistent: the strongest teams use a VPAT as one input in a broader procurement workflow. They check how recent it is, whether the product scope is clearly defined, whether claims are supported by testing methods, and whether high-risk barriers are acknowledged with realistic remediation timelines. This matters because inaccessible technology creates legal exposure, blocks employees and customers, slows implementations, and increases downstream costs for support, customization, and retrofits.
For a compliance and implementation program, procurement is where accessibility risk is easiest to control. If the contract is signed before the accessibility facts are known, the organization loses leverage. If the review happens early, teams can compare vendors on evidence, require remediation commitments, and avoid buying a product that fails core user journeys. This article serves as a hub for procurement and vendor management, covering how to read a VPAT critically, what evidence to request next, how to score vendor responses, and how to turn accessibility findings into contract terms and implementation safeguards.
What a VPAT tells you, and what it never proves
A VPAT is the template; an ACR, or Accessibility Conformance Report, is the completed document. Many people use VPAT as shorthand for both, but the distinction matters in vendor management because you are evaluating the completed report, not the blank framework. The common versions are based on WCAG, Revised Section 508, and EN 301 549. The Information Technology Industry Council maintains the template, and the vendor fills it out. That origin alone explains the central limitation: the report is a vendor statement, often useful, sometimes careful, but inherently not independent proof.
The most important rule is simple: a VPAT can support due diligence, but it cannot establish compliance on its own. A product may have a clean-looking report and still fail in production because of configuration choices, custom templates, PDF exports, third-party widgets, mobile differences, or accessibility regressions introduced after the report was written. The reverse is also true. A candid VPAT may list exceptions while the product remains workable for your use case if the vendor has an active remediation plan and your implementation avoids unsupported features. Context determines risk.
Read the conformance language carefully. Terms such as “supports,” “partially supports,” “does not support,” and “not applicable” are meaningful only when paired with remarks that explain impact. “Partially supports” can describe a minor issue with a workaround, or a severe blocker on keyboard use. “Not applicable” may be valid, such as criteria for prerecorded captions in a product with no media, or it may hide vague scoping. If the report does not define the tested product version, platforms covered, assistive technologies used, and evaluation methods, treat every claim as preliminary.
How to review a VPAT like a procurement control
Start by checking document quality before you debate technical details. A credible report names the product, version, date, and modules in scope. It states whether the evaluation covered web, native mobile, desktop client, documents, and embedded third-party components. It also identifies the standard and level used, usually WCAG 2.1 AA for modern procurement. If your organization supports public sector requirements, Section 508 and EN 301 549 mappings may also be necessary, but those mappings still depend heavily on the underlying WCAG findings.
Next, examine the testing methodology. Strong reports describe manual testing, automated scanning, keyboard review, screen reader testing, zoom and reflow checks, color contrast analysis, and testing across supported browsers. Look for named tools and assistive technologies such as JAWS, NVDA, VoiceOver, TalkBack, Axe, WAVE, or Accessibility Insights. Tool names are not magic, but they signal whether the vendor understands how accessibility is actually validated. I place much more weight on a report that states “tested critical workflows manually with NVDA and keyboard only” than on one that lists generic conformance claims without methods.
Then review the remarks by user journey, not by criterion alone. Procurement decisions rarely fail because of an abstract violation count; they fail when a user cannot log in, complete checkout, submit a form, join a meeting, export a report, or approve a workflow. When I assess a VPAT, I map the product’s critical tasks to the relevant criteria and ask whether any issue blocks completion, creates major inefficiency, or affects legal obligations such as accommodation for employees or access for customers. Severity and business impact matter more than the number of rows marked partial.
Finally, compare the VPAT against everything else the vendor has told you. Sales demos, security questionnaires, product roadmaps, release notes, and support documentation often reveal gaps. If a vendor claims keyboard support in the report but the demo requires drag and drop with no alternative, that inconsistency deserves immediate follow-up. If they say PDFs are accessible, request a sample export and test headings, tags, reading order, and table structure. Procurement control means triangulating claims, not accepting a single document at face value.
Red flags that suggest the VPAT is weak or outdated
Some warning signs appear again and again. One is age. A VPAT older than twelve to eighteen months can be stale for fast-moving SaaS products, especially if the vendor releases monthly. Another is a report that covers only a marketing site while the purchased application is a separate authenticated platform. I also treat sparse remarks as a major red flag. If most rows say “supports” with no explanation, there is little evidence behind the conclusion. Serious accessibility work leaves a trail of specific observations.
Watch for overuse of “not applicable,” especially around time-based media, documents, reflow, status messages, or pointer gestures. These criteria often apply somewhere in enterprise products, even if not everywhere. A report that avoids mentioning mobile apps, downloadable files, embedded charts, or admin screens may be excluding the very areas your users depend on. Another red flag is inconsistency in terminology, such as mixing WCAG versions or referencing deprecated success criteria names. It suggests the report was copied forward rather than produced from current testing.
A final warning sign is a VPAT that acknowledges issues but offers no ownership or remediation path. Good vendors know which defects are open, which are scheduled, and which require design changes. Weak vendors write around the problem with phrases like “supports with exceptions” but cannot say whether a fix is planned. In vendor management terms, that means you are being asked to accept unknown risk. Unknown risk becomes expensive after implementation because leverage drops, user complaints rise, and urgent fixes compete with your rollout timeline.
What evidence to request beyond the VPAT
Because the VPAT is not proof, the next step is evidence. Ask for a current accessibility statement, recent audit summary, sample test cases for critical workflows, and a list of known issues with target fix dates. For high-impact systems, request a live accessibility demonstration where the vendor completes core tasks using only a keyboard and, where relevant, a screen reader. This single meeting often reveals more than the report because you can observe focus order, labels, error handling, modal behavior, and whether support staff can answer implementation questions clearly.
Request artifacts tied to your actual use case. If you are buying an HR platform, test application submission, onboarding forms, document signing, and manager approvals. For an analytics tool, test chart accessibility, data tables, filtering, export functions, and PDF or PowerPoint output. For collaboration software, test captioning, transcripts, chat notifications, and meeting controls. Accessibility is feature-specific. A vendor may be strong in the main dashboard and weak in reporting or admin configuration, which means your procurement review should reflect the workflows your people will actually use.
When the product will be configured heavily, ask whether accessibility differs by theme, template, plug-in, extension, or customer-authored content. Many systems are accessible only under default settings. Learning management systems, intranets, CRM platforms, and website builders are common examples because administrators can introduce inaccessible workflows long after purchase. In those cases, vendor responsibility and customer responsibility must be separated. A trustworthy vendor will tell you where the platform enforces accessible patterns and where your implementation team must govern templates, content entry, or custom code.
Scoring vendors and comparing procurement risk
Procurement teams need a repeatable way to compare vendors, not just a pile of documents. I recommend scoring accessibility across four dimensions: document credibility, issue severity, remediation maturity, and implementation dependency. Document credibility covers freshness, scope clarity, and testing detail. Issue severity measures whether barriers affect critical tasks for keyboard, screen reader, low-vision, deaf, hard-of-hearing, or mobility-impaired users. Remediation maturity asks whether defects are logged, prioritized, staffed, and dated. Implementation dependency measures how much accessibility will depend on your own configuration or content governance.
| Dimension | What to assess | Low risk example | High risk example |
|---|---|---|---|
| Document credibility | Date, product version, scope, methods | Current ACR with detailed methods and platform coverage | Two-year-old report with vague scope |
| Issue severity | Impact on critical workflows | Minor contrast issue in nonessential screen | Keyboard trap in checkout or job application |
| Remediation maturity | Ownership, backlog, target dates | Known defects mapped to releases within one quarter | No timeline or accountable team |
| Implementation dependency | Reliance on customer setup or content | Accessible defaults enforced by platform | Accessibility depends on customer-created templates |
This type of model helps avoid false precision. You are not pretending to certify compliance; you are estimating risk and leverage. In one selection I supported, two vendors both submitted VPATs with similar numbers of partial supports. The better choice was the vendor whose report was newer, whose team could demonstrate accessible workflows live, and whose contract accepted remediation milestones. The other vendor minimized issues and resisted commitments. The technical differences were not huge on paper, but the implementation risk was dramatically different.
Turning VPAT findings into contracts, implementation, and governance
The procurement review only matters if findings change decisions and obligations. If accessibility is a requirement, put it into the contract. Common terms include a representation that the product conforms to specified standards except as disclosed, a commitment to maintain or improve conformance, prompt notice of material regressions, cooperation on accessibility issues, and remediation timeframes for high-severity defects. Some organizations also require escrow-like protections such as service credits, termination rights, or holdbacks when critical accessibility defects remain unresolved. Legal language should align with your risk tolerance and sector requirements.
Implementation planning should reflect known gaps. If the VPAT or audit shows issues in a reporting module, do not discover that during training week. Build workarounds, phased rollouts, or alternate processes before launch. Assign owners across procurement, legal, accessibility, product, IT, and business operations. Accessibility defects often sit between teams unless responsibility is explicit. I also recommend a post-implementation validation step, because even a good vendor can ship regressions or miss configuration-specific problems. Spot-check the workflows you considered critical during selection and compare the deployed state with the evidence you reviewed.
As a hub for procurement and vendor management, the practical lesson is straightforward: treat the VPAT as the beginning of due diligence, not the end of it. Use it to ask sharper questions, target demonstrations, compare risk, and negotiate enforceable commitments. That approach protects users and gives your team better buying power. If you manage software selection, renewals, or implementation, build a standard accessibility review path now: request current reports, validate critical workflows, score vendor risk, and carry the findings into the contract and rollout plan.
Frequently Asked Questions
What is a VPAT, and why should it not be treated as proof of compliance?
A VPAT, or Voluntary Product Accessibility Template, is a standardized document vendors use to describe how their product supports accessibility requirements under frameworks such as WCAG 2.1 AA, Section 508, or EN 301 549. The key point is that a VPAT is a disclosure tool, not a certification, legal determination, or independent audit result. It helps a vendor communicate where accessibility features exist, where support is partial, and where issues may still remain. That makes it useful in procurement and vendor review, but it does not by itself confirm that a product is fully compliant in real-world use.
One reason teams over-rely on VPATs is that the document appears formal and technical. It often contains detailed tables, conformance language, and references to standards, which can give the impression that the matter has already been settled. In reality, the quality of a VPAT depends heavily on how it was prepared. Some are based on rigorous internal testing or third-party review, while others are broad, outdated, incomplete, or written in a way that minimizes risk without clearly explaining limitations. Even an honestly prepared VPAT is still a point-in-time statement that may not reflect current versions, user configurations, assistive technology combinations, or recent releases.
For that reason, the best way to use a VPAT is as one input in a broader accessibility due diligence process. It should help your team ask better questions, identify likely risk areas, and decide what to test next. If you need confidence for procurement, legal review, or public-sector obligations, you should pair the VPAT with supporting evidence such as test methodology, issue logs, remediation commitments, accessibility roadmaps, and, ideally, hands-on validation by qualified accessibility specialists and users of assistive technology.
How can you tell whether a VPAT is credible and useful during procurement or vendor review?
A credible VPAT usually shows signs of specificity, recency, and technical substance. Start by checking the version date, product name, product version, platform coverage, and the exact standard being evaluated. A useful VPAT should clearly identify whether it applies to a web application, mobile app, desktop software, PDFs, or all of the above. If the document is old, vague about scope, or silent on which product version was reviewed, its value drops quickly. Accessibility changes with every release, so a VPAT without version clarity may describe a product that no longer exists in the same form.
Next, look closely at how the vendor describes support levels. Strong VPATs do more than mark items as “Supports” or “Partially Supports.” They include meaningful remarks that explain known limitations, affected workflows, and the conditions under which support was evaluated. For example, a useful entry might note that keyboard navigation works across most screens but fails in a drag-and-drop component, or that screen reader labels are present in core workflows but incomplete in administrative settings. Generic statements repeated across many criteria can be a warning sign that the template was completed at a surface level rather than through careful testing.
It also helps to ask who completed the VPAT and how. Was it prepared internally by a knowledgeable accessibility team, by a consultant, or by a general product manager with limited testing background? Did the vendor use manual testing, automated scanning, assistive technology checks, and user scenario reviews? Can they provide a summary of methods, test environments, and known exceptions? A credible vendor should be able to explain the process behind the document. The more transparent they are about testing methods and unresolved issues, the more confidence you can place in the VPAT as a serious disclosure rather than a marketing attachment.
What red flags in a VPAT suggest you should investigate further before relying on it?
One major red flag is overly perfect conformance claims without meaningful detail. If a complex product claims full support for nearly every criterion yet provides little explanation, that should prompt skepticism. Modern software products, especially large platforms with dynamic interfaces, integrations, reporting tools, and administrative panels, almost always have at least some accessibility limitations. A VPAT that reads as flawless may indicate shallow review, overly generous interpretation of the criteria, or reluctance to document known issues. Perfection is not impossible, but it is unusual enough that it should be backed by strong evidence.
Another warning sign is boilerplate language that appears copied across dozens of success criteria. If every row uses the same generic sentence, the VPAT may not reflect criterion-by-criterion evaluation. You should also be cautious when the remarks do not mention specific workflows, components, or assistive technology behavior. Accessibility is experienced in real interactions, not abstract labels. If the VPAT never discusses forms, modals, tables, navigation patterns, error handling, focus order, or non-text content, it may not give your team enough practical information to assess risk.
Additional red flags include outdated dates, missing platform distinctions, unexplained exclusions, and unsupported references to future fixes. A vendor may note that certain issues are “planned for resolution” or “on the roadmap,” but roadmap language is not the same as remediation evidence. Similarly, if the VPAT is based only on automated tools, that is not enough for a reliable accessibility evaluation. Automated testing can catch some issues, but it cannot verify many critical requirements involving keyboard behavior, screen reader usability, meaningful sequence, instructions, and interactive state changes. When you see these signs, treat the VPAT as a starting point for deeper questioning, not as a dependable endpoint.
What questions should you ask a vendor after reviewing their VPAT?
After reading a VPAT, your follow-up questions should focus on testing depth, issue transparency, and remediation maturity. Start by asking how the document was created: what standards were used, what versions of assistive technologies and browsers were tested, whether manual testing was performed, and whether accessibility specialists or users with disabilities participated in evaluation. This helps you understand whether the VPAT reflects a disciplined review process or a minimal documentation exercise. If the vendor cannot explain the methodology behind the VPAT, that is an important signal in itself.
You should also ask for evidence tied to risk areas relevant to your organization’s use case. For example, if your teams depend heavily on dashboards, document export, data tables, or workflow approvals, request clarification on those specific functions. Ask the vendor to identify known accessibility limitations, severity levels, workarounds, and expected remediation timelines. If they say a criterion “Partially Supports,” press for operational details: what exactly does not work, who is affected, how often the issue appears, and whether there is an accessible alternative. The goal is not to trap the vendor; it is to convert broad disclosure into actionable risk information.
Finally, ask questions that reveal the vendor’s accessibility program, not just the status of a single document. Do they have an internal accessibility policy? Is accessibility included in design, QA, and release processes? How often is the VPAT updated? Do they maintain an issue backlog and publish release notes related to accessibility fixes? Can they share audit summaries or sample defect reports? Vendors that treat accessibility as an ongoing product discipline are generally more reliable partners than vendors that produce a VPAT only when procurement requests one. A strong answer set will give you more confidence than the VPAT alone ever could.
What is the best way to use a VPAT as part of a broader accessibility evaluation process?
The most effective approach is to treat the VPAT as a screening and scoping document. It can help your team understand which standards the vendor considered, where they claim support, and where they already acknowledge gaps. From there, you can prioritize review of high-impact workflows and higher-risk criteria. For instance, if the product will be used by employees or customers for critical tasks such as enrollment, reporting, purchasing, or communication, your evaluation should focus on whether those tasks are actually usable with keyboard navigation, screen readers, zoom, color contrast requirements, and error recovery—not just whether the VPAT includes favorable labels.
In practice, a sound process often combines document review, targeted testing, and contractual follow-up. Review the VPAT first, then validate representative workflows through manual accessibility testing. If possible, include testing with assistive technologies commonly used in your environment. Compare what your testing finds with what the VPAT claims. Any mismatch is valuable because it tells you whether the document is current, accurate, and sufficiently detailed. If accessibility issues are found, assess their severity in relation to your legal obligations, user population, and business dependence on the product.
The final step is to turn what you learn into procurement and governance decisions. If the product is otherwise a strong fit but has accessibility gaps, document those issues, require remediation commitments, define timelines, and consider contract language around accessibility support and updates. If the product is high risk and the vendor cannot provide credible evidence or a realistic remediation path, the VPAT should not shield that product from further scrutiny. Used properly, a VPAT helps structure the conversation. It is valuable because it informs evaluation, not because it replaces it.
