Accessibility Statement

01Conformance target

Docket Build aims to conform to the Web Content Accessibility Guidelines 2.2 at Level AA. We test with keyboard-only navigation, VoiceOver on macOS and iOS, NVDA on Windows, and automated auditing in continuous integration on every release.

Accessibility matters particularly in this product because the people who spend most time in it are paralegals working long sessions in dense document interfaces, and because those sessions frequently happen under deadline pressure.

02What conforms today

• Full keyboard operability across navigation, forms, tables, accordions and the interactive sandbox, with a visible focus indicator on every interactive element.
• A skip-to-content link at the start of every page.
• Semantic headings, landmarks and list structure throughout.
• Text contrast of at least 4.5:1 for body copy and 3:1 for large text and interface components.
• Form fields with associated labels, inline error messages tied to their field, and errors announced to assistive technology.
• Touch targets of at least 44 by 44 pixels on primary controls.
• Full support for prefers-reduced-motion, which disables the logo marquee, entrance animations and confetti.
• Text resizing to 200% without loss of content or functionality.
• Alternative text on every informative image, with decorative graphics marked as such.

03Known gaps

• Some data tables scroll horizontally on narrow viewports. They are keyboard-scrollable and correctly announced, but a responsive stacked view would serve small screens better. Planned for Q4 2026.
• Colour is used alongside icons and text to convey document status. Icons and text labels are always present, but we are strengthening the non-colour signal on coverage bars.
• Complex chart graphics carry a text summary rather than a full accessible data table. Adding tabular equivalents is planned for Q4 2026.
• The PDF packets Docket Build generates carry document structure and bookmarks but are not yet tagged to PDF/UA. This is on the roadmap for 2027.

04Assistive technology tested

05Reporting a barrier

If something blocks you, write to accessibility@docketbuild.com with the page, what you were trying to do, and the assistive technology and browser you were using. We acknowledge within two business days and give a remediation timeline within ten.

If a barrier is preventing you from completing work on a live matter, say so and we will prioritise it and provide a workaround the same day.

06Assessment approach

Automated auditing runs on every pull request. Manual keyboard and screen reader testing runs before each release on the paths customers use most: intake, mapping, assembly review and export. An independent accessibility audit is commissioned annually; the most recent was completed in May 2026 and its findings are reflected in the gaps listed above.