Vendor accessibility documentation is more than a VPAT, and teams that treat the VPAT as the entire record usually discover the gap during procurement, remediation, or litigation. In accessibility programs I have helped build, the most expensive mistakes rarely came from missing one form; they came from missing evidence that showed what a vendor claimed, what was tested, what failed, what was fixed, and what risk the buyer accepted. This matters because digital products now sit inside employment, education, healthcare, banking, and public services, where inaccessible software creates legal exposure, operational friction, and direct harm to users with disabilities.
A VPAT, or Voluntary Product Accessibility Template, is the standard format vendors use to explain how a product aligns with accessibility requirements such as WCAG 2.1 AA, Section 508, or EN 301 549. The completed VPAT is commonly called an Accessibility Conformance Report. It is useful, but it is not proof of full accessibility, and it is not a complete compliance file. A mature documentation set also includes test plans, defect logs, product roadmaps, policy statements, support procedures, exception approvals, and communication records that show whether the vendor can maintain accessibility over time.
Documentation, records, and evidence matter because accessibility is not a one-time feature review. Software changes, integrations break labels, mobile updates alter focus behavior, and third-party widgets introduce new barriers. Buyers need a defensible record that supports vendor selection, contract terms, implementation decisions, and ongoing monitoring. Internal stakeholders also need different levels of detail: procurement wants consistent evaluation artifacts, legal wants substantiated statements, security and architecture teams want version-specific details, and disability inclusion teams want confidence that issues reported by users will actually be resolved.
This hub article explains what to keep beyond the VPAT, how each record fits into a practical governance model, and how to organize evidence so it remains useful after the purchase order is signed. If your goal is to build a documentation trail that supports audits, renewals, remediation, and informed risk decisions, this page gives you the framework.
The VPAT’s role and its limits
The VPAT is best understood as a structured disclosure, not a certification. It tells you how a vendor says its product meets specific accessibility criteria and where it does not. A strong report identifies product version, testing scope, evaluation methods, and remarks for each criterion. A weak report uses vague phrases such as “supports with exceptions” without naming the exception, affected workflow, severity, or workaround. In practice, many accessibility reviews begin with the VPAT but should never end there.
There are three common limits. First, the VPAT may be outdated. I regularly see reports tied to a release from twelve or eighteen months ago, while the production tenant uses a newer interface. Second, the VPAT may be incomplete in scope. Native mobile apps, embedded PDFs, admin interfaces, support portals, video players, and procurement-only modules are often excluded unless the buyer asks directly. Third, the VPAT rarely shows operational maturity. It does not tell you whether the vendor has an accessibility bug intake process, how fast critical defects are fixed, or whether future releases are regression tested.
For those reasons, a VPAT should anchor the file, but supporting records must answer the questions the VPAT cannot. What evidence backs the claims? Which user journeys were tested? What issues remain open? Who owns remediation? What contractual commitments exist? And what has your organization accepted as residual risk?
Core records every buyer should keep
A complete vendor accessibility file should preserve evidence across the product lifecycle, from evaluation through renewal. The following records form the backbone of that file and should be retained in a system with version history, clear ownership, and access controls.
| Record | What it proves | Why it matters |
|---|---|---|
| Accessibility Conformance Report | Vendor’s stated conformance by standard and version | Baseline disclosure for procurement review |
| Test methodology summary | Tools, assistive tech, browsers, devices, and pages tested | Shows whether claims are credible and relevant |
| Issue log or defect register | Known barriers, severity, affected users, status, target dates | Supports remediation tracking and risk acceptance |
| Roadmap or remediation plan | Planned fixes, sequencing, dependencies, owners | Separates aspirational promises from scheduled work |
| Contract language and SLAs | Accessibility commitments, notice duties, cure periods | Creates enforceable obligations after purchase |
| Support and accommodation procedures | User reporting channels and interim workarounds | Reduces harm while defects remain unresolved |
| Exception or risk approval memo | Decision rationale for buying with known gaps | Protects governance integrity and audit readiness |
In mature organizations, each record ties to a trigger. New procurement requires an Accessibility Conformance Report and test summary. Implementation requires issue mapping to business workflows. Production use requires support procedures and escalation contacts. Renewal requires an updated report, a review of closed and open defects, and evidence that previous commitments were met. Without those triggers, records become stale attachments instead of decision tools.
Storage discipline matters as much as collection. Keep the signed contract version, the exact VPAT reviewed, and dated correspondence in the same repository. If your team uses ServiceNow, Jira, SharePoint, or a governance platform, create required metadata fields for product name, version, standard, review date, owner, business criticality, and expiration date. That structure makes future audits and enterprise reporting far easier.
Evidence behind the claims: testing, scope, and reproducibility
If you need to know whether a vendor’s accessibility statements are reliable, ask for the evidence package behind them. At minimum, that package should identify the standard used, usually WCAG 2.1 AA or WCAG 2.2 AA, the date of testing, the product version, and the specific environments tested. Serious vendors can usually name the pages, workflows, or screens assessed; the assistive technologies used, such as JAWS, NVDA, VoiceOver, TalkBack, or Dragon; and the browsers and operating systems included in the test matrix.
Reproducibility is the key test. If a vendor says keyboard access is supported, a competent file should show where it was tested and under what conditions. If color contrast failures were identified, the record should note affected components, measured ratios, and whether the issue appears in a design system or a one-off screen. I prefer to keep screenshots, short video captures, or ticket links when possible because they reduce ambiguity later, especially after interface changes.
Buyers should also document scope exclusions explicitly. If the report does not cover mobile apps, customer-generated content, exported spreadsheets, e-signature flows, or integrated third-party payment pages, write that down in the review notes. Hidden exclusions are one of the most common reasons teams overestimate accessibility readiness. In one review I handled for a learning platform, the core web app had reasonable keyboard support, but the video caption editor and quiz authoring tool were outside the initial report. Those modules created the real operational barriers for instructors.
Independent validation can strengthen the record. Internal audits, consultant reviews, or disability user testing often uncover issues a vendor summary misses. Keep those findings linked to the vendor file, not in a separate silo, so the organization can compare self-attestation against observed performance. That comparison is often the most persuasive evidence in executive risk discussions.
Operational documentation that shows whether accessibility is sustainable
Accessibility documentation should reveal whether the vendor can sustain accessible delivery, not just describe a single point-in-time review. That means keeping records about process maturity. Useful examples include the vendor’s accessibility policy, secure product development lifecycle references that include accessibility checkpoints, design system guidance, release notes mentioning accessibility fixes, and escalation paths for disability-related defects.
Support procedures are especially important. Ask how end users report accessibility barriers, whether reports are triaged separately from general usability issues, who reviews them, and what service levels apply. If a screen reader blocker is reported in a core workflow, the organization needs a documented interim accommodation path, not an informal promise. For employment or education systems, that might include an alternate submission workflow, staffed assistance, or a temporary accessible format process while remediation is underway.
Training records can also matter. I do not expect every vendor to share internal HR files, but a strong accessibility posture is often visible through role-based training for designers, developers, QA analysts, and support agents. If the vendor says accessibility is built into engineering practice, ask what that means in concrete terms. Do pull requests include keyboard and semantic checks? Are automated tools like axe DevTools, Accessibility Insights, Pa11y, or Lighthouse used in continuous integration? Are manual regression scripts maintained for critical journeys? Evidence of repeatable practice is more valuable than polished marketing language.
For enterprise buyers, change management records deserve a place in the file. If the vendor introduces a major UI redesign, AI assistant panel, or embedded analytics module, document whether accessibility review was repeated and whether the prior VPAT still applies. Sustainable accessibility is visible in the trail of updates, not just in the initial procurement packet.
Contracts, exceptions, and governance records
Some of the most important accessibility documentation is created by the buyer, not the vendor. Contract exhibits, negotiated commitments, and internal approval records determine what happens when the product falls short. Keep the final contract language that addresses conformance standards, update obligations, audit rights, issue notification, remediation timelines, indemnity where applicable, and termination or cure rights. If accessibility language changed during negotiation, retain the redlines or summary notes so later reviewers understand intent.
Exception records are equally important. Many organizations buy tools with known accessibility issues because no equivalent option exists, timelines are fixed, or the business impact of delay is too high. That can be a reasonable decision, but it should be documented. A sound exception memo identifies the affected user groups, relevant workflows, legal or policy standard, severity of barriers, available alternatives, expected remediation dates, interim accommodations, approving authority, and review date. Without that record, teams often inherit risk they do not understand.
Governance notes should capture decision context. Why was the tool approved despite nonconformance? Was the issue limited to an admin-only function or did it block applicants, students, patients, or customers? Were disability employee resource groups consulted? Was counsel involved? These details matter later during audits, complaints, or renewal negotiations. In my experience, organizations are judged not only on whether a product had issues, but on whether they knew the issues, documented them, and managed them responsibly.
Finally, link accessibility records to the wider compliance environment. Privacy impact assessments, security reviews, data retention schedules, and third-party risk files often live in separate workflows, yet implementation teams need a consolidated view. Accessibility should sit beside those controls as a standard procurement evidence stream, not as an afterthought buried in email.
How to organize this hub and keep documentation useful over time
As a hub page for documentation, records, and evidence, your main job is to create a system that lets related guidance branch into focused articles while keeping one coherent record strategy. Start with categories: baseline disclosures, validation evidence, operational process records, contractual controls, and governance decisions. Under each category, define required artifacts, owners, review cadence, and storage location. This approach turns a pile of attachments into a maintainable program.
Use naming and version standards that survive staff turnover. For example, include vendor name, product, module, version, standard, and review date in every file title. Set renewal reminders ninety days before contract anniversaries so teams can request updated reports and status on open defects. Archive superseded documents, but never overwrite them. Historical evidence often becomes critical when a complaint references an older product state.
Hub pages also work best when they direct readers to more detailed guidance on topics such as evaluating VPAT quality, writing contract clauses, logging accessibility defects, documenting accommodations, and handling exceptions. The hub should define the full map, while subpages go deep on each record type. That structure helps procurement staff, compliance managers, legal teams, and accessibility specialists find the exact artifact they need without losing the bigger governance picture.
The central lesson is simple: keep the VPAT, but do not stop there. Preserve the testing details that make claims credible, the issue records that show real barriers, the plans that commit the vendor to remediation, the contract terms that make promises enforceable, and the governance notes that explain your decisions. Build that file once, maintain it consistently, and your organization will be better prepared for audits, renewals, implementation surprises, and the everyday responsibility of delivering technology people with disabilities can actually use. Review your current vendor files this quarter and close the evidence gaps before they become risk.
Frequently Asked Questions
Why is a VPAT not enough as the full accessibility record for a vendor?
A VPAT is an important starting point, but it is not a complete accessibility record. It is essentially a vendor’s structured statement about how a product aligns with accessibility standards such as WCAG, Section 508, or EN 301 549 at a given point in time. What it usually does not provide is the underlying evidence needed to evaluate reliability, risk, and accountability. If a team relies on the VPAT alone, it may know what the vendor says, but not what was actually tested, which user flows were included, what assistive technologies were used, what defects were found, how severe those defects were, or whether any promised fixes were ever delivered.
That gap becomes expensive when the product is used in high-impact contexts such as employment systems, customer-facing transactions, education, healthcare, or internal business tools. During procurement, the missing record makes it hard to compare vendors or justify a buying decision. During remediation, it becomes difficult to reconstruct which issues were known before launch and whether the vendor committed to a timeline. During a legal complaint or audit, the absence of documentation can make an organization look unprepared, even if it acted in good faith. A strong vendor accessibility file goes beyond the VPAT and preserves evidence of claims, testing, exceptions, remediation commitments, retest results, and internal risk decisions.
What accessibility documents should buyers keep beyond the VPAT?
Buyers should maintain a documentation set that shows the full story of accessibility due diligence over time. In practice, that usually includes the VPAT itself, but also the vendor’s accessibility statement, third-party audit reports, conformance test results, product-specific test plans, lists of known issues, remediation roadmaps, and records of retesting after fixes. It is also valuable to keep supporting materials that clarify scope, such as which product version was tested, which platforms were covered, whether mobile and desktop were both reviewed, and whether testing included key workflows rather than just isolated screens.
Procurement and legal records matter as well. Teams should retain accessibility questionnaires, email commitments from the vendor, contract language addressing accessibility obligations, service-level commitments for defect correction, and any negotiated exceptions or waivers. Internally, it is wise to preserve risk assessments, meeting notes, approvals from accessibility or legal stakeholders, and documentation of why the organization proceeded despite unresolved issues. If user testing was conducted, keep summaries of findings and whether people with disabilities participated. If the vendor supplied issue trackers, release notes, or fix verification screenshots, those can be valuable too. The goal is to maintain an evidence trail showing what the vendor represented, how those representations were evaluated, what problems existed, what mitigation steps were planned, and what level of risk the buyer knowingly accepted.
How should teams document accessibility testing, failures, and fixes from vendors?
The best approach is to document accessibility as an ongoing record rather than a one-time intake task. For each vendor product, teams should record the date of review, product name, exact version, environments tested, applicable standards, and the specific workflows that matter to the organization. Then they should capture the source of each finding: whether it came from the vendor’s own audit, an independent assessment, internal testing, customer complaints, or user feedback from employees with disabilities. This structure prevents confusion later when multiple reports exist and product versions change.
Each issue should be logged with enough detail to be actionable and defensible. That typically means including the affected page or feature, a description of the barrier, the relevant WCAG criterion or other standard reference, severity or business impact, the users likely affected, and evidence such as screenshots, screen reader notes, keyboard testing results, or video clips where appropriate. Just as important, teams should record what happened next: whether the vendor acknowledged the issue, what remediation timeline was promised, whether a workaround exists, whether the issue was retested, and whether the fix actually resolved the barrier. If the organization accepted the issue temporarily, the file should explain why, who approved the decision, and what compensating measures were put in place. This kind of documentation turns accessibility from a vague vendor assurance into a traceable compliance and risk-management process.
What role does accessibility documentation play in procurement, remediation, and litigation risk?
Accessibility documentation plays a different but equally important role at each stage. In procurement, it supports informed decision-making. It helps buyers distinguish between vendors that simply provide a polished VPAT and vendors that can substantiate their claims with test evidence, issue management, and a credible remediation process. It also gives procurement, legal, security, and accessibility teams a shared basis for negotiation, especially when deciding whether to require contract language, holdbacks, implementation conditions, or alternative product reviews.
In remediation, documentation becomes the operating record. Teams need to know what issues existed before purchase, what the vendor committed to fix, what deadlines were set, and whether the organization depended on those commitments when approving deployment. Without that history, accessibility work tends to become reactive, repetitive, and hard to prioritize. During litigation, demand letters, agency inquiries, or formal complaints, the documentation can become critical evidence. It may show that the organization asked the right questions, reviewed substantive materials, identified barriers, pushed for fixes, considered affected users, and made reasoned decisions rather than ignoring accessibility. While good documentation does not eliminate legal exposure, it can significantly improve the organization’s ability to explain its process, demonstrate diligence, and support a defense that accessibility was treated seriously rather than as a checkbox exercise.
How long should organizations keep vendor accessibility records, and how should they organize them?
Organizations should retain vendor accessibility records for as long as the vendor product is in use, plus any additional period required by internal retention policies, procurement rules, regulatory expectations, or litigation hold obligations. In many cases, keeping only the current VPAT is not enough because older versions may show what the organization knew at the time of purchase or renewal. Historical records can be especially important when a product changed over time, a barrier was reported months earlier, or a dispute arises over whether the vendor had already acknowledged a known issue.
As for organization, the most practical method is to store records in a centralized, searchable repository tied to the vendor and product lifecycle. Each file should be named and indexed consistently, with metadata for vendor name, product name, version, review date, owner, status, and document type. Many teams benefit from a simple folder structure or governance system that separates baseline documents, testing evidence, issue logs, remediation commitments, retest results, contracts, and internal approvals. A summary sheet for each vendor can also help by listing major known issues, current risk status, last review date, and next action. The objective is not to create bureaucracy for its own sake. It is to make sure that when procurement asks what was reviewed, when engineering asks what still needs to be fixed, or when counsel asks what evidence exists, the organization can produce a complete and credible accessibility record without scrambling.
