Trust & Safety

Accessibility

What we aim for, what we have actually done, and — the part most statements leave out — what we already know is not good enough yet. If you hit a barrier, there is an address at the bottom that reaches a person.

Last updated August 2026

We are not claiming a conformance level

A statement that claims full WCAG 2.2 AA conformance should be backed by a real audit, and we have not had one. Saying otherwise would be the easiest sentence to write and the least honest. What follows is what we have built for, what we have checked ourselves, and where we know the gaps are.

What we are aiming at

WCAG 2.2 Level AA is the target, because it is what public-sector and enterprise buyers are measured against and it is the right bar regardless. We treat it as a direction we are moving in rather than a badge we have earned.

What is actually in place

  • Keyboard operation. Tools are reachable and operable without a mouse, and focus is visible rather than suppressed. The command palette opens with ⌘K / Ctrl-K and is fully keyboard driven.
  • Semantic structure. One h1 per page, headings in order, real landmarks, and lists marked up as lists — which is what a screen reader navigates by.
  • Text alternatives. Decorative icons are hidden from assistive technology; icon-only controls carry a label rather than relying on the shape.
  • Reduced motion. Animation respects prefers-reduced-motion. The first-visit brand animation never plays for anyone who has asked for less motion.
  • Light and dark. Both themes are designed rather than inverted, so contrast holds in each.
  • Resizing. Layouts use relative units and reflow rather than forcing horizontal scrolling when text is enlarged.
  • No time limits. Nothing expires while you are working on it, and nothing auto-plays sound.

Known gaps — the honest part

  • No independent audit. Nobody outside the team has assessed us, and no VPAT exists. If you need one to procure, say so and we will talk about getting it done.
  • Limited testing with real assistive technology. We have used automated checks and keyboard testing. That is not the same as sitting with a screen reader user, and we know it.
  • The visual editors are the weakest area. Annotate, Redact and Edit involve placing things on a page by dragging. Drag-and-drop is genuinely hard to make equivalent without a mouse, and we have not solved it yet. If that is what you need, tell us — it moves up the list.
  • A PDF we produce is only as accessible as what went in. Converting a scanned image does not create a tagged, screen-reader-friendly document. Running OCR helps; it is not the same as a properly tagged PDF.
  • Third-party content. The checkout is Stripe’s hosted page and its accessibility is theirs, not ours.

One thing that helps more than it looks

Because most tools run inside your browser, they work with the assistive technology and browser settings you already have configured, offline, with no account and no sign-in step in the way. There is no separate app to make accessible and no cloud session to keep alive.

Tell us about a barrier

If something blocked you, we want the specific detail — the page, what you were trying to do, and what happened. [email protected], or the feedback form. We aim to reply within five working days and to say plainly whether we can fix it, when, or that we cannot.

If you need something urgently in another format, ask. That is a reasonable request and we would rather do it than have you go without.

Reviewed

This statement was last reviewed in August 2026 and is written against our own testing. It will be updated as gaps close — including this sentence, when there is an audit to point at.