An Accessibility Conformance Report, or ACR, can support that response, but the questionnaire may also ask about implementation, support, future releases, and remediation commitments. Treat those as separate questions with their own evidence and owners.
Start with the buyer’s request
Before drafting answers, collect the solicitation, product requirements, questionnaire, requested standards, submission deadline, and any required reporting format. Check whether the customer is evaluating your standard product, a particular configuration, an implementation service, or a combination.
For federal procurement, Section508.gov explains how ACRs support the evaluation of ICT products. The solicitation determines which requirements the response needs to address. A report about your marketing website may not describe the application the customer intends to purchase.
Ask the buyer to clarify an ambiguous requirement early. For example, “Please confirm whether your request covers the administrative console, the end-user application, exported documents, and the mobile application.” This helps the team define a response that matches the purchase.
Build a response from evidence
On narrow screens, scroll the table horizontally to read all columns.
| Buyer question | Information to provide | Supporting evidence |
|---|---|---|
| What was evaluated? | Product version, modules, workflows, roles, and exclusions | Scope statement and tested configuration |
| Which requirements were used? | The exact standards and levels included in the evaluation | Report scope and applicable criteria |
| How was testing performed? | Methods, environments, and dates actually used | Evaluation notes and report methodology |
| Is an ACR available? | The report date, product version, and requested edition | The completed ACR |
| What limitations remain? | Affected functionality and its effect on users | Findings and criterion-level remarks |
| What will be corrected? | Agreed owners, priorities, dependencies, and verified status | Remediation plan and retest records |
Use responses that match the product’s actual status
The following are illustrative response structures. Replace bracketed fields with verified information and remove any statement the evidence does not support.
An ACR is available: “Our ACR dated [date] covers [product and version] against [standards]. It describes the evaluation methods and known limitations. [Modules or configurations] are outside that report’s scope.”
Testing is underway: “The evaluation of [scope] is in progress. We can share [available evidence] now. [Report delivery date] is our confirmed target, subject to [identified dependencies]. We cannot yet provide completed conformance ratings for the remaining evaluation.”
A limitation is documented: “The evaluation identified [barrier] in [workflow], affecting users who [interaction or access need]. The current status is [verified status]. [Workaround] has been verified in [configuration], if applicable. The planned correction depends on [dependency].”
Do not describe a planned workaround as available or an engineering ticket as a verified correction. A clear limitation gives the customer more usable information than an unsupported assurance.
Keep current findings and future commitments separate
Assign someone from product or engineering to confirm technical statements. Have the person responsible for delivery review dates and commitments. Sales should know which promises are approved and which require a further scope discussion.
A remediation plan should distinguish a target date from a contractual commitment. Where dates depend on another vendor, a platform release, or customer configuration, explain that dependency rather than suggesting complete control.
Review the packet before submission
Check that the product name, version, report date, standards, and scope agree across the questionnaire, ACR, proposal, and supporting documents. Confirm that shared links work and that the reviewer can access the evidence. Record who owns follow-up questions.
Use the sample VPAT/ACR to understand the reporting format. Our guide to what procurement teams look for explains the buyer’s perspective.
Coordinate testing and procurement documentation
CompliCorp’s Procurement Readiness Program can bring evaluation, ACR preparation, questionnaire support, and remediation planning into an agreed scope. Share the customer’s request, product details, available evidence, and deadline so the engagement addresses the decision your buyer needs to make.