Updating a VPAT after remediation means re-evaluating the success criteria that were fixed, adjusting the conformance language for each row, refreshing the evaluation methods and notes, and issuing a new ACR with a current date and version number. The product itself drives the update. If remediation closed out specific issues, those rows move from Partially Supports or Does Not Support to Supports. Anything still open stays as is, with honest notes. The result is a fresh Accessibility Conformance Report that reflects the product as it exists today, not as it existed before fixes were made.
| Step | What Happens |
|---|---|
| Re-evaluate | Conduct a follow-up evaluation on the remediated criteria to confirm fixes hold |
| Update conformance | Adjust each row’s language (Supports, Partially Supports, Does Not Support) |
| Refresh notes | Rewrite remarks to reflect current product state, not prior issues |
| Document methods | Update the evaluation methods section with the new evaluation details |
| Re-issue | Publish a new ACR with current date, version number, and product scope |
Why a VPAT Needs Updating After Remediation
An ACR is a snapshot. It reflects the product on the day the evaluation ended. Once remediation closes issues, that snapshot is out of date.
Buyers, procurement teams, and government agencies want a current document. An old ACR showing Does Not Support for criteria that have since been fixed undersells the product and creates friction in deals.
The reverse problem is worse. An ACR that claims Supports for criteria that were never properly remediated is a misrepresentation, and that risk grows as procurement teams scrutinize accessibility documentation more closely.
What Triggers a VPAT Update?
The most common trigger is a remediation cycle. After developers close out issues from an evaluation report, the ACR no longer matches reality.
Other triggers include significant product changes, a new release that adds or removes features, a redesign, or a platform migration. ACRs do not have a formal expiration, but the recommendation is to update after meaningful product changes or at least annually for active products.
If the remediation cycle was small, say a handful of criteria, the update is light. If remediation touched dozens of criteria across multiple sections, the update is closer to a full rewrite of the conformance table.
Re-Evaluate the Remediated Criteria
You cannot update conformance language based on developer claims alone. Each remediated criterion needs to be re-evaluated by an auditor to confirm the fix holds across the evaluated pages or screens.
This is a follow-up evaluation, sometimes called validation. The auditor reviews each previously failing criterion against the updated product and confirms whether it now meets WCAG 2.1 AA or 2.2 AA, depending on the standard the original ACR used.
Validation is where most update efforts succeed or fall apart. A fix that works on one page may not work on another. A correct ARIA pattern in one component may have been copied incorrectly to a sibling component. The auditor catches these.
Adjust the Conformance Language
VPATs use four conformance terms: Supports, Partially Supports, Does Not Support, and Not Applicable. After validation, each remediated row gets re-categorized.
A criterion that fully passes across all evaluated pages moves to Supports. A criterion that passes in some areas but still has issues elsewhere stays at Partially Supports. A criterion where the fix did not hold stays at Does Not Support.
The remarks column needs equal attention. Stale remarks describing pre-remediation issues must be rewritten to describe the current state. If a row now reads Supports, the remarks should briefly confirm what was implemented, not describe the problem that no longer exists.
Update the Evaluation Methods Section
The evaluation methods section documents how the product was evaluated. After a follow-up evaluation, this section needs to reflect the new evaluation, including dates, scope, environments evaluated, and assistive technologies used.
If the original evaluation covered desktop only and the validation added mobile, that change goes here. If the WCAG version was updated from 2.1 AA to 2.2 AA, that goes here too.
This section is where many ACRs lose credibility. Vague language like “automated evaluation” or generic vendor descriptions raises flags with experienced procurement reviewers. Specifics build trust.
Re-Issue the ACR
The updated ACR gets a new revision date and version number. Some companies keep prior versions accessible internally so buyers can see the progression. Others retire old versions entirely.
Either approach works. What matters is that the version currently shared with prospects, customers, and procurement teams reflects the current product. The previous ACR should not be the one in circulation.
How often should a VPAT be updated?
Update after any meaningful remediation cycle, after significant product changes, or annually for actively maintained products. There is no formal expiration date, but a stale ACR loses credibility quickly in procurement reviews.
Can you update a VPAT without a new evaluation?
Not credibly. Conformance claims need evidence, and that evidence comes from an auditor evaluating the remediated criteria. Self-attestation without an evaluation weakens the document and exposes the company if buyers push back.
Does the updated VPAT need to use the same edition?
Usually yes. If the original was the WCAG edition, the update should be the WCAG edition. Switching editions, for example moving from WCAG to INT, is appropriate when the buyer base or regulatory context has changed, not as part of a routine update.
An updated ACR is only as strong as the work behind it. Validation, honest conformance language, and current evaluation details are what make the document hold up under scrutiny.
To get help updating your ACR after remediation, contact Kris.