Access Contact Detail Screen with Full Accessibility Support
All interactive elements on the contact detail and edit screens must conform to WCAG 2.2 AA accessibility standards, which all four partner organizations have identified as a non-negotiable requirement. The semantics wrapper widget provides semantic labels for every interactive element. Touch targets meet the minimum 44×44pt size as enforced by the accessible touch target wrapper. The accessible modal sheet is used for any overlays. Live region announcements are triggered for dynamic content changes such as validation errors appearing. The contrast ratio validator ensures all text meets minimum contrast ratios against the dark background. The cognitive load rule engine ensures the edit form does not present more than 7 fields per screen section.
User Story
Audience Summaries
Universal accessibility is not a differentiator for this product — it is a contractual and legal baseline. All four partner organizations (NHF, Blindeforbundet, HLF, and Barnekreftforeningen) have explicitly classified accessibility as a MUST HAVE, with Blindeforbundet requiring screen reader support as their primary access modality. This story ensures the contact detail and edit screens meet WCAG 2.2 AA standards from day one, which is the only economically rational approach: retrofitting accessibility post-launch costs three to five times more than building it in, risks contract termination with partners whose coordinators cannot use the product, and exposes the development team to legal liability under Likestillings- og diskrimineringsloven. Beyond risk mitigation, accessible design improves usability for all coordinators — clearer touch targets, logical focus order, and cognitive load management benefit every user, not only those with disabilities.
Delivering this story on schedule protects partner relationships and ensures the product is legally compliant at launch.
This story is critical priority with zero functional dependencies, meaning it can be scheduled in parallel with other contact screen work and should be treated as a quality gate rather than an additive feature. The scope covers six acceptance criteria spanning VoiceOver/TalkBack semantic labelling, live region announcements for validation errors, 44×44pt touch target enforcement, 4.5:1 contrast ratio compliance, cognitive load field grouping (max 7 fields per section), and logical keyboard focus order. Cross-functional coordination is required with designers to audit contrast ratios against the dark background theme, and with QA to establish accessibility testing procedures using both iOS VoiceOver and Android TalkBack. Partner involvement from Blindeforbundet for screen reader acceptance testing is strongly recommended before sign-off.
Risk: accessibility testing is time-consuming and often reveals cascading layout issues; buffer this story's QA phase accordingly. The cognitive load rule engine (max 7 fields per section) may require design review if the contact form has more than 7 fields in a single section.
Implementation is infrastructure-level work that must be applied consistently across both the contact detail and edit screens. Key components: (1) Semantics wrapper widget applied to every interactive element with meaningful labels — these must include dynamic values (e.g., contact name, field current value) not just static role labels. (2) Accessible touch target wrapper enforcing minimum 44×44pt hit areas — audit all icon buttons and compact list items which commonly fall short. (3) Live region announcements for validation errors — in Flutter this means using `Semantics(liveRegion: true)` on the error message widget so screen readers announce errors without requiring refocus.
(4) Contrast ratio validator — all text on the dark background must be tested programmatically; flag any color tokens that fall below 4.5:1 for normal text or 3:1 for large text. (5) Cognitive load rule engine — implement as a form section builder that groups fields into labelled sections, enforcing a max-7-fields-per-section rule via configuration rather than hardcoding. (6) Focus order — verify widget tree order matches visual layout; use `FocusTraversalOrder` if the visual and semantic orders diverge. Automated accessibility testing via Flutter's `AccessibilityGuideline` matchers should be added to the widget test suite for regression coverage.
Acceptance Criteria
- Given a coordinator uses VoiceOver (iOS) or TalkBack (Android), When they navigate the contact detail screen, Then every interactive element is announced with a meaningful semantic label including the contact's name, field values, and action buttons
- Given a coordinator uses the edit contact screen with a screen reader, When a validation error appears on a field, Then a live region announcement is triggered informing the user of the specific error without requiring them to refocus
- Given any button or tappable element on the contact detail or edit screens, When I inspect its rendered size, Then it meets the minimum 44×44 points touch target requirement
- Given the edit screen renders field labels and values against the dark background, When the contrast ratio is measured, Then all text meets the minimum 4.5:1 contrast ratio for normal text and 3:1 for large text
- Given the edit form contains more than 7 fields, When it is rendered, Then fields are grouped into labelled sections with a maximum of 7 fields per section to reduce cognitive load
- Given I navigate the contact detail screen using keyboard-only navigation (accessibility mode), When I tab through interactive elements, Then focus order follows a logical top-to-bottom, left-to-right sequence matching the visual layout
Business Value
All four partner organizations — NHF, Blindeforbundet, HLF, and Barnekreftforeningen — explicitly identified universal accessibility as a MUST HAVE requirement, with Blindeforbundet specifically requiring screen reader support as their primary access modality. Failing to build accessibility into the contact detail and edit screens from the start would require expensive retrofitting, exclude a significant portion of the coordinator user base with disabilities, and potentially expose the development team to legal liability under Norwegian universal design legislation (Likestillings- og diskrimineringsloven). Accessibility is architecture, not a feature add-on.
Components
- Contact Detail Screen ui
- Edit Contact Screen ui
- Semantics Wrapper Widget ui
- Live Region Announcer ui
- Accessible Touch Target Wrapper ui
- Contrast Ratio Validator Service service
- Accessible Modal Sheet Widget ui
- Plain Language Error Display ui
- Cognitive Load Rule Engine service
- Design Token Theme infrastructure