AccessGuard runs a real audit of a storefront: a browser loads the page, axe-core measures it, and the app reports what failed. This is what the audit now keeps for every failing element, how the lists are capped and why the cap is printed, what is computed rather than guessed, what a person still has to check by hand, and what the record at the end of all of it is and is not.
The short version: for every element that fails a rule, the audit keeps the element and the reason axe measured for it. For a contrast failure that means the ratio it measured, the two colours, the font size and the ratio the criterion requires, for that element rather than for a representative one. The lists are capped, the caps are stated on the page, and nothing that is cut from a list is cut from the count.
What Is Kept for Every Element
axe reports one finding per rule per page, and inside the finding one node per element that failed. It also computes, for each node, why that node failed: the selector that reaches it, a snippet of its markup, and the measurement behind the failure. The audit keeps the node and its reason together, so a merchant looking at a contrast finding with thirty failing elements can open any one of them and see what was measured on that one.
The change exists because the earlier version of the audit did not do this. It kept the first element and a count, so a merchant read one sentence and a number, and the reason axe had already computed for every other element on the page was discarded before it reached them. What follows is what replaced that.
The rule the caps encode
Occurrences are listed per finding and per run: forty per finding and four hundred per run, read from the engine as this published, with the budget spent on the worst severity first so a critical finding is never trimmed to make room for a minor one. The caps change what is listed, never what is counted. When a list is cut, the finding says how many more elements there are on the page that are not listed, and every one of them still counts.
The Passing Colour Is Computed
A contrast finding used to come with the standard advice, which is to increase the contrast. The audit now computes a colour that passes. It takes the text colour and the background axe measured for the element and mixes the text colour toward black or toward white, one percent at a time, until it reaches the first shade that clears the ratio the criterion requires for that text size, using the luminance maths WCAG defines. That shade is what the finding suggests, alongside the ratio it was measured against.
What the computed colour is not
It moves the text colour only. The background is left where it is, because changing a background changes a page and changing a text colour changes a rule. It is the nearest passing shade, not a design decision: a theme with a palette will want to choose its own passing colour, and the number it has to clear is printed beside the suggestion. And a contrast figure in the report is always a measurement the engine made on that element. The audit never asserts a ratio it did not compute.
The Reason Is Axe's. The Steps Are Written for a Theme.
Every finding carries axe's own explanation of the failure. On a Pro plan the audit also rewrites that explanation into steps that make sense inside a Shopify theme: where the setting lives, what to change, what to check afterwards. The rewrite is a rephrasing of the reason axe computed. It does not decide what failed, it cannot add a failure and it cannot remove one. If the rewrite is unavailable for any reason, the finding shows axe's text instead, and the audit does not wait for it.
The Half Automation Cannot Reach
Automated testing can measure what is on the page. It cannot tell whether an alt text actually describes the image, whether a video's captions are right, whether a purchase can be completed on a keyboard alone, or whether the message under a form field says what went wrong. Those are judgement calls, and an audit that pretends to make them is lying about its own coverage.
So the app has a checklist of twelve manual checks, available on every plan. Each one states when it applies, what to check, what a pass looks like, and why the audit cannot see it.
The twelve checks, as this published
- Alt text quality
- Media alternatives
- Captions
- Audio description
- Keyboard purchase
- Focus order
- Focus visible
- Autoplay can be paused
- Error identification
- Error suggestion
- Purchase review
- Colour is not the only signal
A manual check never scores
Marking a check as passed changes nothing about the score. The score is what the engine measured; a mark is what a person attested; and the app keeps the two apart on purpose, because a number that could be raised by ticking a box would stop meaning anything. What a mark does is enter the record, dated, next to the audits.
Whose Finding Is It
Some failures on a storefront belong to the theme and some belong to an embedded widget: a reviews carousel, a chat bubble, a payment button drawn inside its own frame. The audit classifies each finding by ownership rather than by a list of vendors. A selector that reaches into a shadow root or an iframe belongs to whoever ships the widget; everything else belongs to the merchant. A finding the merchant cannot fix is labelled as such, so they know which ones to take to the vendor and which ones to take to their theme.
Every Criterion, by Name
The report also has a view per WCAG success criterion, and it renders on every plan. It is built from a map of thirty-two names, counted on the day this published: the twenty-four criteria the vendored axe build can report, plus the criteria the manual checks cover. A merchant who wants to know how a page stands against a specific criterion, rather than against a specific rule, reads it there.
The Record
Pro compiles the stored audits and manual checks into a remediation record: dated events, each saying that a finding appeared, changed or cleared, each stamped with the version of the ruleset that measured it, with a plain-text copy for the merchant's own files. Two rules govern it. Not re-checked is not fixed: a finding clears only when a later audit measures the same page and does not find it, so the absence of a run is never read as a clearance. And a clearance on an embedded widget reads as the widget having changed, because the merchant did not change it.
The record is Pro, and it fails closed. If the app cannot confirm the plan, it shows no record rather than a partial one. A free account keeps its audits and its manual check entries; the compiled record is what the subscription produces, and weekly monitoring is what keeps it current without anyone running audits by hand.
What the record is not
It is not a VPAT, not an ACR, not a certificate and not a conformance claim. It is dated evidence of what was found and what changed. No audit, no checklist and no record makes a store compliant, and none of the three says so anywhere in the app. What they do is tell the truth about what was measured, when, and against which ruleset, which is the thing a merchant actually needs when someone asks.
Where This Sits
The argument for measuring a storefront instead of laying a script over it is in AccessGuard versus accessibility overlays, and the reason a free scan can only ask questions about a page it reads from outside is in reading a free scan you did not run. Tuesday's Cited versus asking the AI yourself makes the same case for a different question: a measurement you can repeat beats an impression you cannot. The rest of the shelf is in seven apps and the problem each one was built for.
AccessGuard is on the Shopify App Store, and the plain-language version of what it does is on its page here.