What Is a VPAT? Your 2026 Guide to Compliance & Risk

You're probably here because someone asked for a VPAT and you need to answer quickly without guessing. A procurement manager sends the request. A sales deal pauses. An internal team asks, “Do we already have one?” That moment is where a lot of confusion starts.

The short version is simple. A VPAT helps buyers understand how an app, website, or software product lines up with accessibility requirements. The less obvious part is what it can and can't do. It can help you compare products, ask better follow-up questions, and document due diligence. It can't, by itself, guarantee that a product is accessible today, tomorrow, or after the next release.

TL;DR

• A VPAT is a standardized template used to report accessibility conformance for ICT products.
• When the template is filled out with test results, it becomes an Accessibility Conformance Report (ACR).
• Buyers often ask for a “VPAT,” but they usually mean the completed report.
• The most useful part of the document is often the remarks and explanations, not the rating alone.
• A strong VPAT starts with real testing, including manual review and testing by native assistive technology users.
• A VPAT is a starting point, not the final destination. It supports procurement review, but it isn't a certification or pass/fail seal.
• For SaaS and AI-driven products that change often, a static report needs support from ongoing monitoring and verification.

Good accessibility documentation reduces friction in procurement. It also gives teams clearer next steps for remediation, governance, and internal accountability.

What Is a VPAT and Why Does It Matter

A contract is ready to move. Security has signed off. Pricing is approved. Then procurement asks one last question: “Do we have the VPAT?” That file can decide whether the purchase keeps moving or stalls while teams sort out accessibility risk.

A VPAT, short for Voluntary Product Accessibility Template, is the standardized format vendors use to report how an information and communication technology product addresses accessibility requirements. Once that template is filled in with findings, scope notes, and supporting explanations, the completed document is called an Accessibility Conformance Report, or ACR.

That distinction helps procurement teams ask better questions. If someone says, “Send the VPAT,” they usually want the completed report, not the empty template. In day-to-day buying, people blur those terms. For review and documentation, it helps to separate them.

A simple comparison works well here. The VPAT is the form. The ACR is the form with evidence-filled answers.

• VPAT refers to the template itself
• ACR refers to the completed report based on that template
• For buyers, the document creates a common structure for comparing products and recording due diligence

If your team needs broader business context for why accessibility appears in procurement reviews, Baslon Digital's website accessibility insights are a useful companion read.

Why buyers ask for one

Procurement teams use VPATs to reduce uncertainty. A good report helps them see which standards were evaluated, where the product appears to conform, and where follow-up is needed. That is useful in public sector purchasing, higher education, healthcare, and enterprise software reviews, where accessibility often sits alongside security and privacy in the approval process.

The document also creates a paper trail. If a product causes accessibility issues later, the buyer can look back and ask practical questions: What version was tested? What limitations were disclosed? What remediation commitments were made?

That is why a VPAT should be treated like a starting snapshot, not a finish line. A static report captures a product at a moment in time. Modern SaaS platforms, AI features, and weekly release cycles can change accessibility faster than a PDF can keep up. A clean-looking VPAT from six months ago may describe a product that no longer exists in the same form.

For that reason, the smartest buyers use the VPAT to start a risk conversation, not end one. They pair the report with demos, follow-up questions, testing expectations, and ongoing monitoring after purchase. WebAbility.io's 2026 ACR guide offers a practical reference for teams that want to understand how that documentation fits into a larger review process.

The key point is simple. A VPAT helps you make a more informed decision. It does not certify that a product is accessible today, and it does not protect you from changes introduced in the next release.

Decoding the Structure of a VPAT Report

A procurement review often stalls at the same moment. Someone opens the VPAT, sees pages of tables, acronyms, and notes, and asks, “Where do we even start?”

That reaction is normal. A VPAT is built to serve several readers at once. Procurement teams want to confirm scope and version. Accessibility specialists want enough detail to judge credibility. Legal and compliance teams want a record they can reference later if questions come up.

The structure becomes easier to read once you know what job each part is doing. In practice, most VPATs have two sections that matter most: the product information page and the conformance tables. Harvard University's guide to interpreting a VPAT lays out that basic format clearly.

