Terms of Service

Version: 2.6
Effective: 30 July 2026
Applies to: readyaudit.dev, the ReadyAudit macOS app, and every audit we perform

In short: You buy a credit, submit a build, and get back a readiness assessment with recorded evidence. Your build is confidential, is never used to train a model, and is deleted when the audit completes — along with the recordings, the source screenshots and any demo credentials. The measurement itself (the Finding rows, the score, the coverage) is kept so a later audit can tell you what changed, and you can have it erased. A 48-hour delivery target is a target, not a guarantee — if we miss it we owe you a credit, not damages. Nothing we produce is a certification or legal advice, and our liability is capped at what you paid for the audit in question.

1. Who these terms are between

These Terms of Service (the Terms) are a contract between Buğra Günay, Erzene Mahallesi, 113/28 Sokak No: 8/4, Bornova, İzmir, Türkiye (we, us), trading as ReadyAudit, and the person or organisation that buys a credit or submits a build (you). They govern the ReadyAudit website at readyaudit.dev, the ReadyAudit macOS application, and every audit we perform.

Your licence to run the macOS application itself is set out separately in the App licence. It is a separate document because it licenses software to you, while these Terms buy you a service; Apple's licensed-application terms also apply to the app in Apple's favour. Where the two disagree about the software, the App licence governs the software; these Terms govern the service.

2. Definitions

These words carry a specific meaning throughout the set of documents.

Submitted Build — the application binary you upload for audit: a simulator .app bundle (as produced by xcodebuild -sdk iphonesimulator), supplied directly or inside a .zip, together with any demo credentials you supply with it. Device-signed .ipa binaries are refused at upload, because a simulator cannot install one.
Device Build — where you enable Device Verification, the device-signed build of the same application, at the same version, that you distribute to us through TestFlight. It is necessarily a different binary from the Submitted Build; you are responsible for the two being built from the same source revision, and the Report records the version and build number of each.
Build — the Submitted Build and, where one exists, the Device Build. Where a clause in these Terms applies to only one of them, it says which.
Device Verification — the optional step in which you invite audits@readyaudit.dev as a tester on Apple's TestFlight and we install your Device Build on a physical device we own, in order to run the checks a simulator cannot reproduce. It carries no additional charge. Where you enable it, the Device Build reaches us through Apple under your own developer account and distribution terms, and you confirm you are entitled to distribute it to us in that way.
Not testable — the verdict recorded for a check we could not perform, including every check that needs a physical device where you have not enabled Device Verification. It is not a neutral outcome: a not-testable check counts against the coverage percentage, which is calculated as the checks we could reach divided by the checks in scope. Declining Device Verification therefore lowers your published coverage rather than hiding the gap, which is the intended behaviour.
Credit — a one-time purchase entitling you to one Audit. Held on our server against your Device Token.
Device Token — the random identifier the macOS app generates on first launch and stores in the macOS Keychain. It carries your credit balance. It is not an account, contains no personal information, and is not linked to your Apple ID.
Audit — one automated and human-reviewed examination of one Build, on one platform, against the Rule Catalog.
Run — a single execution of an agent task against your Build inside an isolated simulator.
Finding — a single issue we assert, with a severity, a rule reference and its supporting Evidence.
Evidence — the screenshot, cropped element, measured value or failure frame that proves a Finding.
Rule Catalog — the versioned set of rules an Audit is run against. The version used is recorded in your Report.
Report — the document we deliver, containing the Findings, the Evidence embedded inside it, the readiness score and the coverage percentage.
Readiness score — a number out of 100 derived from the Findings by a published weighting. It is a summary of what we found, not a grade of your application.
Coverage — the percentage of the checks in scope that we were able to reach, as defined under not testable above. It is published beside the score and never combined with it: a high score at low coverage means we found little because we could see little.
The 60% floor — where coverage falls below 60%, the readiness score is withheld: it is not printed as a number anywhere in the Report or on any surface we publish. You still receive every Finding, every piece of Evidence and the coverage figure itself. A score computed from less than three-fifths of the checks would be quoted as if it meant something, and it does not.
Readiness Assessment — what a Report is: a technical statement about the Build we tested, at the time we tested it, against the Rule Catalog version named in it. See section 4.

3. What the service does

We install your Build on an isolated simulator, drive it through a set of real user tasks, measure what a user with an access need would encounter, and hand back a Report in which every Finding is supported by Evidence. The method has three layers: deterministic measurement, recorded agent runs, and human review of critical Findings.

