high priority low complexity testing pending testing specialist Tier 2

Acceptance Criteria

Test suite covers: button renders in the expected position (top-right corner or as per design spec)
Test verifies that a single tap calls Navigator.pop() exactly once
Test asserts Semantics label is 'Close' (or the project-standard string) using tester.getSemantics()
Test asserts Semantics hint is 'Closes this dialog' (or equivalent per design spec)
Test verifies touch target size is ≥ 44×44dp by inspecting the RenderBox size
Test verifies a dismissal SemanticsAction or equivalent announcement fires on tap
AccessibilityAuditRunner executes on the widget tree containing ModalCloseButton with zero violations
All tests pass on both iOS (Cupertino semantics) and Android (Material semantics) test profiles
Test file follows project test naming convention and is placed in the correct test directory

Technical Requirements

frameworks
Flutter
flutter_test
performance requirements
Tests must complete in under 10 seconds per test case
ui components
ModalCloseButton (component under test)
AccessibilityAuditRunner (test utility)

Execution Context

Execution Tier
Tier 2

Tier 2 - 518 tasks

Can start after Tier 1 completes

Implementation Notes

Wrap ModalCloseButton in a minimal MaterialApp + Navigator scaffold for each test to isolate the widget cleanly. Use a MockNavigatorObserver (extend NavigatorObserver) to capture pop() calls without needing a real route stack. For the dismissal announcement test, check that SemanticsAction.dismiss is available on the node OR that the Semantics onTap fires and announces. Keep test setup in a shared setUp() function to avoid duplication.

Do not test internal implementation details — test observable behavior only (position, tap effect, semantics, size).

Testing Requirements

Widget tests only (no integration tests in this task). Use WidgetTester to pump ModalCloseButton inside a MaterialApp with a Navigator. Use tester.tap() for interaction, tester.getSemantics() for Semantics assertions, and inspect RenderBox via tester.getSize() for the 44×44dp check. Mock Navigator.pop() using a NavigatorObserver.

Run AccessibilityAuditRunner.audit(tester) and assert the result contains no violations. Cover at least 5 distinct test cases as described in acceptance criteria.

Component
Modal Close Button
ui low
Epic Risks (3)
high impact high prob technical

Flutter's ModalBottomSheet and showDialog do not automatically confine VoiceOver or TalkBack focus to the modal's subtree on all platform versions. Background content may remain reachable by screen readers, confusing users and violating WCAG 2.2 criterion 1.3.1.

Mitigation & Contingency

Mitigation: Wrap modal content in an ExcludeSemantics or BlockSemantics widget for background content. Use a Semantics node with liveRegion on the modal container and manually request focus via FocusScope after the modal animation completes. Test on both iOS (VoiceOver) and Android (TalkBack) during widget development.

Contingency: If platform-level focus trapping is unreliable, implement a custom modal wrapper widget that uses a FocusTrap widget (available in Flutter's internal tooling) and an Overlay entry with semantics blocking on the dimmed background layer.

medium impact medium prob technical

On iOS, the system-level swipe-back gesture (UINavigationController) can bypass PopScope and GoRouter's gesture suppression, meaning users can still accidentally dismiss screens via swipe even after the component is implemented. This breaks the gesture-free contract for motor-impaired users.

Mitigation & Contingency

Mitigation: Set popGestureEnabled: false in GoRouter route configurations where swipe-back is suppressed. Test specifically against Flutter's CupertinoPageRoute, which respects this flag, and verify that GoRouter generates Cupertino routes on iOS rather than Material routes with gesture enabled.

Contingency: If go_router's popGestureEnabled flag does not propagate correctly, wrap affected routes in a WillPopScope replacement (PopScope with canPop: false) and file a bug with the go_router maintainers. Document the workaround in the navigation-route-config component for future maintainers.

medium impact medium prob scope

The feature description implies migrating all existing ModalBottomSheet and dialog call sites across the app to use the new accessible helpers, which is a cross-cutting change. Scope underestimation could mean the epic finishes the new components but leaves many call sites un-migrated, leaving the accessibility promise partially broken.

Mitigation & Contingency

Mitigation: Audit all existing modal call sites at the start of the epic (grep for showModalBottomSheet, showDialog, showCupertinoDialog) and add the count to the task list. Treat migration as explicit tasks, not an implied post-step.

Contingency: If migration scope grows beyond the epic's estimate, create a follow-up tech-debt epic scoped only to call-site migration, and gate the release on at minimum all flows used by the accessibility user-story acceptance criteria being migrated.