Read a VPAT/ACR from SaaS Providers

SaaS and software products sit at the center of how most businesses operate today. From CRM systems and accounting tools to HR platforms, live chat widgets, and internal dashboards, these products quietly shape how work gets done.

For smaller organizations, SaaS is often the default choice. Lower upfront costs, faster setup, easier scaling, and fewer infrastructure headaches make it appealing. You don’t need servers. You don’t need to install it on every machine. Updates happen automatically. Integrations are usually built in.

But accessibility is rarely part of the buying conversation.

When teams evaluate SaaS or software products, the focus is usually on features, pricing, and how well the tool fits existing workflows. Accessibility often comes up later, if at all, usually when something breaks or a requirement suddenly appears.

Accessibility expectations are getting harder to ignore

Accessibility requirements aren’t standing still. In both public-sector and regulated private environments, expectations around digital accessibility have become more concrete and more closely reviewed.

If you adopt software that isn’t accessible, the impact doesn’t stop at the vendor. The organization using the product carries responsibility for how that software affects users, employees, and customers. That includes accessibility failures introduced through third-party tools.

This catches many teams off guard. There’s a common assumption that if a SaaS product is widely used, accessibility must already be “handled.” In reality, many vendors still treat accessibility as an afterthought or limit their efforts to surface-level fixes.

Why third-party tools are still your responsibility

When you integrate a third-party SaaS product or software into your environment, you inherit its accessibility behavior. If a live chat tool can’t be used with a keyboard, or a scheduling widget isn’t announced properly by screen readers, those issues become part of your digital experience.

From a compliance and risk perspective, “the vendor built it” isn’t a defense.

That’s why understanding accessibility documentation matters. Not just whether a vendor claims to be accessible, but how they describe limitations, scope, and testing results.

This is where VPAT ACRs come in

Many SaaS and software vendors provide an Accessibility Conformance Report (ACR) created using the VPAT® template. These documents are meant to explain how a product supports accessibility requirements and where it falls short.

The problem is that not all ACRs are created equal.

Some are detailed and honest. Others are vague, outdated, or copied from earlier versions of the product. If you don’t know how to read one, it’s easy to miss red flags or misunderstand what’s actually being disclosed.

This article focuses on how to read VPAT-based ACRs created by SaaS and software providers, so you can:

understand what the report actually covers
spot gaps, assumptions, and vague language
ask better follow-up questions before committing to a product

Accessibility decisions don’t require deep technical expertise. They do require knowing what to look for and what not to take at face value.‍

The VPAT approach to procuring accessible SaaS and software

Most sales teams selling SaaS or software are not accessibility experts. That’s normal. It also means accessibility rarely comes up unless you know to ask.

This is where the VPAT® (Voluntary Product Accessibility Template) becomes useful. A VPAT is a standardized template vendors use to disclose how their product supports accessibility requirements such as WCAG, the Revised Section 508 Standards, and, in some cases, EN 301 549.

When the template is properly completed, the result is an Accessibility Conformance Report (ACR). These reports are used by government buyers and procurement teams to understand accessibility risk before selecting a product.

You don’t need to be a public agency to benefit from this approach. Using VPAT-based ACRs when evaluating SaaS or software helps you:

understand whether a product aligns with accessibility expectations
identify known limitations before they affect users
avoid inheriting accessibility issues through third-party tools
ask vendors clearer, more informed follow-up questions

A VPAT won’t tell you whether a product is perfect. What it can do is make accessibility visible instead of hidden behind marketing claims. That alone puts you in a much better position when choosing software that will be part of your business long-term.

Reading a VPAT ACR created by a SaaS and software provider

If you’re serious about accessibility, you can’t rely on sales pages or feature lists. You have to look at the vendor’s VPAT-based Accessibility Conformance Report and actually read it.

A VPAT ACR isn’t marketing material. It’s where vendors explain, in plain terms, how their product behaves when real accessibility requirements are applied. That’s why it matters more than any checkbox claim.

The first thing to understand is that VPATs are technical by nature. They reference U.S. and international standards and use language that isn’t always friendly. That doesn’t mean the report should be confusing. It just means you’re looking for clarity, not perfection.

You should also check which VPAT version the report is based on. Older reports often leave out details that procurement teams now expect. An outdated VPAT doesn’t automatically mean the product is unusable, but it does mean you should slow down and ask follow-up questions.

Don’t expect a one-line answer that says “yes, this product is accessible.” That’s not how VPATs work. An ACR is a disclosure, not a verdict.

When you open the report, start with the basics. The product name, version, report date, and testing method should be clearly stated. If you can’t tell what was tested or when, the rest of the document won’t help much.

Next, look at which standards are covered. Most SaaS and software VPATs reference WCAG along with the Revised Section 508 Standards. Some also include EN 301 549. That’s fine. What matters is that the scope matches how the product is actually used.

The core of the ACR is the conformance tables. These are organized around WCAG principles and list each success criterion with a status like “Supports,” “Partially Supports,” or “Does Not Support.”

Ignore the status labels at first and read the remarks column. That’s where the truth lives. A useful report explains what works, what doesn’t, and under what conditions. A weak one hides behind vague language or repeats the same sentence for every row.

If the explanations feel generic or avoid specifics, treat that as a warning sign. A solid VPAT doesn’t pretend everything is perfect. It tells you where the edges are so you can decide whether the product fits your environment.

That’s the mindset to bring when reading any VPAT ACR. You’re not looking for flawless compliance. You’re looking for honesty, scope, and enough detail to make a smart decision before the software becomes your problem.

Need help with reading a VPAT ACR from a SaaS or software provider?

Don’t let the non-conformance of SaaS or software products or services provided to your SME by a third party harm your business’ accessibility reputation.

We can assist you in reviewing the VPAT ACRs for the SaaS and software that you wish to purchase for your SME. We have the accessibility domain experience to assist you in reading any VPAT ACR provided by a SaaS or software provider, as well as the ability to create a correct and ready-to-submit VPAT report for SaaS and software providers.

If you need a VPAT ACR reading, shoot us a convenient time at (626) 486-2201 or by filling out a simple contact form, and we’ll get a consult on the books. Our consultations are always free!