What a Report can actually contain is set by the Rule Catalog version named in it, not by this section. A rule that is not active in that version produces no Finding and, just as importantly, no pass — it is absent, and the coverage arithmetic in section 2 accounts for what was not measured. The catalog is published, so the extent of what you are buying is checkable before you buy and again against the version stamped on your Report. This section describes the method; the catalog states the extent, and where the two seem to differ the catalog governs.

Runtime Findings pass a reproducibility filter before they are reported: each is attempted three times, the median measurement is the one published, and a Finding that does not reproduce in at least two of three attempts is dropped rather than reported. The filter removes Findings that do not reproduce; it is not, and is not offered as, a guarantee that a Finding which does reproduce is correct. Section 14 states what we can and cannot promise about accuracy.

Findings are mapped to WCAG 2.2 AA success criteria and to EN 301 549 clauses where a mapping exists. That mapping is our editorial judgement about which criterion a Finding relates to. It is not an assertion by any standards body, conformity assessment body or regulator.

4. What the service is not

A Report is a technical readiness assessment. It is not, and must not be represented by you as:

a certification, accreditation or conformity assessment of any kind;
a guarantee, warranty or assurance that your application complies with the European Accessibility Act, EN 301 549, the Americans with Disabilities Act, Section 508, WCAG, or any other law or standard;
legal advice, or a substitute for advice from a qualified lawyer in your jurisdiction;
an accessibility statement, a conformance claim, or a VPAT prepared on your behalf;
a substitute for testing with disabled users, or for review by an accessibility specialist familiar with your product.

We are not a conformity assessment body and we do not hold ourselves out as one. Every Report and every page of this site carries the line Technical readiness assessment — not legal advice.

An Audit examines what the Rule Catalog covers. It does not cover every WCAG success criterion — many criteria require human judgement about content and context that no automated run can supply — and a Report that lists no Findings in an area is not a statement that no issue exists there. The Report names the Rule Catalog version so that you, or anyone reviewing your work, can see exactly what was and was not examined.

5. Who may use the service

The service is intended for businesses, developers and agencies acting in a professional capacity. You must be able to form a binding contract, and if you accept these Terms on behalf of an organisation you confirm you are authorised to bind it.

Where you are a consumer under the mandatory law of your country of residence, nothing in these Terms removes rights that law gives you. Where a clause here conflicts with such a right, the right prevails and the rest of the Terms continue to apply.

6. There are no accounts

ReadyAudit deliberately has no sign-up, no password and no user profile. Your Credit balance is held on our server against your Device Token, which the app generates locally and keeps in your Keychain. The consequences are worth stating plainly, because they cut both ways:

We hold no name, email address or account record against your Credits — only the Device Token and the audits bought with it.
We cannot look up "your account" if you email us. To reach your Credits we need the App Store transaction identifier from your Apple receipt.
If you delete the app, erase the Keychain item or move to a different Mac, the Device Token is gone and the balance it carried is not automatically transferred. Contact info@readyaudit.dev before you do any of these and the transfer is straightforward. Afterwards it depends on your Apple receipt still identifying the purchase; where it does, we will move the balance, and where it does not, we cannot recover Credits we have no way to attribute to you. That is the cost of having no accounts, and we would rather state it than discover it with you.

7. Credits

A Credit is bought through the Mac App Store at $149.99 (Apple is the merchant of record and sets the local price and tax for your storefront). One Credit buys one Audit: one application, one platform. Re-auditing the same application after you have made fixes is a separate Audit and a separate Credit.

Your balance is authoritative on our server, not in the app. The app displays a number; the server decides it. This is what makes the balance survive an app reinstall, and it is also why the app cannot spend a Credit on its own.

A Credit is consumed when we accept your Build and create the Audit — at upload, not on delivery. A Run that then fails does not return it.
What a consumed Credit still buys is more than one attempt. If a Build cannot be installed, opened or driven, you may attach a corrected Build to the same Audit — up to twice, within 72 hours — from the failure screen in the app. Nothing further is charged for those attempts and no Credit is returned.
A failure on our side — our machine, our queue, our tooling — is re-run automatically, costs you none of those two attempts, and is normally not something you see happen.
After the 72 hours, or after both attempts, the Build we were holding is deleted under the retention rules and a further attempt is a new Audit on a new Credit.
If we miss the delivery target for reasons within our control, we add a bonus Credit on the terms in section 8. You do not have to ask.
Credits do not expire, cannot be transferred or resold, and have no cash value.

