Enterprise customers, universities, and government-adjacent buyers increasingly treat digital accessibility as a non-negotiable requirement. If you sell software-as-a-service, you’ve likely been asked for a “VPAT,” sometimes alongside security questionnaires and SOC 2 reports. A strong VPAT can reduce sales friction, clarify your compliance posture, and signal that accessibility is built into your product—rather than patched on during procurement.
This article explains what a VPAT is, how it applies to SaaS products, which standards it maps to, and how to produce a credible document backed by real testing and evidence.
VPAT stands for Voluntary Product Accessibility Template. It’s a standardized format used to create an Accessibility Conformance Report (ACR) that describes how a product meets accessibility requirements. In practice, “VPAT” is often used to refer to the completed report, not just the template.
A VPAT is not a certification, legal guarantee, or a one-time checkbox. It’s a structured statement of conformance that should be backed by testing results, known limitations, and remediation plans. Buyers use it to compare vendors, assess risk, and identify where accommodations may be needed.
SaaS products are used across many environments—employee portals, learning platforms, citizen-facing services, internal tools—so accessibility risk scales quickly. A VPAT helps procurement teams answer questions like:
If your customers include U.S. federal/state entities, higher education, healthcare, or large enterprises with mature compliance programs, a VPAT often becomes mandatory. This is especially true when your SaaS touches high-impact workflows like hiring and onboarding—see how accessibility expectations show up in platforms like job portals and HR tools.
There are multiple VPAT editions depending on the regulatory context. The most common are:
Many organizations request a VPAT that includes both Section 508 and WCAG, or a combined report that also references EN 301 549. Your sales region and customer base usually determine which version is expected.
SaaS accessibility isn’t limited to “the website.” You’re typically documenting conformance across:
For regulated contexts like healthcare, accessible patient or staff experiences can be tied directly to trust and outcomes. If your SaaS serves clinical environments, the stakes (and scrutiny) are higher—see practical considerations in digital accessibility for hospitals and clinics.
A VPAT should be honest, test-based, and actionable. Here’s a practical process that works for most SaaS teams.
Start by documenting what’s included: domains, key pages, authenticated areas, roles/permissions, and critical workflows (e.g., sign-in, data entry, checkout, exporting reports). Buyers care most about real tasks, not isolated UI screens.
Also note supported browsers, assistive technologies, and environments (e.g., “latest Chrome/Edge + NVDA,” “Safari + VoiceOver”). VPATs are stronger when you specify what you actually tested.
Automated checks can catch common issues (missing labels, contrast failures, heading structure problems), but they don’t validate full usability. Use automation to triage and monitor, not to claim complete conformance.
Platforms like Corpowid (corpowid.ai) can help SaaS teams run automated accessibility audits and ongoing monitoring across key pages, making it easier to track regressions as your UI changes.
Manual evaluation is essential for criteria involving interaction, focus order, error handling, and dynamic components. Include at least:
Where possible, validate findings with real users with disabilities. This is where many “looks compliant” products break down in actual use; the difference is explained well in why user testing with people with disabilities beats any automated tool.
Most VPATs ask you to indicate conformance levels (e.g., Supports, Partially Supports, Does Not Support) and provide remarks. The remarks are where credibility is earned. Good remarks include:
Avoid overstating. If your date picker traps focus or a chart lacks text alternatives, mark it accordingly and explain the plan to fix it. Procurement teams often prefer an honest “Partially Supports with a roadmap” over an unrealistic “Supports” that falls apart in validation.
A VPAT is easiest to maintain when accessibility is integrated into your system, not handled as a one-off project. Prioritize:
This also supports inclusive experiences for broader audiences—especially as you scale to new regions and user populations. Accessibility isn’t just compliance; it’s participation and equity, as highlighted in who gets left behind when digital services aren’t accessible.
Many buyers look for an accessibility statement that summarizes your commitment, standards targeted (e.g., WCAG 2.2 AA), known limitations, and a contact method for support. Your VPAT is a technical procurement artifact; your accessibility statement is the public-facing trust signal.
Tools like Corpowid (corpowid.ai) can streamline maintaining an accessibility statement by tying it to audit findings and helping teams keep disclosures current as issues are resolved.
In SaaS, the product changes constantly—new components, redesigned flows, third-party integrations. A VPAT should be treated as a living document. Update it when:
As a baseline, many vendors refresh their VPAT annually, but high-velocity products often need updates more frequently. Ongoing monitoring helps you detect regressions early; Corpowid can support this with continuous checks that complement manual testing.
A VPAT is ultimately a snapshot of how inclusive your SaaS experience is today—and how responsibly you manage gaps tomorrow. Teams that treat accessibility as a product quality practice (like security and performance) tend to produce VPATs that stand up to scrutiny and reduce back-and-forth with enterprise buyers. It also positions your product to support inclusive digital moments at scale—whether that’s serving employees, patients, job seekers, or the public during large events like building a digital celebration everyone can access.
Hospitals and clinics serve everyone—so their websites, patient portals, and digital forms must work for everyone. This guide explains WCAG-based accessibility priorities, common barriers, and a practical compliance roadmap.
Corpowid has been recognized by Gartner, a leading global research and advisory firm, for our innovation and performance in digital accessibility. These badges reflect our commitment to creating inclusive, AI-powered web experiences.
TR
