Look at the evaluation date on the front of your report, then look at your release log. The distance between those two things is your answer, because nothing in WCAG expires a report. There is no renewal interval in the standard, no validity period on a conformance claim, and no rule anywhere that a document older than some number of months stops counting. What a report has is a date, and what that date means is that somebody looked at those pages, in those conditions, on that day.
So the useful question is not how long the document lasts. It is how far your site has moved since the day it was written, because a report describes a site at a moment and your site is a thing people change on purpose. A twelve-month-old report on a brochure site nobody has touched is still an accurate description. A three-week-old report on a site that shipped a redesign last Tuesday is already fiction in the places the redesign reached.
That is good news, because it turns an unanswerable question into a checkable one. Below are the nine changes that age a report, what each one puts in doubt, and the smallest honest thing you can do about it. Work down the list against your own release history and you will have a better answer than any interval could give you. What to actually buy once you have that answer is a separate decision, and retest or new audit is the page that works it through.
What the Standard Actually Dates
WCAG never requires you to publish anything. You can conform to the standard and say nothing at all, and plenty of careful sites do exactly that. If you do publish a conformance claim, five things have to be in it, and the first is the date of the claim.
- The date of the claim.
- The guidelines title, version and address, written out in full.
- The conformance level satisfied, so A, AA or AAA.
- A concise description of the web pages the claim covers, including whether subdomains are in it.
- A list of the web content technologies relied upon.
Read that list again with the question in mind. A claim is stamped with a date and pinned to a named set of pages, and nothing in it renews, lapses or ages. It is a statement about a moment, made by you, and it stays exactly as true or as false as it was when you made it. Our reference page on the five conformance requirements has the whole set with worked examples.
One consequence catches people out. A conformance logo counts as a claim and has to be accompanied by all five components. So a badge sitting in your footer eighteen months after a replatform is a dated claim about a site that no longer exists, which is worse than no badge at all. If you display one, the date on it is doing work.
The Only Clock WCAG Puts on Anybody
There is exactly one interval in the whole conformance section, and it is not a repair deadline for your own defects. It applies to pages that carry content other people add, so comments, reviews, user uploads, aggregated feeds, dynamically inserted advertising.
For those pages the standard offers two ways forward. You can determine conformance based on best knowledge, on the condition that the page is monitored and non-conforming content is removed or brought into conformance within two business days. Or you publish a statement of partial conformance, saying the page does not conform but would conform if the named uncontrolled parts were removed. If you cannot monitor or correct that content at all, no claim can be made.
Two business days is the number people half-remember and then apply to everything. It is not a fix deadline for your own code, it is not a legal response period, and it is not a general rule about how fresh evidence has to be. It is a condition attached to one specific move, which is claiming conformance for a page whose contents you do not fully control.
The Nine Changes That Age a Report
This is the worksheet. Take your release history since the report date and mark which of these happened. The middle column is what the change puts in doubt, which is usually wider than the change itself, and the right-hand column is the least you can do and still be honest about what you know.
| What changed | What it puts in doubt | The smallest honest response |
|---|---|---|
| A shared component or template | Every page that renders it, which on a templated site is most of them. This is the change with the widest blast radius and the one least likely to be noticed. | Retest the component itself plus one page that uses it, and treat a clean result as covering the rest of that template |
| A new page type shipped | Nothing in the report, because the report never saw it. The old findings still stand for the old templates. | Test the new template on its own. No need to reopen anything else |
| A third-party embed added, updated or swapped | The whole page it sits on. Conformance is claimed for a full page and you cannot carve out the part somebody else wrote. | Retest that page, and check whether either of the two third-party remedies applies to what you cannot fix |
| A step added to or removed from a journey | Every page in that journey. If any page in a process fails, no page in the process conforms, however clean the others are. | Retest the journey end to end, including the branch routes people actually take |
| A design token moved, so a color, a focus style, a spacing scale or a target size | Contrast, focus visibility and target size everywhere the token reaches, which is usually everywhere. | Recheck the affected rules across the sample. This is fast and it is the change most often shipped without anybody thinking of it as a change |
| A new layout or breakpoint | That layout, on its own. Each variation a page presents for a different screen size has to conform by itself before the page conforms at all. | Test the new width. A pass at one width says nothing about another |
| A lot of new content published | The content rules on those pages, so alt text, headings, link text, tables and captions. Not the templates, which have not moved. | Sample the new content rather than reopening the template work |
| Your audience moved, or the agreed baseline widened | Results that were measured against a narrower set of browsers and assistive technology than you now need to serve. | Re-run the affected checks on the added pairing, and add it to the record rather than leaving it off |
| The standard moved | Criteria that were tested against wording which has since changed, plus any criteria that did not exist when the report was written. | See the version-upgrade route rather than testing only the new rules |
And the tenth row, which is the one nobody writes down. If none of those happened, your report still describes your site, and buying another one proves nothing you did not already have in writing. That is not us being modest. It is what the change-driven view of validity actually implies, and any supplier telling you otherwise is selling you a calendar rather than a finding.
How to Turn That Into a Date
Four steps, and it takes about twenty minutes with your release notes open.
- Write down the report's evaluation date, not the date it landed in your inbox. The two are usually a week or two apart and the earlier one is the one that matters.
- List every change since then that touches a template, a journey, a design token, a layout, an embed or the baseline. Ignore copy edits and new blog posts for now.
- Mark the earliest one that hits a template or a journey. That is the day your report started describing something other than your site, and it is almost never the day you expected.
- Decide what you need the report for. Steering your own fix list tolerates a lot of drift. Answering a customer, a regulator or a procurement questionnaire tolerates very little, because somebody else is going to hold the date up against your release log.
That last step is the one that actually decides it. The same document can be perfectly serviceable for one purpose and out of date for another on the same morning, which is why a fixed interval was never going to work. Once you have your date, take it to the retest or new audit decision, which turns the same four answers into the smaller purchase or the larger one.
Where the Twelve-Month Figure Comes From
You will hear that a report lasts a year, and there is a real source behind it that says something narrower than the version you were told. UK government guidance for education teams advises holding budget for an accessibility audit every twelve months. The reason it gives is readiness. If the service has changed, new patterns or components have arrived, or a complaint or monitoring finding needs answering, the money is already there.
That is budgeting advice, and the same page carries the sentence that never gets quoted with it. If no change has been made, previously identified issues have been resolved and retested, or the team has carried out sufficient internal testing, a new audit may not be needed. The interval is about having the budget available, not about the evidence going stale on a schedule.
It is also guidance for public sector teams working to a service standard, so it is not a duty on a private business and it is not in WCAG. Whether any law reaches you, and what it asks for, is a separate question with a different answer in every jurisdiction, and our laws by country pages are where that belongs rather than here.
Three Things Move in a Year, and Only One Is Your Site
Even a site nobody touches drifts, because two of the three things a report depends on are outside your building.
Your content changes, which is the obvious one. The assistive technology changes, because NVDA, JAWS and VoiceOver all ship through the year, and an announcement that worked in one version can stop working in the next. That is a thing you cannot see from inside your own codebase. And the standard itself moves quietly. WCAG 2.2 was republished on December 12, 2024 carrying errata that modified four defined terms, including programmatically determined, which is a phrase the success criteria are built out of. Nobody sends you a letter when that happens.
None of that means an annual audit is required. It means a report is a photograph rather than a certificate, and the three clocks run whether or not you deploy anything.
What a Dated Report Is Still Good For
An older report is not worthless, and treating it as worthless is its own kind of waste. Three jobs it keeps doing.
- It is a baseline for the next one. A retest that can read the previous report can mark every finding fixed, regressed or still open, which is a document a fresh audit cannot produce at any price.
- It is your template diagnosis. Findings tied to a component are true about that component until somebody changes it, and most of what an audit finds on a templated site is about a handful of components.
- It is evidence of what you knew and when. A dated report plus a dated fix log is a record of a business taking the thing seriously, and it reads very differently from a business that never looked.
What it stops being is a description of the current site, and the honest thing is to say the date out loud whenever you hand it to somebody. Evaluated in March, and here is what has shipped since is a stronger position than a document with an unqualified date on it, because it is the sentence the reader was going to work out anyway.
Our Own Windows, and What They Are For
Two dated windows sit on our own pricing, and neither of them is a claim about how long evidence stays true.
A re-audit is half of whatever you paid, any time within 3 months of your report, on the same pages with the same three passes. That window exists because a retest against a list this fresh is genuinely a retest. After 3 months it is a fresh audit at the normal price, because by then most sites have moved far enough that comparing against the old list would be comparing two different products. And the annual review is always full price for the same reason, which we would rather say on the page than at the checkout.
One honest limit
Everything above is about the evidence rather than about the law. No jurisdiction we cover sets an audit interval for a private business inside WCAG, because WCAG sets no interval at all. Whether a regulator, a contract or a procurement rule imposes one on you is a legal question this page does not answer. If you are being asked for evidence dated within some window, that window came from whoever is asking, and the right move is to read their requirement rather than to assume a standard produced it.
What to Do This Week
Put the evaluation date of your last report somewhere you will see it. Then add one line to whatever you use for release notes, naming the six changes worth flagging, so a template change, a journey change, a token change, a new layout, a new embed and a new page type. That single line turns the question from a guess into a lookup, and it costs a developer about four minutes a release.
Do that and you never have to wonder how old your evidence is again. You will know, and so will anybody who asks.