Credits are not a refund instrument. Refunds are Apple's decision and are covered in the Refunds & purchases policy, which forms part of these Terms.

8. Delivery target, and what it obliges us to do

We publish a delivery target of 48 hours. What that does and does not oblige us to do:

The clock starts when we accept a Build for audit — not when you begin the upload — and stops when the Report is delivered.
Time spent waiting on you (working demo credentials, a build that installs, an answer to a question that blocks the Run) does not count against it.
It is a target, not a guarantee, and it is not a deadline of the kind that makes time of the essence.

Your remedy if we miss it. If we exceed the target for reasons within our control, we add a bonus Credit to your balance. If we exceed it by more than seven days for reasons within our control and you no longer want the Audit, you may withdraw the Build before delivery. A Credit is consumed when we accept the Build (section 7), so withdrawing does not un-spend it — what leaves you whole is the bonus Credit above, which was already added when we missed the target, stays in your balance when you withdraw, and buys the Audit you no longer want us to finish. Those are the remedies; the delivery target does not give rise to a claim for damages, service credits beyond the above, or loss of profits.

9. What you must provide, and what you promise

By submitting a Build you represent and warrant that:

you own the application or are authorised by its owner to have it tested;
you have the right to give us any demo credentials you supply, and those credentials belong to a disposable test account containing no real customer data;
the Build contains no personal data of third parties, no live production data, no payment instruments and no unlawful content;
you will not supply credentials to a production environment or to any system where an automated Run could cause loss to you or anyone else.

Our agent drives your application the way a user would: it taps controls, fills fields and submits forms. If you give us a live environment, it will do those things in that live environment. Use a test build with test data.

10. Your build is confidential

Your Build, its contents, and everything we observe while running it are your confidential information. We process them for the sole purpose of producing your Report. We do not share, disclose, publish, redistribute, sell or licence your Build or its contents to any third party, and we do not use your Build or its contents to train, fine-tune or evaluate any machine learning model. The agent that drives your application runs on a commercial API tier under terms that prohibit training on submitted content, not on a consumer subscription.

The Submitted Build is deleted when the Audit completes (audit_completed), and the exact UTC deletion time is stamped into your Report. Where Device Verification was used, the Device Build is removed from the physical device at the same point; the TestFlight distribution itself is yours to revoke, since it sits in your developer account rather than ours. A failed Run holds the Submitted Build for the 72-hour retry window and it is then deleted the same way. Demo credentials live only for the length of the Run and are never written to logs or telemetry. They are held in the job record, which is encrypted before it reaches the disk under a key belonging to that Run alone. What that protection does and does not cover — in particular that the master key sits on the same host as the data it unlocks — is stated in full in the Privacy Policy. Screen recordings are destroyed with the Build; the screenshots and the single frame from the moment a task failed are embedded in the Report, which is the only copy in existence — we keep none, which also means we cannot re-issue your Evidence if you lose the Report.

What we keep is the measurement, not the evidence. The two are different things and we state them separately rather than letting the sentence above be read as "nothing survives". Destroyed with the Run: build binary, screen recordings, screenshot originals, demo credentials, notification email address. Retained after the Run: normalized finding rows, score, coverage, audit metadata, audit id. That record is what allows a later Audit of the same application to tell you which Findings you fixed and which are new, and it is the record the benchmark clause in section 12 aggregates. It contains none of the following: screenshots, video frames, element text, accessibility labels, credentials, build bytes, and any pointer that could retrieve a destroyed artifact. It is linked to your Audit and your Device Token, so it is pseudonymous, not anonymous; you may have it erased at any time (see the Privacy Policy).

The operational detail behind each of these statements is on the Security page; who processes what, and where, is in Sub-processors.

11. Intellectual property

Yours stays yours. Your Build, your application, your brand and everything in them remain your property. Nothing here transfers any right in them to us beyond the limited licence in section 12.

Ours stays ours. The Rule Catalog, the audit method, the report format and templates, the ReadyAudit name, mark and site content are our property. Buying an Audit does not licence any of them.

