Accessibility Statement

Version: 2.0
Effective: 26 July 2026
Applies to: accessproof.dev · the AccessProof macOS app

This document is complete in substance but still carries placeholders in square brackets for the registered entity, address and governing law. It has not yet been reviewed by a qualified lawyer in the relevant jurisdiction, and it is not legal advice.

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. This is a self-assessment, not a third-party audit, and it is dated. 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: partially conformant — most of the standard is met; the exceptions are in section 6.
Scope: all pages of accessproof.dev, and the AccessProof macOS application (dev.accessproof.mac).
Assessment date: 26 July 2026.

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

Keyboard-only traversal of every page and every screen, checking reachability, visible focus, and focus order.
VoiceOver on macOS and Safari, and NVDA on Windows and Firefox, for the website; VoiceOver and Full Keyboard Access for the Mac app.
Programmatic contrast calculation against the design tokens rather than eyeballing — the values are in section 4.
Reflow and zoom to 400%, and testing with text spacing overrides applied.
Testing with prefers-reduced-motion, Increase Contrast and Reduce Transparency enabled.
Automated checks, 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.

4. What we have done — accessproof.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 on white, above the 4.5:1 threshold for normal text, and a darker #0b5647 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. What we have done — the macOS app

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@accessproof.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 AccessProof 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

[LEGAL_ENTITY], [REGISTERED_ADDRESS], [COUNTRY]. Registration [COMPANY_REGISTRATION_NUMBER] · Tax ID [TAX_ID].

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