How to Create a VPAT: 2026 Compliance Guide

Creating a VPAT means choosing the right ITI template, auditing your product against standards such as WCAG and Section 508, documenting a conformance level for every applicable requirement, and writing detailed remarks that explain what you found. Once completed, that VPAT becomes an Accessibility Conformance Report (ACR), which is often required when selling to U.S. government buyers.

If you're reading this, you're probably in one of two situations. A buyer just asked for a VPAT and your team realized nobody owns it, or you've been told to “fill one out” and discovered it's not a simple form at all. It's a technical audit, a procurement document, and a trust signal rolled into one.

What Is a VPAT and Why Does It Matter

A buyer asks for your VPAT on Friday, and the sales team wants to send something by Monday. At that point, the document stops being abstract. It becomes a gate in the deal cycle.

A Voluntary Product Accessibility Template (VPAT) is the standard format vendors use to document how a product meets accessibility requirements. When completed, it becomes an Accessibility Conformance Report (ACR) that buyers review during procurement. If you need a plain-language refresher, this VPAT definition covers the terminology cleanly.

The distinction matters because buyers are not asking for a blank template. They are asking for your position, backed by testing, on how the current product performs against specific requirements.

Teams new to the process often treat the ACR as a form to complete quickly. Buyers read it differently. They use it to judge product risk, implementation effort, and vendor credibility. A thin report with generic remarks tells them your team may not understand the product's accessibility gaps or may not have tested the product in a disciplined way.

A strong ACR does more than answer "does it support this criterion." It explains where support is solid, where exceptions exist, and what those exceptions mean in practice for users and for deployment. That is where trust is built. If a workflow has a keyboard trap, an unlabeled control, or incomplete screen reader feedback, a careful remark gives the buyer something useful to evaluate instead of forcing them to guess.

Why buyers pay close attention

Procurement teams, accessibility reviewers, and enterprise customers use VPATs for different reasons, but they look for the same signals. Is the report current. Does it match the actual product version. Do the remarks sound tested, or copied.

Good remarks help sales teams answer follow-up questions faster. They also reduce friction with legal and security reviews because the document shows a pattern of honest disclosure rather than overclaiming. In practice, buyers are often more comfortable with a product that has known, well-documented issues and a credible remediation plan than with a report that says "Supports" everywhere and falls apart under review.

That is the true business value.

If your company is already working on achieving ADA website compliance, the VPAT gives that work a formal procurement output. It turns internal accessibility effort into something a buyer can review, compare, and approve.

The better strategic view is to treat the VPAT as part audit record, part sales asset, and part product management tool. It helps buyers assess fit, helps account teams handle objections, and helps engineering see which gaps are blocking revenue. For SaaS teams, that last point matters because the report cannot be a one-time document. It has to reflect a product that changes every sprint, which means the quality of your conformance decisions and your remarks will affect how sustainable the process becomes later.

Laying the Groundwork for Your VPAT Audit

The teams that struggle with how to create a VPAT usually don't fail in testing. They fail before testing starts. They pick the wrong template, scope the wrong product version, or leave key workflows out of the assessment.

The first planning decision is the edition. The VPAT process requires selecting the correct edition, such as WCAG 2.1, 2.2, or Section 508, and completing all applicable tables, including areas such as Chapter 3 and Chapter 5, with no option to omit tables unless they are non-applicable after verification, as noted in the Section 508 ACR guidance.

Choose the template before you schedule testing

Don't start with tools. Start with the procurement context.

If you sell a web application into enterprise environments, buyers may ask for WCAG-focused reporting. If you sell into federal procurement, Section 508 language often drives the conversation. If your product spans multiple markets, you need a clear rationale for the edition you select and the tables you complete.

For teams that need a refresher on the current success criteria context, this primer on UX accessibility with WCAG 2.2 is a useful companion resource before you finalize scope.

Define the product like a procurement reviewer would

A defensible VPAT starts with a precise definition of what was evaluated. That means:

