Start with the actual procurement request
Collect the solicitation, accessibility clauses, questionnaire, and requested reporting format. Identify the product version and the functions the buyer intends to use. A general request for “508 compliance” is not a complete test plan. Clarify the expected evidence, delivery date, and point of contact before choosing the evaluation scope. Section 508 testing services can help turn those requirements into a defined assessment.
Distinguish Section 508 from a WCAG-only audit
The Revised Section 508 Standards incorporate WCAG 2.0 Level A and AA criteria for covered electronic content and software. They also address other ICT requirements. Depending on the product, hardware, software interoperability, documentation, and support provisions may matter. A WCAG 2.2 audit can be useful, but its label alone does not establish that every applicable Section 508 provision was evaluated.
Inventory everything included in the offer
List the web application, downloadable files, help content, hardware interfaces, and support channels that are part of the product or service. Separate your own components from third-party dependencies. Record any parts excluded from testing and the reason. For a device, coordinate hardware accessibility evaluation with the software and documentation assessment instead of treating the website as the whole product.
Prepare an ACR that identifies its evidence
Use the VPAT edition requested by the buyer and complete the report for the evaluated product version. Describe the methods and explain limitations with specific remarks. Keep the test records behind the ratings so your team can answer follow-up questions. The VPAT and ACR guide explains the difference between the blank template and the completed disclosure.
Handle documentation and unresolved barriers
Include user guides, installation instructions, help content, and accessible support information in the scope where applicable. Plan document accessibility remediation when those materials contain barriers. For unresolved findings, record the affected function, available alternatives, responsible owner, and proposed correction. Keep plans separate from tested results; a planned fix should not be reported as completed.
Keep procurement answers consistent with releases
When a release changes the evaluated functionality, review the related evidence and report. Give sales, product, and procurement teams the same current ACR so an older copy does not circulate after remediation. Record who owns the report and when it should be reviewed. The buyer evaluates the evidence in its own procurement context; the report is not an automatic approval or certification.
Frequently asked questions
What if a solicitation asks for both WCAG and Section 508?
Record both requirements and confirm their versions, levels, and applicability to the product. They overlap, but Section 508 can involve additional ICT provisions. Do not assume a WCAG-only report answers the full request. A Section 508 assessment can map the requested software, content, hardware, documentation, and support coverage before testing starts.
Can an existing ACR be reused for a new solicitation?
It can be useful when it describes the current product and the standards, configuration, and functions the new buyer requires. Compare the report with the actual request and identify changes since testing. An old date is one reason to review the evidence, but scope mismatch can matter even in a recent report. Additional evaluation may be needed before reusing its conclusions.
What should we do if the buyer's accessibility request is unclear?
Ask for clarification of the product scope, applicable standards, report format, and evidence the reviewer expects. Keep a record of the response and include it in the evaluation plan. For example, a request for a VPAT may leave the edition or required product configuration unstated. Resolving those details before testing is more useful than guessing and preparing the wrong report.
What belongs in a remediation response to a procurement reviewer?
Identify each relevant barrier, its impact, the responsible team, and the planned correction and verification. Distinguish committed dates from estimates and current results from future work. Do not revise an ACR rating merely because a fix has entered the backlog. Remediation and retesting support can help connect the response to evidence as the product changes.