A retest report answers one question, and the question is narrower than most people expect when they order one. It asks what happened to the findings in the previous report. Each one comes back fixed, regressed or still open, with fresh evidence attached and a new date on it, and anything that shipped while the fixing was going on arrives alongside them.
What it does not do is upgrade a sample into a verdict about your website. The limit that applied to the first audit applies to the second one unchanged, because it was never about the quality of the testing. It is that a page nobody opened can always carry an error, and running the same sample twice does not open any new pages.
That sounds like a small document. It is the most useful one in the whole sequence, because it is the only piece of paper in your possession that says a fix actually landed rather than that somebody closed a ticket. Here is what belongs in it, what a good one looks like written out, and the two ways a retest goes wrong.
The Three Verdicts, and the Fourth State Nobody Prints
Every finding in the original report gets exactly one of three answers, and each one has to carry its own evidence rather than a checkbox.
- Fixed. The barrier is gone, confirmed on the same page and the same pairing the original finding named, with new dated evidence. Not the code changed, which is a claim about a commit rather than about a person's experience.
- Regressed. The barrier is gone and something else broke while it was being removed. This is a new finding, not a footnote on the old one, and it needs the full set of fields any finding needs.
- Remaining. The barrier is still there. Sometimes because nobody got to it, sometimes because the change did not do what it was meant to do, and the report should say which, because the two lead to different next steps.
Then the fourth state, which no standard names and every honest retest needs. Not reachable. The test account expired, the seeded basket no longer exists, the promo code lapsed, the staging build drifted, and the retester could not get to the step where the failure lived. That is neither fixed nor remaining, and writing it as either is the single most common way a retest report tells a lie without anybody intending one.
The reason it happens so often is structural rather than careless. A page sitting inside a process cannot be identified by its address, so reaching it means reproducing the actions, the inputs and sometimes the credentials that got somebody there the first time. W3C's methodology asks evaluators to record exactly that, and when the record is missing or the account behind it has gone stale, the step is simply unreachable. A retest that names those honestly is more useful than one that quietly marks them fixed.
A Worked Retest, Before and After
Three findings, one of each verdict, written the way a retest entry should arrive. These are illustrations built from failures we meet often rather than from any client engagement, and the dates and reference numbers are invented.
| Finding | Original | What changed | Retest verdict |
|---|---|---|---|
| WR-002, focus invisible sitewide, 2.4.7, Level AA | The global stylesheet set *:focus { outline: none } and nothing showed where the keyboard was on any of the ten pages. | The reset was deleted and a :focus-visible style was added in the design system. | Fixed. Tabbed all ten pages on Chrome with NVDA. A visible ring appears on every interactive element, including the ones inside the cookie banner. Screenshot dated April 28. |
| WR-007, delivery error never announced, 3.3.1, Level A | The postcode field turned red on a validation failure with no text explaining what was wrong. | An error message was added, aria-describedby was wired up, and focus was moved to the field on submit. | Regressed. The message is present and correct. It is also announced twice, because a live region was added alongside the focus move and the second reading interrupts the first. Raised as WR-024. |
| WR-011, category filters unreachable by keyboard, 2.1.1, Level A | The filter chips were div elements with click handlers and no keyboard support. | Nothing. The ticket is in the backlog with the label applied. | Remaining. Reproduced unchanged on April 28. Same element, same behavior, new screenshot. |
Two things to notice about the middle row, because it is the row that earns the money. The team did the right thing and shipped a real fix, and the retest still found a new failure. Nobody was lazy and nobody was wrong in the pull request. And the regression is invisible to a fresh scan, because a fresh scan has never read the March report and would not know that anything was supposed to have changed here at all.
Every entry also carries its own conditions rather than inheriting March's. The browser, the screen reader, their versions and the date belong on the April evidence, because the same as last time is not a testable statement about software that has shipped four releases since.
Why the Double Fix Keeps Happening
That middle row is worth its own section, because it is the commonest regression in this whole category and it comes from diligence rather than from sloppiness.
A team is told a validation message is never announced. There are two correct instruments for that. Move focus to the message, so the screen reader reads it because focus arrived there. Or leave focus alone and put the message in a live region, so it is announced without anything moving. Both work. Doing both means the message is read once because focus landed on it and once because the live region fired, and the second reading interrupts the first.
The mechanism underneath is a definition. Moving focus is a change of context, and a status message is defined as a change in content that is not a change of context, so once focus moves the live region was never the right tool. That is a sentence in the glossary rather than a matter of taste, and our guide to what a change of context means has it in full. Nothing in a diff shows it, and nothing in a scanner catches it. Only a retest that knows what the original finding said will spot it.
Which Pages a Retest Should Open
There is published guidance on this and hardly anybody follows it, so it is worth knowing before you agree a scope. W3C's evaluation methodology has a section on re-running an evaluation, and it asks for a sample built from two parts.
Keep a sub-set of the pages from the first evaluation, so the two sets of results can be compared at all. Then replace another sub-set with pages that were not in the first sample, to widen the coverage. The proportion is specific. The replaced share is typically about half of the original sample, and the method adds that it can go higher when the kept pages are mostly coming back clean. Unless the product changed significantly, the sample size and the sampling approach stay the same.
So a retest has two jobs pulling in opposite directions, and the method resolves them by doing both. Comparability wants the same pages. Coverage wants different ones. Halve it, and each round both proves the fixes and opens ground the last round never saw.
Our own verification re-audit does not do that, and it is worth saying plainly rather than letting you assume. It reruns all three passes on the exact pages from your report, which is the comparability half only. On a ten-page scope that is a defensible trade, because swapping five of ten pages would leave half your original findings unverified, and the thing you are buying is verification. If widening coverage is what you want, a fresh audit with a new sample is the honest purchase and we will say so.
A Retest Should Find New Failures
If a retest comes back with the old list resolved and nothing else, be a little suspicious of it. Releases add as well as remove, and the site your team has been improving is also the site your team has been changing. Between March and April somebody shipped a feature, updated a dependency, swapped a consent banner or let a content author loose on a landing page.
So a good retest report has two sections rather than one. The dispositions of the original findings, which is what you ordered, and anything new found while looking, ranked alongside the rest. A report with only the first section has answered a narrower question than the one you probably had.
What a Retest Report Cannot Say
Three sentences that do not belong in one, whoever writes it.
| Cannot say | Why not | Can say |
|---|---|---|
| The site now conforms to WCAG 2.2 Level AA | Conformance is defined for a web page. A claim can cover a run of pages, and it holds only where every page in it was evaluated or produced by a process that guarantees each one passes. A sample is neither. | These ten pages were evaluated on this date and no failures were found against the criteria tested at this level |
| All accessibility issues have been resolved | The retest checked the findings from one report against one sample. Anything that was never found cannot have been fixed, and nothing about a retest widens the original coverage. | Every finding in the March report is now closed, and here is what the April pass found that March did not |
| The site is 94% conformant | WCAG has no score and no rating scheme, and W3C says so while explaining that aggregated scores can mislead. A percentage of findings closed is a progress metric, which is a different and legitimate thing. | Of the 23 findings, 19 are closed, three remain open and one regressed, with the counts defined right here |
That third row is the one worth defending internally, because a progress number is genuinely useful and it is one sentence away from being a lie. Publish the denominator with it. 19 of 23 findings closed is honest and quotable. 94% accessible is neither, and the difference is whether the reader can tell what was counted.
Who Should Run It
Whoever made the fixes should not be the one grading them, and this is the document where that matters most, because a retest exists to be read by somebody who was not in the room.
There is no WCAG rule about it. The standard says nothing at all about who evaluates or how independent they are, so this is a governance argument rather than a compliance one. It shows up in practice anyway. In US federal guidance the program manager who resources the fixes and the accessibility program manager who validates them are two different roles, and the plan is not retired until that validation happens.
We took the strongest version of that position and it costs us money. We sell no repair work at any price, which means we cannot have been the people who made your fixes, which is what turns our retest into a check rather than a firm grading its own homework. The full argument about who should verify sits on its own page, along with the cases where an internal retest is perfectly reasonable.
Ask for these four before you book a retest
Will you retest every finding, or a selection? Will the report say which pages you could not reach and why, rather than passing over them? Will new failures found in passing be included, or only the original list? And will each entry carry its own date, browser and screen reader rather than inheriting the first report's? Four questions, four sentences, and the answers tell you what the document will actually be worth to somebody outside your company.
What It Costs Here, and the Window
A verification re-audit is half of whatever you paid for the audit it follows, any time within 3 months of that report, on the same pages with the same three passes. After 3 months it is a fresh audit at the normal price, because by then most sites have moved far enough that a retest is not really a retest.
If somebody outside your team has to read the progress rather than take it on trust, the progress delta report charts the two reports against each other and is priced per report on top of the re-audit. If all you need is the retest and a reissued document, the verification re-audit on its own is the cheaper door. And if you are not sure a retest is the right purchase at all, retest or new audit is four questions that settle it. Fix, verify, done. No subscription and nothing to cancel.