Writing a VPAT That Enterprise Buyers Actually Trust
What a credible VPAT and accessibility conformance report needs: honest scope, tested criteria, and known issues stated plainly.
Enterprise buyers do not need a perfect VPAT. They need a believable one. A conformance report that claims every criterion supports, with no method and no known issues, reads as marketing to any procurement team that has seen a few of them, and it slows the deal it was meant to speed up.
A trustworthy VPAT is specific about what was tested, how, and where the gaps are. This guide covers scoping the report to real templates, writing remarks that help a buyer judge risk, and keeping the document current as the store changes.
Scope the report to templates and flows
Base the report on the templates and flows buyers will actually use: product, collection, cart, checkout configuration, and account pages. Testing a storefront by template is honest because templates carry the barriers, and it makes the report retestable when a theme changes.
State the evaluation window and the product version in the report. A VPAT with no date or version floats free of the store it describes, and a buyer cannot tell whether the checkout they will use is the checkout that was tested. Dates make a document accountable.
Write remarks a buyer can act on
The remarks column is where trust is built or lost. For each criterion that partially supports or does not support, say what the barrier is, who it affects, and what the workaround or fix plan is. Vague remarks like 'some issues may occur' tell a buyer you found problems and chose not to describe them.
For criteria that fully support, a short method note helps: tested with keyboard and a named screen reader, not just an automated scan. Buyers compare VPATs side by side, and method notes are how a careful vendor separates from a careless one without making bigger claims.
State known issues and the remediation plan
Every real store has known issues. Listing them with severity and a target fix window does not weaken a sales conversation, it professionalises it. Procurement teams manage risk for a living. A short, dated issue list is a risk they can price. A surprise barrier after signing is a risk they remember.
Pair the issue list with the monitoring arrangement: how new barriers get found, and how the VPAT gets updated after a fix or a rebuild. A living document with a review date beats a pristine document that quietly expired a year ago.
Keep the VPAT current
Assign an owner and a review trigger: a theme upgrade, a new checkout extension, or a quarterly review, whichever comes first. When a listed issue is fixed, update the remark and note the retest date rather than quietly deleting the row. The history is part of the credibility.
Publish the summary where buyers look for it, linked from the accessibility statement. Making a buyer chase a sales rep for a document that should be public adds friction for the exact customers who care most about doing this well.
Related reading
If this topic is useful, these earlier guides go deeper on connected questions: Auditing a Headless Shopify Storefront for Accessibility, Scoping Accessibility Work in a Statement of Work Clients Can Sign, and Accessible Mega Menus and Navigation Drawers: Keyboard Paths, Focus Order, and Escape Routes.
Frequently asked questions
What is a VPAT in plain terms?
A VPAT is the template for an accessibility conformance report. It lists the WCAG criteria, states how the product does against each one, and adds remarks on method and known issues. Buyers use it to judge accessibility risk before they buy or integrate a product.
Should a VPAT claim full support everywhere?
Only if testing supports it, criterion by criterion. Partial support with a clear remark and a fix plan is more credible than blanket full support, and enterprise reviewers are trained to discount reports that claim perfection with no method behind them.
How often should a VPAT be updated?
After any major storefront change and at least quarterly for active stores. Each update should carry a new evaluation date and retest notes for fixed issues, so a buyer can see the document tracks the live product rather than a launch day snapshot.
Who should write the remarks?
Whoever ran the evaluation, using the test evidence. Marketing rewrites that soften findings into vagueness are the fastest way to make a technically sound report read as untrustworthy to an experienced reviewer.