Accessibility Statement

1. Our Commitment to Accessibility

HeyMariner is committed to ensuring that its platform is accessible to all users. We believe that maritime intelligence — safety notices, regulatory guidance, port information, technical articles, and navigational data — must be available to every maritime professional regardless of whether they use assistive technologies, have visual, hearing, motor, or cognitive impairments, or access the platform under challenging physical conditions. Accessibility is not an optional enhancement for us; it is a core design requirement.

We target conformance with the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA as our baseline standard. This means we aim to meet all Level A and Level AA success criteria in WCAG 2.1. We go beyond minimum compliance where the specific context of maritime professional use demands it — for example, in our approach to colour contrast in chart viewing contexts and in our support for low-light night-mode use on the bridge.

This accessibility statement describes our current state of conformance, the specific features we have implemented, the known limitations that still exist, and our plans for improvement. We update this statement at least annually and following any significant change to the platform. The current review date is stated at the end of this document.

We welcome feedback from users about accessibility barriers on HeyMariner. If you encounter anything that prevents you from using any part of our platform, please contact us. The contact details are provided in Section 11 of this statement.

2. What Accessibility Means for HeyMariner

Accessibility on HeyMariner is not simply a compliance exercise. The context in which our platform is used creates specific accessibility requirements that go beyond the standard desktop web browsing scenario that most accessibility guidelines assume.

Maritime professionals use HeyMariner in demanding physical environments: on the bridge of a vessel at sea, in the engine room, in a port control centre, on a berth in direct sunlight, or on a small handheld device with a cracked screen in a port agent's office. The platform must be usable in low ambient light conditions, in high-glare conditions, on screens of widely varying sizes, with hands that may be wearing gloves, with limited internet bandwidth at sea, and under time pressure where slow, complex interactions are not acceptable.

In addition to these environmental factors, seafarers and maritime professionals with permanent disabilities use HeyMariner as a professional tool. A seafarer who is deaf or hard of hearing needs the same access to audio content as a hearing seafarer. An officer with a motor impairment who relies on voice control or keyboard navigation must be able to access every feature of the platform. A mariner with low vision must be able to read charts, table data, and regulatory text without losing critical information.

The intersection of these environmental and disability-related accessibility needs means that our accessibility implementation must be robust, thoroughly tested, and continuously improved. We cannot afford to treat accessibility as a feature that benefits a minority of users — in the maritime context, environmental accessibility barriers affect nearly every user at some point in their professional life.

3. Accessibility Standards We Follow

HeyMariner's accessibility programme is designed to meet or exceed the requirements of the following standards and legal frameworks:

3.1 WCAG 2.1 Level AA

The Web Content Accessibility Guidelines 2.1 published by the W3C Web Accessibility Initiative (WAI) are the internationally accepted technical standard for web accessibility. We target Level AA conformance across all four WCAG principles: Perceivable (information must be presentable in forms users can perceive), Operable (interface components must be operable), Understandable (information and operation must be understandable), and Robust (content must be interpretable by assistive technologies). We apply WCAG 2.1 success criteria across all pages and features of the platform.

3.2 Section 508 (United States)

Section 508 of the Rehabilitation Act of 1973, as amended, requires that electronic and information technology developed, procured, maintained, or used by the US federal government must be accessible to people with disabilities. HeyMariner's headquarters and corporate operations are based in Jersey City, New Jersey. We apply Section 508 standards as a framework for US accessibility compliance, ensuring that our platform is accessible to users who access maritime intelligence from federal government contexts and to US-based maritime professionals who are entitled to reasonable accommodation under US disability law.

3.3 Americans with Disabilities Act (ADA)

The Americans with Disabilities Act of 1990, and particularly Title III (which covers places of public accommodation), has been interpreted by US courts and the Department of Justice to extend to websites and digital services. We take ADA compliance seriously as a legal obligation and as an ethical commitment to the maritime professionals and general public who use HeyMariner from the United States. Our accessibility programme is designed to ensure that HeyMariner constitutes an accessible place of public accommodation under the ADA.

3.4 EN 301 549 (European Accessibility Standard)

EN 301 549 is the European standard for accessibility requirements for ICT products and services. It incorporates WCAG 2.1 Level AA as its web content accessibility requirement and extends to other ICT including software and documentation. Because HeyMariner serves maritime professionals across European flag states and port states, and given that the European Accessibility Act (EAA) extends accessibility obligations to private sector digital services from June 2025, we include EN 301 549 compliance in our accessibility programme. This standard aligns closely with WCAG 2.1 AA for web content and does not create significantly different requirements in that context.

