Accessibility Statement

Effective date: July 27, 2026
Last updated: September 10, 2026

Esqase, Inc. ("Esqase," "we," "us," or "our") builds practice management software for law firms, and we want everyone who uses it, including people with disabilities, to be able to work with it effectively. That includes the lawyers and staff who run their firm in Esqase, the clients they invite to book, sign, pay, and share information, and anyone reading our website or documentation. This statement describes the standard we design toward, the concrete measures we take, the areas where we know we are not there yet, and how to tell us when something gets in your way.

This Accessibility Statement is published for information. It does not amend and is not incorporated into our Terms of Service, and nothing in it creates a warranty or a service commitment. We publish it because we think you are entitled to know where we stand, and we intend to keep it accurate.

1. Our Commitment

Accessibility is part of how we design and build Esqase, not an afterthought. Our commitment covers every surface of the platform:

• The marketing website and documentation at esqase.com.
• The firm dashboard at app.esqase.com, where firms manage contacts, matters, tasks, documents, billing, and communications.
• The public pages firms share with their clients: booking pages, intake forms (including forms a firm embeds on its own website), payment pages, shared document links, and the eSignature signing pages at docs.esqase.com.

Clients of law firms do not choose the software their firm uses. Because these public pages are often the only way a client interacts with Esqase, we hold them to the same accessibility standards as the rest of the platform.

2. Standards We Design Toward

We design toward the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA, and we use its four principles as our frame: content should be perceivable, operable, understandable, and robust.

We are working toward this standard across the platform. Conformance is an ongoing effort rather than a finished state, and some parts of the platform do not yet meet every criterion. Section 4 describes the areas we know need work.

Using the conformance vocabulary the W3C recommends for accessibility statements, Esqase is partially conformant with WCAG 2.2 Level AA: some parts of the platform do not fully conform to the standard. We do not claim full conformance.

3. Measures We Take

3.1 Accessible Component Foundation

The entire Esqase product suite is built on a single shared component library based on widely used, accessibility-focused UI primitives. These primitives provide accessible behavior by default, including keyboard interaction, focus management, and the semantics assistive technologies rely on. Because every app in the suite uses the same components, an accessibility improvement in the library reaches the dashboard and every public page at once. Our website and documentation are built separately, on the same primitives and the same design decisions, so an improvement there is applied deliberately rather than inherited.

3.2 Keyboard Navigation

Every interactive control is expected to be reachable and operable with a keyboard. Visible focus indicators are part of our component library and our standards prohibit removing them.

3.3 Focus Management

Dialogs trap focus while open and return focus to the triggering control when closed. When a dialog opens, focus moves to a sensible starting point so keyboard users are never left stranded.

3.4 Semantic HTML and ARIA

Form fields carry programmatic labels. Fields with validation errors are marked with aria-invalid and paired with visible error text. Icon-only buttons carry accessible labels, and status indicators expose their state to assistive technology, not just visually.

3.5 Color and Contrast

Color comes from one shared theme applied across the platform, and our engineering standards route a wanted visual change into that shared theme rather than into a one-off at the call site, which keeps text, controls, and focus treatment consistent instead of drifting screen by screen. A few specialist surfaces, such as the syntax colors inside a code block in the document editor, carry their own palette. We design toward the WCAG 2.2 Level AA contrast ratios for text and for user interface components, and we do not use color on its own to carry meaning: status, validation, and required fields are also expressed in text, an icon, or a shape.

3.6 Predictable States

Screens are designed with loading, empty, and error states. Loading placeholders match the final layout so content does not shift unexpectedly, and errors are shown as clear, plain-English messages rather than raw technical output.

3.7 Responsive Design and Reflow

The pages a law firm shares with its clients, along with our website and our documentation, are responsive: they reflow down to small phone widths without forcing you to scroll in two directions. The firm dashboard is built for a desktop or tablet workspace. Below roughly 700 pixels of width it keeps its layout and scrolls sideways rather than reflowing, so on a small phone it is reachable but not comfortable. Section 4 records this as a known limitation.

3.8 Accessibility in Engineering Review

Accessibility is a codified part of our engineering standards. Keyboard operability, focus behavior, labels, and designed states are checked when new screens are built and reviewed, so accessibility is considered before a feature ships rather than after.

4. Known Limitations

We aim to be honest about where we stand. Areas we know need continued work include:

