What Is VPAT Compliance? A Clear Guide

What Is VPAT Compliance?

VPAT compliance means documenting how an information and communication technology product meets accessibility standards. VPAT stands for Voluntary Product Accessibility Template. It is a standard form used to review software, websites, hardware, and other digital tools.

A VPAT does not act as a legal certificate. It records a product’s accessibility features and known gaps. A qualified reviewer studies the product against set rules. The reviewer then records the results in the template.

The finished document is called an Accessibility Conformance Report, or ACR. An ACR describes one product, version, or service. It should name the test scope, standards used, review date, and known limits.

Procurement teams use the report before they buy a digital product. They can compare the product with their own access needs. They can also ask vendors for proof, tests, or fixes.

Why VPAT Compliance Matters to Buyers and Vendors

Public bodies often need accessible technology. Their duties may come from laws, contracts, or public service rules. A clear ACR helps a vendor show how its product meets those duties.

Government buyers may ask for a VPAT during a tender. A missing or weak report can slow review. It may also remove a product from a short list. This makes VPAT documentation a key part of vendor sales work.

Private firms gain value from the same process. An accessible product can serve more users with fewer support issues. It can also help a buyer manage risk across its staff and customers.

A VPAT is not a pass or fail badge. It gives buyers a view of the product’s current state. Buyers still need their own checks, since use cases and settings can change results.

• It gives procurement teams a shared review format
• It shows where a product supports access needs
• It makes known gaps easier to discuss
• It creates a record for future product updates

How to Fill Out a VPAT

Start by choosing the right VPAT edition. The edition sets the rules and rows that the review must cover. Then define the product scope, test build, and review date.

Next, gather evidence from more than one source. Reviewers may use manual tests, screen readers, keyboard checks, and code review. They may also review support guides and known issue logs.

For each rule, record the result in the conformance column. Add a short explanation in the remarks column. The remark should name the affected feature, user impact, and any work-around.

Use clear examples. For instance, a report might state that keyboard users can reach all controls. It might also note that one chart lacks a usable text view. A buyer can act on that detail.

1. Set the product and test scope
2. Select the standards and VPAT edition
3. Test each applicable requirement
4. Record the result and supporting detail
5. Review the report with product and legal teams
6. Publish the dated ACR with a named contact

Do not mark every row as “Supports” without proof. That approach can damage trust during a buyer review. A candid report is more useful than a perfect-looking report.

VPAT Editions and the Standards They Cover

There are four main VPAT editions. Each one maps the report to a different set of accessibility rules. The right choice depends on the buyer, market, and contract.

Edition	Main use	Typical reference
Section 508	U.S. federal procurement	U.S. Section 508 rules
WCAG	Web and digital product reviews	Web Content Accessibility Guidelines
EN 301 549	European ICT procurement	European accessibility requirements
International	Markets with mixed needs	Several standards in one report

The Section 508 edition suits vendors that sell to U.S. federal agencies. The WCAG edition focuses on web content and related digital features. The EN 301 549 edition covers wider ICT needs in European procurement.

The international edition combines more than one standard. It can help a vendor serve buyers across regions. It also creates more rows and needs careful mapping.

Check the version of each standard before you begin. A report should state the exact rule set used. This detail helps buyers compare reports from different vendors.

Conformance Levels Explained

VPAT reports use four main conformance terms. Each term describes the product’s result for a specific requirement. It does not rate the whole product in one broad score.

• Supports: The product meets the requirement for the tested scope.
• Partially Supports: Some parts meet the requirement, but known gaps remain.
• Does Not Support: The product does not meet the requirement.
• Not Applicable: The requirement does not fit the product or feature.

Use “Partially Supports” when a feature works for some users or tasks. Explain the limit in plain terms. State whether the gap affects one mode, platform, or part of the product.

Use “Not Applicable” with care. A reviewer should explain why the row does not fit. A blank row gives buyers no useful answer.

These levels need context. A product with one major gap may create more risk than one with several minor gaps. Buyers should read the remarks, not just count labels.

How Buyers Use an Accessibility Conformance Report

A procurement team can start by listing its user groups and work tasks. It can then match those needs to the ACR rows. This step keeps the review tied to real use.

For example, a team may need staff to create reports by keyboard. It should check keyboard access, focus order, and form labels. It should also test the product in the browsers and devices used by staff.

The ACR can guide follow-up questions. A buyer may ask for a live demo, test notes, or a fix plan. It may also ask how the vendor handles support for disabled users.

In Australia, buyers may also need to consider local legal and policy duties. The ACR does not replace that work. It gives the team useful evidence for its access review.

Review the report alongside a trial. A report can describe a product well, yet miss a buyer’s unique workflow. Hands-on testing closes that gap.

For background on accessible web content, compare the report with the W3C Web Content Accessibility Guidelines. The W3C publishes the standard that defines many web access tests. It is the best source for the rule text itself.

Best Practices for Strong VPAT Documentation

Use a reviewer with real accessibility testing skills. Product knowledge helps, but it is not enough on its own. The reviewer must understand assistive tools and user barriers.

Keep the report tied to a named version. Include the build number, test dates, and platforms reviewed. Buyers need this detail because products change often.

Write remarks that buyers can act on. Name the feature, failure, affected users, and planned fix. Avoid broad claims such as “the product is accessible.”

Check the report before release. Product owners can confirm feature details. Accessibility leads can check test claims. Legal teams can check that the report does not promise more than the evidence shows.

Update the VPAT after major releases or access fixes. A new feature may add new gaps. A changed framework may also affect keyboard access or screen reader output.

• Date every report and list the tested version
• State the edition and standard version
• Explain every partial or failed result
• Separate tested facts from planned fixes
• Review the ACR after major product changes
• Keep old reports for contract and audit records

The U.S. government’s Section 508 guidance on accessibility reports offers useful context for vendors. It explains how ACRs support federal buying decisions. Use the relevant local rules when a contract sets a different need.

Common Questions About VPAT Compliance

Is a VPAT the same as an accessibility audit?

No. An audit tests a product against selected rules and use cases. A VPAT records the findings in a buyer-friendly format. A strong ACR often draws on audit work.

Does a VPAT prove legal compliance?

No. A VPAT is a disclosure document, not a legal guarantee. Buyers must judge the report against their duties and real use.

Who should complete a VPAT?

A trained accessibility reviewer should lead the work. Product, design, engineering, and legal staff should also check the final report.

How often should a VPAT be updated?

Update it after major product changes, new tests, or changes to the cited standards. Many vendors also set a yearly review date.

Can a product have “Does Not Support” results?

Yes. Honest gaps are allowed and can help buyers plan. The report should explain the impact and state any fix plan.

What makes VPAT documentation useful?

Useful documentation names the scope, standard, version, test date, results, and limits. It uses clear remarks that link each result to a real product feature.