Accessibility Statement

1. Our commitment

Cabica Ltd is committed to making the platform usable by as many people as possible, including people who use a screen reader, navigate by keyboard, need larger text, or cannot use a mouse or a precise touch.

This matters more than usual here. A taxi is often the accessible option — the thing someone uses precisely *because* other transport does not work for them. A booking app that a blind passenger cannot use has failed at the one job that mattered most.

We aim to meet Web Content Accessibility Guidelines (WCAG) 2.2, Level AA across every surface: the passenger app, the driver app, the operator booking websites, the dispatch console and this website.

2. Where we stand legally

3. How accessible the platform is right now

Partially conformant with WCAG 2.2 Level AA. Some parts do not fully conform, and they are listed in the next section.

That wording is deliberate and it is the honest one. "Fully conformant" would require a complete audit of every screen against all 56 Level AA criteria, by someone qualified, with assistive technology. That has not happened yet. Claiming it anyway would be both untrue and, under the EAA, a compliance failure in itself.

4. What we have checked, and what we fixed

A code-level accessibility review was carried out across all surfaces in August 2026. It looked at semantic structure, form labelling, keyboard operation, focus management, status announcements and touch target sizes. It did not include a full manual pass with a screen reader on every screen.

Found and fixed:

• The passenger booking website's address fields had no accessible name. The visible label was an unlinked `<span>`; the only name reaching a screen reader was the placeholder, which vanishes the moment you type. Someone using a reader was left in an unnamed box halfway through a booking. Now properly labelled (WCAG 4.1.2, 3.3.2).
• The address suggestions were unreachable by keyboard in any sensible way and unannounced. Rebuilt to the ARIA combobox pattern: arrow keys to move, Enter to choose, Escape to dismiss, and a live region that says how many suggestions appeared (WCAG 2.1.1, 4.1.3).
• The fare appeared silently. It arrives asynchronously after both addresses are set, so a screen reader user filled the form, heard nothing, and pressed a button whose label had changed to include a price they were never told. Now a polite live region (WCAG 4.1.3).
• Submission errors were visual only. Now announced as an alert (WCAG 4.1.3).
• Name and phone fields had no autocomplete tokens, so a browser could not fill in what it already knew (WCAG 1.3.5).
• The passenger app's icon-only buttons were unlabelled — back, send, call, message, theme, "use my location", "save this place", "remove stop". A screen reader announced "button" for all of them. Every one now has a label describing the action, and the shared component takes the label as a required argument so the compiler asks at each new call site (WCAG 4.1.2).
• The passenger app's in-field icons were 28dp touch targets, below the 48dp minimum. The touch area is now expanded to 48dp without changing what is drawn (WCAG 2.5.8).

Checked and already correct:

• Every page declares its language, and the operator sites take theirs from the tenant's locale (WCAG 3.1.1).
• The marketing site has a skip-to-content link.
• Images carry alt text; decorative icons are correctly marked as decorative rather than given noise labels.
• The driver app's icon buttons were all already labelled.
• Form fields in the booking flow wrap their control in a `<label>`, so the visible text and the programmatic name are the same string.
• Both apps support the system dark theme, and both respect the operating system's text size.

5. Known problems

These are the things we know are not right. Listing them is not an excuse for them; it is so you know before you hit one, and so we can be held to fixing them.

6. If you are an operator

Your obligations under the Equality Act — and the EAA if you serve EU passengers — are yours, not ours. What we can do is make sure the software is not the reason you fall short. Some of it, though, is in your hands:

• Brand colours. Check your primary and accent colours against your background. A gold-on-white pairing that looks smart can fail contrast badly, and someone with low vision cannot read your fares.
• Your own content. "About us" text, custom place names and notes are yours. Write in plain language and do not rely on colour alone to convey meaning.
• Anything you add. A chat widget or booking plugin you drop onto your site is yours to make accessible, and yours to declare.
• Accessibility requirements in bookings. The platform records wheelchair-accessible vehicle needs and assistance requirements as capabilities on a booking. Use them — refusing an assistance dog is unlawful, and the platform will not stop a dispatcher who ignores the flag.
• Your own statement. If you trade in the EU, you need your own accessibility statement. You may reuse this one as a starting point; it must describe your site, not ours.

7. Tell us when something does not work

This is the part that actually improves things. If you hit something that stops you using the platform:

You do not need to know the WCAG criterion. "I cannot book a taxi with my screen reader" is a complete and useful report.

If you are not happy with our response, you can contact the Equality Advisory and Support Service (EASS) in the UK. In the EU you can complain to the market surveillance authority in your country under the European Accessibility Act.

8. How this statement was prepared

This statement was prepared on 8 August 2026 following a self-evaluation of the platform, carried out as a code-level review against WCAG 2.2 Level AA across the passenger app, driver app, operator booking website, dispatch console and marketing site.

It has not been reviewed by an independent third party. When it has, this section will say so and will name them.

We review this statement whenever we make a material change to any user interface, and at least once a year.