• Product version: Name the exact release, not a general platform family.
• Interfaces included: Web app, admin portal, customer dashboard, public site, mobile shell, embedded content.
• Key workflows: Login, navigation, forms, checkout, document downloads, reporting, support access.
• Dependencies: Third-party components that materially affect the user experience.

If your product changes often, resist the temptation to describe “the platform” in broad terms. Broad scoping feels efficient at first, but it creates weak remarks later because you can't tie findings to specific workflows.

A strong setup often begins with a formal website accessibility audit, then narrows the VPAT scope to the user journeys and product areas that are currently in market.

Build the right working group

One person rarely owns all the inputs needed for a credible ACR. The strongest process usually includes:

• An accessibility lead: Interprets conformance and signs off on the evidence.
• A product manager: Confirms what's in scope and what shipped in the tested version.
• An engineer or QA lead: Verifies reproducibility and technical root causes.
• A sales or compliance stakeholder: Makes sure the final document answers buyer questions cleanly.

Don't let legal or sales write the technical findings alone. They need to review the report, not invent it.

Decide your evidence standard up front

Before the first test run, agree on what “enough evidence” looks like. Typically, that means every finding should be traceable to a tested page, workflow, component, or support artifact. If the internal review team can't tell where a rating came from, the buyer won't trust it either.

Executing the Accessibility Assessment

A scoped audit becomes a credible ACR only after the product is tested the way buyers and users will use it. That means checking more than code errors. It means verifying whether someone can sign in, complete a core task, recover from errors, and finish a workflow with a keyboard and assistive technology.

A reliable VPAT assessment uses both automated scanning and manual testing. Scanners are good at finding repeated structural defects quickly. Manual review catches the issues that decide whether the product is usable in practice, such as broken focus management, unclear control names, missing announcements in dynamic interfaces, and task failures inside forms, tables, and dialogs.

Start broad enough to identify patterns across shared components. Then spend most of the time on the workflows a buyer is likely to test during procurement.

What to test in practice

At minimum, test keyboard access, screen reader behavior, visual presentation, and the underlying code support tied to the applicable criteria. In practice, many teams validate in common enterprise environments such as Windows 11 with Chrome, NVDA, JAWS, and keyboard-only navigation, because those combinations reflect how many buyers review accessibility claims.

A practical sequence usually looks like this:

1. Run automated scans first

   Use them to find repeated issues such as missing labels, contrast failures, empty buttons, heading structure problems, and basic ARIA misuse.

2. Test complete workflows with a keyboard

   Go through login, account setup, search, filtering, data entry, checkout or billing, reporting, and support flows without touching a mouse. Check menus, modals, tables, date pickers, dropdowns, drag-and-drop alternatives, and custom controls.

3. Validate with screen readers

   NVDA and JAWS are common choices for VPAT work. Listen for accurate names, roles, states, instructions, error messages, and announcements during dynamic updates. Confirm that the reading order matches the visual and task order.

4. Review visual and code-level behavior

   Check zoom, reflow, visible focus, color reliance, error recovery, semantic structure, and whether the DOM supports the accessibility claims made by the interface.

If you want a grounded comparison of where scanners help and where they stop, WebAbility.io's accessibility insights explain the trade-offs clearly.

What good evidence looks like

The assessment should produce evidence that another reviewer can follow and reproduce. If a finding cannot be tied to a specific page, component, or workflow, it will be hard to defend in the VPAT and even harder to explain to a buyer.

Log each issue with enough detail for engineering, compliance, and sales to use the same record. Include:

• Affected screen, component, or workflow
• Browser, assistive technology, and device used
• Steps to reproduce
• Observed barrier
• Expected accessible behavior
• Relevant WCAG criterion
• User impact and product impact

That last point matters more than many first-time teams expect. A focus indicator defect on one settings screen and a screen reader failure in checkout are not the same business problem. Both may affect conformance. Only one is likely to block a sale. Good assessment notes make that distinction early, which helps later when you write remarks for partial support and decide what needs immediate remediation.

Why hybrid testing wins

Teams often ask whether a tool can generate the VPAT for them. It cannot. A tool can support the audit. It cannot determine conformance by itself or judge whether a user can complete a promised task from start to finish.

