What accessibility evidence does a government software buyer need?

Prepare software accessibility evidence around the product and version you are offering, the solicitation's requirements and the testing behind your claims. A government buyer needs enough detail to understand what users can do, which barriers remain and how your team will address them.

The practical trigger is often a proposal review: business development has found a software requirement, and the product team has an accessibility report on file. The next step is to establish whether that report describes the offered release and covers the functions the buyer needs. A report can be useful without settling every part of the response.

In G2X, begin with the opportunity and follow the federal opportunity review guide to its original notice, attachments and amendments. Read the accessibility provisions and submission instructions together. Identify the requested report, supporting evidence, demonstrations and any requirements for software developed or configured during performance.

Identify the software the report describes

An Accessibility Conformance Report, or ACR, describes how an information and communication technology product meets applicable accessibility standards. GSA's ACR guidance recommends generating one for products marketed to the federal government and points vendors back to the requirements in the solicitation.

The Voluntary Product Accessibility Template, usually called a VPAT, is a template used to prepare that report. GSA's instructions for completing an ACR call for product information, a report date and evaluation methods, including the product version where applicable.

For your response, reconcile those details with the offer. Record the release, modules and configuration your team expects to provide. If the report covers an earlier release or a narrower set of functions, have the product owner establish what changed and what additional assessment is needed. Keep that difference visible to the proposal reviewer.

This matters when the buyer's work crosses several parts of the product. An accessible login screen does not answer whether a user can complete the required approval, retrieve a report or use the associated help material. Use the buyer's stated tasks to focus the evidence request.

Explain the assessment and the remaining barriers

A conformance level becomes more useful when the buyer can understand the assessment behind it. Have the product team identify the test scope, methods and relevant results, then check that the report's explanations agree with them. Do not convert an untested function into a supported claim to fill a response field.

GSA's guidance on requesting accessibility information, updated in August 2026, distinguishes standard products from customized technology. For standard products, it describes supporting information about evaluation methods, accessibility features, unusable core functions and configuration. It also identifies an Issue Detail Supplement that helps buyers understand the severity and user impact of accessibility issues. The solicitation determines what the offeror must submit.

That distinction gives a vendor a useful preparation task: connect each known barrier to the work it affects. Explain the condition, the affected function and the available remediation information. A general promise to improve the product later gives the evaluator much less to assess than a documented gap with a responsible owner.

Keep planned improvements separate from the evaluated release. If a demonstration or further testing is requested, agree internally on which version and configuration will be shown and who can answer questions about the findings.

Prepare the response your team can stand behind

The output should be a concise evidence brief for the proposal and product leads. It should identify the offered software, link each requested item to the available evidence, and name the unresolved assessments or gaps. That brief helps the team decide whether to proceed, seek clarification or change the proposed approach before submission.

You can complete this work manually using the public solicitation, authorized product reports and a local worksheet. G2X's Community Edition provides a free GovCon growth suite for finding the work and keeping CRM context. In CRM Accounts, keep a dated action such as “confirm ACR coverage for the offered release,” with an owner. Check current account access.

If your account includes Lumen access, upload the authorized solicitation and product documents to G2X Lumen to assess fit, identify evidence gaps and plan the response. Require citations and have the product or accessibility lead verify them. Lumen can organize the review; it cannot supply test results your team has not produced. No executed assessment is claimed here.