Skip to main content
EveryShopper

Monitoring: the second scan is the product

A one-off scan tells you what is broken today. Monitoring tells you what changed between one check and the next, on which page, and when — which is the question a store owner or an agency actually has to answer, and the one a single audit cannot answer twice.

Continuous monitoring is not running yet

There is no account, and no store pays us to watch it. The loop itself does run — it has run on our own site before, and it now runs on one store we do not own, whose owner asked us in writing to have it checked, free, as a pilot, on the platform’s scheduler — keeping a dated record of every run and comparing each run with the previous one, and it has sent one real monitoring message, to an address we control; messages to that mailbox have also been read and answered automatically by the program that reads it — none of them from a customer. None of the scans on this page came from it: every figure below was collected by hand. What is missing is the part a customer would need — there is no way to put your store into it, with no signup and no checkout — so nothing you can buy reaches you yet and we cannot yet alert you about anything. That program reads the mailbox, not a person: it records metadata about a reply and never the body of it — when it arrived, the address it came from and the name on that address, the subject line, how long it was, whether it arrived as HTML only, the filenames of any attachments, which of our own rules it matched, whether its acknowledgement went out and whether it was passed on to a person — and attempts one automatic acknowledgement. None is sent if the address is already on our stop list, if the message is a bounce, an automated or away reply, or comes from this mailbox’s own address, or if the run that read it could not send mail — no read key, sending switched off for that run, no usable address in your message to reply to, or the mail service refusing the message or failing to take it. The run records which of those happened — unless the program could not read the message at all: then nothing is recorded for that message and nothing is sent in answer to it, and the next run tries the message again. An acknowledgement is an attempt to answer, never a promise that one reaches you. The program polls the newest 250 messages in that mailbox on each run; a message older than those 250 is not listed, so it is not recorded and not answered. A message that looks like it needs a person — a question, a complaint, an expression of interest, a request to stop, or anything else a person wrote — is passed on to a person, with the message’s own text, so that a person can see what was written, when our own internal alert address is set. If that address is not set, or is unusable, nothing is passed on, and the run that handled the message records that it was not. A bounce, a spam complaint, an automated or away reply, or a message we sent ourselves is never passed on, and nothing is promised to come back from that. A reply asking us to stop puts that address on a stop list the sending run checks before it sends anything, so from the run after that check no further monitoring email goes out to it. No reply and no time frame is promised.

What follows is real scan data, collected by hand on purpose so that the change-detection argument can be judged on evidence instead of on a mock-up. We ran the scanner over the same three public pages twice, 25 Sep 2026, 22:48 UTC and 26 Sep 2026, 20:44 UTC — 6 real scans in total. That is two points in time, not a service.

The timeline, from the scans we actually collected

Three public pages, picked before the first round and never dropped for being unflattering: one online store — exactly the kind of shop this product is aimed at — plus a large public-service homepage and a news page. Every figure below is copied from the stored scan results, unedited. What a market’s law requires of a store is set out, with sources, separately on the home page — never here, and never about a particular shop.

A UK coffee retailer

A real UK online store — the kind of site this product is aimed at.

  1. Baseline fetch2026-09-25 22:48 UTC

    45 affected elements from 27 checks (19 produced no finding — which is not a pass, on any page). 14 critical, 24 moderate, 7 minor.

    HTTP 200 · 108,272 bytes of HTML read · 189 ms · page title present — not quoted here, because a title names the site

  2. Re-check #12026-09-26 20:44 UTC

    45 affected elements from 27 checks (19 produced no finding — which is not a pass, on any page). 14 critical, 24 moderate, 7 minor.

    HTTP 200 · 108,272 bytes of HTML read · 201 ms · page title present — not quoted here, because a title names the site

Real diff — no change detected on a UK coffee retailer between 25 Sep 2026, 22:48 UTC and 26 Sep 2026, 20:44 UTC. The same checks produced the same findings, with the same number of affected elements each time (45 → 45 affected elements).

The page's HTML was byte-for-byte the same size in both fetches.

A technology news site

