Accessibility Statement

Our commitment. CourtFlow AI is built for litigation professionals — including those who use assistive technology. We work to make the marketing site, signed-in dashboard, and email notifications usable by everyone, and we welcome feedback when something falls short.

1. Standard We Target

CourtFlow AI uses the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA, as our design and development target. WCAG 2.1 Level AA is the standard most U.S. federal procurement (Section 508 of the Rehabilitation Act) and most state procurement processes use as a baseline, and is widely cited in ADA Title III settlements involving web accessibility.

We treat WCAG 2.1 AA as a continuous commitment, not a one-time certification: surfaces are reviewed for accessibility as they are built or substantially redesigned, and known issues are tracked alongside other product work.

2. Scope

This statement covers the following surfaces operated by CourtFlow AI, Corp. at courtflow.ai:

• The public marketing site (homepage, pricing, demo, blog, compare, practice-area pages, FAQ, legal pages).
• The free public tools at /try (filing analyzer) and /rules (court rules reference), and the public probate intake portal.
• The signed-in product surfaces at /dashboard and its sub-routes.
• Transactional and notification emails CourtFlow sends (daily briefings, processing notifications, deadline reminders, weekly case-law digest).

This statement does not cover content served by third parties that we link to or embed — for example, Google Drive and OneDrive previews of customer documents, Stripe checkout pages, court e-filing portals, or PDFs produced by courts and uploaded by attorneys. Those surfaces are governed by their own operators' accessibility statements.

3. What This Means in Practice

• Keyboard navigation — All interactive elements (links, buttons, form fields, menus, dialogs) are reachable and operable with a keyboard alone, in a logical tab order. Focus states are visible at all times.
• Screen-reader support — Pages are built with semantic HTML, ARIA roles where native elements are insufficient, programmatic labels for form fields, and landmark regions for navigation. We test with VoiceOver (macOS / iOS) and NVDA (Windows).
• Color and contrast — Body text meets the WCAG 2.1 AA contrast ratio of 4.5:1; large text and non-text UI elements meet 3:1. Information conveyed by color is also conveyed by text, shape, or position.
• Resizable text — Pages remain usable when text is resized up to 200% in the browser without horizontal scrolling on standard viewports.
• Motion and animation — Animations honor the prefers-reduced-motion media query and there are no autoplaying audio or video tracks.
• Form errors — Validation errors are announced to assistive technology, associated with the field that failed, and described in plain language with a remediation suggestion.

4. Known Limitations

We are transparent about areas where the current product does not yet meet our WCAG 2.1 AA goal:

• AI-generated content — Trial preparation outlines, briefs, and other AI-generated documents are produced as semantic text but the underlying structure (headings, lists, tables) is only as good as the model's output. We are iteratively improving prompts and post-processing to ensure consistent heading hierarchy.
• Court PDFs — PDFs that originate from courts vary widely in accessibility (some are scanned images without OCR, some are tagged poorly). CourtFlow does not modify the underlying PDFs; we extract text for analysis but cannot retroactively make a scanned court PDF screen-reader-accessible.
• Data tables in the dashboard — Some legacy table components in the dashboard predate our current accessibility conventions and use ARIA patterns inconsistently. These are being migrated to our newer accessible primitives.
• Calendar grid — The month-view calendar uses a grid pattern with date-cell focus; we are reviewing it against WAI-ARIA Authoring Practices for grid widgets.

If you encounter a specific barrier not listed here, please tell us — see §6 below.

5. Requesting an Accommodation

If a particular workflow or surface in CourtFlow is presenting a barrier to your use of the Service, you can request a reasonable accommodation by emailing accessibility@courtflow.ai. Please describe (a) the surface or feature you were trying to use, (b) the assistive technology you were using (screen reader, magnifier, switch device, keyboard-only, voice control), and (c) what happened and what you expected. We will acknowledge accommodation requests within five (5) business days and propose a workaround, fix, or alternative format as appropriate to your situation.

6. Reporting a Barrier

Reports of accessibility barriers from any user — not just CourtFlow subscribers — are welcome. Email accessibility@courtflow.ai. We treat accessibility barriers with the same seriousness as functional bugs: a triage entry is created, severity is assigned, and the report is tracked through to resolution. Where a fix will take longer than the next regular release, we will share a workaround.

7. Assessment Approach

CourtFlow currently assesses accessibility through internal review and assistive-technology testing during development, supplemented by automated tooling (axe-core, Lighthouse). We have not yet engaged a third-party VPAT (Voluntary Product Accessibility Template) audit; a VPAT engagement is on our compliance roadmap and will be linked here when complete. In the interim, prospective customers with procurement requirements may request a written self-assessment by emailing accessibility@courtflow.ai.

8. Updates to this Statement

We update this statement when significant accessibility work ships or when our scope changes. Material updates are reflected by the "Last updated" date at the top of this page.

Get in touch

Accessibility feedback, accommodation requests, and barrier reports: accessibility@courtflow.ai.