Skip to main content
▲ TrialVector
Workspace

ACCESSIBILITY

Accessibility Statement

Last updated August 17, 2026.

Our commitment

We want every litigator and self-represented party to be able to use TrialVector, regardless of ability. We build to the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA as our engineering target, and we treat WCAG 2.1 AA and Section 508 (Revised) as crosswalks. We do not use an accessibility overlay or widget — those do not fix the underlying code, and we hold accessibility to the same “honest states” standard as everything else: we name what is not done rather than claim full conformance.

How we test — the methods we actually use

These are the checks that run against the product today, not aspirations:

  • Automated scans that block a release. Every push runs axe-core over a representative sample of pages, the authenticated workspace (against fixture data), the keyboard journeys, and reflow / text-spacing / forced-colors / reduced-motion checks. A violation at “moderate” or above fails the build. A weekly job sweeps every route on the live site.
  • A contrast law and a form-label census computed in our test suite: every text color pair is verified in both light and dark themes, and every form control must carry a programmatic label.
  • An assistive-technology proxy. For twelve core tasks we walk the accessibility tree a screen reader consumes — the page title, language, landmarks, heading order, whether every control has a name and role, whether tables carry headers, and whether results are announced once — and we keep the results as evidence.
  • Document inspection. The drafts and forms our engines produce (DOCX, PDF) are inspected to confirm they declare their language and title and carry real heading structure.

We test in current Chromium with keyboard-only operation and at multiple screen widths, including 400% zoom.

What we evaluated

This statement covers the public site and the state sections, the authenticated workspace (exercised through a fixture harness, since it needs an account), and the document families our engines generate. A detailed, per-criterion Accessibility Conformance Report (VPAT® 2.5, WCAG edition) with a Section 508 mapping is published alongside this page:

Where we are honest about the gaps

  • Human screen-reader and disabled-user testing is still pending. Our tree-level checks and code review are thorough, but a machine is not a screen-reader user. A session with NVDA / VoiceOver and testing with people who use assistive technology are scheduled and recorded honestly as not-yet-run until they happen — they are not counted as passes.
  • Court-issued and document-kit PDFs declare their language and title but are not yet fully tagged for structure. The reliable accessible path is the on-screen HTML: every rule and every form reads as text on the site.
  • Third-party steps. Payment runs through Stripe’s hosted checkout and some legal data comes from CourtListener; those surfaces are outside our code. The path on our site around each is built to the same standard.

If you hit a barrier we have not listed here, please tell us — it goes on this list and into the queue.

Report a barrier

Use the form below. It lands on our internal review queue, where every accessibility report is a first-class ticket — we do not ask you to diagnose the problem, only to describe it. We aim to acknowledge reports promptly and to prioritize fixing confirmed barriers. (A monitored email address will be published here once it is in place; until then this form is the reliable channel, and it tells you plainly if it is ever temporarily offline.)

Tell us where you hit the barrier and what you were trying to do. You do not need to diagnose it. Leave a way to reach you only if you want a reply.

= required

a link or a description, e.g. the Deadline Engine
optional — e.g. NVDA with Chrome, 200% zoom, high contrast
optional — an email or phone; only used to reply about this report

Compatibility

TrialVector is designed for current versions of Chrome, Edge, Firefox, and Safari (including iOS Safari and Android Chrome for the public site), with keyboard-only operation, browser zoom to 400%, operating-system high-contrast / forced-colors modes, and the reduced-motion preference.

Display settings on every page

The header of every page carries a display-settings control — the universal access symbol — with first-party preferences: color theme (light, dark, or follow the system), text size, increased contrast, and reduced motion. These are built on TrialVector’s own design system, saved in your browser only, and they add to — never replace — your operating-system and browser settings, which the site honors regardless. TrialVector does not use third-party accessibility overlay widgets.

Statement history

  • July 21, 2026 — first statement (WCAG 2.2 AA target; named the then-open contrast, target-size, and AT-testing gaps).
  • August 17, 2026 — rebuilt from the accessibility program’s evidence ledger: contrast, target size, keyboard, titles, language, status messages, and the offline states addressed and verified; the blocking automation, the AT proxy, and the Conformance Report added. Human AT sessions remain the open item.
  • August 18, 2026 — first-party display settings (color theme, text size, increased contrast, reduced motion) added to every page’s header, behind the universal access symbol.