vpat explained for saas companies
Software companies run into the same request again and again during enterprise sales: “Send us your VPAT.”
For many founders and product teams, the document shows up late in the sales cycle, usually from procurement or a government compliance office. It can stall deals for weeks if no one inside the company knows what it is or how to produce one.
A VPAT isn’t complicated, but it is very specific. It’s a standardized way to explain how accessible a digital product is under federal accessibility standards. Large companies, universities, and government agencies use it to screen vendors before signing contracts.
For SaaS companies selling software platforms, the VPAT has become a routine part of procurement. Some organizations won’t even start security reviews or pricing discussions until they receive one.
This article breaks down what a VPAT is, why SaaS companies get asked for it, how it relates to accessibility standards like WCAG, and what actually goes into writing one.
what a vpat actually is
VPAT stands for Voluntary Product Accessibility Template.
The document was created by the Information Technology Industry Council in the late 1990s as a standardized format vendors could use to describe accessibility compliance for technology products.
The template itself isn’t the final report. It’s the structure used to produce something called an Accessibility Conformance Report, usually shortened to ACR.
Most companies still say “send the VPAT,” even though what they really mean is the completed report.
A typical VPAT document includes:
• product name and version
• date of evaluation
• applicable accessibility standard
• evaluation methodology
• detailed accessibility findings
• known limitations
The core of the document is a long table. Each row corresponds to a requirement from an accessibility standard, most often WCAG 2.1.
For each requirement, the vendor must state one of several conformance levels:
• supports
• partially supports
• does not support
• not applicable
A short explanation follows each entry.
Here’s a simplified example:
Requirement: WCAG 2.1 – 1.1.1 Non-text Content
Conformance: Partially Supports
Remarks: Decorative images lack alt text in older product modules released before March 2022.
That format lets procurement teams quickly scan accessibility coverage.
why saas companies keep getting asked for a vpat
The request almost always comes from organizations that must comply with accessibility laws.
Three common buyers require VPAT documentation:
Federal agencies
State or local government departments
Universities and public colleges
These organizations must comply with accessibility requirements tied to federal law.
One of the most cited standards in procurement policies is Section 508 of the Rehabilitation Act.
The law requires federal agencies to buy accessible technology. If an agency buys inaccessible software when accessible alternatives exist, the purchase can be challenged.
Because of that rule, procurement teams ask vendors to submit VPAT documentation before approving contracts.
Private companies sometimes follow the same process.
Large corporations — especially banks, healthcare networks, and insurance companies — often copy government procurement procedures for accessibility.
That’s why SaaS companies selling HR software, CRM tools, marketing platforms, or project management tools regularly see VPAT requests even when they aren’t selling directly to government agencies.
how vpat relates to wcag and section 508
A VPAT doesn’t create new accessibility rules.
It simply maps product accessibility to existing standards.
The most common standards referenced inside VPAT reports are:
WCAG 2.1
Revised Section 508 standards
EN 301 549 (European procurement rules)
WCAG is the most familiar to developers.
WCAG 2.1 contains 78 testable success criteria covering topics such as:
keyboard navigation
color contrast
text alternatives for images
form labels
screen reader compatibility
error messaging
When a VPAT is prepared for web software, each of those criteria appears as rows inside the accessibility table.
Section 508 references many of the same WCAG criteria.
The current federal standards were updated in 2017 to align with WCAG 2.0 Level AA. Many organizations now request WCAG 2.1 coverage because it includes additional requirements for mobile accessibility and low-vision users.
For SaaS products accessed through a browser, WCAG criteria usually represent the majority of the VPAT document.
the four vpat versions vendors encounter
The template has evolved over time. Vendors now choose between four versions depending on the market they serve.
VPAT 2.4 Rev 508
Used for U.S. federal procurement. Maps accessibility to Section 508 standards.
VPAT 2.4 WCAG
Focused entirely on WCAG 2.x criteria.
VPAT 2.4 EU
Used for products sold to European governments following EN 301 549.
VPAT 2.4 INT
A combined international version that maps requirements across all three standards.
Most SaaS companies preparing their first VPAT choose the WCAG version or the international version.
The international template produces longer reports but reduces the need to create separate documents for different regions.
what a vpat report actually looks like
A finished Accessibility Conformance Report often runs 30 to 70 pages depending on product complexity.
Large SaaS platforms with multiple modules sometimes exceed 100 pages.
The document usually includes the following sections.
Evaluation methods used
Vendors explain how accessibility testing was performed. The most credible reports describe both automated testing and manual evaluation with assistive technology.
Typical methods include:
screen reader testing
keyboard navigation testing
contrast evaluation
automated scanning tools
Products tested
Many SaaS tools operate across multiple browsers and devices. The VPAT lists the environments used during evaluation.
Example:
Chrome version 120
Firefox version 121
Safari version 17
Windows 11
macOS Sonoma
Assistive technologies tested
Accessibility evaluation often includes real screen reader software.
Common examples:
NVDA
JAWS
VoiceOver
The report explains which tools were used and what functionality was verified.
Accessibility conformance tables
This is the largest section. Each requirement from WCAG or Section 508 appears as a table row with the vendor’s conformance claim.
Remarks and explanations
Vendors must describe known accessibility limitations and provide context.
This section often includes the most useful information for buyers.
what “supports” actually means in a vpat
The conformance labels inside VPAT reports are sometimes misunderstood.
“Supports” doesn’t mean a product is perfectly accessible. It means the vendor believes the feature meets the accessibility requirement under normal use.
“Partially supports” is common.
SaaS applications are complex. A login page may fully meet accessibility standards while an older reporting module still has issues with screen reader navigation.
VPAT guidance encourages vendors to document those gaps honestly.
The goal isn’t perfection. It’s transparency.
A typical entry might read:
WCAG 2.1 – 2.4.3 Focus Order
Conformance: Partially Supports
Remarks: Focus order works correctly across the main navigation and account management pages. Some modal dialogs in the analytics dashboard skip focus back to the page body.
Procurement teams often accept partial support as long as the vendor documents the issue and shows progress toward fixing it.
why many early vpat reports are inaccurate
Many first-time VPATs are created quickly by marketing teams trying to close a deal.
That approach produces unreliable reports.
Accessibility testing requires real interaction with assistive technology and keyboard navigation. Automated scanners alone can’t verify many WCAG requirements.
Common mistakes in rushed VPAT reports include:
marking every requirement as “supports”
relying entirely on automated scanning tools
testing only the home page of a product
ignoring mobile interfaces
copying results from unrelated products
Some procurement teams now reject VPAT documents that lack detailed remarks or testing methodology.
A blank explanation field next to dozens of “supports” entries is a red flag.
the cost of producing a real vpat
The price varies widely depending on product size.
A small SaaS product with fewer than 20 screens may cost $3,000 to $8,000 for a professional accessibility audit and VPAT report.
Larger enterprise platforms often cost $15,000 to $40,000 because testing must cover multiple modules and workflows.
Internal preparation time adds more cost.
Engineering teams often spend weeks fixing accessibility issues discovered during the audit before the final VPAT is published.
Some companies skip that step and publish a VPAT describing current limitations. Others wait until remediation work is complete.
Both approaches appear in procurement processes.
a real procurement example
In 2023 a mid-size SaaS analytics company attempted to sell its platform to a state university system.
The platform had about 70 user interface screens and had never undergone accessibility testing.
Procurement requested three documents:
security questionnaire
data processing agreement
VPAT accessibility report
Security documentation was available. The VPAT was not.
The sales team tried to assemble one internally using automated scanning tools.
During review, the university’s accessibility office rejected the document. The remarks sections were blank and testing methods were unclear.
The deal paused for six weeks while the vendor hired an accessibility consultant.
The final report identified several issues:
missing form labels
low contrast text in chart legends
keyboard traps inside modal dialogs
Those issues didn’t kill the deal. The university accepted the VPAT once the problems were documented and remediation timelines were provided.
The delay cost the vendor a full quarter of sales pipeline time.
limitations of vpat documents
VPAT reports have value, but they also have clear limitations.
The document relies heavily on vendor self-reporting.
Procurement teams rarely repeat the entire accessibility evaluation themselves. They depend on the accuracy of the vendor’s report.
Because of that structure, VPAT quality varies widely.
Some reports are detailed and credible. Others read like marketing documents.
Another limitation: the report only reflects the product version tested.
SaaS products change constantly. A VPAT created in January may be outdated by June if new interface components introduce accessibility issues.
Some companies now update VPAT reports annually or after major releases.
Even that cadence can miss smaller changes introduced during frequent deployment cycles.
common accessibility issues found in saas products
Accessibility audits for SaaS tools tend to surface similar problems across products.
Keyboard navigation failures are common.
Interactive elements sometimes require mouse input. Dropdown menus, date pickers, or drag-and-drop interfaces often break when accessed via keyboard alone.
Color contrast failures also appear frequently.
Design teams often choose subtle color palettes that look clean but fail WCAG contrast ratios.
Screen reader labeling errors appear in complex forms and dashboards.
Developers may build custom components that look like standard form elements but lack the semantic HTML attributes screen readers rely on.
Dynamic content is another frequent issue.
Single-page applications built with modern frameworks sometimes update interface content without notifying assistive technology. Screen readers may not detect those updates.
These problems show up repeatedly in VPAT reports across CRM systems, analytics dashboards, project management platforms, and HR software.
when saas companies should create their first vpat
Some companies wait until the first procurement request arrives.
That approach slows deals.
A more common strategy is to produce a VPAT before selling to large organizations.
Typical timing happens when a SaaS company begins targeting:
universities
government agencies
healthcare networks
large corporate procurement departments
Sales teams working in those markets expect accessibility documentation during vendor onboarding.
Without it, deals stall early.
Another factor is legal risk.
Accessibility lawsuits against websites and digital services increased in recent years. Many complaints reference WCAG accessibility standards.
While a VPAT doesn’t prevent lawsuits, it demonstrates that a company has evaluated accessibility and documented known issues.
Some legal teams prefer having that record available.
who usually writes the vpat
Several roles may contribute to the final document.
Accessibility consultants
Specialized firms often perform audits and prepare the report.
Internal engineering teams
Developers sometimes document accessibility findings after internal testing.
Compliance or legal teams
These groups review wording to avoid inaccurate claims.
Product managers
They often provide context about product features and planned fixes.
Marketing teams sometimes attempt to create VPAT reports alone. That rarely works well because accessibility testing requires technical evaluation of user interfaces.
Most credible reports combine engineering knowledge with accessibility expertise.
how vpat reviews affect saas sales cycles
Accessibility documentation often appears near the end of enterprise sales processes.
Procurement teams review VPAT reports alongside security questionnaires and privacy documentation.
If the report reveals serious accessibility barriers, buyers may ask vendors for remediation timelines before approving the purchase.
Minor issues usually don’t stop contracts.
Universities and government agencies understand that most software contains some accessibility limitations.
What they want is visibility.
A detailed VPAT helps procurement teams decide whether accessibility risks are acceptable for a specific product.
Deals slow down when documentation is missing or vague.
criticism of the vpat system
Accessibility professionals have raised several criticisms of the VPAT model.
The largest concern is inconsistent quality.
Two vendors may submit VPAT reports claiming “supports” across most criteria while the actual products behave very differently for screen reader users.
Another criticism involves readability.
Some VPAT reports run dozens of pages with technical explanations that procurement staff struggle to interpret.
Accessibility offices within universities often review the reports instead of procurement teams because the technical details require specialized knowledge.
There is also debate about whether static reports match the pace of SaaS development.
Modern software releases updates weekly or daily. A PDF report created months earlier may not reflect current accessibility conditions.
Despite these criticisms, the template remains the dominant procurement format for accessibility reporting.
No widely adopted replacement has emerged.
how companies maintain vpat reports over time
Organizations that sell widely to enterprise buyers usually treat VPAT updates as a recurring compliance task.
Common maintenance practices include:
annual accessibility audits
updating VPAT documents after major product redesigns
documenting accessibility improvements between versions
publishing updated reports on company trust or compliance pages
Some SaaS vendors also publish accessibility roadmaps describing upcoming fixes or improvements.
Those roadmaps sometimes appear as links inside the VPAT remarks section.
The goal is simple: reduce procurement friction during future sales.
what procurement teams actually look for
Accessibility reviewers rarely read VPAT reports line by line from start to finish.
Instead they scan for several signals.
Clear testing methodology
If the document describes assistive technology testing and manual evaluation, reviewers view the report as more credible.
Honest remarks
Entries that acknowledge accessibility limitations are usually viewed as more trustworthy than documents claiming full support everywhere.
Recent evaluation dates
Reports older than two years sometimes trigger requests for updated documentation.
Coverage of major product workflows
Testing should include login, navigation, data entry, and reporting features — not just static pages.
The VPAT functions more like a technical disclosure document than a marketing asset.
Buyers want information they can evaluate.
a quick comparison with accessibility statements
Many SaaS companies already publish accessibility statements on their websites.
Those statements are short summaries describing accessibility goals and standards.
A VPAT is very different.
Accessibility statement:
public web page
general overview
short narrative description
VPAT report:
detailed technical document
dozens of pages
line-by-line accessibility evaluation
Procurement teams almost always require the VPAT when accessibility documentation is requested.
Statements alone rarely satisfy procurement requirements.
why vpats are becoming routine for saas vendors
Ten years ago, most SaaS startups never encountered accessibility procurement requirements.
That changed as digital accessibility laws expanded and public institutions moved more operations into cloud software.
Universities now rely on SaaS platforms for admissions systems, student portals, learning tools, and internal analytics.
Government agencies use SaaS products for licensing systems, service portals, and internal collaboration.
Those organizations must document accessibility compliance for technology purchases.
As a result, vendors entering those markets now expect VPAT requests as part of normal vendor onboarding.
For SaaS companies selling into enterprise or public-sector environments, accessibility documentation has become another standard compliance artifact alongside security and privacy documentation.
The template may look bureaucratic, but procurement teams rely on it because it creates a consistent format for comparing vendors.
Without it, accessibility claims would be impossible to evaluate across dozens of competing software products.
Comments (0)
No comments yet.