The Procurement Wall

Accessibility is a hard procurement requirement for selling software to the U.S. federal government. Section 508 of the Rehabilitation Act mandates that federal agencies purchase only ICT products meeting WCAG 2.0 Level AA — and vendors must prove it with a completed VPAT before a contract can be awarded. For SaaS companies targeting government clients, accessibility is not a nice-to-have: it is a sales prerequisite.

The question back to the SaaS company: "Do you have a VPAT certifying Section 508 compliance?" If the answer is no, the deal is typically dead. Not "let's talk about it." Not "we can get compliant in a few months." Just no. The company is disqualified from bidding.

This isn't hypothetical. This is how government procurement works. Section 508 compliance is a gate, not a preference. And for many SaaS companies who've never thought about accessibility, discovering this at deal time is a shocking wake-up call. They've built a product without considering accessibility. They didn't think anyone was asking for it. But government buyers (and increasingly private enterprises) are asking for it.

The VPAT isn't a nice-to-have certification. It's a procurement requirement. Missing it can cost you millions in potential revenue.

What Government Buyers Actually Check

Government procurement teams have reviewed hundreds of VPATs. They know what a real one looks like and what a faked one looks like. Here's what they actually evaluate:

  • Date of the VPAT. If the VPAT is three years old and your product has been heavily updated since then, they'll be suspicious. Most procurement teams want a VPAT dated within the last 18 months. If you claim compliance but haven't tested recently, it's a red flag.
  • Product version matching. Does the VPAT cover the exact product version being proposed? If the RFP specifies version 4.2 and your VPAT is for version 3.8, you have a problem. Government buyers want assurance that the tested version is what they're actually getting.
  • Specificity of remarks. Vague remarks like "Supports with exceptions" without explanation are a sign of a lazy VPAT. Government buyers want detail. If you say a criterion is not supported, they want to know why and when you plan to fix it. Specificity builds trust.
  • Does Not Support entries. A VPAT with dozens of "Does Not Support" entries is worse than a VPAT that's honest about partial support with a remediation timeline. If your product genuinely can't support a criterion in the current version, say so. Just provide a plan to address it.

The pattern government buyers look for: honesty, specificity, and a clear roadmap. A well-written VPAT that acknowledges gaps but shows a path to compliance is far more credible than one that claims universal support but has vague documentation.

The VPAT as a Sales Tool

This is the key insight that many SaaS companies miss: a well-written VPAT isn't a compliance document. It's a sales tool. It demonstrates due diligence. It shows that you've thought about accessibility. It builds trust with procurement teams who've seen too many companies claiming compliance without evidence.

Here's the psychological dynamic: a government buyer is already nervous about buying software from a vendor. Will it work? Will it break our workflows? Will the vendor support it? When they see a thoughtful VPAT that clearly documents strengths and weaknesses, it signals that the vendor is responsible and honest. That matters.

Conversely, a VPAT that claims "Supports" for everything looks fake. No real product supports every single WCAG 2.1 criterion equally. A VPAT that admits "Partially supports" for something like 1.4.3 (Colour Contrast) but explains exactly how the product supports it and what exceptions exist is far more credible.

Some of the best VPATs I've seen don't claim perfect compliance. They're honest. They say: "We support Level AA across the core product. We identified these gaps in Q3. Here's our remediation timeline. Here's what we're doing in Q2 2026 to address them." That honesty is powerful. It tells government buyers the vendor is serious about accessibility and has a plan.

Building the Internal Case

Getting product teams to prioritize accessibility is often harder than compliance itself. Product leaders ask: "Why? How many users actually need this?" The answer lies in showing them the pipeline.

Start by auditing your deals in flight. How many involve government buyers? How many have asked about accessibility or a VPAT? The numbers might surprise you. If you have five deals worth $1M each that require a VPAT, the cost of not having one is $5M in lost opportunity. That's a compelling argument for product prioritization.

Translate that into a roadmap. Here's what we need to do to unlock government sales. Here are the highest-impact issues. Here's the cost to fix them. Here's the revenue upside. When you quantify the business impact, you get attention.

Sales teams should also communicate the competitive advantage. If your competitors don't have a VPAT and you do, that's a differentiator. Some government buyers actively screen for it. Having one before you're forced to make one is strategic positioning.

Getting Started Fast

The good news: you don't need to be perfectly compliant to have a functional VPAT. You need to be honest and have a plan.

Step 1: Baseline testing. Run an automated accessibility audit on your core product. Use tools like axe DevTools, Lighthouse, or WAVE to identify obvious issues. Document what you find. This is your baseline: what you support today.

Step 2: Manual testing. Test the core workflows with a screen reader (NVDA or VoiceOver). Test keyboard navigation. Check colour contrast. Document gaps. This gives you a real sense of what users with disabilities actually experience.

Step 3: Prioritize Level A first. WCAG has three conformance levels: A, AA, and AAA. Most government requirements ask for Level AA, but Level A is the absolute baseline. If you're behind, start there. Fix the most critical barriers first: keyboard navigation, screen reader support, colour contrast.

Step 4: Write an honest VPAT. Document what you support. Be specific about partial support. For issues you don't support, include a remediation plan with dates. A VPAT with a roadmap is infinitely better than no VPAT or a fake one.

Step 5: Iterate. Accessibility isn't a one-time project. It's an ongoing practice. Once you have a VPAT, you can defend it to government buyers. In six months, fix more issues and update the VPAT. Show progress. Build momentum.

A partial VPAT with a clear roadmap gives you credibility to bid on government work today while you improve the product over time. That's the pragmatic path most successful SaaS companies take.