Accessibility Statement

Tripistic is used by guides, drivers, office staff, and travellers with a wide range of abilities and devices. Accessibility is a product requirement, not an afterthought.

Our commitment

We design, build, and test Tripistic against the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA. That commitment covers the marketing website, the authenticated application, public booking pages, the customer portal, and email templates.

Conformance status

Partially conformant with WCAG 2.2 Level AA. "Partially conformant" means most of the platform meets the standard and known exceptions are listed below with remediation plans.

We reassess conformance each release cycle and after any significant interface change.

What we have implemented

Perceivable

• Text and interactive elements meet a minimum 4.5:1 contrast ratio in both light and dark themes; large text and UI components meet 3:1.
• Colour is never the only means of conveying status — booking, payment, and operational states pair colour with a text label or icon.
• All meaningful images carry alternative text; decorative graphics are hidden from assistive technology.
• Content reflows to a 320 CSS pixel viewport without horizontal scrolling, and remains usable at 200% zoom.
• Wide content such as comparison tables and code blocks scrolls within its own container rather than breaking the page.

Operable

• Every interactive element is reachable and usable with a keyboard alone, in a logical order.
• Visible focus indicators on all focusable elements, in both themes.
• A "Skip to content" link is the first focusable element on every page.
• No keyboard traps; dialogs return focus to their trigger on close.
• Animation respects prefers-reduced-motion — motion is reduced to a simple fade or removed entirely.
• No content flashes more than three times per second.
• Target sizes meet the WCAG 2.2 minimum for touch interaction.

Understandable

• The page language is declared, and headings follow a single logical hierarchy.
• Form fields have programmatically associated labels; errors are described in text, announced to assistive technology, and explain how to fix the problem.
• Navigation, terminology, and component behaviour are consistent across the platform.
• Authentication does not depend on a cognitive function test such as transcribing a distorted image.

Robust

• Semantic HTML with ARIA used only where a native element cannot express the pattern.
• Live regions announce asynchronous updates such as save confirmations and operational status changes.
• Tested against current versions of major browsers and screen readers.

Assistive technology support

We test with:

Known limitations

Assessment approach

We combine automated testing in CI, manual keyboard and screen-reader passes on primary flows, contrast verification of every design token pair, and review of new components against a per-component accessibility checklist. We supplement internal testing with periodic third-party audits.

Feedback and enforcement

If you encounter a barrier, tell us — accessibility reports are prioritised.

Email support@tripistic.com with the subject line "Accessibility", and include the page or feature, what you were trying to do, your browser and assistive technology, and the barrier you hit.

If you are not satisfied with our response, you may escalate to legal@tripistic.com. We will also provide information in an alternative format on request.

Standards referenced

• WCAG 2.2 Level AA (primary target)
• EN 301 549 (European accessibility requirements for ICT)
• Section 508 of the US Rehabilitation Act
• European Accessibility Act, for services in scope