A feature can work and still leave people stuck.
Start with a free check of your public pages.
Free and private. It reviews accessibility on your public pages. It doesn’t sign in, submit forms or publish anything. Reviews of signed-in tasks come with paid plans.
An invitation that seems to vanish. A message a screen reader never hears. Variantly tries your product’s important tasks in a browser, from the perspective you describe, and keeps every screen. Usability and accessibility findings sit on the same evidence, and a person decides what to act on.
Proposed from the screens kept for the send step. It waits for a person’s decision. Select to open the evidence.
The message is added outside a live region, so a screen reader isn’t told the invitation went out. Select to open the evidence.
- Decision
- Not made yet
- Recheck
- Not run
f. 2The record
Follow one task from what you meant to what happened.
You describe the task and how you’d know it worked. An attempt tries it from the perspective you describe. Each finding keeps the screens it rests on, a person’s decision and a recheck after a change. In the product this is called a task review.
Static version: all five parts of the record, in reading order.
1 · The intended result
- The task
- Invite a teammate with the right access.
- Who is trying
- New administratorFirst week with the product· assumedSigns in as admin· test account
- How you’d know it worked
- “sam@demo-target.test” appears in “Invitations waiting for a reply”.Checks: words appear in a list on screen. Doesn’t check: that the email arrives.
2 · What the attempt did
“Invitations waiting for a reply” check: seen in 2 of 2 attempts as New administrator.
- 01Opened Team.
- 02Typed sam@demo-target.test into Email address.
- 03Left Role as Member.
- 04Pressed Send invitation.
- 05Saw “Invitation sent to sam@demo-target.test.”Flagged: a finding rests on this step.
- 06On the next screen, the message was gone.Flagged: a finding rests on this step.
- 07Reloaded. The invitation is listed as Pending.
Attempts are counted, never averaged. The task completed; the feedback along the way is what the findings are about.
3 · The evidence kept for step 5
<div id="invite-flash" class="ok"> Invitation sent to sam@demo-target.test. </div> <!-- removed after 3000 ms; no role="status" -->
button, Send invitation (page loads) heading level 1, Team: Ledgerly demo — no announcement of the confirmation —
Each step keeps its screenshot, accessibility tree, focus trace and virtual screen-reader transcript. Both findings link here.
4 · A person’s decision
A person decides each usability finding with its evidence open, and says why. The choices are:
The accessibility finding comes from rule checks and isn’t decided here. A usability decision never sets a report row.
5 · Follow-up after a change
A recheck tries the same condition again, with the same perspective and test account, and keeps the original record beside the new one.
- Seen
- The condition appeared again.
- Not seen
- It didn’t appear on the same path.
- Couldn’t tell
- The evidence doesn’t settle it.
- Not checked
- The attempt stopped first.
This example has no recheck yet. A recheck shows how the interface behaves after the change. Whether people understand it needs research with people.
f. 3Key to the marks
Every statement carries its mark.
A rule, the AI and a person say different things about the same screen. Each kind keeps its own mark wherever a finding appears, and so does what nobody has established.
f. 4Index
Where the record goes.
- A task reviewIn your workspace
Findings for one task, in counts, with what the review didn’t cover. Each finding opens to its screens. Read an example review.
- A brief for engineersPaste into a ticket
The finding, evidence links, the proposed change and the recheck condition, written for a person or a coding agent.
- An accessibility conformance reportWhen a buyer asks
An ACR in VPAT® 2.5 and OpenACR formats, scoped and dated, on a public permalink. Its rows come from full-coverage scans, never from task-review findings.
f. 5Schedule of fees
Start free. Pay for tasks, sign-in and reports.
Every paid plan includes task reviews and the accessibility report. An attempt is one try at a task from one perspective.
- Free checkFree
Accessibility results for your public pages, private to you.
- ACR package$799once
One product for twelve months: signed-in areas, 5 key workflows, 10 task-review attempts with the purchase, monthly re-checks, VPAT® 2.5 and OpenACR.
- Starter$2,400a year
Everything in the package, ongoing: nightly re-checks and 40 task-review attempts a month.
- Team$7,200a year
Five products, 25 key workflows each, nightly re-checks and 200 task-review attempts a month, shared by its products.
- sign in
- submit forms
- attempt tasks
- publish a report
Colophon
Built by
Adam Stankiewicz
Founder and builder
Adam works across product engineering, design systems and accessibility. He has led accessibility and design-system work on education products, including seven years leading an open-source design system for an online learning platform. His research background spans human–computer interaction (HCI), computer-supported cooperative work (CSCW) and learning at scale.
Questions, feedback and corrections are welcome. Write to adam@variantly.app
- Set in
- Charis SIL and Geist
- Standard
- Built to WCAG 2.2 AA. If you find a failure on this page, it is ours to print.
- Evidence on this page
- Redrawn from Variantly’s demo target. An illustration; no review ran.
- Access and data
- How we handle product access and evidence
Variantly · Your frontend, on the record. VPAT® is a registered trademark of ITI. An ACR documents conformance on a date; it is not a certification.