Accessibility

If any part of TRYX is difficult or impossible for you to use, email support@tryxapp.com with the page or screen and what happened. We aim to reply within five business days and will tell you plainly whether we can fix it and when.

If you need information that is currently inaccessible to you — an invoice, a timesheet, a billing summary — say so and we will provide it in another format at no charge.

We build against the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA, and on Apple and Android platforms against their native accessibility APIs.

We do not claim conformance. TRYX has not been audited by an independent accessibility firm, and we have not tested with people who use screen readers day to day. Saying “compliant” without that work would be a claim we cannot support, so we describe what we have actually verified instead.

These were measured on rendered pages and running apps, not inferred from code:

• Colour contrast. Computed from live styles on the marketing site, the sign-in pages, this set of policy pages and the client portal. Text meets or exceeds the 4.5:1 ratio AA requires.
• Keyboard use. Interactive elements on the marketing site, the sign-in pages and this set of policy pages are reachable and show a visible focus indicator.
• Screen readers. Form fields are programmatically labelled, errors are announced rather than only shown, and data tables carry column headers and captions so a figure is read with the column it belongs to. Each sign-in page has a unique descriptive title, a top-level heading and a main landmark, so you can tell which page you are on and jump straight to its content. Dialogs are exposed as dialogs and carry an accessible name.
• Client portal. The billing table can be scrolled to every column on a phone, and entry descriptions wrap in full rather than being cut off.

Listing these is more useful to you than omitting them. We are working on each:

• No independent third-party audit has been carried out.
• We have not tested with VoiceOver, TalkBack, NVDA or JAWS users. Automated checks find a minority of real barriers; this is the gap we most want to close.
• Exported documents (invoice PDFs, timesheets) have not been reviewed for tagging, reading order or alternative text.
• Parts of the administrator dashboard have had less accessibility review than the client-facing and sign-in surfaces.
• The iOS app does not yet honour the system text-size setting. Only the running-timer display and navigation titles grow when you enlarge text; client names, matter references, buttons and tab labels stay at a fixed size, and at the largest accessibility sizes the search field's placeholder is no longer shown. If you rely on larger text, the iOS app will not currently give it to you. This is a real barrier, we have measured it, and it is the accessibility work we consider most overdue.
• Dialog keyboard behaviour has not been exercised. Our dialogs are built to close on Escape, to move focus into themselves when opened and to return it when closed. We have confirmed how they are wired, but we test them as rendered markup rather than by driving them with a keyboard, so the behaviour itself is unverified. Please treat it as such until we say otherwise.
• The Android app has not been checked at large text sizes beyond the sign-in screen. Sign-in scales cleanly at the largest system font setting. But seventeen places across the home, hours-log, statistics and firm screens render text on a single fixed line — among them client names and the client and billing-code pickers — and we expect those to cut text off when enlarged. We have not measured them, so we are not claiming either way.
• The running-timer display updates continuously; we have not yet settled how it should be announced without becoming disruptive.

If your firm needs a conformance report or a completed accessibility questionnaire for procurement, contact us and we will tell you exactly where we stand — including what has not been tested. We would rather lose a deal than overstate this.