A page whose content rotates every few minutes.

  1. Baseline fetch2026-09-25 22:48 UTC

    41 affected elements from 27 checks (20 produced no finding — which is not a pass, on any page). 34 critical, 4 serious, 3 moderate.

    HTTP 200 · 34,042 bytes of HTML read · 98 ms · page title present — not quoted here, because a title names the site

  2. Re-check #12026-09-26 20:44 UTC

    41 affected elements from 27 checks (20 produced no finding — which is not a pass, on any page). 34 critical, 4 serious, 3 moderate.

    HTTP 200 · 34,550 bytes of HTML read · 96 ms · page title present — not quoted here, because a title names the site

Real diff — no change detected on a technology news site between 25 Sep 2026, 22:48 UTC and 26 Sep 2026, 20:44 UTC. The same checks produced the same findings, with the same number of affected elements each time (41 → 41 affected elements).

The HTML itself differed by +508 bytes between the two fetches, but no check changed its verdict. We record only the size of each response, so we cannot say what differed. That is exactly what a quiet monitoring period looks like — and it is also why we show the raw figures rather than only a “nothing to report” message.

A UK government website

A large, deliberately stable public-service homepage.

  1. Baseline fetch2026-09-25 22:48 UTC

    4 affected elements from 27 checks (26 produced no finding — which is not a pass, on any page). 4 minor.

    HTTP 200 · 85,520 bytes of HTML read · 65 ms · page title present — not quoted here, because a title names the site

  2. Re-check #12026-09-26 20:44 UTC

    4 affected elements from 27 checks (26 produced no finding — which is not a pass, on any page). 4 minor.

    HTTP 200 · 85,520 bytes of HTML read · 38 ms · page title present — not quoted here, because a title names the site

Real diff — no change detected on a UK government website between 25 Sep 2026, 22:48 UTC and 26 Sep 2026, 20:44 UTC. The same checks produced the same findings, with the same number of affected elements each time (4 → 4 affected elements).

The page's HTML was byte-for-byte the same size in both fetches.

This is the severest finding that came with a piece of markup to show, from our baseline scan of the home page of a UK coffee retailer at 2026-09-25 22:48 UTC — one of 45 affected elements on that page. Severity first, then the number of elements affected; a finding with no markup to quote is not shown here at all. The markup is what the page's server sent us; the fix is what we would tell its developer to do. The site is described rather than named: no site we scanned is named on this page, and nothing here says one agreed to be shown.

Critical

Image has no alt attribute

8 elements affected on this page · Images ·Related to WCAG 1.1.1 Non-text Content (A) — not a pass/fail verdict · rule image-alt-missing

  • ul.navbar-nav > li.dropdown > a#dp-d1-2 > span > img.d-inline

    <img class="d-inline mb-1 ml-1 fillable" style="transform: rotate(90deg);" src="/assets/icons/fillable/navbar-arrow.svg" >

  • ul.navbar-nav > li.dropdown > a#dp-d1-4 > span > img.d-inline

    <img class="d-inline mb-1 ml-1 fillable" style="transform: rotate(90deg);" src="/assets/icons/fillable/navbar-arrow.svg" >

  • ul.navbar-nav > li.dropdown > a#dp-d1-5 > span > img.d-inline

    <img class="d-inline mb-1 ml-1 fillable" style="transform: rotate(90deg);" src="/assets/icons/fillable/navbar-arrow.svg" >

What this means

A screen reader cannot describe the image, so a person who cannot see it hears the file name or nothing. If the image is a link or a button, the control becomes unusable.

How to fix it

Add alt="" if the image is purely decorative. Otherwise write alt text that says what the image conveys in this context — a short phrase, not a file name.

What this check cannot tell you: We cannot judge whether alt text is accurate or useful. Only a human can.

You can run the same checks yourself: scan a page of your own. Counts move on a live site, so your run may differ from ours — that is a property of the site, not a disagreement between the numbers.

What a monitored store would receive

Two panels, and they are not the same kind of thing. The first is the alert's shape, filled in with figures from the real checkpoint above — but an alert is composed only when a comparison finds something to report: a check that was not there before, or a rise in the number of elements an existing check affects. A quiet day like this one sends nothing until the monthly digest — except a page that could not be checked, which gets a note of its own even on a day when nothing else went out. The second is what a change alert looks like when something has moved — no such change exists in our data, so that panel is invented, and it is marked as invented wherever a number appears. Neither panel says anything about whether a law applies to the store being monitored: monitoring shows what changed on a page, which is not a legal position.

