The field reality we design for
Most aquaculture data is captured standing at a pond bank, not sitting at a desk. The phone is held in one hand, the other hand is holding a sampling net or a feed scoop. There is glare. There may be no signal. The user may have been awake since the 04:00 dissolved-oxygen check.
Those conditions produce the same requirements as a permanent disability does: large targets, high contrast, forgiving interactions, no reliance on precision or on colour. Designing for the field and designing for accessibility converge almost completely, which is why we treat them as one problem.
Tap targets and reachability
- Minimum size. Interactive controls clear 44 by 44 pixels. Field Mode raises that to 48 by 48 for primary actions.
- Icon-only controls. The compact icon variant is smaller by default, so any icon-only control that is a primary action is explicitly enlarged — and always carries an accessible name, since there is no visible text to fall back on.
- Spacing. Adjacent targets are separated so a mis-tap does not trigger a destructive neighbour. Destructive actions are never placed directly beside their confirming counterpart.
- Thumb zone. Primary actions sit within comfortable one-handed reach at the bottom of the viewport; the floating action stack has a documented ordering contract so new elements cannot silently overlap an existing one.
Field Mode and four-tap logging
Field Mode is a deliberately reduced surface for capturing a daily log entry. The target is four taps from opening the app to a saved entry. Fewer interactions means fewer chances to mis-tap, less scrolling, less time with the screen in the sun.
Accessibility properties that fall out of that design:
- One decision per screen, so screen reader users are not navigating a dense form.
- Numeric entry uses appropriate input modes, so the correct keypad appears without extra taps.
- Regional voice input is offered as an alternative to typing, in the user's own language.
- Every step is reversible, and no step depends on a gesture that has no button equivalent.
Announcing offline and queued states
The platform is offline-first: when connectivity drops, submissions are written to a local queue and replayed on reconnect. Accessibility-wise, the risk is a silent state change — the user taps Save, nothing visibly happens, and they cannot tell whether the entry exists.
So each transition is both shown and announced:
- Going offline announces that entries will be saved locally.
- Each queued submission confirms that it is queued, with a running count.
- Reconnecting announces the flush and its outcome, including anything that failed.
- Failures are actionable — a retry control, not a dead-end message.
Orientation, zoom and reflow
- Zoom is never disabled. The viewport declaration does not lock scale; pinch-zoom works everywhere.
- Reflow, not horizontal scroll. Content reflows to a single column at narrow widths. Wide tables become stacked cards rather than a sideways scroll region.
- Both orientations work. Nothing requires landscape or portrait.
- Safe areas are respected. Bottom navigation and floating controls honour device safe-area insets, so nothing sits under a home indicator or notch.
- Full-height layouts use dynamic viewport units, so mobile browser chrome appearing and disappearing does not clip the bottom of a screen.
Mobile gaps still open
- No mobile screen reader pass. VoiceOver on iOS and TalkBack on Android have not been manually tested by a third party. This is the largest open item on mobile.
- Charts on small screens. Dense charts remain hard to interpret at phone widths even with the tabular alternative available.
- Map interactions. Pinch and drag on the pond map and disease heatmap have no full keyboard or switch-control equivalent; the accompanying table does.
- Native shell. The packaged mobile shell inherits the web surface, so it inherits these gaps too.