How often should a VPAT be updated? Versions, SaaS, staleness
How often should a VPAT be updated? No rule sets an expiry date, but reports go stale. What triggers an update, how SaaS changes it, and what to require.
How often should a VPAT be updated? There is no official answer. Neither the ITI template, the Section 508 standards nor the ADA Title II rule puts an expiry date on an Accessibility Conformance Report. What exists instead is a simple principle: a report describes one product, at one version, at one point in time. When any of those three stops matching what you are buying, the report has stopped describing it.
That makes "how often" the wrong framing. The useful question is "what has changed since this was written?"
How often should a VPAT be updated? What the sources say
The ITI VPAT 2.5Rev template requires every report to name the product and its version identifier "if available", and to give a report date of at least month and year. Its best-practice guidance says that when a report is revised, the author should change the report date and explain the revision in the Notes section, or issue a new report that states it supersedes the earlier one. It does not set a cadence.
Section508.gov's ACR guidance for vendors goes a step further: every time a product is changed or updated, "an updated ACR may be required to address any changes in the product's accessibility." It also says that a report written against the original 2001 Section 508 standards must be redone against the Revised 508 Standards published in 2017.
The Title II rule says nothing about conformance reports at all. It requires a public entity to ensure its web content and mobile apps conform to WCAG 2.1 Level AA from its compliance date onward. That is a continuing obligation. Software that conformed at award and regressed in a later release is a problem for the entity, regardless of what the report on file says.
Annual review is a common practice and a sensible default for actively developed software. It is a practice, not a requirement, and it is not the only trigger.
What should trigger an update
For vendors, these are the events after which an existing report probably no longer describes the product:
- A new major version. The template ties the report to a version for a reason.
- A redesign or new front-end framework. Changing component libraries can alter focus handling, labels and contrast across the whole product at once. A report that predates the redesign is describing a different interface.
- New modules or workflows. If the product gained a payments module or a mobile app, the existing report does not cover it, however accurate it is about everything else.
- Remediation shipped. Fixes are a reason to update too. A report that still says "Partially Supports" on 2.4.7 Focus Visible after the fix shipped understates the product and costs the vendor in evaluation.
- A new standard requested. A report written to WCAG 2.0 or 2.1 does not answer a WCAG 2.2 requirement, however recent it is. That is a coverage gap rather than staleness, but the fix is the same: a new evaluation.
- A known regression. If a release broke something that the report says is supported, the report is now inaccurate, not just old.
SaaS and continuous delivery
Version numbers mean little for software that deploys weekly. Many SaaS reports name the product with no version at all, or with a version label that marketing chose and engineering never uses. The template permits this; "if available" is in the wording.
For SaaS, the report date effectively becomes the version. That shifts what a buyer should look for:
- A specific evaluation date, not just a publication month, and ideally the release or build that was tested.
- Evaluation methods that describe ongoing practice: accessibility checks in the release process, regular manual testing with named assistive technology, not only a one-time audit.
- A statement of what changed since: if the product has shipped significant features since the evaluation, the vendor should be able to say whether those were tested.
A twelve-month-old report on a product that ships weekly has had perhaps fifty releases since anyone looked. That does not mean it is wrong. It means you are taking those fifty releases on trust, and you should know that you are.
What makes a report stale
From the buyer's side, treat a report as stale and ask for an update when any of the following is true:
| Signal | Why it matters |
|---|---|
| Report is undated | Nothing establishes when it was true |
| Version named is not the version offered | It describes different software |
| More than about a year old on actively developed software | Unknown number of changes since |
| References the 2001 Section 508 standards (1194.21, 1194.22) | Superseded since January 2018 |
| Reports WCAG 2.0 only, against a WCAG 2.1 requirement | Twelve Level A and AA criteria unaddressed |
| Uses an old VPAT template version | Often a sign the report itself has not been touched |
The one-year line is a judgment, not a rule. A stable desktop product unchanged in two years may have a perfectly current report from two years ago. A SaaS portal redesigned last quarter may have a stale report from six months ago. The red flags guide covers the other signals worth raising.
What buyers should require
Write currency into the solicitation and the contract, so that it is not left to whoever reads the report:
- At submission: an ACR covering the product version proposed, dated within a period you set (twelve months is a reasonable default), with the standard and version named. For background on what an ACR is, see what is a VPAT.
- During the contract: an updated ACR after each major release or redesign, and at least annually for continuously delivered software.
- On regression: notice from the vendor when a release reduces conformance, with a remediation date. Section508.gov's sample contract language includes a clause that maintenance upgrades must not reduce the original level of conformance, which is a useful model.
- On request: the evaluation evidence behind the report, so an update is more than a new date on old content.
Keep each version of the report in the procurement file. The sequence of reports over the life of a contract is the record of whether the product got better or worse, and whether the vendor told you.
For vendors
A report that was accurate when written but has not been touched since is the most common reason a capable product is challenged in evaluation. The fix is mostly process: tie report updates to your release calendar, keep a revision note in the Notes section as the template suggests, and re-evaluate the specific criteria a change is likely to affect. The guide to filling out a VPAT covers the rest. If you want to know how your current report will read to a government reviewer, have it reviewed before you submit it.
Sources: ITI VPAT 2.5Rev template instructions (April 2025); Section508.gov, ACR/VPAT FAQ and Define Accessibility Criteria in Contracts; 28 CFR part 35, subpart H (the DOJ's 2024 Title II web rule, as amended 20 April 2026); W3C, What's New in WCAG 2.1. This is general guidance, not legal advice.
GOVvpat returns a dated assessment of each report you receive and tracks whether promised updates arrive. Request a quote, or if you are a vendor, have your report reviewed.