VPAT Cost: What It Really Takes to Document Accessibility Compliance

“VPAT cost” is one of the first questions procurement teams ask when accessibility requirements appear in an RFP. The tricky part is that a VPAT isn’t a product you simply “buy” off the shelf—it’s the documentation of real testing, evidence gathering, and truthfully describing how a digital product meets (or doesn’t meet) accessibility standards.

A VPAT (Voluntary Product Accessibility Template) is commonly delivered as an ACR (Accessibility Conformance Report). It’s widely used for U.S. public-sector purchasing and for private organizations that want consistent accessibility documentation. Your VPAT cost will largely reflect how much work is required to test the product against applicable requirements (often WCAG and Section 508), and how much remediation or risk clarification is needed before the report can be signed off.

What you’re paying for when you pay for a VPAT

A VPAT/ACR is more than a “fill in the table” exercise. A credible report usually includes several labor-intensive components:

• Scope definition: which product version, platforms (web, iOS, Android), user flows, and document types are included.
• Accessibility testing: manual testing (keyboard, screen readers, zoom/reflow, contrast), plus limited automated checks.
• Evidence collection: screenshots, code snippets, reproduction steps, and test notes to support each conformance statement.
• ACR authoring: writing accurate remarks, exceptions, and “supports with exceptions” notes without over-claiming.
• Review and validation: internal QA, stakeholder review, and often legal/procurement alignment.

When done well, a VPAT becomes a living artifact that helps sales, compliance, and product teams have honest conversations about accessibility and roadmap commitments.

Typical VPAT cost ranges (and why they vary)

Pricing varies by vendor, scope, and maturity, but you can think in ranges rather than one universal number:

• Small, low-complexity web app or marketing site: often a few thousand dollars, if the scope is limited and the site is already WCAG-conscious.
• Mid-size SaaS product (multiple roles, dashboards, complex components): commonly in the mid four figures to low five figures.
• Enterprise platforms (multiple modules, integrations, rich data visualization, admin tooling): can extend into higher five figures, especially when multiple platforms and detailed evidence are required.
• Multi-platform products (web + iOS + Android): cost often increases substantially because each platform needs its own testing approach and assistive-technology coverage.

These numbers move up quickly when the VPAT must cover multiple product editions, customer-specific configurations, or tightly regulated workflows (e.g., claims, banking, healthcare).

Key factors that drive VPAT cost

1) Product scope: pages, screens, and critical user flows

Most VPAT projects are scoped around representative screens and critical flows (login, onboarding, checkout/transactions, reporting, account settings). The more unique UI patterns you have, the more test coverage is needed. A common cost pitfall is underestimating “variations”: modals, dynamic tables, drag-and-drop, custom date pickers, charting libraries, and role-based experiences.

2) Accessibility maturity and remediation readiness

If the product is already aligned with WCAG (semantic HTML, consistent focus states, accessible components, adequate color contrast), testing and documentation are faster. If the product has recurring issues—missing labels, non-keyboard operable controls, inaccessible PDFs, or inconsistent heading structure—testers spend more time documenting exceptions and re-testing fixes.

For organizations in regulated industries, accessibility maturity can also influence how procurement evaluates risk. For example, if your product supports insurance workflows, accessibility gaps can have outsized impact; see Digital Accessibility for Insurance Companies: A Practical WCAG Compliance Guide for how industry expectations shape compliance planning.

3) Standard and edition: VPAT 2.x, WCAG level, and Section 508 mapping

VPATs can cover different technical criteria depending on what the customer requests: WCAG 2.1 vs 2.2, Level A/AA/AAA (AA is most common), and Section 508 requirements. Broader coverage means more criteria to evaluate and more evidence to capture.

4) Testing method: automated checks vs. manual testing

Automated tools are useful for finding certain issues at scale, but they cannot validate many WCAG success criteria (e.g., meaningful focus order, accurate alternative text, form error recovery, or whether instructions rely solely on sensory characteristics). A credible VPAT relies heavily on manual testing using assistive technologies such as screen readers and keyboard-only navigation.