A worked example of the quiet-run summary · never sent

From: EveryShopper Monitoring <monitoring@send.everyshopper.co.uk> — the sender the loop now uses; no alert has been sent to a customer

To: the monitored store's contact address — we hold no customer address, so nothing is addressed to one

Reply-To: hello@in.everyshopper.co.uk — the address the sending run sets by default, and the one mailbox the monitoring program polls. A run can be configured to point replies elsewhere; what this page can say is which mailbox is read, and it is this one

Subject: no accessibility changes since your last check — <the store's own name>

We fetched <the address you gave us> again at 2026-09-26 20:44 UTC. Since the previous check at 2026-09-25 22:48 UTC: findings: 45 then, 45 now critical: 14 then, 14 now 0 new, 0 fixed Nothing changed, so there is nothing to fix. No action needed. This is an automated check of the HTML your server sent. It is not a compliance certificate and it cannot see anything that needs a human or a rendered browser.

Every number above is from the two real scans of the home page of a UK coffee retailer whose timestamps are on this page. The sentences around them are the shape a quiet-run summary would take, not a message that has been sent: nothing in this shape has ever been sent, and the loop never composes this message, because when a comparison finds nothing to report — no new check, and no rise in the number of elements an existing check affects — it sends nothing at all, so a quiet store's next message from us is the monthly digest, unless one of its pages could not be checked, which has a note of its own. The loop has sent exactly one monitoring message, to an address we control; messages to that mailbox have also been read and answered automatically by the program that reads it — none of them from a customer.

Illustrative example — not a real scan of any siteexample-store.test does not exist

Subject: 2 new accessibility findings on example-store.test since the last check (illustrative)

We fetched https://example-store.test/checkout at 2026-09-25 21:05 UTC (illustrative). Since the previous check at 2026-09-25 20:05 UTC (illustrative): new findings: 2 (illustrative) findings fixed: 1 (illustrative) total findings: 45, up from 44 (illustrative) critical: 14, up from 13 (illustrative) The worst new one: "Image has no alt attribute" on the payment-methods strip — 4 elements (illustrative). Fix: add alt="" if the images are decorative, otherwise a short description of what each card logo means.

Why this panel is separate from the timeline above.

No change was detected in any of the real scans we have collected, so we have no real change alert to show you. Everything in this box is invented to show the shape of the message: the host is a domain that does not exist, and every number in it — both times, all four counts, the “4 elements” figure and the count in the subject line — carries an (illustrative) tag, so no figure from it can be read as a measurement of your site or of anyone else’s.

  • New: 2 findings that were not there before (illustrative)
  • Fixed: 1 finding that no longer appears (illustrative)
  • Total: 45 findings, up from 44 (illustrative)

What monitoring adds, and what it will not

Adds

  • A change caught between two checks. Most accessibility faults arrive with new code, not with age. Without a timestamped “before”, nobody can tell a new fault from an old one — and nobody fixes what they cannot date.
  • A record that outlives the argument. A dated series of real scans shows what your pages did and when — that a problem was known, reported and acted on. It is a record of what the HTML did, not a statement of compliance, and it is worth more than a single PDF, whichever way a client conversation goes.
  • Client reports without the copy-paste. For an agency, the recurring artefact is the deliverable: one report per client per period, from that client’s own data — once the export is built.

Will not

  • It will not certify compliance, and it will not be evidence that a site complies with any law.
  • It will not tell you that a law applies to the store you monitor. The four markets differ — the front page sets out what each one requires — and a dated scan is a record of your pages, not of your legal position.
  • It will not replace a human or rendered check. The coverage line in every report applies identically to every scan we ever run, however often it runs.
  • It will not catch a regression that lives in JavaScript, in a stylesheet or behind a login — we read the HTML the server sends, once per page.
  • And it is not running for your site yet: no account, no alerts to a customer, and no site of yours watched.

These are findings from automated checks on the HTML this page's server sent. Automated checks find a subset of real barriers, they do not certify compliance, and they do not replace a human or rendered check.

Where to go from here