Navigation & Gesture Accessibility
Feature Detail
Description
A navigation pattern that relies exclusively on explicit tap/button interactions rather than gesture shortcuts, with a persistent back button on all screens and vertical scrolling as the only scroll axis. This directly addresses the workshop requirement to avoid swipe-to-dismiss and horizontal carousels, which are inaccessible to users with motor impairments, screen reader users, and older adults unfamiliar with gesture conventions. All modal sheets and dialogs must be dismissible via a clearly labelled close button in addition to any swipe gesture. Deep navigation paths must always show a back control. The bottom navigation bar must preserve tab state so users never lose their place when switching sections, reducing re-navigation burden for users with motor fatigue.
Analysis
Directly requested across all three workshop organisations. Improves usability for the widest range of users including motor-impaired users, older adults, and screen reader users who cannot reliably perform swipe gestures. Reduces drop-off during activity registration — the single most critical user flow.
Use StatefulShellRoute (already in current architecture) to preserve tab state. Add explicit close IconButton to every ModalBottomSheet and AlertDialog. Disable or never rely on DismissibleRoute swipe-back as the sole dismissal mechanism. Audit with Switch Access (Android) and Full Keyboard Access (iOS) to confirm all flows are operable without gestures.
Components (201)
Shared Components
These components are reused across multiple features
User Interface (59)
Service Layer (52)
Data Layer (33)
Infrastructure (54)
User Stories (14)
As a As a Peer Mentor (Likeperson)
I want the app to have been tested for navigation accessibility regressions automatically as part of each release build
So that I can trust that accessibility features I rely on will not break silently between app updates, and any regression is caught before it reaches my device
- Given a CI build is triggered, when the accessibility audit runner executes, then it checks all navigation-related widgets for missing semantic labels and reports results
- Given a developer introduces a navigation widget with a touch target below 44×44pt, when the CI build runs, then the audit fails with an error message identifying the widget, screen, and required minimum size
- Given a modal is added without a close button or focus-trap semantics, when the CI build runs, then the lint check flags the missing accessibility pattern
- +2 more
As a As a Coordinator
I want the app to have been tested for navigation accessibility regressions automatically as part of each release build
So that I can trust that accessibility features I rely on will not break silently between app updates, and any regression is caught before it reaches my device
- Given a CI build is triggered, when the accessibility audit runner executes, then it checks all navigation-related widgets for missing semantic labels and reports results
- Given a developer introduces a navigation widget with a touch target below 44×44pt, when the CI build runs, then the audit fails with an error message identifying the widget, screen, and required minimum size
- Given a modal is added without a close button or focus-trap semantics, when the CI build runs, then the lint check flags the missing accessibility pattern
- +2 more
As a As a Peer Mentor (Likeperson)
I want all primary content in the app to scroll vertically, with no required horizontal swipe to reveal hidden content or actions
So that I can access all content using a single-direction scroll motion, which is more accessible for users with motor impairments and aligns with familiar usage norms
- Given I am viewing any list screen (contacts, activities, notifications), when I scroll with one finger vertically, then all items are reachable without any horizontal scroll
- Given a list item has swipe actions (e.g., delete or archive), when I long-press the item or tap an overflow menu icon, then the same actions are available without horizontal swiping
- Given I am using switch access or keyboard navigation, when I navigate through a list, then all items and their actions are reachable using linear focus traversal without triggering scroll
- +2 more
As a As a Peer Mentor (Likeperson)
I want the app to remember my position within each tab when I switch to another tab and return
So that I do not lose my place or have to re-scroll to find where I was, which is especially important when I have a cognitive disability or am in the middle of a multi-step task
- Given I have scrolled halfway down the Contacts list, when I switch to the Home tab and then return to Contacts, then the list is scrolled to the same position without reloading
- Given I have navigated to a contact detail screen within the Contacts tab, when I switch to the Notifications tab and return to Contacts, then the contact detail screen is still displayed
- Given I am using a screen reader and return to a previously visited tab, when the tab regains focus, then the focus is restored to the element I last interacted with
- +2 more
As a As a Peer Mentor (Likeperson)
I want the screen reader focus to always land in a logical, predictable location after every navigation event, including screen pushes, pops, tab switches, and modal opens
So that I never need to manually search for where focus has gone after a transition, which would be disorienting and slow down my workflow
- Given I am using VoiceOver and I tap a contact card to open the contact detail screen, when the detail screen finishes rendering, then VoiceOver focus is on the contact's name heading at the top of the screen
- Given I am using VoiceOver on a contact detail screen and I activate the back button, when the previous screen appears, then focus is on the contact card I originally tapped
- Given I open the activity registration bottom sheet, when the sheet opens, then VoiceOver focus moves to the sheet's title or the first form field
- +2 more
As a As a Coordinator
I want all primary content in the app to scroll vertically, with no required horizontal swipe to reveal hidden content or actions
So that I can access all content using a single-direction scroll motion, which is more accessible for users with motor impairments and aligns with familiar usage norms
- Given I am viewing any list screen (contacts, activities, notifications), when I scroll with one finger vertically, then all items are reachable without any horizontal scroll
- Given a list item has swipe actions (e.g., delete or archive), when I long-press the item or tap an overflow menu icon, then the same actions are available without horizontal swiping
- Given I am using switch access or keyboard navigation, when I navigate through a list, then all items and their actions are reachable using linear focus traversal without triggering scroll
- +2 more
As a As a Coordinator
I want the app to remember my position within each tab when I switch to another tab and return
So that I do not lose my place or have to re-scroll to find where I was, which is especially important when I have a cognitive disability or am in the middle of a multi-step task
- Given I have scrolled halfway down the Contacts list, when I switch to the Home tab and then return to Contacts, then the list is scrolled to the same position without reloading
- Given I have navigated to a contact detail screen within the Contacts tab, when I switch to the Notifications tab and return to Contacts, then the contact detail screen is still displayed
- Given I am using a screen reader and return to a previously visited tab, when the tab regains focus, then the focus is restored to the element I last interacted with
- +2 more
As a As a Coordinator
I want the screen reader focus to always land in a logical, predictable location after every navigation event, including screen pushes, pops, tab switches, and modal opens
So that I never need to manually search for where focus has gone after a transition, which would be disorienting and slow down my workflow
- Given I am using VoiceOver and I tap a contact card to open the contact detail screen, when the detail screen finishes rendering, then VoiceOver focus is on the contact's name heading at the top of the screen
- Given I am using VoiceOver on a contact detail screen and I activate the back button, when the previous screen appears, then focus is on the contact card I originally tapped
- Given I open the activity registration bottom sheet, when the sheet opens, then VoiceOver focus moves to the sheet's title or the first form field
- +2 more
As a As a Peer Mentor (Likeperson)
I want to navigate backwards through the app using a clearly visible back button on every screen rather than relying on swipe gestures
So that I can use the app confidently even if I have limited fine motor control, use an assistive device, or am unfamiliar with gesture-based navigation patterns
- Given I am on any secondary or detail screen, when the screen renders, then a back button is visible in the top-left header area with a minimum touch target of 44×44pt
- Given I am using a screen reader (VoiceOver), when I navigate to the back button, then it is announced as 'Go back' or the equivalent localized label with role 'button'
- Given I tap the back button, when the action completes, then I am returned to the immediately preceding screen with focus restored to the element I was interacting with
- +2 more
As a As a Peer Mentor (Likeperson)
I want every modal bottom sheet and dialog to have a clearly visible, labelled close button that I can always activate without swiping down or tapping outside the modal
So that I can dismiss modals even if I have limited motor control, use switch access, or if the modal overlays content I need to avoid touching
- Given a bottom sheet modal opens, when the sheet finishes animating, then a close or cancel button is visible in the top area of the sheet with a minimum touch target of 44×44pt
- Given I am using VoiceOver and a modal opens, when the sheet renders, then screen reader focus automatically moves to the modal's title or first focusable element
- Given a modal is open and I activate the close button via switch access or VoiceOver double-tap, when the button is activated, then the modal is dismissed and focus returns to the element that triggered the modal
- +2 more
As a As a Peer Mentor (Likeperson)
I want the bottom navigation bar to be fully operable with a screen reader, with each tab announced by name, current state, and position within the tab set
So that I can switch between the Home, Contacts, Add, Work, and Notifications sections of the app without needing to see the screen or rely on visual cues alone
- Given I am using VoiceOver and focus on the bottom navigation bar, when I swipe through tabs, then each tab is announced with its label, selected state, and index (e.g., 'Home, tab, selected, 1 of 5')
- Given the Notifications tab has unread notifications, when VoiceOver focuses on it, then it announces the unread count (e.g., 'Notifications, 3 unread, tab, 2 of 5')
- Given I activate a tab using a screen reader double-tap, when the new screen loads, then a live region announces the screen name within 500 milliseconds
- +2 more
As a As a Coordinator
I want to navigate backwards through the app using a clearly visible back button on every screen rather than relying on swipe gestures
So that I can use the app confidently even if I have limited fine motor control, use an assistive device, or am unfamiliar with gesture-based navigation patterns
- Given I am on any secondary or detail screen, when the screen renders, then a back button is visible in the top-left header area with a minimum touch target of 44×44pt
- Given I am using a screen reader (VoiceOver), when I navigate to the back button, then it is announced as 'Go back' or the equivalent localized label with role 'button'
- Given I tap the back button, when the action completes, then I am returned to the immediately preceding screen with focus restored to the element I was interacting with
- +2 more
As a As a Coordinator
I want every modal bottom sheet and dialog to have a clearly visible, labelled close button that I can always activate without swiping down or tapping outside the modal
So that I can dismiss modals even if I have limited motor control, use switch access, or if the modal overlays content I need to avoid touching
- Given a bottom sheet modal opens, when the sheet finishes animating, then a close or cancel button is visible in the top area of the sheet with a minimum touch target of 44×44pt
- Given I am using VoiceOver and a modal opens, when the sheet renders, then screen reader focus automatically moves to the modal's title or first focusable element
- Given a modal is open and I activate the close button via switch access or VoiceOver double-tap, when the button is activated, then the modal is dismissed and focus returns to the element that triggered the modal
- +2 more
As a As a Coordinator
I want the bottom navigation bar to be fully operable with a screen reader, with each tab announced by name, current state, and position within the tab set
So that I can switch between the Home, Contacts, Add, Work, and Notifications sections of the app without needing to see the screen or rely on visual cues alone
- Given I am using VoiceOver and focus on the bottom navigation bar, when I swipe through tabs, then each tab is announced with its label, selected state, and index (e.g., 'Home, tab, selected, 1 of 5')
- Given the Notifications tab has unread notifications, when VoiceOver focuses on it, then it announces the unread count (e.g., 'Notifications, 3 unread, tab, 2 of 5')
- Given I activate a tab using a screen reader double-tap, when the new screen loads, then a live region announces the screen name within 500 milliseconds
- +2 more