The two big sections

The Product Information Page is the cover sheet for the evaluation. It usually lists the product name, version, report date, contact details, and notes about what was included in testing. If you want to know whether the document applies to the product in front of you today, start there.

The Conformance Tables hold the working details. They organize the product against the relevant accessibility standards and include the evaluator's remarks for each requirement. This is usually the longest part of the document, and it is where a careful review pays off.

A simple way to read the structure is this: the first section tells you what was assessed. The tables tell you how the vendor says it performed.

What the standards sections mean

A VPAT can include different standards sections depending on the product and the market it is sold into.

VPAT section	What it helps assess	Who often cares most
WCAG	Accessibility requirements for web content and many software interfaces	Web teams, enterprise buyers, global organizations
Section 508 Chapter 5	Federal software-related procurement requirements	U.S. public sector buyers
Section 508 Chapter 6	Accessibility of support documentation and support services	Procurement, support, compliance teams

That distinction matters. A web app may draw most of the attention to the WCAG portion, while a product under government review may get equal scrutiny for software requirements and support materials. A polished interface does not reduce risk if the help center, PDF guides, or support channels create barriers.

Tables themselves can also become part of the accessibility conversation. If your team wants a practical reference on how accessible tables should be coded and structured, WebAbility.io on table code is a useful technical companion.

What to scan first

A full line-by-line review comes later. The first pass should answer four practical questions:

• Is the report current? Check the date and the product version.
• Is the scope clear? Confirm whether the whole product was reviewed or only selected flows, modules, or platforms.
• Are the right standards included? Match the report to your organization's requirements.
• Are the remarks specific? Specific notes usually signal real evaluation work. Repeated boilerplate often signals the opposite.

A short VPAT can still help. A vague VPAT usually adds risk.

One point causes confusion for many buyers. The structure may look formal enough to feel complete, but a well-formatted VPAT is still only a snapshot. Modern products change constantly. New releases, interface updates, AI features, and third-party integrations can all shift accessibility after the report is published. So the structure of the document matters, but so does the date on the document, the scope behind it, and the vendor process that keeps it current.

How to Read and Interpret a VPAT Conformance Table

This is the part of the report that drives decisions. Each row tells you how the product performed against a specific criterion, but the label alone isn't enough. You need to read the explanation next to it.

A valid VPAT uses specific conformance terms. To generate a valid VPAT report, an accessibility expert must document conformance levels for each criterion using specific mandatory terminology: “Supports,” “Partially Supports,” “Does Not Support,” or “Not Applicable” (Level Access on VPATs and ACRs).

What the four conformance levels mean

Here's the plain-English version:

• Supports means the criterion is met based on the evaluator's findings.
• Partially Supports means some parts work as required, but there are exceptions or gaps.
• Does Not Support means the product fails that criterion.
• Not Applicable means the criterion doesn't apply to the product or feature under review.

The phrase that causes the most confusion is Partially Supports. Some readers treat it as a soft pass. It isn't. It means you need to understand exactly what fails, who is affected, and whether there's any workaround.

A sample entry and how to read it

Below is a simple example of the kind of row you'll see in a VPAT.

Sample VPAT Conformance Table Entry

Criterion	Conformance Level	Remarks and Explanations
WCAG Success Criterion for tables and relationships	Partially Supports	Data tables include headers in many areas, but some complex tables don't expose relationships consistently to assistive technologies. Users may need alternate navigation methods while remediation is in progress.

Now read it the way a procurement reviewer would.

First, the rating tells you there's a gap. Second, the remarks tell you whether the author understands the issue. Third, you can infer whether the impact touches a minor screen or a critical workflow.

Review habit: The remarks column is often more important than the rating column.

If the product relies heavily on tables, this entry matters much more than it would for a simple marketing site. That's why context matters.

For teams that want a better feel for accessible table structure itself, WebAbility.io on table code is a useful companion resource because many VPAT findings trace back to table markup and screen reader behavior.

Questions to ask after reading a row

A good review usually leads to follow-up questions such as:

1. Which user flow is affected? Login, checkout, reporting, support docs?
2. How recent is this finding? Was it tested on the current release?
3. Is there a workaround? If yes, who can realistically use it?
4. Is the issue documented consistently elsewhere in the report?

If the conformance table is detailed and honest, it helps you make a grounded decision. If it's thin, generic, or overly confident, that's a sign to slow down and verify.

The Vendor Side How a Credible VPAT Is Created

A credible VPAT doesn't begin in a Word document. It begins in testing.

The strongest reports come from teams that audit the actual product, review real workflows, and document findings conservatively. When vendors skip that work, the VPAT usually reads like marketing copy. Procurement reviewers can spot that quickly.

What a credible process looks like

A sound process includes more than one testing method. To generate a valid VPAT report, an accessibility expert must first conduct a thorough accessibility audit that includes manual evaluation and testing by native users of assistive technologies against standards like WCAG 2.2, and then document conformance levels for each criterion using the required terminology (Georgetown's VPAT guide).

In practice, vendors often move through a sequence like this:

• Initial scans: Automated tools help identify obvious issues quickly.
• Manual expert review: Accessibility specialists test focus order, labels, keyboard behavior, error handling, and dynamic components.
• Assistive technology testing: Native users of screen readers and other tools validate what the interface is like in use.
• Documentation: Findings are written into the report with clear remarks, caveats, and scope notes.

A vendor that understands this process usually produces better evidence, even when the product still has gaps.

What buyers should look for

A procurement manager doesn't need to run the audit, but it helps to know what signs suggest the report is trustworthy.

• Specific remarks: The notes describe actual product behavior, not canned language.
• Defined scope: The report says what version and workflows were tested.
• Acknowledged limitations: The vendor doesn't hide known issues.
• Current alignment: The team appears to understand present-day accessibility expectations.

For a deeper operational view, this resource on understanding Section 508 VPAT requirements is useful when you need to evaluate whether a vendor's process sounds real or superficial.

This short video gives a practical overview of how the reporting process fits into accessibility work.

A VPAT is only as reliable as the audit behind it. If the testing is weak, the document is weak.

Common Pitfalls and the Modern Limits of a VPAT

The biggest mistake I see is treating a VPAT like a guarantee. It isn't one.

A VPAT is useful because it gives procurement teams a structured view of accessibility conformance. It becomes risky when teams assume that receiving the document means the accessibility question is settled. That's the false security gap.

The false security problem

A vendor can provide a polished report and still leave important questions unanswered. The report may be outdated. The scope may be limited. The remarks may understate the actual impact on users. And even a detailed report is still an informational document, not a live system check.

That matters in procurement because contracts are binding, while the VPAT itself is not a certification. If your organization buys on the strength of the report alone and the product later fails user testing or an independent audit, the operational and legal exposure doesn't disappear.

A VPAT helps you ask better questions. It doesn't remove the need to ask them.

Why annual updates aren't enough for modern software

The second issue is timing. Many teams still think of VPAT maintenance as an annual task. That model breaks down fast for SaaS platforms and AI-driven products that ship updates constantly.

For AI-driven and SaaS products, the VPAT must be supplemented with continuous automated scanning and real-time compliance scoring, as a static annual document cannot verify current conformance for products that update without user intervention (WCAG.com on VPAT accessibility documentation).

That raises a practical procurement question: how do you evaluate current accessibility if the product changed significantly after the report was issued? The honest answer is that you need more than a point-in-time document.

One helpful way to think about this is to pair the VPAT with broader verification practices. These methods for accessibility testing offer useful context for teams that need to go beyond static paperwork and look at how accessibility is maintained.

A better risk posture

If the software is dynamic, your review process should be dynamic too.

• Request the latest ACR: Check that it reflects the current product version.
• Ask about release cadence: Frequent changes increase the chance of drift.
• Require supporting evidence: Audit summaries, issue logs, or testing notes help.
• Use ongoing checks: Continuous monitoring fills the gap between formal reports.

That shift changes the question from “Do we have a VPAT?” to “Do we know the product is still accessible now?”

Beyond the Report Strategic Accessibility Governance

A procurement manager approves a tool based on a clean-looking VPAT. Three months later, a customer cannot complete a key workflow with a screen reader after a product update. The document was still useful, but it answered a narrower question than the team assumed. A VPAT records what was evaluated at a point in time. Governance is the system that checks whether accessibility still holds as the product changes.

That distinction is important because the completed VPAT document, or ACR, is not a certification of compliance and isn't intended to be a pass/fail document. It is a standardized tool specifically required for websites and web-based content when contracting with a U.S. government entity under Section 508 (Vispero on VPATs).

A useful analogy is building inspection paperwork. The report helps you understand the condition of the property on inspection day. It does not guarantee that nothing will break after tenants move in, walls are changed, or systems are updated. Modern software behaves the same way, especially in SaaS products and AI-driven interfaces that change often.

What mature governance looks like

Teams with a stronger process treat the VPAT as one input in an ongoing review model:

• Procurement review: Collect and assess VPATs during vendor evaluation.
• Independent validation: Test critical user journeys instead of relying only on vendor claims.
• Ongoing monitoring: Check for regressions after releases and configuration changes.
• Reporting discipline: Maintain audit trails, compliance reports, and remediation history in one place.

Clear roles reduce risk.

Procurement gathers the vendor evidence. Accessibility specialists verify the claims against real workflows. Product and engineering teams fix defects and track regressions. Leadership gets a current view of exposure instead of a folder full of aging PDFs.

Moving from document collection to operational visibility

For modern teams, governance works better when documentation and monitoring stay connected. Manual audits still matter. Vendor reporting still matters. But neither one tells you enough on its own once releases, feature flags, third-party widgets, and AI-generated interfaces start shifting the user experience week to week.

That is the gap many organizations miss. The VPAT helps you compare vendors and spot obvious risk during procurement. Continuous monitoring helps you confirm whether the product remains accessible in production, where legal, operational, and customer risk emerge.

One example is WebAbility.io, which provides ongoing scanning, compliance scoring, reporting, and dashboard-based visibility for teams that need to manage accessibility continuously rather than only at procurement time. If your team is comparing reporting approaches, WebAbility.io's guide to compliance reports is a practical reference point.

Governance insight: The procurement file shows what was reported. Monitoring shows what is true today.

A VPAT starts the conversation. Strategic governance keeps the answer current.

VPAT Frequently Asked Questions

Is a VPAT the same as an ACR

Not exactly. The VPAT is the template. The ACR is the completed document with testing results entered into that template. In everyday business conversations, people often say “VPAT” when they mean the finished report.

Is a VPAT a certification

No. It isn't a certification or a pass/fail seal. It's a standardized reporting tool that helps buyers assess accessibility conformance and compare products during procurement.

Who should create a VPAT

A credible report should be created after a real accessibility audit. In practice, that means accessibility specialists should be involved, and testing should include manual evaluation plus testing by native users of assistive technologies.

If a vendor marks Supports, is that enough

Not by itself. You still need to review the remarks, the scope of testing, and the report date. A strong “Supports” entry should be backed by specific evidence, not generic language.

How often should a VPAT be updated

For products that change rarely, teams often treat the VPAT as a point-in-time document that gets refreshed when the product changes materially. For SaaS and AI-driven products, relying on a static annual cycle can leave a big gap between the document and the current product experience.

What should procurement ask after receiving a VPAT

These are usually the most useful follow-up questions:

• What version was tested: Make sure the report matches the product being purchased.
• What was in scope: Ask whether the full product, mobile views, and support content were covered.
• How was it tested: Look for manual testing and assistive technology coverage.
• What has changed since the report date: This matters a lot for products with frequent releases.

What is a VPAT in one sentence

It's a standardized accessibility reporting template used to document how an ICT product conforms to accessibility requirements, and once completed with findings, it becomes an ACR.

---

If your team needs more than a static document, WebAbility.io can help you combine accessibility reporting with ongoing monitoring, compliance visibility, and practical workflows for managing accessibility over time.