If your organization is suddenly focused on digital accessibility because the sales teams needs a VPAT or ACR asap, there is good reason. The requirement for accessibility and WCAG compliance is newer for SaaS providers, compared to website teams who have had this pressure on them for years. The spotlight is now on web apps and SaaS platforms because of both the ADA Title II update in the US, and the new European Accessibility Act globally. While this may appear as a burden initially, there are significant upsides to making your products accessible, in addition to earning a VPAT to satisfy sales and their need to meet procurement requirements to get through the front door.
The process is straightforward once you know what’s involved: define scope, coordinate internally, work with auditors, and maintain the documentation over time.
This post covers each step so you can move confidently and set your team up to do this the right way – because yes, there are wrong ways.
What is the difference between a VPAT and an ACR?
Let’s clear up this potential confusion right up front. A VPAT is a template that covers the audit scope (core workflows, documentation, authentication), and is designed to evaluate the level of conformity with WCAG 2.2 (or 2.1) Level AA. The completed VPAT becomes an ACR (Accessibility Conformance Report). Most in the industry inaccurately refer to an ACR as a VPAT. That’s ok though, just roll with it.
Who should author your product VPAT?
First, SaaS companies obtain a VPAT by having an audit conducted – but not be anyone with a screen reader or a friend with blindness. The depth of the audit is key, else the VPAT will be shallow and lack credibility needed by procurement. Also, a good audit provides a lot of added value in the form of clearer and more contextual remediation guidance. And ultimately the added value is in making your product simply work better for more people. This is not just a procuerment cost, its an opportunity to enhance your platform.
Even if you have WCAG testing tools in your workfow, and have people who can work a screen reader, that doesn’t prepare you for authoring a VPAT that will pass procuerment scrutiny. The VPAT is a technical template that requires substantial experience and knowledge of both the WCAG and the myriad of user spectrums and technogy scenarios to cover. A VPAT author must also understand that front-side code of the product and the workflow for production. Lastly, an author of a SaaS VPAT must have a thorough undersanding of the accessibility and WCAG compliance of the product itself. This requires a comprehensive audit that goes beyond what an in-house team is capable of producing with basic WCAG testing tools. But with an experienced accessibility compliance consultant with a lot of experience in the SaaS space, this process will provide a lot more value than producing a clean VPAT/ACR
Who Owns VPAT Readiness Inside a SaaS Organization?
VPAT readiness is cross-functional. Product management typically drives the process, engineering owns technical implementation and remediation, design maintains accessible component libraries, and legal reviews conformance claims. Assigning a single accountable owner—often a product lead or accessibility program manager- prevents work from stalling between teams. This is the key to success.
Product Management typically drives the process. PMs define what’s in scope, coordinate timelines, and connect audit findings to roadmap decisions. They’re the ones who get the call when procurement asks for documentation.
Engineering owns the technical implementation. They’ll need to provide test accounts, explain custom components, and ultimately fix what the audit uncovers. Engineers who understand WCAG criteria can anticipate issues before they become findings.
Design owns patterns and component libraries. If your design system has accessibility gaps, every product built on it inherits those gaps. Design needs visibility into audit results to update shared patterns.
Legal and Compliance care about the claims you make. They’ll want to understand what “Supports” vs. “Partially Supports” means and how findings translate to risk. Some organizations route ACRs through legal review before publishing.
Customer Success and Sales need to know what documentation exists, when it was last updated, and how to respond when procurement asks questions. They shouldn’t be discovering gaps during an RFP.
The common failure: treating accessibility as an engineering task alone. Organizations that assign a single owner move faster.
What Scope Should a SaaS VPAT Cover?
SaaS VPATs should cover core application functionality, authentication and onboarding flows, help documentation, and any third-party components or integrations users interact with. If mobile or responsive access is common, include those experiences. Define scope explicitly and document what’s excluded to avoid procurement follow-up questions.
Core application functionality is baseline. This includes the primary workflows users interact with: dashboards, data entry, reporting, configuration. If it’s behind the login, it’s likely in scope.
Documentation and help content often gets missed. If users rely on knowledge bases, embedded help, or PDF guides, those need testing. Inaccessible support documentation creates barriers even when the product itself is accessible.
Authentication and onboarding flows are high-risk areas. These are the first things users encounter. If someone using a screen reader can’t complete signup or password reset, product accessibility is irrelevant.
Third-party integrations and embedded components are complicated. You may not control the code, but you’re responsible for the experience. If you embed a chat widget, payment form, or analytics dashboard, its accessibility becomes your problem.
Mobile and responsive experiences matter if that’s how users access your product. A VPAT covering only desktop when your users work from tablets leaves gaps procurement will notice.
Define scope early. Document what’s included and what’s explicitly excluded. Auditors and procurement reviewers both benefit from clarity.
What Slows SaaS Teams Down During VPAT Preparation?
Common delays include design system accessibility debt, false confidence in third-party component libraries, complex custom interactions, difficulty provisioning test accounts, rapid release cadence creating moving targets, and feature flags obscuring what’s in production. Teams with simpler products and clear ownership typically move 2-3x faster through preparation.
Design system debt is the most common bottleneck. If your shared components have accessibility issues—improper ARIA, missing keyboard support, broken focus states—every product surface inherits those issues. Fixing the system fixes everything built on it; ignoring it multiplies remediation work.
Third-party component libraries create false confidence. “We use Material UI” or “Our charts are from a popular library” isn’t evidence of accessibility. Component libraries vary widely in conformance, and defaults often need customization. Test what you actually ship.
Custom interactive patterns require manual verification. Drag-and-drop interfaces, complex data grids, multi-step wizards, real-time collaboration features- these are where automated tools miss problems. If your product differentiates on interaction design, expect more manual testing time.
Authentication and role-based access complicate audit logistics. Auditors need access to every user role and permission level. If provisioning test accounts requires tickets through IT, build that into your timeline.
Rapid release cadence creates moving targets. If you ship weekly, the product changes during the audit. Teams need to decide: freeze the scope, or accept that findings may need re-verification.
Feature flags and A/B tests obscure what’s actually in production. If features vary by user segment, someone needs to define what the “real” product is for audit purposes.
What Do SaaS Teams Misunderstand About VPATs?
Common misconceptions derail preparation. Teams assume automated scans are sufficient (they typically catch 30–40% of WCAG issues), that the VPAT template is the solution (it requires testing evidence), that component library claims equal conformance (implementation matters), and that documentation can wait until a deal requires it (procurement timelines don’t wait for audits).
“We’ll just run an automated scan.” Automated tools catch roughly 30–40% of WCAG issues. They can’t test whether a screen reader user can complete your multi-step workflow, whether keyboard focus moves logically, or whether dynamic content announces correctly. A VPAT based only on automated results won’t survive procurement scrutiny.
“We just need a template.” The VPAT template is a reporting format, not a solution. Filling it out accurately requires evidence from real testing. “Supports” claims without test documentation invite challenges. Procurement reviewers—especially in government and higher education—have seen enough weak VPATs to know what thorough looks like.
“Our component library claims WCAG conformance.” Library marketing isn’t evidence. How you implement components, what you customize, and how components interact in your specific product all affect conformance. The VPAT must reflect your actual implementation.
“We can mark everything ‘Supports with Exceptions.'” Overusing this rating signals evasion. Procurement reviewers prefer honest “Partially Supports” or “Does Not Support” with clear explanations over vague exceptions that obscure real gaps.
“We’ll handle this when a deal requires it.” Enterprise procurement timelines don’t wait for audits. If a contract requires documentation in 30 days and you haven’t started, you’re already too late. Teams that treat VPATs as proactive sales assets avoid last-minute scrambles.
“We can do this ourselves.” Product managers naturally gravitate toward owning deliverables—it’s what makes them effective. But VPAT authoring requires deep familiarity with WCAG success criteria, the many ways different disabilities affect interaction, and how assistive technologies actually behave across browsers and platforms. Knowing your codebase isn’t the same as knowing whether a custom dropdown works with JAWS, VoiceOver, and Dragon. A VPAT authored by a qualified accessibility consultant carries more weight with procurement reviewers, and it’s far less likely to contain errors that invite follow-up questions—or undermine your credibility when a buyer’s accessibility coordinator takes a closer look.
What Does Good Evidence Look Like for VPAT Claims?
Credible ACRs include tested workflows (not just pages), assistive technology coverage (screen readers, keyboard, voice control), reproducible findings with steps to replicate, and version and date stamps. Evidence should be sufficient for a procurement reviewer to trust claims without requiring exhaustive narrative.
Good evidence includes:
- Tested workflows, not just pages. Did you verify that a user can complete onboarding, enter data, run reports, and configure settings without a mouse? Workflow-level evidence matters more than page-level scans.
- Assistive technology coverage. Testing with at least one screen reader (commonly JAWS, NVDA, or VoiceOver), keyboard-only navigation, and voice control demonstrates real-world validation.
- Reproducible findings. Test notes should describe steps to reproduce issues, not just “contrast failed on settings page.” Reproducibility helps your team fix issues and demonstrates rigor.
- Version and date stamps. Audits are point-in-time. Your documentation should state what version was tested and when. Procurement needs to know whether the ACR reflects the current product.
Good evidence doesn’t require exhaustive narrative. It requires enough detail that a reviewer can trust the claims.
What Happens After the VPAT Exists?
After receiving an ACR, teams should expect procurement follow-ups, plan to update documentation after major releases, and maintain remediation plans for items rated below full conformance. Organizations that embed accessibility into design and QA processes sustain conformance more effectively than those treating VPATs as one-time projects.
Procurement follow-ups are normal. Reviewers may ask clarifying questions, request remediation timelines for “Partially Supports” items, or want to see your accessibility roadmap. Having internal owners who can respond quickly matters.
Major releases trigger updates. If you redesign your dashboard, add new workflows, or rebuild core components, the ACR needs to reflect those changes. Some organizations audit annually; others update after significant releases.
Customers expect freshness. An ACR dated two years ago invites skepticism about current conformance. Maintaining documentation signals ongoing commitment—and makes the next update faster because less has drifted.
Remediation doesn’t end with the audit. Audits surface issues; fixing them is separate work. Teams need realistic plans for addressing findings, especially for items rated “Does Not Support” or “Partially Supports.”
Accessibility becomes operational. Organizations that succeed long-term embed accessibility into design reviews, QA processes, and release criteria. The VPAT becomes one output of a broader capability—not a one-time project.
How Often Should a SaaS VPAT Be Updated?
VPATs should be updated after major product releases or at least annually. Documentation older than 18–24 months raises procurement concerns about current conformance. Organizations with rapid release cycles often maintain a rolling update schedule, refreshing documentation quarterly or after significant feature launches. Frequent updates are faster when accessibility is embedded in development workflows rather than treated as a periodic project.
Making VPAT Readiness Part of Your Product Workflow
Treating accessibility documentation as reactive—something to scramble for when procurement asks—creates predictable stress. Teams that build readiness into normal operations move faster and compete better.
That means assigning ownership, scoping honestly, budgeting time for preparation, and maintaining documentation after it’s created. The VPAT is the artifact; the capability is what makes it credible.
FAQ
How long does it take to get a VPAT for a SaaS product?
Total timeline depends on product complexity, internal readiness, and remediation scope. Audits themselves typically take 4–8 weeks. Internal preparation—defining scope, provisioning access, addressing known issues—often adds several weeks. Teams responding to RFPs should plan months ahead, not weeks.
Can we write our own VPAT in-house?
Technically yes, but procurement reviewers give more weight to ACRs from independent third-party evaluators. Self-authored VPATs invite scrutiny about objectivity and often contain inaccuracies due to unfamiliarity with WCAG nuances. Third-party documentation signals rigor.
Do we need separate VPATs for US, EU, and Canada?
No. WCAG 2.2 Level AA underpins accessibility requirements across these regions. A comprehensive ACR based on WCAG 2.2 AA addresses ADA, Section 508, EN 301 549 (EAA), and Canadian standards. One thorough audit covers multiple jurisdictions.
What’s the difference between a VPAT and an ACR?
The VPAT is the template format. Once completed based on actual product testing, the document becomes an ACR (Accessibility Conformance Report). The terms are often used interchangeably in procurement contexts, but the ACR is the finished documentation buyers review.
How do we handle third-party components in our VPAT?
If users interact with third-party widgets, embeds, or integrations within your product, those experiences fall under your VPAT scope. You’re responsible for the user experience regardless of code ownership. Document third-party components, note any accessibility gaps, and include remediation plans where possible.
What if our product can’t fully conform to WCAG 2.2 AA?
Honest disclosure is better than vague claims. Use accurate conformance ratings (“Partially Supports,” “Does Not Support”) with clear explanations of gaps and remediation plans. Procurement reviewers respect transparency and specific timelines over ambiguous “Supports with Exceptions” ratings.
Should we update our VPAT every time we release a feature?
Not every release warrants a full update, but major changes—new workflows, redesigned interfaces, rebuilt components—should trigger ACR review. Many organizations audit annually and update after significant releases. Stale documentation raises procurement concerns about current conformance.