Your Report. On delivery you receive a perpetual, worldwide, irrevocable, royalty-free licence to use, copy and distribute your Report for any purpose connected with your business — including giving it to your client, your auditor, your insurer, a regulator or a court. You may not resell the Report as a standalone product, present it as your own work product, or remove the readiness-assessment disclaimer from it.

12. The licence you give us, and how to switch it off

You grant us a limited, non-exclusive licence to store, install, execute, record and analyse your Build strictly to perform your Audit, for as long as the retention rules in section 10 allow, and for no other purpose.

Benchmarks. From the retained Finding record described in section 10 we derive a separate, one-way projection with the link to your Audit and Device Token stripped, and it is only that projection we aggregate into category benchmarks and research. What that supports is rates, not measurements — for example, "62% of the banking apps we audited failed the minimum tap-target rule". It cannot support a median tap size in points, because no measured value survives the Run: the retained fields are the rule, the verdict, the severity and the run's context, and nothing else. The distinction matters and we will not blur it: the stored record is pseudonymous, the benchmark projection is de-identified, and the projection cannot be reversed to identify your application. No individual customer, application, Build or Finding is ever published in identifiable form.

If you would rather your Findings were never benchmarked, email info@readyaudit.dev with your transaction identifier before the Audit and the record is flagged so no projection is ever derived from it. Asking afterwards removes your record from every future projection — and you may have the record erased entirely under the Privacy Policy — but an aggregate we have already computed cannot be recomputed without you, because the projection is one-way and we no longer know which rows were yours. We will not claim otherwise to make the clause read better. There is no charge and no consequence for opting out either way.

13. Acceptable use

You may not:

submit an application you do not own and are not authorised to have tested;
use the service to test, probe or attack a system you do not control;
attempt to identify another customer, their application or their Findings;
represent a Report as a certification, a compliance guarantee or legal advice, or alter a Report so that it reads as one;
reverse engineer, scrape or systematically extract the Rule Catalog in order to reproduce it;
resell Audits as your own service without a written agreement with us;
interfere with the service, circumvent the Credit system, or access it by any means other than the app.

We may suspend or refuse an Audit that we reasonably believe breaches this section. Where we refuse a Build before accepting it, no Credit is taken. Where we stop an Audit we had already accepted, the Credit was consumed at acceptance (section 7) and we do not return it.

14. Accuracy, and the limits of it

We work to a no-false-positive standard: a Finding is meant to be something you can reproduce and act on, and the filter in section 3 drops anything that does not reproduce in at least two of three attempts. That filter removes intermittent results. It does not, and cannot, catch a wrong judgement that reproduces consistently. So we do not promise that every Finding is correct, that every issue in your application was found, or that a Finding will reproduce on hardware, an OS version or a device configuration different from the one recorded in your Report.

Simulator behaviour is not identical to device behaviour. Assistive technology behaviour — VoiceOver in particular — can differ between a simulator and a physical device. An Audit reflects the Build we tested, at the time we tested it, against the Rule Catalog version named in the Report, and nothing beyond that.

If you believe a Finding is wrong, tell us. Reply to the report email or write to info@readyaudit.dev with the Finding identifier, and send back the Report itself where you can — it holds the only surviving Evidence, because the recordings and the original screenshots are destroyed when the Audit completes. If we agree a Finding is wrong we will issue a corrected Report: withdrawing or amending the Finding, restating the score and coverage, and noting what changed and why. What we cannot do after deletion is produce fresh Evidence for the same Run — re-testing means a new Run against the Build as it is then, and we will say so rather than presenting it as the same Audit. Where the error is material we add a Credit.

15. Third parties

Purchases are processed by Apple, under Apple's terms, and Apple is the merchant of record. Parts of the service run on infrastructure operated by the providers listed in Sub-processors. We remain responsible to you for the service; we are not responsible for the availability of Apple's services or of a third-party site we link to.

16. Disclaimer of warranties

Except as expressly stated in these Terms, and to the maximum extent permitted by law, the service and every Report are provided "as is" and "as available", without warranty of any kind, whether express, implied or statutory, including any implied warranty of merchantability, fitness for a particular purpose, non-infringement, or that the service will be uninterrupted or error-free.

Nothing in this section limits a warranty that cannot lawfully be excluded, including consumer guarantees under the mandatory law of your country of residence.

17. Limitation of liability

To the maximum extent permitted by law, and except for the matters in the paragraph immediately below:

