Accessibility statement

What we aim for

The target is WCAG 2.2 at level AA. That is the target, not a certificate: nobody has audited this site, and we are not going to imply otherwise by putting a conformance badge on it. What follows is what has actually been built and what we know is still short.

What is in place

• A skip link as the first thing in the tab order, so keyboard users can jump past the header straight to the page.
• Every control reachable and operable by keyboard, including the file drop zones, which respond to Enter and Space as well as a click.
• A visible focus outline on everything focusable, drawn in the site's accent colour at a 2px offset so it stays legible over any background here.
• Controls sized for thumbs rather than cursors: 40 pixels square or larger on the tools, where WCAG 2.2 AA asks for 24.
• Real headings in order, real lists, real buttons. The FAQ and the language menu are the browser's own disclosure elements rather than scripted accordions, so they expand without JavaScript and announce their own open and closed state.
• Text that survives zoom: the layout is fluid down to 320px wide and reflows rather than scrolling sideways.
• prefers-reduced-motion honoured globally: transitions and animations are cut to almost nothing when the operating system asks for that.
• prefers-color-scheme honoured too, so a device set to dark gets a dark site. Both themes are held to the same contrast standard, and you can override the system setting in account settings if you would rather.
• Status messages, errors and progress written as text, never signalled by colour alone.
• lang and dir set correctly on every page, including the right-to-left languages, so a screen reader picks the right voice.

The tools specifically

The tools are more than prose, so they need more than prose accessibility. Where you reorder pages or files, there are real buttons to move an item up and down; drag and drop is an addition, never the only way. Every drop zone is labelled with what it accepts. Rendering progress is announced as text, not as a spinner alone.

⌨️Any tool here can be driven start to finish with a keyboard: tab to the drop zone, press Enter to open the file picker, tab through the controls, and tab to the download button.

Known gaps

The parts we know are not good enough yet:

• The tools need JavaScript. There is no non-JavaScript fallback and there cannot be a meaningful one, because the processing is the JavaScript. Every content page on the site works fine without it.
• Page thumbnails are images of your pages, and we cannot write alt text describing what is in them. They are labelled by page number, which is what the controls act on, but a screen reader user is choosing pages by number rather than by looking.
• Large documents can lock the tab while they render. That is a problem for everybody and worse if you rely on assistive technology, which may lose responsiveness with it. Moving that work to a background thread is on the roadmap.
• No formal audit and no testing with a paid screen reader in a professional setup. See below for what has actually been checked.

How this was checked

Keyboard-only walkthroughs of the tools and the content pages. A narrow-viewport pass at phone width, to confirm nothing overflows or needs sideways scrolling. Contrast is measured rather than eyeballed: a script loads the site in a real browser in both themes, reads back the colour of every piece of text and the colour actually painted behind it, and fails the build if any pair falls under the AA threshold. That is what turned up two greys in the footer and on the legal pages that had been under it for months.

What has not happened: a formal audit, or testing with JAWS, NVDA or VoiceOver by someone who uses them every day. Those find things that a sighted developer with a keyboard does not, and until they happen this statement stays worded exactly the way it is.

Telling us about a problem

If something here blocks you, we want to know, and a one-line description is plenty: the page, and what would not work. Write via the contact page or email us directly; both go to the same place.

We read everything, and accessibility reports go to the front of the queue over feature requests. If a fix is going to take a while, we will say so rather than leave you waiting.

Related: how it works explains what the tools do to your file, and the sitemap lists every page on the site in one place.

This statement was last reviewed in August 2026, and gets revised whenever something on it stops being true.