Accessibility statement

We build Includoc for people who make documents accessible, and for everyone who relies on those documents. Our own website and app should meet the standard we help you reach, and go beyond it where we can.

Our goal

We aim to conform to the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA across our website and app. Where our color palette allows, we go further: body text meets the stricter Level AAA contrast ratio of 7:1.

How we build for accessibility

Accessibility is part of how we build every page, not a check at the end:

• Accessible components. Our buttons, menus, dialogs, tables and file upload controls are built on React Aria Components, a library designed and tested for accessibility.
• Keyboard first. Everything works with a keyboard, with a clearly visible focus indicator. Keyboard shortcuts are optional, and none use a single key unless you turn them on.
• Status you don't need color to read. Results always show an icon, a word and a color together: Passed, Needs review or Failed.
• Room to tap. Buttons and other touch targets are at least 44 by 44 pixels.
• Zoom and small screens. Pages work at 320 pixels wide and at 400% zoom, with content that reflows to fit.
• Motion and themes. We respect your reduced-motion setting and never auto-play video. Light and dark themes follow your system setting, and you can switch manually.
• Structure. Every page has a skip link, landmarks and one main heading.
• Readable text. We write in plain language, at about a US grade 8 reading level, and use Atkinson Hyperlegible Next, a typeface designed by the Braille Institute for legibility.

How we test

Automated checks. Every change to our code runs automated accessibility tests (axe) before it can be merged. A change with a serious or critical issue can't be merged. Each interface component is also tested on its own.

Manual testing. Before we release a new feature or flow, we test it with:

Reports and documents we create

The conformance reports Includoc produces are tagged PDFs. We validate each one with veraPDF against PDF/UA, the standard for accessible PDF files, before you receive it. Reports are also available as web pages.

Accessibility Conformance Report (ACR)

We're preparing an Accessibility Conformance Report using the VPAT 2.5 International Edition template, which covers WCAG, Section 508 and EN 301 549. It isn't published yet. Once it is, it will be available on request, and we'll update it every quarter. To get a copy as soon as it's ready, contact us.

Known issues

We're completing our first full manual audit. We'll list anything we find here, along with what we're doing about it and when.

Some parts of the experience come from other companies:

• Payments use Stripe's hosted checkout page. If it doesn't work for you, contact us and we'll send an invoice instead.
• Bot protection uses Cloudflare Turnstile, which usually runs without you noticing. If it ever blocks you, contact us and we'll help you check your document another way.
• Booking a walkthrough uses a third-party scheduling page. If you can't use it, email us and we'll find a time together.

Tell us about a problem

If something on Includoc doesn't work for you, please tell us. Use the feedback form on this page or email accessibility@includoc.com. We respond within 2 business days.

If you can't complete a task, such as checking a document or reading your report, we'll help you get the result another way. If you need information from this site in a different format, ask and we'll provide it.

Technical details

Includoc relies on HTML, CSS, JavaScript and WAI-ARIA to work with your browser and any assistive technology you use.

About this statement

This statement was prepared on October 9, 2026. We'll review it after each audit and update it whenever something changes.