our total aggregate liability arising out of or in connection with an Audit is limited to the price charged for the Credit spent on that Audit — measured by what you were charged in your storefront, whether that payment was collected by us or by Apple as merchant of record;
our total aggregate liability arising out of or in connection with the service as a whole, in any twelve-month period, is limited to the total price charged to you for Credits in that period, measured the same way, and is in any event not less than the price of one Credit;
we are not liable for indirect, incidental, special, punitive or consequential loss; loss of profit, revenue, business, goodwill or anticipated savings; loss or corruption of data; or for any fine, penalty, damages award or legal cost imposed on you by a regulator, court or counterparty, whether or not connected to the accessibility of your application.

What we never exclude. Nothing in these Terms limits or excludes liability for death or personal injury caused by negligence, for fraud or fraudulent misrepresentation, for wilful misconduct, or for any other liability that cannot lawfully be limited or excluded.

Read together with section 4, this is the allocation of risk you are agreeing to: an Audit is evidence you can act on, and the decision about whether your application meets a legal obligation — and the consequences of that decision — remain yours and your advisers'.

18. Indemnity

You will indemnify us against claims, losses and reasonable legal costs arising from a Build you submitted that you were not authorised to have tested, from third-party personal data or unlawful content contained in a Build, or from your use of a Report in breach of section 13.

19. Suspension and termination

You may stop using the service at any time; deleting the app is enough. We may suspend or terminate access where you breach these Terms, where required by law, or where continuing would expose us or another customer to material risk. Sections 10, 11, 14, 16, 17, 18, 21, 22 and 23 survive termination — section 22 in particular, because a governing-law clause that dies with the contract leaves a dispute about the contract with no forum.

Credits you have already paid for are your property and we do not forfeit them. If we terminate for convenience, or you stop using the service, your unconsumed Credits remain redeemable, and where redemption is no longer possible we will refund their price through the process in the Refunds & purchases policy. If we terminate for your material breach we may decline to perform further Audits for you, and we will refund the price of any unconsumed Credit rather than keep both the money and the work. This does not affect any claim we have against you for the breach itself.

20. Events outside our control

We are not liable for a failure or delay caused by an event beyond our reasonable control, including a failure of Apple's services, of a sub-processor, of network infrastructure, or an OS or tooling change that prevents Runs from completing. Where such an event prevents delivery, the Run has failed on our side: it is requeued automatically and costs you none of your attempts under section 7, and where it also puts us past the delivery target, the bonus Credit in section 8 applies. The Credit spent on the Audit itself is not returned — section 7 says when it is taken, and we would rather repeat that here than imply an exception we do not operate.

21. Changes to these Terms

We may update these Terms. The version number and effective date at the top of this page change with them, and the previous version is available on request from info@readyaudit.dev. A material change is announced in the app before it takes effect. The Terms that govern an Audit are the ones in force when we accepted the Build for that Audit — deliberately not the moment the Credit is consumed, which section 7 puts at delivery, because that would let a change published while your Audit was running apply to it. A later change does not apply retroactively to work already commissioned.

22. Governing law and disputes

These Terms are governed by the law of Türkiye, and the courts of Türkiye have jurisdiction. If you are a consumer, this does not deprive you of the protection of the mandatory law of your country of residence, and you may bring proceedings there.

Before starting proceedings, please write to info@readyaudit.dev and give us thirty days to resolve the matter. Most disputes about a Report turn out to be disputes about a single Finding, which section 14 is designed to handle. That route is offered, not required, and nothing in this paragraph is a condition of bringing a claim or affects any time limit that applies to one.

23. General

Entire agreement. These Terms, together with the App licence, the Privacy Policy, the Refunds & purchases policy and the Sub-processors list, are the whole agreement between us about the service.
Severability. If a provision is unenforceable, the rest continues in force.
No waiver. Not enforcing a provision once does not waive it.
Assignment. You may not assign these Terms without our consent. We may assign them to a successor of our business, on notice.
Notices. Legal notices to us go to info@readyaudit.dev and to the registered address above. Notices to you go to the address you used to contact us, or through the app.
Language. These Terms are drafted in English. A translation is provided for convenience only; the English version governs.

Contact

Buğra Günay, Erzene Mahallesi, 113/28 Sokak No: 8/4, Bornova, İzmir, Türkiye.

One address handles everything — legal notices, privacy and data subject requests, support, security disclosure and accessibility feedback: info@readyaudit.dev. Put the subject in the first line and it reaches the right person.