When a customer asks about accessibility, most SaaS companies scramble. The request typically comes from a procurement team, a compliance officer, or an enterprise client with a legal requirement. The right response is a combination of transparency, documentation, and a credible path toward WCAG conformance.
SaaS companies that prepare before the first question lands close deals faster and avoid reactive projects that cost more and deliver less.
| Customer Request | What the SaaS Company Needs |
|---|---|
| VPAT or ACR | A completed Accessibility Conformance Report based on a WCAG audit of the product |
| Conformance status | An honest assessment of current WCAG 2.1 AA conformance with known issues documented |
| Remediation timeline | A prioritized plan showing when and how identified issues will be addressed |
| Accessibility statement | A published statement describing the product’s accessibility posture and contact method |
| Ongoing commitment | Evidence that accessibility is part of the development lifecycle, not a one-time project |
Why Do Customers Ask About SaaS Accessibility?
Enterprise buyers and government agencies have their own compliance obligations. When they purchase a SaaS product, they inherit its accessibility profile. A web app that doesn’t conform to WCAG 2.1 AA creates legal exposure for the buyer.
Government procurement under Section 508 requires vendors to provide an ACR. Higher education institutions increasingly require them too. Private enterprises with ADA obligations or European Accessibility Act (EAA) exposure extend those same expectations to their software vendors.
The question is rarely academic. It typically gates a purchase decision.
The First Request Is Usually for a VPAT
Most SaaS companies hear the word “VPAT” before they hear “accessibility.” The VPAT is the template. The ACR is the completed document that reports how a product conforms to WCAG criteria.
A credible ACR requires an accessibility audit of the product first. The audit identifies issues across the interface, and the ACR maps those findings to WCAG success criteria with conformance levels and remarks for each.
SaaS companies that try to fill in a VPAT without an underlying audit produce documents that don’t hold up under scrutiny. Procurement teams review ACRs carefully, and vague or inflated conformance claims erode trust.
What a Credible Response Looks Like
A SaaS company that handles accessibility questions well has three things ready: an ACR, a remediation plan, and an accessibility statement.
The ACR provides the factual baseline. It shows what conforms, what partially conforms, and what doesn’t. Accessible.org audits follow WCAG 2.1 AA and produce ACRs that reflect actual product behavior, not aspirational conformance.
The remediation plan shows the path forward. Customers understand that full conformance takes time. What they need is evidence that the company has identified its issues, prioritized them by user impact, and committed development resources to fixing them.
The accessibility statement ties it together. Published on the product’s website, it describes the current conformance target, known limitations, and how users can report issues or request assistance.
What Happens When SaaS Companies Aren’t Prepared
The most common scenario: a sales team receives a VPAT request, loops in engineering, and discovers nobody has evaluated the product against WCAG. A reactive audit gets scheduled, but the sales cycle stalls while the company catches up.
Some companies attempt to use automated scans as a substitute. Scans only flag approximately 25% of issues. An ACR built from scan results alone will miss the majority of conformance problems, and any experienced reviewer will recognize the gaps.
Other companies produce a self-assessed ACR without professional evaluation. This carries risk. If the document overstates conformance and a customer relies on it for their own compliance, the SaaS company has created a trust and liability problem simultaneously.
Building Accessibility Into the Product Lifecycle
The companies that handle these requests smoothly treat accessibility as part of their development process rather than an event triggered by a customer question.
This means conducting a baseline audit, remediating identified issues, and then incorporating accessibility checks into QA and release cycles. Accessibility Tracker Platform provides a way to manage this ongoing work, mapping audit findings to development tasks and tracking conformance progress across product updates.
When a new VPAT request arrives, the ACR is already current or close to it. The response time drops from weeks to days.
How Often Should a SaaS Company Update Its ACR?
ACRs don’t have a formal expiration date. The practical trigger is product change. A major redesign, a new feature set, or a significant UI update can shift the conformance profile enough that the existing ACR no longer reflects reality.
Accessible.org recommends updating the ACR after any significant product change. For SaaS products with frequent release cycles, an annual re-evaluation is a reasonable baseline, with interim updates when major features ship.
Customers notice when an ACR references an outdated product version. Keeping the document current signals that accessibility is an active priority, not a checkbox from two years ago.
Which VPAT Edition Do SaaS Companies Need?
The VPAT comes in four editions: WCAG, Section 508, EN 301 549, and INT (International). Most SaaS companies serving primarily U.S. commercial customers need the WCAG edition. Companies selling to U.S. federal agencies need Section 508. Companies with European customers or EAA obligations need EN 301 549.
The INT edition combines all three and covers the broadest set of requirements. SaaS companies with a global customer base often default to INT to avoid maintaining multiple documents.
The Role of Prioritization in Remediation
After an audit identifies issues, the natural question is where to start. Not every issue carries equal weight. A missing form label on a checkout flow affects more users and carries more risk than a contrast ratio issue on a rarely visited settings page.
Risk Factor or User Impact prioritization formulas help development teams sequence their work. The platform at Accessibility Tracker sorts issues this way automatically, so teams don’t spend cycles debating priority when they could be fixing problems.
Customers reviewing a remediation plan want to see that high-impact issues are addressed first. A prioritized approach demonstrates maturity in how the company thinks about accessibility.
Preparing Before the Question Comes
The SaaS companies that lose deals over accessibility are almost always the ones caught off guard. The ones that win have documentation ready, a clear conformance narrative, and evidence of ongoing investment.
The cost of preparation is modest compared to the cost of a stalled enterprise deal or a lost government contract. A WCAG audit, an ACR, and a published accessibility statement form the minimum credible response to any procurement accessibility question.
Can a SaaS company use an automated scan instead of an audit for a VPAT?
No. Automated scans only flag approximately 25% of WCAG issues. An ACR built from scan data alone will contain significant gaps. Procurement teams and accessibility reviewers expect findings from a thorough evaluation that includes screen reader testing and manual review of interactive components.
What if a SaaS product isn’t fully conformant yet?
Most products aren’t. Customers expect honesty, not perfection. An ACR that accurately reports partial conformance alongside a remediation plan with timelines is far more credible than a document that claims full conformance without evidence. Transparency protects the relationship and the company.
How long does it take to get an ACR for a SaaS product?
The timeline depends on product complexity. A focused web app with a defined scope can typically move through audit and ACR completion in a few weeks. Larger products with multiple user roles, workflows, and integrations take longer. Starting the process before a customer asks removes the time pressure that leads to rushed, lower-quality results.
Do SaaS companies need a new ACR for every customer?
No. A single ACR covers the product. Different customers may request different VPAT editions depending on their regulatory context, but the underlying audit and conformance findings apply across all of them.
SaaS companies that treat accessibility as a product attribute rather than a customer-driven emergency end up in a stronger position on every front. The documentation is ready, the product improves steadily, and the sales team never has to stall a deal while engineering figures out where things stand.
Contact Accessible.org for a WCAG audit, ACR, or accessibility program for your SaaS product.
