A VPAT audit tells buyers how accessible your product claims to be; accessibility testing tells your team what actually works, what breaks, and what to fix. They are related, but they solve different problems. If you treat them as the same task, you may end up with a polished report and a product that still blocks real users.
TLDR: A VPAT audit produces a formal accessibility conformance report, often needed for sales, procurement, or legal review. Accessibility testing checks the product itself through automated scans, manual review, keyboard use, screen readers, and user flows. For example, a SaaS company bidding on a state contract may need a VPAT showing WCAG 2.2 AA support, while testing might reveal that 18% of form fields still lack usable labels. One is the document buyers ask for; the other is the work that helps make the document honest.
What Is a VPAT Audit?
A VPAT audit is a structured review of a digital product against accessibility standards. VPAT stands for Voluntary Product Accessibility Template. The completed version is usually called an Accessibility Conformance Report, or ACR.
The audit checks how well a website, app, platform, document system, or software product supports standards such as:
- WCAG 2.1 or WCAG 2.2, often at Level AA
- Section 508, used by U.S. federal agencies
- EN 301 549, used in the European market
- Revised accessibility procurement rules for public sector buying
The result is not just a bug list. It is a formal statement of conformance. Each requirement is usually marked as supports, partially supports, does not support, not applicable, or a similar status.
That makes a VPAT audit useful for sales teams, legal teams, procurement teams, and enterprise buyers. It answers a direct question: Can this product meet our accessibility requirements?
What Is Accessibility Testing?
Accessibility testing is the practical process of finding barriers in a digital experience. It asks a more hands-on question: Can people with disabilities actually use this?
Good testing includes more than clicking a scan button. Automated tools help, but they miss a lot. A tool can spot missing alt text. It may not tell you whether the alt text is useful. It can flag low contrast. It will not always know if a checkout flow makes sense to a screen reader user.
The catch is that automated reports can look impressive while still leaving painful issues untouched. It drives teams crazy when a tool says a page is “92% accessible,” yet the menu takes 11 extra tab presses to reach and traps keyboard users inside a modal.
Accessibility testing may include:
- Automated scans for common issues like contrast, labels, ARIA errors, and heading structure
- Keyboard testing to confirm every action works without a mouse
- Screen reader testing with tools such as NVDA, JAWS, VoiceOver, or TalkBack
- Manual code inspection for semantic HTML and ARIA use
- Cognitive accessibility review for clarity, error prevention, and plain language
- Mobile accessibility checks for touch targets, zoom, orientation, and gestures
- User testing with people who use assistive technology in daily life
The Main Difference
The easiest way to separate the two is this:
- VPAT audit: produces a formal conformance document.
- Accessibility testing: identifies usability and compliance issues in the product.
A VPAT audit needs evidence. Accessibility testing provides much of that evidence. But they are not identical. Testing can happen every sprint. A VPAT audit usually happens before a sales opportunity, annual review, public sector bid, or major release.
| Area | VPAT Audit | Accessibility Testing |
|---|---|---|
| Main purpose | Document conformance | Find and validate accessibility issues |
| Audience | Buyers, procurement, legal, compliance | Designers, developers, QA, product teams |
| Output | Accessibility Conformance Report | Bug reports, test results, recommendations |
| Timing | Pre-sale, release, renewal, compliance review | During design, development, QA, and maintenance |
| Risk if skipped | Lost contracts or weak compliance proof | Broken experiences for users and inaccurate claims |
Why Teams Confuse Them
The confusion is common because both activities use the same standards. Both may refer to WCAG success criteria. Both may mention color contrast, form labels, focus order, captions, keyboard access, and screen reader support.
But the intent changes everything.
Accessibility testing is like inspecting a building for blocked ramps, heavy doors, poor signs, and broken elevators. A VPAT audit is like writing the official access report for that building. If the inspection is shallow, the report will be weak. If the report exaggerates, buyers may lose trust fast.
When You Need a VPAT Audit
You likely need a VPAT audit if you sell to government agencies, universities, hospitals, banks, or large enterprises. Many procurement teams request an ACR before they approve a purchase. Some will not even review a proposal without one.
A VPAT audit is also useful when:
- You are entering public sector procurement.
- A customer asks for proof of accessibility.
- Your legal team wants a documented risk position.
- You are preparing for a major product launch.
- You want a baseline before an accessibility remediation plan.
A weak or outdated VPAT can slow deals. In some cases, it can kill them. If a buyer asks for WCAG 2.2 AA status and your report only covers WCAG 2.0, expect extra questions. Expect delays too.
When You Need Accessibility Testing
You need accessibility testing long before a VPAT is written. Ideally, it starts during design. Color palettes, component libraries, forms, dialogs, menus, and error states should be checked before engineers build them across the whole product.
Testing is especially needed when:
- You add a new feature.
- You redesign a page or workflow.
- You change a design system or component library.
- You release mobile updates.
- You receive complaints from users.
- You prepare evidence for a VPAT audit.
Accessibility bugs get more expensive later. A missing label in a design system may spread to 300 screens. A broken focus state may affect every modal. Fixing it after launch can take days instead of minutes.
Can You Have One Without the Other?
Yes, but it is risky.
You can do accessibility testing without producing a VPAT. Many teams do this during normal development. That is healthy. It keeps issues from piling up.
You can also produce a VPAT without deep testing. But that is where trouble starts. A VPAT built from guesses, quick scans, or old data may mislead customers. If a buyer runs their own checks and finds major blockers, trust drops. Fast.
The best approach is simple: test first, document second. Use real findings to support the VPAT. If some criteria only partially support accessibility, say so. Then list known issues and remediation plans.
What a Strong Process Looks Like
A mature accessibility workflow connects testing and VPAT work without treating them as one giant last-minute task.
- Start with product scope. Define which pages, flows, platforms, and versions are included.
- Run automated and manual testing. Cover key user paths, not just home pages.
- Test with assistive technology. Use keyboard, screen readers, zoom, captions, and mobile settings.
- Prioritize issues. Focus on blockers first, such as unusable forms or trapped focus.
- Fix and retest. Do not assume a ticket is resolved because code changed.
- Prepare the VPAT audit. Match findings to standards and document support levels.
- Update regularly. A report from two years ago rarely reflects the current product.
Common Mistakes to Avoid
- Relying only on automation. Automated tools may catch around 20% to 40% of common WCAG issues, depending on the product and tool.
- Writing a VPAT as marketing copy. Buyers want accuracy, not glossy claims.
- Testing only one browser. Assistive technology behaves differently across browser and device combinations.
- Ignoring PDFs and documents. Procurement teams may review those too.
- Letting the VPAT go stale. New features can change conformance quickly.
The Bottom Line
A VPAT audit is about reporting accessibility conformance in a format buyers recognize. Accessibility testing is about finding real barriers and proving whether users can complete tasks. They support each other, but they are not the same thing.
If you need to win contracts, prepare a clear VPAT. If you want that VPAT to stand up to review, test the product properly first. The strongest teams do both on a regular schedule, not in a panic two days before procurement asks for the report.