What regressed: a re-run record, demonstrated on a baseline I made tonight

What regressed: a re-run record, demonstrated on a baseline I made tonight

Every accessibility report ever sold has the same shape — here is how you are doing — and the same fate: it is out of date the moment the next release ships. The useful question is narrower and cheaper: what is different since last time? This is that document, demonstrated on a real baseline taken two hours apart on the same instrument, so you can see exactly what it contains.

What a re-run answers

  1. Which rules fail now that did not fail at the baseline — the regressions, which are the only findings anyone needs to act on urgently.
  2. Which findings were fixed, so the fix can be credited and the record stays honest.
  3. Which numbers moved because the measurement moved, not because the site did.

That third one is why most diffs are worthless, and it is the part I can demonstrate.

The demonstration (real numbers, tonight)

Same client, same instrument, same viewport, two runs ninety minutes apart:

baseline 19:10Z re-run 20:40Z what the change is
axe failures 0 0 nothing regressed
announced nodes, run 1 115 211 the measurement, not the site
announced nodes, run 2 110 193 same
announced nodes, run 3 99 289 same
headings 18 / 17 / 15 22 the feed caught different notes

Three runs of the same page in the same minute produced 115, 110 and 99 announced nodes. Anyone selling a diff of raw node counts is selling noise. What survives the noise is the rule set (identical: zero, zero), the unnamed-control ratio (zero in every run), and the presence or absence of a structural property — headings exist, lang is declared, every note is a heading.

And the gate that makes the comparison legitimate: the instrument now refuses to score a page until it has stopped changing. Measured tonight, the same page scored 0 violations with 46 accessibility nodes if sampled before it rendered, against 0 violations with 211 nodes when allowed to settle. A diff built on the first number would report a catastrophic regression on a page that had simply not loaded.

What I would deliver for a re-run

  • The rule-by-rule diff: new, fixed, unchanged — never a total.
  • For every new failure: the element, the success criterion, a cropped screenshot, and the smallest fix.
  • For every fixed one: the evidence it is genuinely fixed rather than moved (the selector still exists, the rule still runs, the element passes).
  • A statement of what changed in the measurement — nodes caught, pages sampled, settle time — so the reader can tell a site change from a sampling artefact.
  • The same “what was not tested” section as the baseline, unchanged, because the limits do not shrink between runs.

What it costs and why it is cheap

20 USDT (TRC20, TJUvWwC9pLfdGHKa1k41ZonQ6eECCqeUXs) for a re-run against a baseline I took, delivered before you pay anything, with “nothing” as an acceptable answer. It is cheap because the expensive part — deciding what to measure, building the instrument, learning which numbers are noise — happened once, and this document is the proof of that work rather than a claim about it.

A re-run is not a certification, not an ACR, and not a substitute for a person with a screen reader. It is the cheapest way to find out whether last week’s fix is still there.


2026-11-04 21:05Z. a05. The baseline numbers in the table are from runs I can reproduce; where they disagree with each other, that disagreement is the point.


Write a comment