What should send you back for testing is a change, not an anniversary. A retest re-checks findings you already have, on pages somebody already opened. A new audit re-establishes what the evidence covers, because the thing being tested is no longer the thing that was tested. So the question is never how long it has been since the last report. It is what has moved since, and the four questions below take you from that to an answer in about five minutes.
We sell both of these, so read this knowing that, and notice which way the advice runs. One of the four answers below is that you should not buy anything yet. We have left it in because it is true often enough to matter, and because a firm that recommends a purchase every time has stopped giving advice and started reading from a price list.
Work Through These Four Questions in Order
Answer each one honestly and keep going. They are cumulative rather than exclusive, so it is normal to finish with two answers, and where that happens the second one is usually the bigger purchase.
- Has your team marked findings from the last report as fixed? If yes, a retest is the thing that closes them, and it is the cheapest door in the building. A retest takes the original findings one at a time and marks each one fixed, regressed or still open, with fresh dated evidence either way. It answers a closed question about a known list, which is exactly why it costs less than the audit it follows. Keep reading anyway, because a retest may not be all you need.
- Has anything been added that was never in scope? A new section, a new subdomain, a language version, a logged-in area, a new app, a storefront on its own address. If yes, a retest cannot reach it, because a retest re-opens the pages the first audit opened and nothing else. What that new thing needs is scope, so either add it to an existing engagement or treat it as a new audit of its own. This is the answer people resist most and it is the least arguable, since nobody can retest a page that has never been tested.
- Has something shared changed underneath the pages that were tested? A template, a component library, a design system, a front-end framework, the content management system itself. If yes, the old evidence describes a build that no longer exists. W3C's evaluation methodology treats the CMS, the design system and the front-end framework as things a product relies on for conformance, and encourages recording their version numbers, precisely because changing one changes every page it touches. That points at a new audit, or at minimum a fresh audit of the templates the change reached.
- Did you answer no to all three, and are the last report's findings closed and verified? Then nothing needs buying today. No change, nothing outstanding, and nobody has complained. Put a date in the calendar to ask the same four questions again. Spend the budget on the routine that keeps the answer honest, rather than on a document that will say what the last one said.
What Each Answer Buys, and What It Leaves Open
Four questions, four things you might buy. The differences between them are worth having straight before anybody asks for a quote, because the words suppliers use for these are not standardized and two firms will sell you different work under the same name.
| The answer | What it covers | What it leaves open |
|---|---|---|
| A retest | Every finding in your original report, re-checked on the same pages by the same method, each one marked fixed, regressed or still open with dated evidence. | Anything that arrived after the first report. New pages, new features and new templates are outside it by definition. |
| A scoped audit of what changed | The new or rebuilt part, tested properly against all 55 rules, with its own evidence and its own scope statement. | Whether the rest of the site still holds. If the change was shared, the untested pages may have moved too. |
| A new audit | Fresh scope, fresh sample, all three passes, a report that stands on its own and can be set beside the old one. | Nothing about the old report is carried forward automatically. That is the point of it, and it is why it costs what a first audit costs. |
| Nothing yet | The honest answer when the site has not moved and the findings are closed and verified. | It is a judgment about today. Put the date in the calendar and ask the four questions again, because drift is quiet. |
The Changes That Should Send You Back, and Why Each One Does
The tree above is the shape of the decision. This is the detail behind it, so you can spot a trigger in a release note rather than three months after it shipped. Each row names a change, says why it reaches the evidence, and points at which answer it argues for.
| What changed | Why it reaches the evidence | Where it points |
|---|---|---|
| A page template or a shared component | One template renders many pages, so a change there changes every page it renders, including pages nobody tested. | A scoped audit of the affected templates, then a retest of anything the old findings touched. |
| The front-end framework or the design system | These are recorded as things the product relies on for conformance. Change one and the markup, the focus behavior and the announcements can all move at once. | A new audit. The old evidence describes a build that is gone. |
| The content management system | A migration regenerates the markup around your content, and it usually moves headings, landmarks and link text with it. | A new audit, because the sample has to be re-selected from what the new system actually produces. |
| A step added or removed inside checkout | A page in a process only conforms if every page in that process does, and the standard's own example of a process is a store checkout. | A scoped audit of the whole process, not only the new step. |
| A new section, subdomain, language version or logged-in area | None of it was in the sample, so none of it is in the evidence, and a sample cannot answer for pages nobody opened. | A new audit, or an agreed addition to the existing scope. |
| A new breakpoint or a redesigned mobile layout | Every layout a responsive page presents at a different width counts as a variation that has to conform on its own. | A scoped audit of the affected pages at the affected widths. |
| The screen readers and browsers moved | The evidence was taken against a named pairing, and that list is expected to be revisited as more current versions arrive. | A retest of the findings that depended on announcements, or a fuller pass if the product leans heavily on custom widgets. |
| Somebody complained, or a buyer asked for evidence | A complaint is a report of a barrier a real person hit, which is the most direct evidence there is. A procurement question is a deadline attached to a document. | Start with the specific journey. A user complaint audit reproduces the barrier and audits the journey around it. |
| Nothing | The pages, the templates, the stack and the content are all where they were, and the findings are closed and verified. | Nothing. This row is here because it is a real outcome and almost nobody publishes it. |
Why the Calendar Is the Wrong Trigger
The yearly re-audit is the default advice everywhere, and it is worth understanding what the better version of that advice actually says. UK government guidance for public sector services recommends carrying a budget for an audit every twelve months, and the reasoning is about readiness rather than about a deadline. If your service changes, or new patterns and components arrive, or a complaint lands, the money is already there.
The next sentence of that same guidance is the one nobody quotes. If no change has been made, and previously identified issues have been resolved and retested, and the team has done enough internal testing, a new audit may not be needed. That is the distinction this page is built on. Budget yearly. Buy on change. The calendar is a good way to make sure the question gets asked. It is a poor way to answer it.
It is worth being equally clear about what the standard says here, which is nothing at all. WCAG requires a conformance claim to carry a date, and it sets no expiry, no review interval and no re-audit duty. The date is there so a reader can work out for themselves whether the evidence still describes the product. Where a law does impose a monitoring or reporting rhythm on you, that comes from the law rather than from WCAG. Settle it at which laws apply to you, not in a supplier's renewal email.
A Report Does Not Expire. It Stops Describing Your Site.
That distinction sounds like wordplay and it changes what you buy. If reports expired, the right move would be to replace one every twelve months whatever happened in between. They do not expire. So a report from eighteen months ago is good evidence about a site that has not moved, and a report from six weeks ago is worthless about a checkout that was rebuilt last Tuesday. The clock was never measuring the right thing.
Which means the useful record to keep is not the report's date but a short log of what has shipped since it. Template changes, framework upgrades, new sections, new steps in a process. Teams that keep that log answer the four questions above in minutes and buy the right thing. Teams that do not end up guessing, and guessing usually costs more, because the safe guess is always the bigger purchase. Keeping a site accessible covers the routines that make that log a by-product of how you already work.
What Our Retest Is, and Why It Can Say Anything About Somebody Else's Fixes
Ours reruns all three passes on the exact pages from your report, so the automated scan, the expert review against all 55 rules, and a professional blind screen-reader user back on the same journeys. Every original finding comes back marked fixed, regressed or still open with fresh dated evidence, and anything new that arrived while the fixes were going in arrives with it. It is your report reissued rather than a new document, which is what makes the two comparable at all. The verification re-audit sets out the whole scope.
The part that decides what such a document is worth to anybody outside your company is who did the repair work. We sell audits and we sell no repair work, at any price, in any form, before or after the report. So whoever wrote the fixes, it was not us, and there is no arrangement under which it could have been. That is what turns a retest into a check rather than a firm marking its own homework. It matters most exactly when the verdict matters most, which is when a regulator, a buyer or a board reads it instead of taking your word for it.
Two honest limits go with that. Some findings will come back marked still open, and we will say so plainly, because a verification that cannot fail would prove nothing. And the retest runs at half price within 3 months of your report. After that it is a fresh audit at the normal price, because by then the site has usually moved far enough that a retest is not really a retest any more. The pricing page carries that term in writing.
When a Year Passes and Nothing Has Changed
Then work the four questions, and if the answers really are no, no and no, do not buy. That is an unusual thing for us to write on a page next to a yearly product, and it follows from everything above. A document that repeats what the last one said is not evidence of anything except that you paid twice.
Where a year does earn a fresh look is the case the questions catch, which is drift you did not notice. A year is long enough for new pages, a theme update, a plugin, and a junior hire with publishing access, and long enough for the screen readers themselves to ship several versions. If that describes your year, then what you want is a full pass rather than a diff, because a year of change is too much to sample against an old list. The annual review is that, booked once, on purpose. There is no subscription behind it, no stored card and nothing to cancel, and because it falls outside the 3-month window it is always full price. We would rather write that here than let you find it at the checkout.
The rule this whole page comes down to
Budget yearly so the money is there. Buy on change so the money buys something. And when you do buy, read the header of what comes back before you read a single finding. The conditions at the top decide whether the answers underneath apply to the site you are running today.