That is the trade-off. Automation saves time and improves coverage across templates. Manual testing costs more, but it finds the failures buyers care about during due diligence. For SaaS products that ship often, the right approach is usually a repeatable hybrid process, with automated checks in the delivery pipeline and manual validation on high-risk workflows before each VPAT update.

For teams comparing process options, this breakdown of WCAG audit methodologies and tools is useful because it reflects the same reality seen in VPAT work. Coverage depends on user tasks, not just code scans.

Here's a useful training resource for teams that need to align on audit expectations before documenting results:

A VPAT assessment should answer the buyer's practical question. Can someone using assistive technology complete the tasks your product is being purchased to perform?

Documenting Conformance and Writing Effective Remarks

Most VPATs either become credible or fall apart at this juncture.

The template structure is straightforward. Each requirement gets a conformance value and a remarks field. The hard part is judgment. Teams usually know when something clearly supports a criterion and when it clearly fails. The gray area is Partially Supports, and that's where remark quality determines whether the document builds trust.

Use conformance labels carefully

In plain terms, the common labels work like this:

Conformance level	When to use it
Supports	The tested functionality meets the requirement in the evaluated scope.
Partially Supports	Some parts conform, but there are meaningful exceptions.
Does Not Support	The product fails the requirement in a material way.
Not Applicable	The requirement truly does not apply to the product or feature after review.

The mistake isn't usually the label itself. The mistake is writing a label without enough context for a reviewer to understand what it means in use.

The remarks column is where trust is won

A weak remark sounds like this: “Some issues may occur in certain areas.”

A useful remark sounds like this: “Keyboard users can access main navigation and account settings, but focus isn't consistently moved into the modal during billing updates. This affects task completion for screen reader and keyboard users. Engineering has logged remediation for the current component pattern, and the fix will be applied across affected dialogs in the next release cycle.”

That kind of writing does three jobs at once. It identifies the limitation. It explains user impact. It shows there's an accountable remediation path.

Data cited by Applause on VPAT documentation practices indicates that 42% of enterprise buyers reject products with multiple “Does Not Support” entries unless they include a clear and credible remediation roadmap within the remarks.

What effective remarks include

When you're writing for non-compliant or partially compliant items, include these elements where relevant:

• Scope of the issue: Is it isolated to one workflow or spread across a component system?
• Affected users or assistive technology: Keep this factual and tied to the tested experience.
• Current workaround if one exists: Only include it if it's real and usable.
• Remediation direction: State what your team plans to change.
• Timing language: Be careful. Use it only when product and engineering have agreed to it internally.

Buyer lens: A candid VPAT with clear remediation language is often easier to defend than an over-optimistic VPAT full of unsupported “Supports” claims.

Examples that work better than generic comments

Here are three common scenarios.

For a partially supported form flow

“Most input fields expose accessible labels and error states. In the account invitation flow, required-field errors are not consistently announced to screen reader users after submission. The form remains operable by keyboard. The validation messaging pattern is under remediation.”

For a custom component with a known gap

“The data grid supports keyboard navigation for row selection and sorting. Column resize controls do not expose consistent name and role information to screen readers. This affects discoverability of advanced table actions. The component is scheduled for refactor using the shared design system.”

For support documentation

“User help content is available online, but not all linked PDFs have been verified for accessible structure. Web-based support content is the recommended accessible path while document remediation is in progress.”

What not to do

Don't use legalistic fog. Don't say “best effort.” Don't promise future compliance without owner sign-off. And don't bury obvious barriers in vague language.

If your team needs a companion reference for structuring the finished deliverable, this 2026 accessibility conformance report guide is useful because it focuses on turning audit evidence into buyer-readable documentation.

Avoiding Common Pitfalls and Finalizing Your Report

A lot of VPATs fail review for boring reasons. Not because the testing was poor, but because the final document looks unfinished, inconsistent, or careless.

That's frustrating because these are preventable errors.

The checklist buyers notice first

Before you publish or send the ACR, review it like a procurement analyst would.

