Live verification
A fix that was applied is not the same as a fix that worked. After every approval a second scan re-measures your live page. If that re-check cannot finish, the improvement figure is suppressed rather than estimated.
- Before and after, measured on the live page
- A number only when it is real
- Caught a page that a fix made worse
Why it matters
Why verification is the honest part.
Measured, not estimated
The improvement figure comes from scanning your live page again after the fix. It is not a prediction based on what the fix was supposed to do.
It catches the bad pass
On one store the first pass made a page worse. Verification is what found it. Without that second scan, nobody would have known.
Silence beats a guess
If the re-check cannot finish, no improvement number is shown at all. An unverified figure is worse than none.
New problems get flagged
If the re-check finds something that was not there before, it is raised as a finding instead of being absorbed into the score.
Every check is dated
Verifications land in the evidence pack alongside the scans and fixes, which is what makes the record worth showing.
On the real page, not a copy
Verification runs against your live URL, so it sees your caching, your plugins and your theme as visitors do.
How it works
Three steps, no vocabulary to learn.
On a real WordPress install the measured result was a score of 66 rising to 82, with serious problems falling from 58 to 14. On one store the first pass made a page worse; verification caught it before anyone else did.
You approve a fix
The rule is applied where your platform allows: server-side on WordPress, in the browser elsewhere.
A second scan runs against the live page
Not a simulation of the fix: the actual page your visitors receive, read the same way the first scan read it.
The dashboard shows the measured change
The before and after for that problem, on that page. If the re-check is incomplete, you see “not verified” instead of a guessed improvement.
See a fix proven, not promised.
The free check shows you the problems. Verification is what shows the fixes worked.
What happens after you approve.
The interesting part of an accessibility tool is not what it claims to have fixed. It is what it does when the fix did not work.
The number you see was measured twice.
Before and after are both real scans of your live page. The gap between them is the improvement, and it is only shown when the second scan actually completed.
- Both figures are measurements
- No figure when the re-check fails
- Runs against your live URL
A fix that makes things worse gets caught.
Deterministic rules are safe in general, not in every case. Verification exists because “usually correct” is not good enough when it is running on a real storefront.
- A regression is flagged, not shipped
- Switch the fix off to restore the original
- Attributes and CSS only, so damage is bounded
Each verification is dated in the record.
A verified fix is worth more than an applied one when a complaint arrives, because the record shows what changed, when, and that someone measured the result.
- Dated and printable
- Sits beside the scans and manual checks
- Nothing is back-dated or edited
Frequently asked questions
About live verification. The product-wide questions are on the features page.
Why would a re-check fail to finish?
A page can time out, block the scanner, or change between scans. In those cases the honest answer is “unknown”, so that is what the dashboard says.
Does verification go into the evidence pack?
Yes. Every verification is a dated entry alongside the scan and the fix it checked.
Start fixing your site today. Free.
Five pages, every problem ranked by risk, in plain English — before a lawsuit-hunting scan finds them first.
- Free 5-page check
- No credit card
- 14-day money-back guarantee