Plain language before technical language.
Accessibility
Accessibility is part of resilience.
RelayHub is being designed so ordinary people can understand, operate, recover, and use local-first communication infrastructure without needing specialist technical knowledge.
Commitment
Usability is not a decoration.
RelayHub should be usable by people who do not understand Linux, networking, Reticulum, radio, cryptography, or infrastructure operations. The system may be sophisticated internally, but the edge should remain understandable.
Readable layouts on desktop and mobile.
Status explained with text, not colour alone.
Keyboard-accessible core flows where practical.
Recovery instructions that are findable under stress.
Offline and printable help where practical.
Support paths that do not require hidden technical knowledge.
Continuous improvement as RelayHub matures.
Focus areas
Accessibility means clear operation and clear recovery.
The most important accessibility work is helping users understand what state the system is in, what still works, what changed, and what safe action comes next.
Plain language
RelayHub should explain outcomes, risks, limitations, and next actions without forcing users to understand Linux, Reticulum, networking, or radio engineering.
Mobile usability
Setup, recovery, status, support, and documentation should work on phone-width screens wherever practical.
Keyboard navigation
Important website and product flows should not depend solely on mouse or touch interaction.
Readable contrast
Text, buttons, cards, warnings, and status indicators should remain readable and visually clear.
Non-colour-only status
Ready, Local-Only, Degraded, Updating, Recovery, and Error states should use text and meaning, not just colour.
Recovery under stress
Recovery help should be clear, calm, visible, and usable when the user is tired, worried, offline, or under pressure.
Status clarity
Status must never depend on colour alone.
RelayHub status language should combine clear labels, plain text, consistent meaning, and visual distinction. Colour may help, but colour must not be the only way meaning is communicated.
The node is working for its current supported role.
Local operation may still work even when wider connectivity is unavailable.
The node is running but has not found reachable peers yet.
Some capability is reduced, paused, blocked, or unavailable.
The node is applying, validating, or rolling back an update.
The node needs guided attention before normal operation resumes.
Recovery accessibility
Recovery must be usable under pressure.
A recovery flow that only works for confident technical users is not enough. Recovery should be visible, calm, local-first where practical, and written for people who may be stressed or offline.
Recovery rule
Critical recovery should not depend on hidden knowledge, terminal-only instructions, colour-only warnings, or documentation that disappears when the internet fails.
Low-connectivity usability
Help should remain available when networks fail.
RelayHub is local-first. Accessibility must therefore consider offline, local-only, degraded, and intermittent connectivity as normal conditions rather than unusual edge cases.
- Critical setup and recovery help should not require continuous internet.
- Local-only should be explained as a valid operating state, not automatic failure.
- Offline or printable documentation should be available where practical.
- Status pages should explain what still works when wider connectivity fails.
- Support export should be possible locally where product state allows.
Known limitations
Accessibility will need testing, not assumptions.
RelayHub is still in design and validation planning. Accessibility claims must be tested with real browsers, real devices, real recovery flows, and real users.
- The public website is still evolving.
- Future RelayOS interfaces are not yet product-supported.
- Accessibility testing will need real users and real devices.
- Some third-party services, such as anti-spam challenges, may have their own accessibility behaviour.
- Not every planned product interface exists yet.
- Claims about future accessibility must be validated before being treated as supported.
Design standards
What RelayHub should keep improving.
Website
The public website should remain readable, responsive, keyboard navigable, and clear about product status, limits, and contact paths.
RelayOS
Future local web UI flows should support setup, status, recovery, update, reset, transfer, and support export without unnecessary technical language.
Documentation
Documentation should be structured, searchable, printable where useful, versioned, and written for both ordinary users and deeper operators.
Feedback
Tell us what makes RelayHub harder to use.
Accessibility feedback helps improve the website, documentation, future product interfaces, recovery flows, and support materials.
Helpful feedback includes
- The page or screen where the issue occurred.
- What you expected to happen.
- What actually happened.
- Your browser and device type, if you are comfortable sharing it.
- Whether the issue affected keyboard, screen reader, mobile, contrast, wording, or recovery.
- A screenshot only if it does not expose private information.