This is also why “AI-only VPAT creation” is rarely sufficient. AI can accelerate drafting and organizing findings, but humans still need to validate real user impact and edge cases. For a deeper look, read How AI Is Changing VPAT Creation—and Where Human Review Still Matters.

5) Evidence quality and defensibility

Procurement teams and accessibility stakeholders increasingly expect a VPAT to be specific: which screen, what assistive technology, which steps fail, and what workaround exists (if any). Producing defensible remarks takes time, but it reduces downstream friction when customers ask follow-up questions—or when accessibility commitments become contractual.

Hidden costs: what’s outside the VPAT line item

Even if a vendor quotes a single price for the VPAT document, plan for these related costs:

• Engineering remediation: fixing issues found during testing can exceed the reporting cost, especially for design system updates.
• Design and content changes: improving contrast, restructuring headings, rewriting link text, or clarifying instructions.
• Regression testing: validating fixes across browsers, devices, and assistive technologies.
• Training and governance: preventing the same issues from recurring in new releases.

It’s similar to what organizations learn from high-profile accessibility scrutiny: the cost isn’t just the artifact, it’s the operational discipline behind it. The story behind Netflix and Closed Captions: A Landmark Accessibility Settlement is a reminder that accessibility expectations can evolve into enforceable commitments.

How to reduce VPAT cost without reducing quality

Start with a targeted WCAG audit and fix the repeat offenders

Before commissioning a VPAT, run a structured WCAG audit to identify the systemic issues that will appear everywhere (missing form labels, inaccessible navigation, non-semantic components). Fixing these early reduces the number of “supports with exceptions” statements and speeds up validation.

Platforms like Corpowid (corpowid.ai) can help teams run automated accessibility audits and ongoing monitoring to catch common WCAG failures earlier in the development cycle, so the VPAT effort focuses more on verification and evidence rather than discovery.

Define a realistic scope that matches procurement needs

A VPAT should reflect what you’re actually selling. If a customer only uses your web admin portal, don’t automatically include a mobile app unless it’s part of the purchasing decision. For mobile, the test methodology and coverage differ significantly; this checklist can help you scope properly: Mobile App Accessibility Audit: A Practical WCAG-Based Checklist.

Standardize your components (design system) and document patterns

Reusable, accessible components reduce testing repetition. When a date picker, modal, or table pattern is consistent across the product—and proven accessible—you reduce both remediation time and VPAT authoring time.

Don’t confuse overlays/widgets with conformance

Some organizations try to “lower VPAT cost” by adding an accessibility overlay and assuming it will translate into compliance statements. In practice, overlays don’t replace structural fixes or reliable keyboard/screen-reader behavior. If you’re considering this route, it’s worth understanding the limitations: Free Accessibility Widget: What It Can (and Can’t) Do for WCAG Compliance.

That said, tooling can still help when used appropriately: Corpowid (corpowid.ai) combines audits, monitoring, and accessibility statement tools that support an overall compliance program—useful for staying aligned between VPAT updates.

What to ask for in a VPAT cost quote

To compare quotes fairly, ask vendors (or internal teams) to clarify:

• Which standards are covered (WCAG 2.1/2.2, Level A/AA, Section 508).
• Exact scope: pages/screens, user roles, critical workflows, and file types (PDFs, embedded media).
• Assistive technologies to be used (screen readers, browsers, mobile OS versions).
• Deliverables: VPAT/ACR format, issue log, evidence, retest cycles, and presentation to stakeholders.
• Assumptions: access to staging, test accounts, design system documentation, and engineering support.
• Update policy: how pricing changes for new releases or annual renewals.

Bottom line: VPAT cost is really “cost of truth”

A VPAT is valuable because it communicates reality—what works, what doesn’t, and what you’re doing about it. The most cost-effective approach is to invest in accessibility earlier (inclusive design, accessible components, continuous testing) so the VPAT becomes confirmation rather than discovery. When you treat the VPAT as part of an ongoing WCAG compliance program, you typically spend less over time—and you build more trust with buyers who rely on accessibility to serve their users.