A VPAT for SaaS Products has moved from an optional attachment to a gate that decides whether public-sector and education deals can close at all.
The trigger is regulatory. The Department of Justice’s 2024 rule under Title II of the ADA names WCAG 2.1 Level AA as the technical standard for state and local government web content and mobile apps, and the DOJ’s own fact sheet makes clear that the standard applies even when an outside company built or maintains the content. In April 2026 the DOJ pushed the compliance dates back by a year, but it left the standard unchanged. Every government customer you sell to still needs to know your product will not put them out of compliance.
This guide explains what buyers are really asking for, what a credible VPAT for SaaS products contains, how to build one in five steps, how to keep it current, and where teams go wrong. It is a practical starting map for SaaS product, growth, and revenue leaders, not legal advice, so confirm your specific obligations with counsel.
Why a VPAT for SaaS Products Became a Deal Gate
Three shifts explain why a VPAT for SaaS products is now a sales requirement rather than a courtesy.
First, the accessibility duty flows through vendors. The Justice Department’s fact sheet on the Title II web rule gives a telling example: a county web page listing park hours must meet WCAG 2.1 Level AA even if a local web design company built it and keeps it updated. Replace the web design company with your software, and the logic is identical. A government customer cannot hand its obligation to you, so it pushes that obligation into contract language and procurement checklists.
Second, the date moved but the work did not. Buyers know their deadlines are approaching, and procurement lead times are the most common reason compliance dates get missed. That is why many public entities are sending conformance requirements to vendors now, not at the last minute. A VPAT for SaaS products is how you answer before the question stalls a renewal.
Third, standard vendor questionnaires have absorbed the topic. The HECVAT, the questionnaire widely used by higher-education buyers, includes accessibility questions such as whether a product conforms to WCAG 2.1 AA, and trade coverage describes vendors being expected to supply a report that has been updated within the past twelve months.
One clarification keeps the conversation honest. The ADA does not itself require a VPAT or a completed report. The legal obligation is accessible digital content. A VPAT for SaaS products is the procurement artifact that evidences your side of it, which is exactly why buyers rely on it.
The April 2026 Deadline Extension
On April 20, 2026, the Federal Register published the DOJ’s interim final rule extending the Title II compliance dates by one year. Public entities serving 50,000 or more people now have until April 26, 2027, and smaller entities and special district governments until April 26, 2028. The standard, the scope of covered content, and the exceptions stayed the same.
Two cautions apply. An extension gives your customers more time to reach conformance, but those customers still need conforming vendors to get there. And the DOJ has signaled it may revisit parts of the rule, so the dates and details deserve monitoring. The safest planning assumption is that WCAG 2.1 AA stays the benchmark.
Who Asks for Accessibility Proof, and Why
Requests for accessibility evidence come from several directions, and the same VPAT for SaaS products can usually answer most of them.
| Regime or questionnaire | Who it reaches | Standard it points to | What vendors get asked for |
|---|---|---|---|
| ADA Title II web rule (DOJ) | State and local governments, including public colleges and universities | WCAG 2.1 Level AA | A conformance report and contract language; dates are April 26, 2027 (50,000+) and April 26, 2028 (smaller entities) |
| HHS Section 504 web rule | Healthcare providers receiving HHS funding | WCAG 2.1 Level AA | Conformance evidence for patient-facing tools; dates reported as May 11, 2027 and May 10, 2028 |
| European Accessibility Act | Covered consumer-facing products and services sold in the EU | EN 301 549, which maps to WCAG 2.1 AA | Evidence from vendors whose product powers a covered service; in force since June 28, 2025 |
| HECVAT | Higher-education buyers | WCAG 2.1 AA conformance question | A VPAT or completed report that is current |
| Private-sector buyers | Varies by industry | Usually WCAG 2.1 AA by convention | The same report, often inside a procurement or security packet |
Two points of scope are worth spelling out. For private businesses, Title II never applied, and no single regulation names a web standard for them, although WCAG 2.1 AA remains the benchmark commonly cited in practice. For the European Accessibility Act, analyses of the directive generally conclude that a purely B2B product sold through sales-led contracts and used behind a login sits outside its direct scope. Consumer-reachable surfaces are different: a public sign-up flow, a self-serve checkout, or a help center can fall inside it, and your business customers’ own obligations still flow into your contracts. Teams already managing EU documentation can reuse the discipline; our EU AI Act compliance checklist shows how to structure that kind of evidence.
What a VPAT for SaaS Products Must Contain
A VPAT for SaaS products that satisfies a procurement office is specific, dated, and honest. It tells the reader which product and version was evaluated, how it was tested, which standards it was measured against, and where it falls short.
Template Versus Finished Report
Terminology causes confusion here. VPAT is the template; the completed document is the Accessibility Conformance Report, or ACR. Procurement teams often ask for a VPAT when what they actually need is a finished ACR. The current edition of the template, VPAT 2.5 International Edition, lets one report cover WCAG, the revised Section 508 standards, and EN 301 549 together, which saves rebuilding the same evidence for each buyer.
A solid VPAT for SaaS products includes the product name, version, and report date, the evaluation methods and assistive technologies used, the surfaces covered, and a criterion-by-criterion rating with remarks. The surfaces matter: web application, administrator console, mobile apps, exported documents, notification emails, and the help center can all be in scope depending on what the customer uses.
Conformance Levels in Plain Language
Each WCAG criterion gets a rating, and the remarks column is where credibility is won or lost.
| Level | What it means | How a buyer reads it |
|---|---|---|
| Supports | The product meets the criterion without known issues | Fine, if the remarks explain how it was verified |
| Partially Supports | Some functionality does not meet the criterion | Acceptable when the gap is described and a workaround or fix date is given |
| Does Not Support | The product does not meet the criterion | A risk to be weighed, not an automatic disqualifier |
| Not Applicable | The criterion does not apply to the product | Fine when the reason is stated |
WCAG itself is organized around four principles: content must be perceivable, operable, understandable, and robust. A good VPAT for SaaS products makes it easy for a reviewer to see how the product performs against each.
How to Build a VPAT for SaaS Products in Five Steps
Building a VPAT for SaaS products is mostly a testing and documentation exercise, and a first version is achievable without a large program.
- Define the scope. List every surface a customer touches, such as the web app, admin console, mobile apps, documents, emails, and help content, and decide which are covered. A report that quietly covers only the marketing site will not survive a procurement review.
- Test with both tools and people. Automated scanners are useful for catching common problems, but they cannot judge everything, so add keyboard-only navigation, screen reader testing, zoom and contrast checks, and review of forms and error messages.
- Document each criterion honestly. Rate what you found, not what you hope to ship. A “Partially Supports” with a clear explanation builds more trust than a column of unexplained “Supports” ratings.
- Turn gaps into a dated roadmap. Link each issue to a release and an owner, so remarks like “fix planned in Q2” are commitments you can keep.
- Package, date, and distribute it. Publish the report where sales and customers can find it, state the date and version, and give sales one approved copy so no one circulates a stale file.
A word on shortcuts: accessibility overlay widgets are generally not considered sufficient on their own to achieve conformance, so they are not a substitute for fixing the underlying product. A VPAT for SaaS products built on an overlay invites exactly the questions you were hoping to avoid.
How Buyers Review a VPAT for SaaS Products
It helps to see the process from the other side. Reviewers are usually a mix of procurement, an IT or accessibility coordinator, and legal, and they tend to look for the same warning signs. A report with no remarks, an out-of-date report date, a standard version that does not match the customer’s requirement, a scope that covers only part of the product, or vague testing methods all prompt follow-up questions. Some buyers now use tools that grade vendor reports against WCAG criteria, which makes thin answers easier to spot. Our enterprise AI procurement scorecard shows how buying teams weigh vendor evidence in general, and the same instincts apply here.
Keeping a VPAT for SaaS Products Current
A stale VPAT for SaaS products undermines the trust it was built to create. Treat it as a living document tied to your release process rather than an annual chore.
- Review it whenever the product changes materially, such as a redesign, a new module, or a switch of front-end framework.
- Keep it within the freshness window buyers expect. Reports older than about twelve months draw questions, particularly from higher-education buyers.
- Track promised fixes. If a remark says a gap will be resolved by a certain release, either deliver it or update the remark.
- Version the report. Keep a short changelog so reviewers can see what changed between editions.
The cadence benefits from the same discipline as any compliance program, and our guide to continuous AI governance improvement covers how to build a review rhythm that survives staff turnover.
Common Mistakes in a VPAT for SaaS Products
Most failures come from treating a VPAT for SaaS products as a sales document rather than an accurate record of the product.
Overclaiming Conformance
- Rating everything “Supports.” Almost no complex product conforms everywhere, so a perfect report reads as untested.
- Relying on an automated scan alone. Scanners miss problems that only manual and assistive-technology testing reveal.
- Claiming a newer standard than you tested. If you tested to WCAG 2.1, say 2.1.
- Using an overlay as evidence. It does not substitute for conforming content.
Scoping and Process Mistakes
- Covering only part of the product. Customers expect the surfaces they use to be included.
- Ignoring exports and documents. PDFs, spreadsheets, and emails your product generates are part of the user experience.
- Having no owner. Without a named owner, the report goes stale after the first sale that required it.
- Letting sales edit ratings. Ratings should come from testing, with sales only distributing the approved version.
Deciding Whether Public Sector Belongs in Your ICP
Not every SaaS company needs to chase public-sector or education buyers, and an accessibility gap is a good reason to decide deliberately rather than by drift. A documented approach such as our ICP scoring rubric helps weigh whether these segments fit your product, your sales capacity, and your remediation capacity.
Companies building for regulated sectors feel this gate earlier than most. If your roadmap includes government, education, or healthcare, the dynamics described in our analysis of vertical SaaS startups apply: specialized buyers bring specialized requirements, and accessibility evidence is one of them. If you are already selling into those segments, a VPAT for SaaS products is a priority. If you are only exploring them, assess the size of your accessibility gap before committing sales resources, because discovering it mid-procurement is the most expensive way to find out.
Who Should Own the Report
The evidence behind a VPAT for SaaS products spans functions, and it stalls when it belongs to everyone and no one. Engineering or QA owns testing and remediation. Design owns patterns that prevent issues from recurring. Compliance or legal reviews the claims. Sales and revenue operations own distribution and make sure only the current approved version circulates.
The structure that works is a single named owner, often in product or compliance, who publishes the report on a fixed cadence and is accountable for the remediation roadmap. Without that owner, the document becomes a one-time project that slowly diverges from the product it describes.
Strategic Outlook: A VPAT for SaaS Products as a Sales Asset
From a growth standpoint, a VPAT for SaaS products is best treated as sales infrastructure. Every public-sector or education deal that stalls on an accessibility questionnaire is a deal where the ability to hand over a current, credible report in the first week would have changed the timeline. For vendors selling into these segments, that is a real lever on sales velocity, and it compounds as your customer base grows.
It is worth staying grounded about the limits. A report documents your product’s accessibility; it does not create it, and a polished document over a product that fails basic keyboard navigation will not survive a reviewer’s first test. Regulatory details can also shift, since the DOJ has indicated it may revisit parts of the rule, so build your approach around the underlying standard rather than a single date.
Next Steps for a VPAT for SaaS Products
- List every surface customers use and decide which belong in scope.
- Run a first audit with both automated tools and manual assistive-technology testing.
- Draft the report with honest ratings and remarks, and turn each gap into a dated roadmap item.
- Name one owner and set a review cadence tied to your release process.
- Ask your three largest public-sector or education prospects what format and standard they require, and compare it with what you have.
- Revisit your approach as the DOJ and other regulators publish updates.
Frequently Asked Questions
What is a VPAT for SaaS products? It is a standardized template used to document how well a software product meets accessibility standards such as WCAG 2.1 AA. The completed version is called an Accessibility Conformance Report, and it is what procurement teams actually evaluate.
What is the difference between a VPAT and an ACR? The VPAT is the blank template, and the ACR is the finished document you complete for your product. Buyers often ask for a VPAT when they mean a completed ACR, so deliver the finished report.
Does the ADA require a VPAT? No. The ADA does not specifically require a VPAT or ACR. The legal obligation concerns accessible digital content, and the report is the procurement document vendors use to evidence conformance.
Did the 2026 deadline extension remove the pressure on vendors? Not really. The DOJ moved the Title II dates to April 26, 2027 and April 26, 2028, but the WCAG 2.1 AA standard is unchanged, and government customers still need conforming vendors to reach it.
Does the European Accessibility Act apply to purely B2B SaaS? Analyses of the directive generally place a purely B2B product, sold through sales-led contracts and used behind a login, outside its direct scope. Consumer-reachable parts such as public sign-up or self-serve checkout can be in scope, and customers’ own obligations often flow into contracts.
Conclusion
A VPAT for SaaS products has become a practical requirement for selling into public-sector and education markets, and a useful asset in almost any enterprise procurement process. Teams that scope the report honestly, test with both tools and people, tie each gap to a dated fix, and keep the document current will answer accessibility questions in days instead of weeks. Teams that treat it as a one-time attachment risk discovering the gap in the middle of a deal.
None of this requires a large program to begin. Start by listing the surfaces your customers use, run a first audit, and draft an honest VPAT for SaaS products with a remediation roadmap. Then ask your largest public-sector prospects what they require and compare it with what you have. If you want a clear starting point, schedule that audit this quarter and build your first report around what it finds.
About the Author
Meet Waqas Raza — a B2B Digital Growth Specialist writing for Vitalora Life, with a background in Finance and 20 years scaling technical SaaS architectures. Waqas shares practical, data-backed frameworks on AI governance, SaaS growth, and turning AI investment into measurable outcomes.