Losing Deals Over an Accessibility Questionnaire

ClearPath Team · 2026-08-08 · 8 min read

Losing Deals Over an Accessibility Questionnaire

Your sales rep gets the term sheet almost signed, then procurement sends over a PDF nobody on your team has seen before. It asks you to rate your product against dozens of accessibility criteria, section by section, with columns for "Supports," "Partially Supports," and "Does Not Support." Someone on the team googles it at 4pm on a Thursday and finds out the deal is now stuck behind a document called a VPAT.

This happens constantly to SaaS companies, agencies and suppliers selling into government, higher ed, hospital systems and large enterprises. It's not a scam and it's not optional paperwork you can talk your way around. It's become a standard part of procurement, and it's worth understanding exactly what it is before it costs you a contract.

What a VPAT and an ACR actually are

The completed document is often called a "VPAT" but the wider procurement community prefers to call it a product Accessibility Conformance Report, or ACR, with the distinction being that the VPAT is the blank form and the ACR is the completed report using that template. The VPAT itself is a free template that translates accessibility requirements from Section 508 and other legal frameworks into actionable testing criteria for products and services.

The current version is VPAT 2.5, and it comes in four editions, 508, WCAG, EU, and INT, each matched to the standards a given market requires. A federal agency will usually want the 508 edition. A university or private enterprise buyer often accepts the WCAG edition. A European public-sector buyer will ask for the EU edition, which maps to EN 301 549. If you sell across all three markets, the INT edition covers everything at once.

Here's the part vendors often miss: a completed VPAT isn't a certification of compliance. It shows the degree to which a product meets specific accessibility standards. There's no pass or fail. A buyer can still choose to move forward with a product that has gaps, as long as they know what those gaps are and have a plan around them.

Who can fill one out, and what it costs

VPATs are self-reported documents, and vendors are not legally required to use a third party to complete them. Your own product or engineering lead can technically write one. The problem is that federal and enterprise procurement teams are increasingly experienced in evaluating VPAT quality, and a report that reads like it was written by someone unfamiliar with WCAG testing methodology is easy to spot.

That's why most companies selling into this space pay an independent accessibility firm to test the product and write the report. Pricing varies by product complexity, but as a rough anchor, one accessibility firm charges around $350 for a WCAG-edition VPAT on top of the underlying audit, with the 508 and EU editions running higher because of the extra time to complete them. Full manual audits, the kind that involve actual screen reader and keyboard testing rather than an automated scan, are commonly billed per page or per screen for anything complex. For a mid-sized SaaS product, budget more like a few thousand dollars total for a credible first VPAT, not a few hundred.

An independently completed VPAT signals to buyers that the vendor has invested in a structured accessibility evaluation and that the resulting report is less likely to contain unsupported claims. That credibility matters more than people expect, which brings us to the actual risk.

Why guessing on the form backfires later

It's tempting to have a product manager sit down, skim WCAG, and mark most rows "Supports" because the team is fairly sure things are fine. Resist that urge. A study found a VPAT inaccuracy rate of 19.6 percent, and that number only covered items that were automatically detectable, meaning the real rate is likely higher once you account for issues that require manual checking.

An optimistic VPAT creates two separate problems. First, a self-reported VPAT that overestimates conformance is often identifiable during review and can affect credibility in the evaluation process, so you can lose the deal on the spot when a sharp-eyed reviewer catches the gap between your claims and reality. Second, if the report gets through and the product turns out not to match it, you've now made a written representation to a customer, sometimes a government customer, that wasn't accurate. False or inaccurate VPAT claims can create legal liability and damage business relationships. That's a much worse conversation to have after the contract is signed than before. There's also a quieter cost. ACRs don't expire, but they become less relevant over time, so you'll want to update yours when you release major features, annually for active products, or when buyers request current documentation. A rushed, inaccurate first draft becomes the baseline everyone measures the next version against. Worth noting here: a widget like ClearPath can give visitors on-page adjustment tools while you work through remediation, but it has no bearing on what you should honestly write in the ACR itself, since the underlying code still needs to be tested and fixed.