4. Accessibility Features We Have Implemented

The following accessibility features are currently implemented across the HeyMariner platform. We document these features to help users understand what assistance is available and to establish a baseline for our ongoing improvement process.

4.1 Keyboard Navigation

Every interactive element on HeyMariner — navigation menus, buttons, form fields, links, modal dialogs, dropdown selectors, tabs, and accordion components — is reachable and operable using keyboard navigation alone, without requiring a mouse or touch input. Users can navigate forward through interactive elements using the Tab key and backward using Shift+Tab. Within components such as menus and tab panels, arrow keys are used for navigation in accordance with ARIA Authoring Practices Guide (APG) patterns. The Enter key and Space bar activate focused buttons and links. The Escape key closes modal dialogs and dropdown menus, returning focus to the element that triggered the overlay. At no point should a keyboard user encounter a focus trap from which they cannot escape, except in the case of modal dialogs where focus is intentionally contained while the dialog is open (and can be dismissed via Escape).

4.2 Screen Reader Compatibility

HeyMariner is built on semantic HTML5 elements that convey meaning to assistive technologies without requiring supplementary ARIA. Where native HTML semantics are insufficient for complex interactive components — such as dynamic search results, live vessel position updates, or multi-step form wizards — we apply ARIA roles, properties, and states in accordance with the ARIA specification and the APG. ARIA live regions are used to announce dynamic content changes to screen reader users without requiring a page refresh. We do not use ARIA in a manner that overrides or conflicts with native HTML semantics. Every form input is associated with a descriptive label, either visible or programmatically linked via aria-labelledby or aria-label. Error messages for form validation are associated with the relevant input field via aria-describedby so that screen readers announce the error when focus returns to the field.

4.3 Colour Contrast

