Legal

Accessibility Statement

The Keepsake web app and this website are built to WCAG 2.2 Level AA. An automated conformance pass runs over every screen of the web app — including in a right-to-left language — as part of the ordinary test suite, so a change that removes a label or a focus ring fails the build rather than reaching you.

Statement prepared 7 September 2026, from a pass run on the code released that day. It is reviewed whenever the interface changes, which is what the test suite makes automatic.

What we claim, and what we do not

We claim exactly three things. The automated WCAG 2.2 AA pass over the web app is green on every screen. The specific defects listed further down were found and fixed rather than papered over. And where we do not know, this page says so.

We do not claim a third-party accessibility audit — there has not been one, the same way there has not been an external security audit, and both are listed as absent in our claim ledger. We do not claim to have tested with screen-reader users. And automated tools can decide only part of the standard: whether a name exists is machine-checkable, whether the name is a good one is not. Treat the green pass as a floor we cannot fall through, not as a ceiling we have reached.

What is covered

• The web app (app.securekeepsake.com) — assessed, and re-assessed by the suite on every change.
• This website — same palette, same focus rules, same markup conventions.
• The Windows and Android apps are not assessed against WCAG. They use the platform's own controls, so they inherit whatever Windows Narrator and Android TalkBack give those controls, and that is a statement about the platform rather than about our work. If you need Keepsake with assistive technology today, the web app is the surface we have tested.
• Documents you store are yours and are shown as you supplied them. A scanned PDF with no text layer is not made accessible by us — though the offline OCR does read one, which is exactly what makes the text searchable and quotable.

How it is tested — and how you can test it

The pass boots the real application, walks it through the states a person actually meets — create a vault, the recovery kit, the empty dashboard, a dashboard with a document, the upload dialog, a document, settings — and runs axe-core 4.13 against the wcag2a, wcag2aa, wcag21a, wcag21aa and wcag22aa rule sets at each stop. It then repeats the first screen in Urdu and asserts the document really is in right-to-left mode, because mirroring is where a screen most often loses its labels.

Two things a headless browser cannot decide are checked another way rather than skipped. Colour contrast is computed arithmetically from the stylesheet's own palette — every text colour against every surface it sits on, white against the button fill in both its states, and every border that identifies a control — because without a layout engine axe reports contrast as incomplete, and an incomplete result quietly counts as a pass. The page-level rules (a language, a title, a viewport that can be zoomed) are asserted against index.html itself.

Run it yourself, from a clone of the source:

cd pwa && npx vitest run a11y

What the first pass found

The suite was written before the fixes, which is the only order in which a statement like this is worth anything. On 7 September 2026 it failed on every screen it visited. Five distinct defects, every one of them real, and the last of them found only after the walk was widened to the settings screen:

• Six unnamed controls. The screens were written as <label>Title</label><input> — a labelled field to anyone looking at it, and two unrelated things to a screen reader. The repeat-password field, the document title, expiry, notes, the category menu and the file input all reached a screen reader as unnamed. Fixed at the one place every screen is built, so the association is made for all sixty labels rather than for the ones somebody remembered.
• A drop zone no keyboard could reach. "Drop a file here or click to choose" was a <div> with a click handler. It is a button now.
• A cloud-provider menu named only by the heading above it, which is a section title and not a name. It carries its own now.
• A focus ring removed with nothing put back. outline: none on every field — the single most common way a keyboard user loses their place. There is a :focus-visible outline now, and a test that fails if it is ever removed again.
• Two colour pairs below the required ratio. White on the accent button measured 3.95:1 where 4.5 is required, and the border that tells you where a field is measured 1.35:1 against the background where 3 is required. The palette now distinguishes a boundary that identifies a control from a hairline that merely separates two cards, and the purple that carries white text on a button from the lighter purple that is readable as text — one colour could not do both jobs honestly.

Languages

The interface is available in English, Urdu, Arabic and Hindi. Urdu and Arabic lay the entire interface out right-to-left; Hindi does not, which is the case that stops "not English" being used as a shortcut for "right-to-left" anywhere in the code.

All four come from one catalogue of 196 strings, and the Windows, Android and web test suites each fail if a language is missing a string, defines one English does not, drops a placeholder, or is quietly still in English. Choosing a language is in Settings and applies immediately, including the layout direction. The offline OCR reads Urdu, Arabic and Hindi documents too, which is why those three came first.

Known limits

• No third-party accessibility audit, and no testing with screen-reader users. Both are wanted; neither has happened.
• The Windows and Android apps are unassessed, as above.
• Document previews render the file you supplied — a PDF's own accessibility is the PDF's.
• The automated pass covers the criteria automation can decide. Reading order, focus order and the wording of error messages were written with care and are not machine-verified.

Telling us something is wrong

Email us — the address is on the imprint — with the screen you were on, what you were using, and what happened. We acknowledge within 3 working days. An accessibility defect is a bug: it is fixed on the same terms as any other bug, on the free tier exactly as on the paid one, and where we can we add the test that would have caught it before we close it.

If you would rather report it as a security-style disclosure, the disclosure policy route works equally well and carries the same commitments.

Questions