VPAT: Everything You Need to Know to Stay Compliant

Digital accessibility isn’t just a “nice-to-have” anymore—it’s something every business needs to take seriously. Why? Because over 1.3 billion people around the world live with a disability. A huge part of the population deserves equal access to digital products and services.

So, how do you prove your product is accessible? You use a VPAT—a Voluntary Product Accessibility Template.

Think of it as a bridge connecting your product to government and enterprise buyers. Before they proceed, these buyers need to know if you meet standards like Section 508 or WCAG.

I’ve worked with teams that care deeply about accessibility. But many of them struggled—not because they didn’t want to do the right thing, but because they didn’t understand how to handle the documentation. That’s why I’m here to break it down—step by step.

What Is a VPAT?

A VPAT is a standardized document on paper. It was developed by the Information Technology Industry Council (ITI) to help vendors evaluate and report how accessible their products are to users with disabilities.

But it’s more than a template — it’s a transparency tool.

When filled out correctly, it provides clear information on how well your digital product supports accessibility standards like:

• Section 508 (U.S.)

• WCAG 2.1 (Web Content Accessibility Guidelines)

• EN 301 549 (European Accessibility Standard)

• Revised 508 / ADA requirements

So, in a way, a VPAT acts like a mirror. It shows your product—its strengths, weaknesses, and all.

Why You Should Care About VPAT Compliance?

You might think, “My product works fine. Why complicate things with VPAT?” 

But here's the thing if you sell to federal agencies or large enterprises, they will ask for it. No VPAT? No deal.

Beyond contracts, a VPAT shows your commitment to inclusivity. It tells users with disabilities that you’ve thought about their experience. It tells investors, partners, and customers you are forward-thinking and responsible.

Who Needs a VPAT?

Let’s make this clear: You need a VPAT if you plan to sell to government agencies, especially in the U.S.

But even if your clients aren’t government bodies, large enterprises often demand VPATs from vendors. Why? Because they need to stay compliant and reduce risk across their supply chains.

So yes, tech startups, SaaS companies, app developers, and e-commerce platforms should all consider a VPAT essential if accessibility is a priority.

And let's face it — it should be.

How Is a VPAT Different from an Accessibility Statement?

Here’s a question I often hear: Isn’t a VPAT the same as an accessibility statement? 

The answer is a big No.

An accessibility statement is a public-facing document that usually appears on your website. It tells users what level of accessibility you’ve achieved and what you’re doing to improve.

A VPAT, however, is more technical and detailed. It is often shared during sales or procurement conversations, not as a general public resource.

One is for users. The other? For stakeholders and decision-makers.

Types of VPATs You Should Know

VPATs come in different versions, depending on which standards your product needs to meet. The key ones include:

• VPAT 2.4 Section 508 - This version focuses on U.S. government standards.

• VPAT WCAG 2.1 - Based on the globally accepted Web Content Accessibility Guidelines.

• VPAT EN 301 549 - Required if you are selling into European markets.

• VPAT International Edition - A combined version that includes all three standards.

So, before you start filling out the form, make sure you are working with the right edition.

How to Create a VPAT (Step-by-Step)?

Creating a VPAT isn’t just filling out a form and calling it a day. It’s a thoughtful process. Here’s how to approach it:

Step 1: Start with an Internal Audit

Before you touch the actual VPAT template, you need to understand where your product stands.

You can’t complete a VPAT without testing your product against the accessibility standards. 

And for that, you need an accessibility audit.

This is not a "gut feeling" exercise. It needs to be evidence-based, and that means testing.

Here’s how to do it:

Manual Testing

Use assistive technologies like:

• Screen readers (NVDA, JAWS, VoiceOver)

• Screen magnifiers

• Keyboard-only navigation (no mouse!)

Test common user flows, such as logging in, filling out forms, navigating menus, and interacting with dynamic content.

Automated Testing Tools