All body text on HeyMariner meets the WCAG 2.1 Level AA contrast ratio minimum of 4.5:1 against its background. Large text (18pt or 14pt bold and above) meets the Level AA minimum of 3:1. Interactive elements such as buttons, links, and form borders meet or exceed the Level AA non-text contrast requirement of 3:1 against adjacent colours. Our primary colour palette — mariner-dark (#081324), mariner-navy (#0D2137), mariner-teal (#0CBDBD), mariner-light (#EEF8FA), and mariner-muted (#64748B) — has been selected and tested for contrast compliance. Text rendered in mariner-teal on dark backgrounds (mariner-dark or mariner-navy) meets the 4.5:1 ratio. We do not use colour as the sole means of conveying information; status indicators, form validation states, and alerts use both colour and text labels or icons.

4.4 Text Resizing

HeyMariner is designed to support text resizing up to 200% of the default size without loss of content or functionality. We use relative units (rem and em) rather than fixed pixel values for font sizes throughout the platform, so that browser-level font size changes are respected. Page layouts use flexible CSS and responsive breakpoints so that enlarged text does not cause content to overflow its container or become clipped. Users can increase text size using browser zoom functions or OS-level accessibility settings without encountering horizontal scrollbars or overlapping content at standard viewport widths.

4.5 Alternative Text for Images

All informative images on HeyMariner — including photographs of ships, port facilities, maritime equipment, and geographic features, as well as diagrams, charts, and infographics — include descriptive alternative text that conveys the meaningful content of the image. For complex images such as route maps or cargo stowage plans, we provide extended descriptions either in the alt attribute or in adjacent text. Decorative images that do not convey content use empty alt attributes (alt="") so that screen readers skip them. Maritime chart images used in articles are accompanied by textual descriptions of the relevant navigational information they illustrate, so that screen reader users can access the substantive content even where the chart itself cannot be fully described in a brief alt attribute.

4.6 Focus Indicators

All focusable elements on HeyMariner display a visible focus indicator when they receive keyboard focus. We use a consistent, high-contrast focus ring (a 2px solid outline in mariner-teal, #0CBDBD) that is visible against both light and dark backgrounds. We have not suppressed the browser's native focus outline without replacing it with an equally visible custom indicator. Focus indicators are displayed for links, buttons, form inputs, and all interactive components. The focus indicator style is consistent across the platform so that keyboard users always know where focus is located.

4.7 Skip Navigation Links

Every page on HeyMariner includes a "Skip to main content" link as the first focusable element on the page. This link is visually hidden by default but becomes visible when it receives keyboard focus, allowing keyboard-only users and screen reader users to bypass the site header and navigation menu and jump directly to the main content area. This is particularly important on HeyMariner because the global navigation menu contains a large number of maritime categories, and requiring users to tab through all navigation items on every page would create an unacceptable burden. On pages with long jump navigation (such as this accessibility statement), an additional skip mechanism within the page is provided.

4.8 Form Labels and Error Messages

All form inputs across HeyMariner — search fields, registration forms, port inquiry forms, contact forms, and data filter controls — are associated with visible text labels. We do not use placeholder text as a substitute for a persistent label. Where a form field has specific formatting requirements (such as an IMO number, a vessel call sign, or a date range), these requirements are described in the label or in associated hint text before the user attempts to submit the form. Form validation errors are displayed as descriptive text messages that identify which field has an error and explain what the correct input should be. Error messages are associated with their respective fields programmatically so that screen readers announce the error when the user returns to the field. We do not rely on colour alone to indicate form errors.

4.9 Table Headers for Data Tables

Data tables used throughout HeyMariner — including vessel data tables, port call data, regulatory comparison tables, IMPA catalog tables, and tidal data — use properly marked-up table headers with the HTML th element and appropriate scope attributes. This allows screen readers to associate each data cell with its corresponding row and column headers, making complex tabular data navigable and comprehensible via assistive technology. We do not use tables for layout purposes; all layout is achieved through CSS flexbox and grid. For tables with complex header structures, we apply ARIA headers attributes where the th/scope combination is insufficient to fully convey the header relationships.

4.10 No Time-Limited Content

HeyMariner does not impose session timeouts on users browsing content or filling in forms without providing a prior warning and the ability to extend the session. We recognise that maritime professionals may need to leave a browser window open for extended periods while attending to duties on the bridge or in the engine room. Where authenticated sessions do time out for security reasons, users are warned before the timeout occurs and are given the option to extend their session without losing their work. We do not use auto-advancing carousels, timed modal dialogs, or any interface element that automatically changes without user interaction and cannot be paused.

4.11 Maritime Chart Alternative Descriptions

Charts, maps, and navigational graphics used on HeyMariner present particular accessibility challenges because the spatial information they convey is not easily reduced to a brief text alternative. For every chart or navigation map used in editorial content, we provide a structured text description that covers: the geographic area depicted; any traffic separation schemes, recommended routes, or restricted areas shown; the location and type of any navigational hazards marked; and the scale and orientation of the chart. Where the chart is illustrating a specific incident, passage, or routing decision, the text description captures the relevant navigational information from the chart that is necessary to understand the editorial context. This means that a screen reader user who cannot see the chart image will still have access to the substantive navigational information it contains.

5. Known Accessibility Limitations

Despite our commitment and the features described above, HeyMariner currently has a number of known accessibility limitations. We document these honestly because we believe users deserve to know what barriers they may encounter, and because transparency about limitations is the first step towards resolving them. For each limitation, we describe an available alternative where one exists.

5.1 Interactive AIS Live Maps

The live AIS vessel tracking map — which displays real-time vessel positions, vessel details, and traffic density — is a canvas-based interactive component that does not currently provide full keyboard navigation for map pan and zoom controls. Users can access vessel position data in tabular form via the "List View" alternative, which displays the same vessel information in an accessible HTML table. We are working on a keyboard-accessible map navigation layer and expect to complete this work by Q1 2027.

5.2 ECDIS Overlay Components

Some editorial content includes interactive ECDIS-style chart overlays that allow users to pan and zoom chart images. These components do not currently expose full ARIA navigation controls and may not be fully operable by keyboard or screen reader users. All content illustrated by ECDIS overlays is also presented in text form, and static chart images with descriptive alt text are provided as fallbacks. Improving the accessibility of these components is part of our 2026-2027 accessibility roadmap.

5.3 Third-Party Embedded Data Widgets

Some sections of HeyMariner embed data widgets from third-party maritime data providers, including weather routing overlays and port traffic dashboards. We do not control the accessibility of these third-party components, and some may not meet WCAG 2.1 Level AA. Where third-party widgets are used, we provide text-based alternatives or supplementary information so that the essential data is accessible without relying on the embedded widget. We have notified our third-party providers of our accessibility requirements and are evaluating alternative providers where existing providers cannot meet WCAG 2.1 AA.

5.4 Legacy PDF Documents

PDF documents published on HeyMariner before July 2026 may not be fully tagged for accessibility and may present challenges for screen reader users. All new PDF documents published from July 2026 onwards are created with accessibility tagging and include document structure, reading order, alt text for images, and meaningful headings. If you need an accessible version of a specific older PDF document, please contact us and we will provide the content in an alternative accessible format.

6. Maritime-Specific Accessibility Considerations

The maritime professional environment creates accessibility needs that go beyond the standard disability-related concerns addressed by WCAG. We have implemented specific features to address these maritime-specific accessibility contexts.

6.1 Bridge and Night Mode

Officers standing watch on the bridge at night must protect their night-adapted vision. Standard bright white interfaces — which are optimal for most contexts — are hazardous on the bridge at night because they destroy night vision adaptation and reduce the officer's ability to see navigational lights and hazards in the surrounding sea area. HeyMariner provides a dark/night mode that switches to a low-luminance interface with reduced blue-light emission. Night mode can be activated manually from the user settings menu or set to activate automatically based on the device's system dark mode setting. In night mode, all text contrast ratios are verified to still meet WCAG 4.5:1 requirements against the dark background, and no content or functionality is lost.

6.2 High-Contrast Mode for Chart Viewing

HeyMariner supports the operating system's high-contrast accessibility mode on all supported platforms. In Windows High Contrast Mode and on macOS with "Increase Contrast" enabled, our interface adapts to use the system's high-contrast colour scheme, with all interactive elements remaining visible and operable. For users who view maritime charts under conditions of high ambient light (on a sun-exposed bridge wing or in a port office with direct sunlight on the screen), we also provide a high-brightness chart display mode that boosts contrast ratios beyond the standard WCAG minimum to improve legibility under glare.

6.3 Glare and Outdoor Use

Maritime professionals frequently access digital content outdoors — on the bridge wing, on deck, on a berth, or in an outdoor port facility. Outdoor use under direct sunlight significantly reduces effective screen contrast. HeyMariner's interfaces are designed with outdoor legibility in mind: body text contrast ratios are set comfortably above the WCAG minimum to provide a margin of usability in degraded viewing conditions, and we avoid interface elements that depend on subtle colour variations that become invisible in bright light.

6.4 Small Screen and Limited Bandwidth

Many mariners access HeyMariner on small-screen devices — smartphones and tablets — using satellite or mobile data connections with limited bandwidth and variable latency. Our platform is fully responsive and optimised for small screens, with all content readable without horizontal scrolling at viewport widths from 320px. Images are served at appropriate resolution for the device's display density and connection speed. We do not auto-play video or audio content, which would consume bandwidth without the user's deliberate choice. Core content — articles, regulatory text, port data — is accessible even on slow connections because we minimise blocking resources and ensure that text content loads before heavy media assets.

7. Testing and Evaluation Methods

HeyMariner uses a combination of automated and manual testing methods to evaluate and maintain accessibility conformance. No single testing method is sufficient on its own to identify all accessibility barriers, so we use multiple approaches in combination.

Automated testing is carried out using the axe-core accessibility engine, integrated into our development workflow and run as part of our continuous integration pipeline. Automated testing identifies a significant proportion of WCAG success criterion violations — particularly those relating to HTML structure, ARIA usage, and colour contrast — before code is merged. However, automated testing cannot identify all accessibility issues; issues relating to keyboard operability, screen reader announcements, cognitive accessibility, and the quality of alt text require human evaluation.

Manual testing is conducted by our accessibility team using assistive technologies on real devices. Manual testing cycles are conducted on all significant new features before release and on existing features on a rolling basis. Our manual testing protocol follows the WCAG 2.1 Level AA success criteria as a checklist and includes structured testing of all interactive components against the ARIA APG patterns for those component types.

We also conduct periodic accessibility audits by external accessibility specialists who bring fresh perspectives and specialist expertise to the evaluation. External audit findings are documented, prioritised, and tracked through our accessibility improvement backlog. The results of completed external audits are summarised in our annual accessibility report.

8. Assistive Technologies Supported

HeyMariner is developed and tested for compatibility with the following assistive technologies. We test these configurations as part of our regular manual testing cycle:

Where an issue is discovered with a supported assistive technology configuration, it is logged as a high-priority defect and addressed in the next release cycle. If you use an assistive technology not listed above and encounter an accessibility barrier, please report it — we will investigate and, where feasible, extend our test coverage to include your configuration.

We follow the WCAG Understanding documents and the ARIA APG for all component implementations, which means that our support should extend beyond the explicitly tested configurations to any compliant assistive technology that correctly implements the relevant accessibility APIs.

9. Mobile Accessibility

A substantial proportion of HeyMariner's users access the platform on mobile devices — smartphones and tablets — often in the maritime operational environment. Mobile accessibility is therefore a primary consideration rather than an afterthought.

HeyMariner's mobile interface is fully responsive and is designed to meet WCAG 2.1 Level AA on mobile browsers. Touch targets — buttons, links, and interactive controls — are sized to at least 44x44 CSS pixels to be reliably activatable by users with motor impairments or when using a touchscreen with gloves or in poor physical conditions. We do not rely on multi-finger gestures, complex swipe patterns, or motion-based interactions as the sole means of accessing any feature.

HeyMariner is tested with VoiceOver on iOS and TalkBack on Android as primary mobile screen reader configurations. We test using a range of physical devices at different screen sizes. Mobile testing is included in our release cycle for all significant features.

Content is presented in a single-column layout on small screens to eliminate horizontal scrolling. Navigation menus collapse to a mobile-friendly format that is fully keyboard and screen reader accessible. Form inputs are configured with appropriate input types (tel, email, number) and autocomplete attributes to assist users who rely on predictive text or autofill, which reduces the burden of text entry for motor-impaired users on small touch keyboards.

10. Third-Party Content Accessibility

HeyMariner uses a number of third-party services and components that contribute content to the platform. These include maritime data providers, weather service APIs, mapping libraries, and embedded social content. We cannot guarantee the accessibility conformance of third-party content or components, as we do not control their implementation.

Our approach to third-party accessibility is as follows: we assess the accessibility of third-party components before integration and prefer providers who can demonstrate WCAG 2.1 Level AA conformance. Where a third-party component is not fully accessible, we provide accessible alternatives that give users equivalent access to the underlying information. We include accessibility requirements in our vendor contracts and procurement criteria. We escalate accessibility deficiencies to third-party providers as a priority issue.

Third-party content delivered via iframes — such as embedded video from maritime training providers — is subject to the same accessibility expectations. Where third-party video is embedded, we require captioning to be available. Where captioning is not provided by the third party, we provide a transcript of the video content as an alternative.

11. Feedback and Contact

We genuinely want to hear about accessibility barriers on HeyMariner. If any part of the platform is inaccessible to you, please contact us. We will investigate your report, provide a response, and work to resolve the barrier or provide an accessible alternative.

12. Formal Complaints Procedure

If you are not satisfied with the response you receive to an accessibility complaint, you may escalate your complaint using the following procedure. First, request a formal review by emailing us at heymariner@gmail.com with the subject line "Accessibility Formal Complaint." Your complaint will be reviewed by a senior member of the team, and you will receive a substantive response within fifteen business days.

If you remain unsatisfied following the formal internal review, you may contact the relevant external enforcement authority for your jurisdiction. In the United States, accessibility complaints about websites may be filed with the U.S. Department of Justice Civil Rights Division. In EU member states, national accessibility enforcement bodies established under the Web Accessibility Directive and European Accessibility Act have jurisdiction. In the United Kingdom, the Equality and Human Rights Commission handles discrimination complaints under the Equality Act 2010.

13. Timeline for Improvements

We are committed to continuous improvement of HeyMariner's accessibility. The following improvements are planned and scheduled:

• Q3 2026: Complete PDF accessibility tagging for all documents published since launch. Provide accessible HTML alternatives for all regulatory documents.
• Q4 2026: Implement fully keyboard-accessible alternative navigation for interactive port maps, including keyboard-accessible zoom controls and a map-to-table toggle accessible from keyboard only.
• Q1 2027: Upgrade third-party AIS map component to a version that exposes full ARIA navigation support, or replace with an accessible in-house implementation.
• Q2 2027: Complete accessibility upgrade of all ECDIS overlay components, including full keyboard navigation and screen reader announcements for chart overlays.
• Ongoing: Conduct accessibility audits of all new features before release. Maintain automated accessibility testing in the continuous integration pipeline. Conduct annual manual audits of all primary user flows with all supported assistive technology configurations.

14. Last Review Date

This accessibility statement was last reviewed and updated on June 19, 2026. The next scheduled review is June 2027. Interim updates will be made promptly following any significant change to the platform that affects accessibility, or following the resolution of any known accessibility limitation described in this document.

This statement was prepared in accordance with the W3C's guidance on writing accessibility statements. The conformance status described in this statement reflects our assessment at the review date and is based on our internal testing results and the findings of our most recent external audit.