Accessibility at Malaka

Malaka should be designed so people can discover sailing holidays, manage Bookings, join Trips, communicate and complete professional workflows through clear and understandable interfaces — whatever device, input method or assistive technology they use.

We treat accessibility as part of how the product is built rather than something added on afterwards. That means considering keyboard use, screen readers, contrast, motion sensitivity and clear language as ordinary parts of design, not exceptions.

[Formal accessibility commitment wording to be reviewed before publication.]

Across the product we aim to keep a consistent set of principles in mind. These describe the qualities we design toward; they are not a claim of formal standards conformance.

The following describes the designed and intended behaviour of Malaka’s interfaces. It is not a statement that every current production page has been independently audited.

We aim to build with the grain of the web: native HTML first, with ARIA used only where a native element cannot express the meaning. The intention is that assistive technologies receive an accurate description of the interface.

Malaka’s sea, clay and sand palette is chosen to stay readable. We aim for strong contrast, comfortable type sizes, generous spacing and a clear hierarchy, with restraint on all-caps text and no tiny “fine print”.

Content should remain usable when you increase browser zoom or text size. Layouts are built to reflow rather than break, and ordinary content should not force horizontal scrolling.

Status is never signalled by colour alone

Where the product shows a state, it pairs colour with text and an icon so the meaning does not depend on colour perception:

Animation should be decorative or supportive — never the only way essential information is conveyed. We respect the operating system’s reduced-motion preference, and we avoid scroll hijacking that takes control away from the reader.

If you have enabled “reduce motion” on your device, the gentle transitions on this page are switched off automatically.

Forms are where accessibility matters most, so we aim to keep them predictable:

A good error message explains three things

What happened, what needs your attention, and how to fix it. We aim to avoid bare messages like “Invalid input”. You can see this approach in action in the feedback form below — submitting it empty produces a clear, linked error summary.

Maps

Malaka may use maps for destinations and Trip context. A map should never be the only way to reach essential information — key details should also be available as text or a list. We don’t name a specific map provider here.

Images & galleries

Informative editorial images should carry meaningful alt text; purely decorative images should be hidden from assistive technology so they don’t add noise. Gallery controls should be keyboard accessible, and important facts about a Boat or Experience should exist as text — not locked inside an image.

Video & audio

[Media accessibility requirements to be defined for any future video/audio content.]

Data tables

Admin and workspace screens may use data tables. These should have meaningful headers, announce sortable state where relevant, offer a workable mobile alternative, and never convey information through cell colour alone.

The Skipper Calendar

The calendar is a complex interface. The principle we hold to is that a month grid must not be the only route to events — the same information should also be available as a list or agenda view.

Charts in Reports & Analytics

Charts should be supported by textual summaries and, where appropriate, a data-table alternative, with meaningful labels and no colour-only distinctions between series.

Drag & drop

Where drag-and-drop exists, it should not be the only way to perform an action; a keyboard or button alternative should be available.

On smaller screens interfaces should reflow rather than overflow sideways, keep touch targets comfortable, preserve visible labels, and avoid hiding essential information behind hover-only interactions. Full-screen sheets should be used carefully, with a clear way to close them.

We aim for comfortable touch targets rather than quoting a formal pixel requirement, which would imply a standard we have not yet adopted.

Malaka includes uploaded and generated documents, and it is worth being honest about an important distinction: the accessibility of files uploaded by other parties can vary and is outside our control. Documents that Malaka itself generates should be designed for accessibility where the format technically supports it.

[Accessibility status of generated / downloadable document formats to be verified.]

We do not claim that every downloadable file is accessible, and we make no PDF/UA conformance claim, unless and until that has been tested and recorded.

Sign-up, log-in and password-reset flows should be accessible, and security measures should not unnecessarily block the use of assistive technology. Any anti-bot mechanism must be assessed for accessibility if it is implemented.

[Any anti-bot / verification mechanism must be evaluated for accessibility if implemented.]

We don’t build authentication on this page, and we never expose security secrets here.

Digital accessibility and physical accessibility are not the same thing. Being able to use Malaka’s website easily does not by itself determine whether a particular Boat, marina, route or sailing Trip is physically accessible.

Physical accessibility varies

Physical accessibility can differ significantly depending on the Boat, the boarding arrangement, the marina, the destination, the weather and sea conditions, and how a Trip is configured. For that reason we do not promise universal physical accessibility.

How practical information is kept private

A Traveller may be able to provide limited practical or accessibility information for their own Trip where it is relevant. This is optional and contextual, remains private, is shared only according to operational need, and is not a broad medical intake. How this data is handled is governed by our Privacy Policy (Page 98).

Asking about physical accessibility for a Trip

An honest accessibility page names its limitations rather than claiming there are none.

[Verified accessibility limitations and remediation status to be added after accessibility testing.]

This prototype deliberately does not fabricate specific issues or remediation dates. Once accessibility testing has taken place, verified limitations will be listed here. Each future entry is intended to follow a consistent format:

Future entries will also record any available workaround and the date each item was last reviewed. Remediation dates are not invented in this prototype.

If something on Malaka gets in your way, we want to hear about it. You can open a short form to describe what happened. It asks only for what helps us understand the problem — and never for medical information.

If a digital barrier stops you from completing something important, Malaka should provide a route to Support so you can still get it done. That might include:

Formal conformance details will be published here once they have been established and verified. Until then, these fields are intentionally left as placeholders rather than filled with an unverified target.

Legal requirements

[Applicable accessibility legal requirements to be confirmed for Malaka’s operating jurisdictions and services.]

How we intend to test

A future testing programme may combine automated testing, keyboard testing, screen-reader testing, zoom and reflow testing, colour and contrast review, and manual UX testing. We do not claim any of these have yet taken place.

[Actual testing process and results to be provided. User testing methodology to be provided.]

Third-party services

Some connected services and content — such as payments, identity verification, maps, embedded media or external documents — have their own accessibility characteristics that can affect your experience and should be assessed. We don’t name providers here.

[Third-party accessibility dependencies to be verified.]

For accessibility questions, or to ask for an alternative way to complete a task, you can reach Malaka through the product’s supported contact routes.

Accessibility connects to several other Malaka policies. Privacy and data questions, in particular, are handled separately.