Explain transfers without relying on line colors
The journey card distinguishes Line 4 from Line 8 only by color. Riders using grayscale or a screen reader cannot tell where to change.
- Focused work estimate
- 1h 15m + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Mobile accessibility · Information design · Compose
Estimated field mix
- Accessibility60%
- Mobile40%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
The fictional Northline commuter app plans bus and rail trips from synthetic timetable and alert feeds. Riders save journeys and choose optional reminders. The scope excludes ticket purchases, safety guarantees, and continuous location collection.
Setup prerequisites
- Synthetic timetable with explicit time zones and service dates
- Departure, alert, and permission adapters with failure fixtures
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
Acceptance criteria
- Each leg shows mode, line label, destination, and boarding/alighting stops in reading order.
- Transfers state walking and waiting time in text.
- Large text and grayscale preserve every required leg distinction.
Implementation constraints
- Keep decorative map graphics out of the essential accessible description.
Verification to include
- Read a two-transfer fixture with assistive navigation and compare spoken order to itinerary order.
- Use grayscale and large text; a canceled leg must remain identifiable without its color or icon.
Deliverables
- Accessible journey-leg card and device walkthrough
Rollout and recovery
Release text semantics with the existing card layout first; revert visual changes independently if leg details become clipped.
Value of the work
For the engineer: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design.
For the team: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.