Accessibility statement

What we aim for

The PDF Hound website is built to meet WCAG 2.2 at level AA. That covers every page a customer uses: the home page and upload form, the progress page, the review and editor screens, the download page, My PDFs, and these policy pages.

In practice this means every control works from the keyboard with a visible focus indicator, page structure is expressed with real headings, landmarks and lists, images and icons carry text alternatives, colour is never the only way information is shown, text can be resized to 200 percent and the layout reflows at a 320 pixel width without sideways scrolling, and status changes are announced to screen readers.

This statement covers the website. The PDFs we produce are checked separately: each fix is validated against the PDF/UA-1 rules with veraPDF and reviewed as a screen-reader reading stream before it is delivered, and the Accessibility Improvement Report that ships with a fixed PDF lists what was checked and what still needs a person's judgment.

How we test

Automated checks run in the build for every customer page. A Playwright browser suite opens each page and runs the axe-core accessibility engine against the WCAG 2.0, 2.1 and 2.2 A and AA rule sets; any serious or critical finding fails the build. The same suite checks that every page reflows at phone width and at 200 percent zoom without horizontal scrolling, and that no element sits outside the visible page.

Automated tools find only part of what matters, so each screen is also used by hand with the keyboard alone (Tab, Shift+Tab, Enter, Space, Escape and the arrow keys), following the same path a customer takes from upload to download. Focus order, dialog behaviour, live status messages and the review editor's controls are checked this way before a change ships.

Colour contrast is managed at the design-token level: text and interface colours come from one set of named tokens chosen to meet the AA contrast ratios, and a test refuses any stylesheet that introduces a colour outside that set.

Known limitations

• Page previews in the review editor are rendered images of the PDF. They show where an item sits on the page; the reading-order list and text beside them carry the content itself.
• Google Sign-In renders its button inside a Google-hosted frame. We size and label it, but its internal markup and focus styling are Google's.
• Stripe Checkout is a Stripe-hosted page. Stripe publishes its own accessibility information for it.
• Very long documents in the review editor produce long lists of reading-order items. They are keyboard-navigable, but moving through hundreds of items is slower than it should be.

We keep this list current as issues are found and fixed. If you hit something that is not listed here, we would like to know.

Tell us about a barrier

If any part of PDF Hound is hard to use with assistive technology, or a page does not work with your keyboard, screen reader, magnifier or voice control, write to hello@pdfhound.com. Tell us which page, what you were trying to do, and which browser and assistive technology you use. We reply within 7 days, and a barrier that blocks a customer from finishing an audit, a fix or a download is treated as a defect and fixed ahead of other work.

If you need an alternative to a specific page or a delivered report in the meantime, say so in the message and we will provide one.