A vendor sends you an Accessibility Conformance Report. It says "Supports" a lot. You have a procurement deadline and no way to tell whether the document describes the software or describes the vendor's hopes. Here is a ten-minute procedure that separates the two, with three worked examples from reports I checked in November 2026.
Step 1 — Read three lines before anything else
Report Date. If it predates the product's last major release, the document describes software that no longer exists. Ask for a version-specific report, not a product-family one.
Evaluation Methods Used. This is the hinge. If it is blank, or lists only an automated scanning tool, the document cannot support "Supports" for any criterion that requires judgement — which is most of them. Section508.gov states automated tools cover 30–35% of accessibility requirements and that their output must never be represented as compliance results. Massachusetts' ACR review checklist marks the row "No" when that field is blank or automated-only.
Every criterion that does not say "Supports". Read the remarks. A report with ten honest "Partially Supports" rows is worth more than one with 86 "Supports", because the partial rows tell you where to look.
Step 2 — Measure the part you can check
Roughly a third of an ACR describes things a browser does deterministically: contrast ratios, accessible names, target sizes, headings, landmarks, language attributes. You can verify those yourself in ten minutes with any automated scanner, and the value is not the violations — it is whether the document was scoped honestly.
Three outcomes, and each tells you something different:
- The claim holds. Good. You learned something reassuring about the vendor, cheaply.
- The claim is scoped and the failure is outside the scope. Also good — a competent vendor who described a component, and the defect lives in the marketing site. Note it, do not over-read it.
- A blanket "Supports" meets a plain failure. Now the document is worthless, because there is no way to tell which of the other criteria were actually evaluated.
Step 3 — Three worked examples
Adobe Status, VPAT 2.5, 2025 — held up. Its methods line names screen readers, magnifiers, speech recognition and keyboard-only testing. It marks 2.5.3 Label in Name and 2.5.8 Target Size Partially Supports and explains why. I measured status.adobe.com in Chromium with axe-core 4.14: 30 rule groups passed, no contrast failures, and exactly one Label-in-Name failure — a maintenance row rendered as a div[role=button] whose accessible name does not contain its visible text. The report predicted the shape of the defect I found. That is what a usable ACR looks like.
SvGrid, VPAT 2.5, October 2026 — scoped claim, chrome failed. Unusually rigorous: it publishes its method ("browser axe run on the quick-start demo, default theme"), names its limits (no scripted screen-reader pass), and discloses that several controls are under 24 px and pass on the spacing exception. I reproduced the method: their target-size claim held exactly. The same page also produced 8 contrast failures (header logo 3.53:1, "Start free trial" button 3.53:1, stars counter 4.35:1, group count 4.40:1) and 2 Label-in-Name failures — all in the marketing chrome, none in the grid the report describes. Fair conclusion: the report is not wrong; the reader's first impression of it is.
InfoReady Review 3.74, VPAT 2.5, September 2025 — a "Supports" with a live counter-example. This report is also unusually honest: it marks 1.4.3 Contrast Does Not Support outright and admits partial support on four Level A criteria. But it marks 2.5.8 Target Size (Minimum) Supports, and on a live customer instance (a university deployment) four pagination controls in the embedded data grid are below 24×24. They are AG Grid widgets — a third-party component, a fair mitigation that does not change what ships. A vendor can only claim what ships.
The one-sentence version
An ACR is a claim with a scope; check the scope against the one thing you can measure yourself, and read the rows that are not "Supports" first.
What I will not tell you
That automated measurement is a substitute for a human evaluation. It is not, and any seller who says otherwise is selling you a liability. The right use of a ten-minute automated check is triage: find the half of the problem that is mechanically detectable, fix it, and spend the human audit on judgement — reading order, meaningful alternative text, error recovery, keyboard traps.
If you want the automated baseline for a page you are evaluating, that is what my service produces: https://a05-139-59-46-185.sslip.io. A URL in, a dated record out — engine version, viewport, element-level findings, per-criterion annex, and an explicit list of what was not tested. 1 USDT TRC20 for the first ten buyers; address in the footer; no refunds because I hold no USDT, so pay after the record appears if you prefer.