• Complex interactive surfaces. The document editor and the calendar and scheduling views involve rich interactions that are harder to make fully keyboard and screen-reader friendly. Dragging an event to a new time on the calendar has no keyboard equivalent today; the same change can be made from the event's own form. Drag-and-drop elsewhere in the platform, including boards, the form and invoice builders, signature field placement, and reorderable lists, can be operated from the keyboard as well as the pointer.
• Content created by law firms. Documents, intake forms, uploaded files, and messages are created and controlled by the firm using Esqase, not by us. We give firms accessible building blocks, but we cannot guarantee the accessibility of the content they produce or upload. Responsibility for that content sits with the firm under our Terms of Service and our Data Processing Agreement.
• Older screens. Parts of the platform built earlier may not yet reflect our current standards. We bring these surfaces up to standard as we revisit them.
• The firm dashboard on small screens. The dashboard, the settings area, and the form builder hold a minimum working width of about 700 pixels and scroll sideways below it instead of reflowing. The pages firms share with their clients, our website, and our documentation are not affected.
• Bypassing repeated navigation. We do not yet offer a skip-to-content link. Our pages use landmark regions, so assistive technology can jump straight to the main content, but someone navigating by keyboard alone still passes through the navigation on each page.
• Reduced motion. Our website honors the reduced-motion setting in your operating system. The firm dashboard and the pages firms share with their clients do not yet honor it, although their motion is limited to short transitions and loading placeholders.
• PDFs we generate. The invoices, reports, and certificates of completion that Esqase generates are PDF files that are not tagged for accessibility, so a screen reader may read them without headings or reliable order. Where a document was uploaded by a law firm, its accessibility depends on the file that firm supplied. The same information is available in the Service itself, and we will provide a record in another format on request.

5. Third-Party Services

Some steps take you to a page or an interface that a third party controls. We do not control the accessibility of those interfaces, and each provider publishes its own accessibility information.

• Subscription checkout. Paying for an Esqase Subscription sends you to a checkout page hosted by Stripe, which your browser is redirected to and returned from rather than a page embedded in Esqase.
• Paying a law firm. A firm's payment page is an Esqase page and is covered by the rest of this statement. It offers the payment methods that firm has set up, such as a link to the firm's own bank or payment provider, or a QR code. Those destinations belong to the firm and its bank, not to Esqase.
• Connected accounts and meetings. Connecting Gmail, Microsoft Outlook, Google Calendar, or Outlook Calendar takes you through Google's or Microsoft's own sign-in and consent screens, and a Google Meet, Microsoft Teams, or Zoom meeting opens in that provider's own interface.

Where we choose a third-party service, we favor established providers with mature accessibility programs. The providers we engage are listed at esqase.com/subprocessors and in our Cookie Policy.

6. Technical Information

Technologies we rely on. Esqase is built with HTML, CSS, JavaScript, and WAI-ARIA. Accessibility here depends on all four being supported by your browser and by any assistive technology you use alongside it. Every Esqase surface is a web application and requires JavaScript.

Browsers and assistive technology. Esqase is designed for the current versions of the major desktop and mobile browsers, including Chrome, Edge, Firefox, and Safari, together with the screen readers, screen magnifiers, and speech input tools that run alongside them.

How we assess accessibility. We assess accessibility by self-evaluation. Keyboard operability, focus behavior, labels, and designed states are checked when a screen is built and again when it is reviewed, against the shared component library described in Section 3.1. Where we find a gap we cannot close straight away, we record it in Section 4.

7. Feedback and Support

We welcome feedback on the accessibility of any Esqase surface. If you encounter a barrier, email support@esqase.com and include, where you can:

• The page or feature where the issue occurred.
• What you were trying to do.
• The browser and any assistive technology you were using.

We review all accessibility feedback and use it to prioritize improvements. If a barrier is blocking your work, our support team will help you find an alternative path in the meantime.

We aim to acknowledge an accessibility report within five business days and to tell you what we plan to do about it and roughly when. You do not need an Esqase account or a Subscription to use this channel. If you ran into the barrier on a page a law firm sent you, write to us anyway.

If you need this statement, a document Esqase generated for you, or anything else we send you in a different format, tell us what works for you and we will provide it at no charge.

8. Legal and Procurement Context

Esqase is offered in the United States and in the other countries where we make the Service available. In the United States, the Americans with Disabilities Act applies to businesses that offer goods and services to the public. No federal regulation sets a technical accessibility standard for a private business's website, and the Department of Justice and the courts have treated the WCAG Level AA success criteria as the working benchmark. WCAG 2.2 Level AA, the standard named in Section 2, contains every success criterion in WCAG 2.1 Level AA and WCAG 2.0 Level AA.

Two further frameworks come up in procurement:

• Section 508 of the Rehabilitation Act applies to information and communication technology procured by United States federal agencies and incorporates the WCAG 2.0 Level A and Level AA success criteria.
• Title II of the Americans with Disabilities Act applies to state and local government entities, including government law offices. Its accessibility regulation names WCAG 2.1 Level AA, with compliance dates of April 26, 2027 for public entities serving a population of 50,000 or more and April 26, 2028 for smaller entities and special district governments.

If your firm or agency needs accessibility information for a procurement review, an accessibility conformance report, or a vendor questionnaire, email legal@esqase.com and tell us what your process requires. We will give you the information we have and be clear about what we have not yet assessed.

9. Continuous Improvement

Accessibility at Esqase is a program, not a milestone. Our engineering standards apply to every new screen we build, our shared component library carries improvements across the whole platform, and we revisit existing surfaces as the product evolves. We will update this statement as our practices and the platform change. We review this statement at least once a year, and whenever we ship a change that affects what it says. The date of the most recent review is the Last updated date at the top of this page.

10. Contact

For accessibility feedback, a barrier report, or help finding another way to complete a task, email support@esqase.com.

For questions about this Accessibility Statement, or for accessibility information a procurement review requires, contact:

Esqase, Inc.
2810 N Church St STE 89268
Wilmington, DE 19802, United States
legal@esqase.com