Answered once, in one place

No. It is a technical readiness assessment — a measured, reproducible view of where your app stands against WCAG 2.2 and EN 301 549. It is not legal advice, and we never claim certification.

How the assessment is produced

Those are excellent for a web DOM. They cannot install and drive your iOS app, turn on VoiceOver, or record a checkout that traps a screen-reader user. Closing that gap is what this product is built around. What ships today is the deterministic layer — 14 rules measured against the accessibility tree your build exposes — plus 7 task rules a person runs on a physical device with VoiceOver on and the screen recorded. The report names the method behind every row, so you always know which one you are reading, and a row nobody measured says so instead of passing.

The honest comparison table

An audit covers the screens an automated crawl reaches from a cold launch: onboarding, sign-in where you hand over demo credentials, the primary tasks and the conversion flow. It stops at a fixed ceiling rather than walking forever, and the report prints how many screens it reached, how many paths it left unexplored, and the reason behind every screen it could not assess. On the apps we have measured that has been eight to fifteen screens. If your app needs more than one crawl can carry, write to us before you buy rather than after.

How the crawl decides where to go

iOS today, and only iOS. A web add-on is planned for v2 — the same task-driven approach, not a static scanner. Android is not scheduled, and we would rather leave it off the page than list it as coming.

$149.99 for one audit, once. No subscription, and no account: you buy the credit inside the Mac app through the Mac App Store, and the app on that Mac holds it. There is nothing to sign up for and no password to lose.

What a credit buys

A credit is not a refund instrument, and a failed run does not put it back in your balance. What it buys instead is another go: if the build cannot be opened you attach a fixed one to the same audit, up to twice within 72 hours, and on delay you get a bonus credit — so you are covered without a chargeback.

Refund and credit policy

One app on one platform. Re-auditing after a fix is a separate credit.

Not yet. The app ships selling one thing — the audit credit. CI Monthly and Agency are planned, and we would rather list them as planned than take a subscription for a cadence we cannot yet guarantee.

Yes. Purchases run through the Mac App Store, so Apple handles invoicing and EU VAT as the merchant of record.

Terms of sale

One artifact: your app built for the iOS Simulator and zipped — what xcodebuild -sdk iphonesimulator produces, not an .ipa. The app shows you the command and refuses the wrong file type in front of you, not two days later. If you would rather run one thing than assemble two, our packaging script is public on GitHub as readyaudit-package: about a hundred lines of bash, MIT, no network calls, meant to be read before it is run.

No. A simulator build and nothing else — no repository access and no signing certificate. No TestFlight seat is needed for the simulator pass; a TestFlight invite is optional and unlocks only the device pass. The honest limit of that: we can name the screen and the element that failed and show you the measurement, but we cannot point at the line in your code. In practice that is a few seconds of your developer’s time, and it is the reason we never have to be trusted with a repository.

What we hold and for how long

You attach a fixed one to the same audit — up to twice, within 72 hours, at no further cost. Being straight about the other half: the credit is spent when we accept the build, and a failed run does not return it, so what we give you is the attempts rather than a refund we have no mechanism to make. Failures on our side are re-run automatically and do not use up those attempts.

Refund and credit policy

You can hand over demo credentials with the audit. They go to the run in a file it reads and deletes, never through a log. Demo credentials live until this run reaches a terminal state — a delivered report or a failed run — and never longer than 72 hours. They do not enter the window the build is held for. If you would rather not, nothing breaks: the screens behind the login are published as not testable, with the reason written out, and never as a pass.

How credentials are handled

The target is 48 hours from the moment we accept your build. If we miss it, a bonus credit lands in your balance automatically — you do not have to ask for it and you do not have to prove anything. The only time that stops the clock is time we spend waiting on you, such as a failed build you have not re-attached yet.

What happens when we are late

Not in this version, and the reason is the product. We compute a 0-100 score on every audit and we do not print it, because we cannot yet explain in one sentence what a given number means: a deeper crawl reaches more screens, finds more, and lowers the score — so a better audit reads as a worse app, and a customer would be right to distrust that. What the report leads with instead is what was found and how much was reached: the finding count, the severity mix (critical, major, minor) and the coverage percentage, each one a row you can open. The score keeps accumulating against real audits, and it comes back to the front page only when it is calibrated and defensible — not before. Coverage below 60% is called out for the same reason: a summary drawn from less than three-fifths of the checks gets quoted as though it meant something.

What a report leads with

Because some checks could not be run, and we publish that instead of quietly dropping them. Every check lands on one of four verdicts: pass, fail, not applicable, not testable. Only "not testable" lowers coverage — a check that does not apply to your app is not a hole in the measurement, and treating it as one would punish you for what you did not build. Every non-pass row carries a written reason, and where we know it, what would unlock the check next time.

The four verdicts in full

Anyone holding the link, on purpose. The report URL is the credential — the id in it is 122 random bits, there is no account to sign into and no endpoint that lists audits. That is what lets you forward a report to a developer, a client or a colleague without us issuing anybody anything. The other half of the deal: treat the link like a password, because it is one.

Why the link is the key

Write to us with the finding id. Every finding carries the measurement that produced it, so a disagreement is almost never about what was observed — it is about whether the rule reads it correctly, which is a conversation worth having and one we publish the outcome of in the rule catalog. We will fix a rule that is wrong. We will not delete a finding because it is inconvenient.

Get in touch

Four questions on the exemption checker — sector, EU sales, headcount, turnover. Article 2(2) is a closed list of services rather than a catch-all, and micro-enterprises providing services are exempt outright, so "the Act does not reach you" is a real answer and one the page gives. An audit is still worth buying on quality grounds; it is not worth buying on a rule you are not subject to.

Am I exempt?

They run on isolated simulators. Your build and the run's recordings are kept for 14 days after your report is delivered — for free re-runs and support, nothing else — and are then destroyed automatically. You can have them destroyed sooner at any time, and every destruction produces a signed record you can check. The visual evidence is embedded in the report itself, and once the window closes we keep no copy of it. What we do keep is the measurement: the finding rows, the score and the coverage. That is what lets a later audit tell you which findings you fixed, and it is linked to your audit, so it is pseudonymous rather than anonymous. Only the benchmark projection is de-identified, and you can have either the benchmark inclusion or the whole record dropped by asking.

Privacy policy

Because the deletion is signed, not asserted. When your build goes — at the end of the window, or the moment you press delete — the server signs a record carrying the audit id, the digest of the build itself, the UTC time and the reason. The app shows it, and `readyaudit-package verify-deletion` checks the signature on your machine against the public key we publish, with no network call and no account. There is deliberately no confirmation email: sending one would mean keeping your address for the length of the window, which is exactly what the rest of this policy refuses to do.

The deletion key

Yes, from the audit's own screen in the app, and it takes effect immediately — the same code path as the automatic deletion, with the same signed record handed back. That is what makes the 14-day window a window and not a condition of purchase. The one thing it does not do is buy back the free re-run: with no build on our side, a second run means a new upload.

What we keep, and for how long