ACCESS / INCLUSIVE DESIGN
Accessibility
The lower sky is shared, and the tools used to understand it should be usable by as many people as possible. We are working towards WCAG 2.2 Level AA across Layer400’s public pages and core account journeys.
1. Our approach
Accessibility is part of design, writing, testing and support rather than a one-off compliance task. We aim for clear headings and language, keyboard operation, visible focus, sufficient contrast, scalable text, reduced-motion support, labelled controls and status messages that do not rely on colour alone.
This statement describes a target and current approach; it is not a claim that every route has passed an independent conformance audit.
2. Using the live map
An interactive geographic map is inherently visual. We aim to expose the same essential current-observation details through lists, filters and text panels, so a user does not have to interpret marker position or colour alone. Map keyboard shortcuts and touch gestures can vary with the map component and browser.
Layer400 data is not a safety-of-life service. An accessible text view remains subject to the same coverage and accuracy limits described in the Data notice.
3. Known areas for improvement
- spatial relationships and dense coverage layers cannot yet be reproduced completely in a non-visual format;
- third-party map tiles and the hosted identity account interface may not match every Layer400 display preference;
- very large text or narrow windows can require more navigation and scrolling on data-heavy screens; and
- new contributor diagnostics and historical charts need continuing screen-reader and keyboard testing.
We prioritise barriers that block sign-in, security, account recovery, receiver enrolment and access to essential observation information.
4. Browser and assistive-technology support
We aim to support current versions of major browsers with common screen readers, keyboard-only use, zoom and operating-system contrast or reduced-motion preferences. Older browsers and heavily modified page styles may behave differently, but we welcome reports that help identify a practical barrier.
5. Requesting an alternative
If a guide, policy or account step is not usable, email [email protected]. Tell us the page, task, browser or assistive technology, and the format or adjustment that would help. Do not include passwords, receiver tokens or private keys.
We will consider a reasonable alternative such as plain text instructions, a structured data extract relating to your own account, or guided support where the feature and security requirements allow it.
6. Feedback and escalation
We value specific feedback from disabled users and people supporting them. We will investigate barriers and prioritise fixes according to impact. If you are unhappy with the response, ask for the issue to be reviewed and include the original reference.