Section508.gov notes that product changes can require an updated ACR. A release number alone does not tell your team how much work is needed. Compare the released product with the evaluated version, then identify the evidence that must be refreshed.
Use the release notes as the starting point
Ask product and engineering to identify changes that could affect how people navigate, understand, and operate the software. Include shared components and third-party updates as well as visible new features.
On narrow screens, scroll the table horizontally to read all columns.
| Change | Questions to investigate | Possible next step |
|---|---|---|
| New workflow or module | Was it included in the previous evaluation? | Evaluate the new functionality and related interactions |
| Replaced shared component | Which screens use it, and has keyboard or screen-reader behavior changed? | Test the component and representative affected workflows |
| Accessibility correction | Was the change verified in the released configuration? | Retest the issue and inspect relevant regressions |
| New document export | Is the generated output covered by existing evidence? | Review the output format and relevant requirements |
| New customer configuration | Does the ACR describe the version and configuration being purchased? | Identify coverage gaps before reusing the report |
| Changed buyer requirements | Does the request call for additional standards or reporting coverage? | Confirm the expanded scope and evidence needed |
The table is a planning aid. It does not establish that every change requires a complete audit or that a small change can be ignored.
Decide what evidence can still be used
Keep the existing findings connected to the product version and configurations they describe. For each changed area, record whether previous evidence remains relevant, needs verification, or no longer applies.
A shared navigation component may affect many screens. Testing only the newly added page could miss changes elsewhere. Conversely, an isolated change may be addressed through a narrower evaluation when its boundaries are understood. The decision should follow the component relationships and affected user tasks.
Verify a correction before changing its status
An engineering ticket marked complete describes implementation status. Retesting determines whether the observed barrier was corrected under the agreed conditions.
Record the released build, test environment, steps performed, result, and any remaining limitation. Consider related instances where the same component appears. If other failures remain for a criterion, correcting one instance does not automatically justify changing that criterion’s conformance rating.
Update the report and the buyer’s packet together
When the evidence supports a revised report, review its product description, version, evaluation methods, date, affected ratings, and explanatory remarks. Keep an internal change record that connects the revisions to test evidence.
Check the documents that sales and procurement teams distribute. An updated ACR is less useful if a proposal attachment, shared folder, or public link still directs buyers to an older report without identifying its scope.
Give customer-facing teams a short explanation of the update: which product version it describes, what was reevaluated, and where limitations remain. Avoid promising that the report establishes accessibility for every configuration or future release.
Set an owner for the next review
Include an accessibility evidence review in release planning. Assign an owner to assess changes, coordinate evaluation, and keep the report aligned with the supported product. Also record any customer-specific requirements for report age or update frequency.
CompliCorp can help scope remediation verification and retesting and ACR preparation. Share the current report, release notes, affected workflows, and buyer requirements so the next engagement addresses the actual changes.