What buyers actually check

Procurement and accessibility staff at universities and agencies don't just file the VPAT away. Because VPATs are self-reported claims, many institutions verify them, checking the product with just a keyboard, running it through tools like WAVE or Siteimprove, testing with a screen reader, and sometimes involving actual users with disabilities. If your ACR says a feature fully supports keyboard access and their reviewer can't tab through your checkout flow, that mismatch gets noticed fast.

Reviewers also read the document itself for quality signals. A critical reading of the cover page, including the evaluation methods used and the date of testing, can imply how seriously the report was actually put together. A VPAT with vague remarks, no testing methodology listed, and every row marked "Supports" with no detail reads as unreliable even before anyone tests the product. For EU-facing sales, the same logic applies to EN 301 549. A conformance declaration should include the scope of what's covered, the standards referenced, the actual conformance status including any known limitations with remediation plans, and contact information for reporting issues. Buyers there are looking for the same honesty signal: does this vendor know exactly where their gaps are.

How to answer honestly and still win the deal

Here's the good news: an imperfect ACR rarely kills a deal by itself. What kills deals is a report that's clearly wrong, or a vendor who has no plan when a gap is found. A few things that actually work:

  • Test before you write anything down. Real keyboard testing, a screen reader pass on your core workflows, and a contrast check will surface most of what needs an honest "Partially Supports."
  • Use "Partially Supports" and explain it. Buyers expect gaps. A vendor who writes "our data table has proper headers but the sort controls aren't yet keyboard operable, fix scheduled for Q1" reads as far more trustworthy than a blanket "Supports."
  • Pair the report with a remediation roadmap. Government and university buyers frequently accept a product with known gaps if there's a documented plan and a timeline, especially when an accessible workaround exists in the meantime. If part of that roadmap includes an interim measure like ClearPath's on-page tools while deeper code fixes are underway, it's fine to mention, as long as it's framed as a stopgap and not as the fix itself.
  • Get a second set of eyes. You don't need the most expensive firm in the market, but a third party who didn't build the product catches overclaims your own team won't see.
  • Keep it current. Re-run the ACR after major releases so procurement teams aren't comparing a two-year-old document to today's product.

None of this requires a perfect product. It requires an accurate one on paper.

Where ClearPath fits

Let's be direct about this one, because it matters: ClearPath does not produce a VPAT or an ACR, and installing it will not make a procurement questionnaire go away. No widget can generate that report for you. Writing an accurate ACR requires someone to actually test your keyboard navigation, your form labels, your heading structure, your color contrast and your underlying code, then document the real results. That's a testing and documentation job, not something a script running in the visitor's browser can do or claim.

What ClearPath does contribute is the visitor-facing layer that sits on top of your product: one line of code adds 25 adjustment tools across 8 disability-focused profiles, in 14 languages, so visitors can adjust contrast, spacing, text size, and navigation aids on the spot. It also auto-generates an accessibility statement for your site, which is useful supporting context for a buyer, but it is not a substitute for the ACR itself. If your questionnaire flags gaps in keyboard traps, missing form labels, image alt text, heading order, or PDF accessibility, those need actual code and content fixes from your team or a developer. ClearPath can sit alongside that remediation work and support your visitors in the meantime, but it won't fill out the boxes on page four of the VPAT for you, and no honest vendor should tell you otherwise.

Not sure how many of these issues are on your own site? Run a free scan, see what comes up, then switch on the tools that help your visitors today.

Scan my site free

The bigger point is that procurement teams asking for a VPAT aren't trying to trip you up. Done right, the ACR gives the reader an idea of how accessible your product is to people with disabilities, and most buyers just want to know what they're getting into before they sign. A small company that answers honestly, shows real testing, and has a credible plan for the gaps will usually beat a competitor who guessed optimistically and got caught. The questionnaire isn't the obstacle. Guessing on it is.