How an audit is actually run
For the person running the audit — the method, the workbench, the machine pass — and for the client reading what they bought. The deliverable is a document a developer acts on in a day.
What Qiksy Access is
An accessibility audit as a service: the deliverable is a document a developer can act on in a day — not a scanner licence, not an overlay.
A client orders an audit of their live store or app. The auditor runs it with Qiksy’s own toolchain — the QA Copilot extension driving the real page, including the states behind login — assembles the findings in the workbench inside Qiksy Studio, and hands back three artefacts: an HTML report, a CSV for the client’s tracker, and an AI fix prompt their coding agent can execute directly.
The report’s core argument is the fix map: most failures share a handful of sources — one design token used everywhere, one component repeated on every page. “Fix 6 components and 3 tokens and 312 of 400 findings disappear” is what the client pays for; four hundred unsorted rows is what they get everywhere else.
| SKU | Price | What it is |
|---|---|---|
| Free scan | $0 | 3 public URLs, top-5 issue types with counts — the outbound door-opener |
| Access Report | $1,500 | Up to 25 states (8 behind login), WCAG 2.1 AA, automated + manual review |
| Fix Pack | $2,400 | Exact before/after per issue + one re-run within 60 days |
| Remediation | $4,000–8,000 | We apply the fixes ourselves — scoped per project |
| Access Watch | $3,900/yr | Monthly re-runs, diff report, regression alerts; no auto-renew |
The pipeline, end to end
One audit is 8–14 hours. The machine covers the breadth; the human judges what machines cannot.
- 1Intake (0.5h). The client sends the key scenarios, a test card / 100% discount code, and either a test account or opens the logged-in states themselves. Freeze the state list in the SOW — the scope is states, not pages.
- 2Recipes (0.5h). Walk login and checkout once; save them as recipes so every later state opens in one call per step.
- 3Machine pass (2.5–3h). Run the state list with the extension: full accessibility tree with geometry, WCAG AA contrast with exact ratios, computed styles with the design token every colour came from, keyboard presses answered with diffs. The exact call sequences per state live in RUN-PLAYBOOK.md.
- 4Roll-up (1h). Group findings by token and component — this is where 400 rows become 9 sources. The workbench computes the fix map live as findings land.
- 5Manual block (2.5–3h). The fixed keyboard route across 8 key states, forms three ways (empty / one bad field / success), alt-text triage, a 20-minute VoiceOver spot check. Protocolised in METHOD §4 — judgement, not wandering.
- 6Assembly (2–3h). Export the report skeleton from the workbench — verdict, fix maps and register are filled in; finish the business summary and manual observations by hand. Ship report + CSV + AI prompt.
The workbench, tab by tab
The auditor’s working notes live in the browser — no backend, no account, nothing leaves the machine.
States
Every audit starts with the canonical 42-state Shopify pack laid out for the run. A state is route × viewport × open layer × data condition × validation condition — “cart” is four states. Base scope is 25: mark the out-of-scope ones n/a rather than deleting them, so the report’s scope appendix stays honest. “390” marks the states the method also runs at mobile width.
Findings
Two fields ARE the fix map: component (the theme file the defect lives in) and token (the CSS variable it comes from). Fill them and hundreds of rows fold into a handful of sources. Numbers (A-007) are stable — deleting a finding never renumbers a CSV the client already has. Datalists offer the WCAG criteria and this audit’s own components and tokens, so one typo cannot split the fix map in two.
Fix map
Computed live from the findings: which sources close how many weighted findings (a finding counts once per state it occurs in). The verdict banner is the same number the exported report leads with — one computation, two surfaces, no way to disagree.
Export
Three artefacts: the HTML report (the deliverable skeleton with this audit’s real numbers — finish the prose before it leaves the house), the CSV (one row per finding, for their tracker), and the AI fix prompt — selectors, before/after and acceptance criteria wrapped in rules an agent can follow: fix only what is listed, change a token once, remove nothing, report fixed / needs-human per finding. The readiness list above the buttons names the holes (states not run, findings without fixes) but never locks the door — a draft skeleton is a legitimate artefact.
The published method, in brief
The full text is METHOD.md and it is quoted in every SOW. Anything not described there was not tested.
| Mark | Meaning |
|---|---|
| AUTO | the toolchain decides it — a human only reads the result |
| SEMI | the machine produces the evidence, a human makes the call |
| MANUAL | human only — alt quality, reading order, error recovery |
| NOT | outside what this method can see — declared as a limit, never as a pass |
Tested against WCAG 2.1 Level AA — the standard EN 301 549 points at, which is what the European Accessibility Act enforces. WCAG 2.2 additions are reported on top as improvements; two of them are geometry questions our snapshot answers mechanically — 2.4.11 Focus Not Obscured and 2.5.8 Target Size — and almost nobody else reports them.
- Never marked as “pass”: 1.1.1 (alt quality), 1.2.x, 1.4.5, 2.2.x, 2.3.1, 2.5.7, 3.2.x, 3.3.7, 3.3.8.
- No raster: text over photographs and gradients is not confirmed; shadows are not judged.
- Third-party iframes are inventoried, not entered — payment fields, maps, players; the report says what ACR to request from each vendor.
- CAPTCHA-guarded flows are not assessed; we read the accessibility tree, not the behaviour of a specific screen reader — the VoiceOver pass is a spot check and is named as one.
Running audits as a partner
The workbench is open to registered Qiksy partners: run the audit, hand the client the report, bring the fixes to us.
The partner model: you run the machine pass and assemble the report with this exact toolchain — the method, the state pack and the report generator keep the deliverable to one standard. The client then needs someone to fix what the report names, and that is the referral: Fix Pack and Remediation close through Qiksy, on the Earn lead split — finder 10% of the deal, full cycle 20%.
- The profile that works: an accessibility-literate QA — HTML/ARIA reading, keyboard habits, a screen reader at “walk a checkout” level. Not a developer.
- Partner materials — the phrase library and the run playbook — come with onboarding; they are not on this public page.
- White-label terms for agencies exist (wholesale audit, your invoice to your client) — ask via Earn.
- Non-negotiables: the banned-words rule, the automated/manual marks, not-covered ≠ pass, and the report generator’s own numbers — a report that says something the toolchain did not measure is not an Access report.
What you receive, and what to do with it
You do not install anything, and your site is not modified. You get a document your developer acts on.
- 1Read the one-page business summary — what a customer with a disability cannot do on your store today, and which of those steps sit between them and a completed order.
- 2Hand the fix map to your developer: tokens first (one change closes dozens of findings), then components. Each finding carries the exact before/after and an acceptance criterion.
- 3If your developer works with an AI coding agent, give them the AI fix prompt — it is the same findings, phrased so an agent can execute and verify them one by one.
- 4After the fixes, the included re-run confirms the delta — “was 400, now 38” — in writing.
- 5Accessibility decays with every release. That is what Access Watch is for: monthly re-runs, a diff, and an alert when a release regresses something. Invoiced ahead, no auto-renew, no stored card.