These tools help catch issues like missing alt text, contrast errors, or incorrect heading structures. Examples:

• Axe DevTools

• WAVE

• Lighthouse

User Testing (If Possible)

If you can, involve users with disabilities. Their feedback uncovers barriers that tools and testers often miss.

Step 2: Choose the Right VPAT Edition

Here’s where you need to be strategic. 

First, you must determine which standards your product is expected to comply with. 

This depends on your market, your audience, and your clients.

Here are your options:

• VPAT 2.4 Rev 508 - Required for U.S. federal clients. Based on Section 508.

• WCAG 2.1 Edition - Focuses on Web Content Accessibility Guidelines. Great for web apps, SaaS platforms, or anything public-facing.

• EN 301 549 Edition - For those selling in Europe.

• International Edition - Covers all of the above. Perfect if you are global or unsure.

If you are not sure which one to pick, ask your sales or compliance team what the client expects. Or just go with the International Edition to cover all your bases.

Step 3: Fill Out the Template

Now comes the real work. This is where you document your product’s accessibility performance.

Each standard (Section 508, WCAG, EN 301 549) includes a list of criteria. For every item, you will assign a conformance level:

• Supports - Your product fully meets the requirements.

• Partially Supports - Some features meet the standard, but others do not.

• Does Not Support - The feature fails to meet the requirement.

• Not Applicable - This part of the standard doesn’t apply to your product (e.g. if you don’t have video content).

For each item, include remarks and explanations. This is where your transparency comes through.

Instead of vague statements like “should work fine,” try something more informative like:

“Keyboard navigation works throughout most of the platform, except within the drag-and-drop dashboard editor. Fix planned in the upcoming release.”

Clear. Honest. Actionable.

This section isn’t just for compliance but a roadmap for your dev team and assurance for your buyers.

Step 4: Review and Validate Your Findings

You have filled out the template. Don’t rush to publish it yet. 

Bring in others — your QA team, legal, and external accessibility consultants — to cross-check your responses. They may catch inconsistencies or issues you missed.

You don’t want to submit a VPAT only to have a client find flaws during their audit.

If you are working with an external expert or agency, they can also help format your final Accessibility Conformance Report (ACR) — the polished output of your completed VPAT.

Step 5: Keep a Record of How Testing Was Done

Most VPAT templates ask about the evaluation methods used. Clients and procurement teams want to know how seriously you approached accessibility.

Document:

• Which testing tools you used

• What assistive technologies were involved

• Who conducted the testing (internal team vs. third-party)

• When the testing was last performed

This builds trust and shows accountability.

Step 6: Publish or Share Your VPAT

Some companies publish their VPATs on their websites or product pages, while others share them upon request during procurement conversations.

Decide what makes sense for your business model. Either way, make sure your team knows where the latest VPAT lives and how to access it.

Also, label the document with a version date and product version. 

Step 7: Review Regularly and Update As Needed

Here’s the part many forget — VPATs have a shelf life.

The software keeps changing. New features get added, the design gets tweaked, and things move fast. With every update, there’s a chance new accessibility issues may pop up.

Make it a habit to review and update it:

• After each major release

• At least once a year

• Whenever accessibility issues are reported or fixed

An updated VPAT tells people, “We’re not perfect, but we’re working on it.” That message matters more than a perfect score. Doing this shows you are responsible and transparent. 

So, keep it up to date. Keep it honest. Keep it helpful.

Conclusion

Accessibility is a mindset, a responsibility, a way to include, not exclude. It’s about the student using a screen reader, the aging parent adjusting font sizes, and the everyday user wanting a fair, simple experience.

Start with your product. Understand how people interact with it. Pick the right VPAT edition. Be honest. Keep it up to date.

And if it feels like too much — that’s alright. You don’t have to figure it out by yourself.

AccessifyLabs can help! We create VPATs, run accessibility audits, and give real support to make sure your product works for everyone.

Let’s make the web better—for everyone, together.