If your SaaS company plans to sell software to a U.S. federal agency, accessibility can become part of the procurement process before a contract is awarded. Federal agencies are responsible for procuring, developing, maintaining, and using accessible information and communication technology (ICT) under Section 508 of the Rehabilitation Act. For vendors, that often means being ready to explain—and document—how a product supports the applicable accessibility requirements.
This is where Accessibility Conformance Reports (ACRs), Voluntary Product Accessibility Templates (VPAT®), accessibility testing, and remediation enter the sales process. The goal is not to produce a document that simply says a product is accessible. The goal is to provide accurate, supportable information that federal buyers can evaluate.
Why Section 508 Matters to SaaS Vendors
Section 508 requirements apply directly to federal agencies, but they have practical consequences for companies that want to sell ICT to those agencies. Section508.gov advises ICT vendors doing business with the federal government to demonstrate how their products or services support the applicable Section 508 Standards.
For a SaaS company, the relevant product surface may include much more than a marketing website. A procurement review can involve the application interface, authentication flows, dashboards, forms, tables, reports, administrative tools, electronic documentation, and other digital content delivered as part of the product.
Accessibility therefore becomes both a product issue and a procurement-readiness issue. Waiting until a solicitation requests accessibility documentation can leave a team trying to test, document, and remediate a complex application under a sales deadline.
Federal Solicitations Are Becoming More Structured Around Accessibility
On August 11, 2026, GSA announced an updated Solicitation Review Tool (SRT) with expanded AI capabilities. The tool can help federal users review draft and published solicitations, identify applicable Section 508 requirements, and determine whether required accessibility language is included.
That does not create a new accessibility standard for vendors. It does, however, reinforce an important procurement reality: accessibility requirements can be surfaced and evaluated systematically during the acquisition process.
For SaaS sales teams, this means accessibility should not be treated as an unexpected questionnaire that appears near the end of a deal. Product, engineering, compliance, and sales teams should know what evidence they can provide before an opportunity reaches the proposal stage.
What Is an ACR, and How Is It Related to a VPAT?
An Accessibility Conformance Report (ACR) describes how an ICT product or service conforms to applicable accessibility standards. Federal buyers use ACRs as one source of information when researching products and evaluating proposals.
A VPAT® is a template developed by the Information Technology Industry Council. Vendors commonly use a VPAT to create an ACR. The terms are often used interchangeably in procurement conversations, but they are not exactly the same thing: the VPAT is the template; the completed accessibility report is the ACR.
Section508.gov recommends that vendors marketing ICT to the federal government generate an ACR. Its current guidance also explains that vendors should test their products against applicable Section 508 Technical Standards and report whether the product supports, partially supports, does not support, or does not have an applicable requirement for the relevant criteria.
Which Accessibility Standards Can Apply to SaaS?
The Revised Section 508 Standards incorporate WCAG 2.0 Level A and Level AA success criteria and conformance requirements for applicable web content and software. Depending on the product, additional Revised Section 508 provisions may also apply, including requirements for software and support documentation.
This distinction matters. A SaaS vendor should not assume that running a website scanner against a few public pages is enough to support an ACR. The evaluation scope needs to reflect the actual product and the requirements that apply to it.
If your team needs background on WCAG terminology, see our guide to WCAG 2.1 AA and the difference between WCAG versions. Keep in mind that the Revised Section 508 Standards specifically incorporate WCAG 2.0 Level A and AA criteria, even though newer WCAG versions are also used in broader accessibility programs.
Why Automated Testing Alone Is Not Enough for Procurement Documentation
Automated tools are useful for detecting certain accessibility issues at scale, but they cannot evaluate every success criterion or reliably determine whether complex user interactions are accessible.
For example, an automated scanner may identify missing labels, some contrast problems, or certain markup errors. It may not tell you whether a keyboard user can complete a multi-step workflow, whether focus moves logically through a modal interface, or whether a screen reader receives useful feedback after a dynamic update.
An ACR should be based on evidence that matches the product being documented. A stronger evaluation process typically combines automated checks with manual accessibility testing of representative workflows and components. Our comparison of automated and manual accessibility testing explains why the two methods serve different purposes.
A Practical Section 508 Readiness Process for SaaS Teams
1. Define the product and version being evaluated
Start with a clear scope. Identify the SaaS application, version or release, major modules, user roles, documentation, and any companion experiences included in the procurement.
2. Identify applicable requirements
Determine which Revised Section 508 provisions apply to the product. Federal solicitations may also specify accessibility requirements that vendors need to address in their proposal or contract deliverables.
3. Test representative workflows
Evaluate the parts of the application that matter to real users: sign-in, navigation, forms, data entry, tables, dialogs, search, account settings, reports, and other core workflows. Include keyboard accessibility and appropriate assistive-technology testing rather than relying exclusively on automation.
4. Document findings accurately
Accessibility findings should be tied to the applicable criteria and supported by evidence. Avoid treating the ACR as a marketing document. Overstating support can create problems when a federal buyer validates the claims during evaluation.
5. Remediate confirmed barriers
Prioritize issues that affect core workflows and user access. Developers should receive reproducible findings, relevant success criteria, and enough technical context to implement fixes efficiently.
6. Retest before finalizing the ACR
After remediation, verify the affected workflows again. The ACR should describe the product that buyers will actually evaluate, not an earlier build that has since changed.
7. Keep the ACR current
Section508.gov notes that product changes or updates may require an updated ACR. For SaaS products with frequent releases, accessibility documentation should be part of an ongoing product process rather than a one-time procurement exercise.
What Federal Buyers May Ask Vendors to Provide
Federal procurement guidance gives agencies several ways to request accessibility information. Depending on the acquisition, a vendor may be asked for a complete ACR, information about evaluation methods, demonstrations of accessible functionality, or evidence related to how a product will be configured and maintained.
The exact request depends on the solicitation. Vendors should read the accessibility language carefully rather than assuming every federal opportunity asks for the same documentation.
Can a Product With Accessibility Gaps Still Be Considered?
An ACR does not need to pretend that every criterion is fully supported. Section508.gov guidance specifically provides conformance terms such as Supports, Partially Supports, Does Not Support, and Not Applicable.
The federal guidance also explains that a product that does not meet every applicable Section 508 Technical Standard may still be considered for purchase. Federal agencies—not vendors—make procurement and exception determinations. For vendors, the more useful approach is accurate testing, transparent documentation, and a concrete remediation process.
How ADA Access Group Can Support Section 508 Readiness
ADA Access Group provides technical website and application accessibility services. For SaaS teams preparing for federal procurement, that can include accessibility evaluation, manual testing, documentation of confirmed findings, remediation guidance, and retesting.
We do not treat an automated scan as proof of complete Section 508 or WCAG conformance. The appropriate scope depends on the product, the applicable standards, and the requirements in the procurement.
If a federal prospect has requested accessibility information—or your team wants to prepare before the next solicitation—request an accessibility audit to identify barriers, establish a testing baseline, and determine what work is needed before accessibility claims are documented.
Frequently Asked Questions
Does every SaaS company need a VPAT?
No. Section 508 applies to federal agencies and their ICT activities, not universally to every SaaS company. However, companies selling ICT to federal agencies are commonly asked to provide accessibility information, and an ACR created using a VPAT is a common way to provide it.
Is a VPAT the same as an ACR?
No. VPAT is the template. The completed document describing a product's accessibility conformance is the Accessibility Conformance Report.
Can we complete an ACR from automated scan results?
Automation can contribute useful evidence, but it cannot evaluate every accessibility requirement or interaction. A defensible product evaluation generally requires manual testing in addition to automated checks.
Should an ACR be updated after product changes?
Potentially, yes. Section508.gov states that product changes, version updates, and bug fixes may require an updated ACR so that the report accurately reflects the current product.
This article provides general technical accessibility information and is not legal advice. Federal procurement requirements vary by acquisition, and vendors should review the specific solicitation and applicable agency requirements.