An accessibility check is only true about the build it ran on. Date it instead, and your statement is a guess.
This is where teams slip when they move from ad-hoc audits to a real compliance obligation. The audit arrives as a document with a timestamp, findings get fixed, the next audit happens months later, and by then nobody can say which of those findings still describe what is in production. The evidence stopped tracking the artifact it was about.
We hit this while building a11ytrail, our open-source accessibility evidence tracker, and the fix turned out to be structural rather than procedural.
Every piece of evidence (an automated run, a manual keyboard pass, a screen reader walkthrough) is stored against a build identifier. Not a date, not a release name someone typed in. The build.
Three rules fall out of that.
A claim that mixes evidence from several builds gets flagged at assessment time. It is not silently averaged into a pass, because a criterion proven on build A and a criterion proven on build C do not add up to a statement about build C.
When two checks disagree, the one taken on the assessed build wins, even if the other one is newer. Recency is the intuitive tiebreaker and probably the wrong one. A check run last week against a different build is a fact about a different product.
And publishing is refused outright until every criterion has conclusive evidence on the assessed build, or the statement itself says the assessment is under way. Partial confidence is allowed. Partial confidence presented as a finished claim is not.
The expensive version of this mistake is not a failed audit. It is a support ticket saying a feature is unusable, next to an internal record that cheerfully reports the criterion as passing, because the passing check belonged to a build that shipped two quarters ago.
Accessibility conformance is a property of an artifact, the same way a test result is. Once you treat it that way, the reporting problem turns into a data modelling problem, and data modelling problems have answers.
So the question worth asking on your own team is what your accessibility evidence is actually pinned to today: a release, a date, or nothing in particular.