Accessibility Statement

Version: 2.6
Effective: 30 July 2026
Applies to: readyaudit.dev · the ReadyAudit macOS app

In short: We target WCAG 2.2 Level AA and the corresponding requirements of EN 301 549 for both the website and the Mac app. The website has been assessed against that target, as of 28 July 2026. The Mac app has not: it has no released build yet, so section 5 states the commitments it is built to rather than results we have measured. This is a self-assessment, not a third-party audit. Known gaps are listed in section 6 rather than omitted. Tell us about anything we missed and we will reply within 5 business days.

1. Why this page is specific

We sell accessibility evidence. A statement from us that said "we are committed to accessibility for all users" and stopped there would be exactly the kind of document our own product exists to expose. So this one is written to the same standard we hold customers to: a named target, a stated method, a date, and an honest list of what is still broken.

2. Conformance target

Standard: Web Content Accessibility Guidelines (WCAG) 2.2, Level AA.
Regulatory mapping: the corresponding clauses of EN 301 549 v3.2.1, the harmonised European standard referenced by the European Accessibility Act.
Status, readyaudit.dev: partially conformant — most of the standard is met; the exceptions are in section 6.
Status, the macOS app (dev.readyaudit.mac): not yet assessed. There is no released build and no App Store listing, so no conformance claim is made for it. Section 5 lists what it is built to do, which is a design commitment and not a measurement.
Assessment date: 28 July 2026. This date moves only when an assessment is actually carried out; it is deliberately not tied to the version date of these documents, which moves for unrelated edits.

This is a self-assessment. It was carried out by us, on our own product, using the methods in section 3. It has not been verified by an independent third party, and it is not a VPAT, an ACR, or a certificate of conformity. We say so plainly because our Terms say the same thing about your report, and a company that applies a stricter honesty rule to its customers than to itself deserves neither.

3. How we assessed it

What has been carried out, on the website, as of 28 July 2026:

Automated checks with axe-core across every built page, treated as a floor and not as a result — an automated pass finds a minority of real barriers, which is the reason our product exists.
Keyboard-only traversal, checking reachability, visible focus and focus order.
Programmatic contrast calculation against the design tokens rather than eyeballing — the values are in section 4.
Reflow to a single column at 320 CSS pixels with no horizontal scrolling, except where section 6 says otherwise.
A JavaScript-disabled pass over the one page that computes an answer in the browser, checking that it degrades to more reading rather than to nothing.

What has not been carried out, and is therefore not claimed anywhere on this page:

An end-to-end screen-reader pass. Individual screens have been checked, but there has been no structured VoiceOver run over the whole site, and no NVDA or JAWS run at all.
Zoom to 400% and text-spacing overrides, as distinct from the 320px reflow above.
Any assessment of the macOS app. See section 5.
Any third-party or independent audit. See the note under section 2.

4. What we have done — readyaudit.dev

Landmarks and structure. Every page uses real header, nav, main and footer landmarks, with a single h1 and a heading order that does not skip levels.
Skip link. The first focusable element on every page jumps to the main content, and it is visible when focused rather than permanently hidden.
Visible focus. A 2px focus ring in the brand green with a 2px offset, applied through :focus-visible so it appears for keyboard users without following mouse clicks around. Focus indication is never removed.
Contrast. Body text #101418 on #fafaf8 is roughly 17:1. Secondary text #3a414a exceeds 9:1. The brand green #0e6e5c measures 5.9:1 against the page background #fafaf8 and 6.2:1 against pure white — both above the 4.5:1 threshold for normal text. The figure quoted here used to be the 5.9 attributed to white, which is the smaller of the two on the wrong surface; a page that polices false precision cannot carry any. A darker #0b5647 (8.6:1 on white) is used where a link sits on a tinted background.
Meaning is never carried by colour alone. Severity is always labelled in text as well as coloured.
Reduced motion. A prefers-reduced-motion query reduces every animation and transition to effectively zero.
Text and zoom. Sizing is relative, line length is capped at a readable measure, and the layout reflows to a single column without horizontal scrolling at 320 CSS pixels.
Semantic HTML, almost no JavaScript. Interactive elements are native a and button elements, so they work with the keyboard and with assistive technology without ARIA patching. The site works with JavaScript disabled.
Language and titles. Every page declares its language and has a unique, descriptive title.

5. The macOS app — what it is built to do

None of the following has been verified by an assessment. The app has no released build and no App Store listing, and no VoiceOver or Full Keyboard Access pass over it has been recorded. What is listed here is how it is built and what we intend to hold it to — not a conformance claim, and not a result. It becomes one on this page when someone has actually run it, and section 2 will say so on the same day.

Built in native SwiftUI, so standard controls expose their accessibility roles, values and traits to VoiceOver without custom work.
Every control has a label; icon-only buttons carry an accessibility label rather than relying on the glyph.
Full Keyboard Access reaches every control, and the tab order follows the visual order.
Dynamic Type and the system text-size settings are respected; layouts reflow rather than clip when text grows.
Increase Contrast and Reduce Motion system settings are honoured.
The same palette as the website, so the contrast figures in section 4 apply to the app.
Status changes during an audit are announced, not only shown, so a screen reader user is not left guessing whether a long-running job moved.

6. Known limitations

These are the things we know are not right yet. The list is kept current; an empty list would mean we had stopped looking.

Data tables on this site scroll horizontally on narrow screens. The sub-processor and processing tables have a minimum width and are placed in a scrollable region. This is announced to assistive technology and the region is keyboard-scrollable, but it is still a horizontal scroll, which WCAG 1.4.10 permits for data tables and which we would rather not need.
Exported PDF reports are not yet tagged to PDF/UA. The report you receive is readable and its text is selectable, but the tag tree is not complete, so a screen reader will not get an ideal reading order. This is the gap we are least comfortable with, and it is being worked on.
Evidence screenshots inside reports have generic alternative text. An image showing a failed contrast check is described by the finding text next to it rather than by a bespoke alt attribute for that image.
No third-party audit. Section 2 — everything here is our own assessment.
Cognitive accessibility is under-tested. We test with assistive technology far more than we test with people who have cognitive or learning disabilities, which is a real gap in our method, not just in our coverage.

7. Tell us

If any part of this site or the app is not usable for you, write to info@readyaudit.dev. Tell us the page or screen, what you were trying to do, and the assistive technology and version if you know it — but a one-line "this button does nothing with VoiceOver" is entirely enough, and we would much rather have that than nothing.

We acknowledge within 5 business days with a real answer about whether it is a bug and what we intend to do, not an automated receipt. If the fix is quick we ship it; if it is not, we tell you the honest timeline and add it to section 6 above in the meantime.

If you need any content on this site in an alternative format, ask and we will provide it at no charge.

8. If we do not resolve it

If our response is not satisfactory, you may raise the matter with the accessibility enforcement body in your country. In the EU, each Member State designates one under the European Accessibility Act; in the UK the route differs by service; in the US, complaints may be made to the Department of Justice. We would strongly prefer to hear from you first, and not because it protects us — an issue we do not know about is one we cannot fix.

9. What this page commits us to

A failure on our own site or app is an argument against our product, and we treat it that way. Accessibility defects we find in ReadyAudit are fixed on the same priority track as defects that break an audit, not on a backlog labelled "polish". If you ever find that this page has drifted out of date relative to what the site actually does, that itself is a bug worth reporting — the statement is part of the product.

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.