Navigate Back Using Explicit Button on All Non-Root Screens
The shared PageHeader widget enforces the presence of a back button on all non-root screens via a required parameter. Swipe-to-dismiss gestures are never the sole navigation mechanism — the explicit back button is always co-present. This applies universally regardless of whether cognitive mode is enabled, as it is a baseline accessibility requirement. The requirement aligns with WCAG 2.2 SC 2.4 (Navigable) and the workshop-identified preference for vertical scroll and explicit tap-to-navigate patterns over gesture-based interaction.
User Story
Acceptance Criteria
- Given a user is on any non-root screen (i.e., not the main tab destinations), when the screen renders, then a back button is visible in the page header in a consistent location
- Given a user taps the back button, when the navigation handler fires, then the app navigates to the previous screen in the route stack without data loss
- Given a user is using cognitive mode, when they arrive on a wizard step screen, then the back button is always visible above the fold without scrolling
- Given a user has filled in form data on a wizard step, when they tap back, then the data entered on that step is preserved and visible when they return forward
- Given a non-root screen, when a developer attempts to render it without a PageHeader back button, then a lint or runtime assertion flags the missing control during development
Business Value
Workshop documentation from NHF explicitly identified 'back button over swipe navigation' as a cognitive accessibility requirement. Gesture-only navigation excludes users with motor impairments and confuses stroke patients who may not reliably remember swipe interactions. Explicit controls reduce abandonment and support calls.
Components
- Simplified Navigation Screen ui
- Cognitive Mode Service service
- Navigation Shell Widget ui
- App Router Service service