A VPAT audit helps you prove your product is accessible before a buyer, agency, or legal team asks hard questions. Do it early. It is much cheaper than fixing a mess during a sales review.
TLDR: A VPAT audit checks how well your website, app, or software meets accessibility rules like WCAG, Section 508, and EN 301 549. The result is an Accessibility Conformance Report, or ACR, which buyers use to judge risk. For example, a SaaS company bidding on a school district contract may lose a deal worth $120,000 if its VPAT says “not supported” too often. Fixing just 12 keyboard and screen reader issues could move that product from “risky” to “ready for review.”
Table of Contents
What Is a VPAT Audit?
A VPAT stands for Voluntary Product Accessibility Template. Sounds friendly. Sounds optional. Then a client asks for one and suddenly everyone panics.
A VPAT audit is the process of checking your product against accessibility standards. The auditor tests features, pages, forms, buttons, menus, documents, and user flows. Then they record the results in a formal report.
That report is usually called an ACR, or Accessibility Conformance Report. People often say “VPAT” when they mean the finished report. Close enough for casual talk. But in contracts, words matter.
Think of the VPAT template as an empty report card. The audit fills it in.
Why Businesses Need One
A VPAT audit is not just for huge tech companies. It matters for any business selling digital products to schools, hospitals, banks, government offices, or large companies.
These buyers care about accessibility. They also care about risk. If your product blocks people with disabilities, the buyer may face complaints, legal costs, or angry users. Nobody wants that meeting.
A solid VPAT can help you:
- Win contracts with public agencies and large buyers.
- Shorten procurement reviews by giving teams clear answers.
- Find accessibility bugs before users complain.
- Reduce legal exposure linked to digital access.
- Build trust with customers who care about inclusion.
Honestly, it feels like some companies treat accessibility as a paperwork chore. Then one missing label on a payment form blocks a blind user from buying. That is not paperwork. That is lost revenue and a bad experience.
What Gets Tested?
A good VPAT audit checks real use. Not just pretty screenshots. Not just the homepage. The auditor should test what people actually do.
Common test areas include:
- Keyboard access: Can users move through the product without a mouse?
- Screen reader support: Do buttons, fields, and alerts make sense when read aloud?
- Color contrast: Can people read text without squinting?
- Forms: Are labels, errors, and instructions clear?
- Focus order: Does the page move in a sane order?
- Captions and transcripts: Are videos and audio usable for more people?
- PDFs and documents: Are files tagged and structured?
- Mobile views: Does access hold up on small screens?
It drives teams a little mad when a modal window traps the keyboard. The user presses Tab five times. Nothing useful happens. Then Escape fails too. That is the digital version of locking someone in a closet.
Which Standards Matter?
Most VPAT audits focus on one or more major standards. The right ones depend on your market.
- WCAG: The Web Content Accessibility Guidelines. These are the most common rules for websites and apps.
- Section 508: U.S. federal accessibility rules. These matter if you sell to federal agencies.
- EN 301 549: European accessibility rules for digital products and services.
- Revised VPAT formats: Templates exist for WCAG, 508, EU, and international reporting.
If you sell globally, you may need the international VPAT version. If you sell to one agency, ask which version they expect. Guessing can waste days.
What the Ratings Mean
VPAT reports use standard conformance terms. They sound dry, but they matter a lot.
- Supports: The product meets the requirement.
- Partially Supports: Some parts pass. Some parts fail.
- Does Not Support: The product fails the requirement.
- Not Applicable: The rule does not apply to the product.
- Not Evaluated: The item was not tested.
Be careful with “Not Evaluated.” Too many of those can look lazy. Buyers may assume you are hiding bad news. That may be unfair. But procurement teams are busy. They skim. Then they flag risk.
How a VPAT Audit Works
The process is simple when planned well.
- Set the scope. Pick the product, version, pages, modules, and user flows.
- Choose the standard. WCAG, Section 508, EN 301 549, or a mix.
- Test key tasks. Login, search, checkout, account setup, reports, admin tools, and support areas.
- Record issues. Each issue should include steps, impact, and proof.
- Fix what you can. Quick fixes often make a big difference.
- Complete the VPAT. Use clear notes. Do not sugarcoat failures.
- Plan updates. A VPAT should age like milk, not wine. Review it after major releases.
A strong audit does not just say “fail.” It explains why. Better yet, it gives your team a fix path. For example, “Add a programmatic label to the email field” is much more useful than “form issue.”
Who Should Do the Audit?
You have three common choices.
- Internal team: Good if you have trained accessibility staff.
- External auditor: Good for independence and buyer trust.
- Hybrid approach: Internal testing first, third-party review after fixes.
For sales deals, an outside audit often carries more weight. Buyers may trust it more. It also helps your team spot blind spots. No joke intended.
Still, internal testing is valuable. Your team knows the product. They know the weird admin screens. They know the button everyone is scared to touch because it was built five years ago by someone named Greg who left no notes.
Common VPAT Mistakes
Most VPAT problems are avoidable. Here are the big ones.
- Testing only the homepage. Your checkout or dashboard may be where the real issues live.
- Being too vague. “Some issues exist” tells buyers nothing.
- Marking everything as supported. If it is not true, it can backfire.
- Ignoring mobile. Many users live on phones.
- Skipping assistive tech testing. Automated tools are not enough.
- Letting the report go stale. A two-year-old VPAT may not match the current product.
Automated scanners are useful. They catch things like missing alt text and weak contrast. But they miss meaning. They cannot always tell if a button label makes sense. They usually cannot follow a complex workflow like a real person.
How Long Does It Take?
Small website? Maybe one to two weeks. Large SaaS platform? Think four to eight weeks, sometimes more. It depends on size, complexity, and how many fixes you want before publishing the ACR.
Expect to waste time if the scope is fuzzy. “Test the app” is not a scope. “Test login, billing, reporting, user settings, admin roles, and help center for version 4.2” is much better.
How Much Does It Cost?
Costs vary. A small audit may cost a few thousand dollars. A large enterprise product can cost much more. The price depends on pages, user roles, platforms, standards, and report detail.
Do not shop only by price. A cheap VPAT that misses major barriers can cost more later. Ask for sample reports. Ask what testing methods they use. Ask if people with assistive tech skills are involved.
What Businesses Should Do Next
Start with a simple plan. Pick your key product. Pick the standard your buyers need. Run an internal check. Fix obvious issues. Then get a formal VPAT audit.
Keep the report honest. Buyers do not expect perfection. They expect clarity. A product with some issues and a clear repair plan often looks better than a perfect-looking report that feels fake.
The best VPAT audit is not just a compliance file. It is a product health check. It helps more people use your software. It helps sales teams answer tough questions. And yes, it can keep legal headaches away.
Accessibility is not glitter you add at the end. Build it in. Test it often. Your users will notice. Your buyers will too.