• Instruction pages removed: The VPAT template includes instructions that should be removed before you publish the final ACR.
• No blank cells: Every applicable row needs a conformance response and remarks.
• Product details present: Include the exact product version and report date.
• Terminology stays consistent: Don't switch between unsupported labels or internal shorthand.
• The ACR itself is accessible: If it's a PDF, Word file, or web page, it should be accessible too.

A common pitfall is failing to provide detailed remarks when a feature Partially Supports or Does Not Support a criterion. Guidance summarized in Accessible.org's VPAT instructions emphasizes that remarks are mandatory in those cases to explain limitations and remediation plans, and that directly affects buyer trust.

A simple final review model

Use a three-pass review before release.

Review pass	What to check
Technical pass	Ratings match actual findings and tested scope.
Editorial pass	Language is specific, consistent, and free of placeholders.
Accessibility pass	The report file itself is readable and navigable.

The assumption worth challenging

Many teams assume a VPAT is done when the fields are filled in. It isn't. It's done when an external reviewer can read it without confusion, connect every rating to credible evidence, and trust that the document represents the current product.

If a buyer has to guess what you tested, what version you tested, or what your remarks mean, the report isn't ready.

The strongest final reports are usually boring in the best sense. Complete. precise. easy to verify.

Maintaining and Versioning Your VPAT Over Time

A VPAT often gets tested for the first time when a buyer asks a simple question during procurement: “Does this still match the current product?” If the report reflects a release from last year, sales slows down, security and legal reviews get harder, and the buyer starts questioning the reliability of the rest of your documentation.

That risk is higher for SaaS products. Weekly releases, design system changes, new integrations, and ongoing remediation work can all change the accuracy of an Accessibility Conformance Report. A VPAT should track the version buyers are evaluating, not serve as a general statement about the product.

Industry guidance and buyer expectations both push in the same direction. Procurement teams commonly ask for a recent VPAT, and older reports often trigger follow-up questions or a request for re-validation. In practice, that means teams need a repeatable update process instead of treating the ACR as a one-time deliverable.

Build update triggers into your release process

Do not reopen the full report after every sprint. Reassess when a change could affect conformance or make existing remarks inaccurate.

Useful triggers include:

• Major UI redesigns: Navigation, forms, modals, dashboards, or design system updates
• New core workflows: Checkout, onboarding, reporting, account administration, or document generation
• Third-party component changes: Anything that affects keyboard support, focus order, announcements, or form behavior
• Accessibility remediation releases: Especially when the current VPAT documents known defects and planned fixes

For agile teams, this is usually the right trade-off. Full retesting on every release burns time and budget. No retesting creates stale claims that buyers will challenge.

Use lightweight version control

A practical maintenance process is simple and disciplined:

1. Tie the ACR to a specific product version

   Every report should clearly map to a release or release range.

2. Flag accessibility-impacting changes in release notes

   Product, engineering, and QA should mark updates that may change conformance.

3. Retest the affected criteria first

   Start with changed workflows and shared components. Expand scope if those changes touch reusable patterns across the product.

4. Update the date whenever findings or remarks materially change

   That gives sales and procurement teams a clean answer when they are asked whether the report is current.

The remarks column matters here. If a known issue has been fixed, the old limitation should not stay in the document for another quarter. If a new issue has appeared, the report should explain the impact, scope, and remediation status in plain language. Buyers notice when remarks read like they were copied forward without review.

Make ownership explicit

VPAT maintenance usually fails because nobody owns the operational work. Assign one person to manage the document lifecycle and one person to confirm the technical evidence behind updates. Accessibility, product, engineering, and QA should all contribute, but named ownership keeps the process from drifting.

Teams often support that process with scanners, issue trackers, design system inventories, and audit records. WebAbility.io is one example of a tool used to monitor findings, organize evidence, and keep documentation aligned with product changes.

A current ACR shows that the team has a working accessibility process. An outdated ACR suggests that nobody has checked whether the published claims still match the product.

A maintained VPAT helps more than compliance. It gives sales a document they can stand behind, gives product teams a record of what changed, and gives buyers confidence that your remarks are honest, current, and useful.