Build EncryptedFieldDisplay widget masked state
epic-contact-detail-and-edit-supporting-ui-task-007 — Create the EncryptedFieldDisplay Flutter widget. In its default state, render the field value as masked bullets with a lock icon and a descriptive semantic label. Ensure the lock icon button meets 44x44pt touch target. Apply design token colours that meet WCAG AA contrast on dark and light themes.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 1 - 540 tasks
Can start after Tier 0 completes
Implementation Notes
Create lib/widgets/encrypted_field_display.dart. Keep it a StatelessWidget; expose: `const EncryptedFieldDisplay({required this.label, required this.ciphertext, required this.onRevealRequested, super.key})`. The bullet string can be a fixed '••••••••' (8 bullets) regardless of actual field length — this prevents length-based information leakage. Wrap the lock IconButton in a SizedBox(width: 44, height: 44) and set padding: EdgeInsets.zero on the IconButton itself; use iconSize: 20 so the visual icon is smaller than the touch target.
Use Semantics(label: 'Reveal $label', child: ...) around the IconButton and set excludeSemantics: true on the Row's bullet Text widget. For design tokens, reference the existing AppColors / AppTextStyles already used in the project — do not hardcode hex values. The ciphertext parameter is accepted so the parent can pass it down for later decryption, but this widget itself never calls decryptField.
Testing Requirements
Widget tests (flutter_test): (1) render EncryptedFieldDisplay and assert the bullet string is visible and the label is visible; (2) assert lock icon button has a hit-testable area of at least 44x44 via tester.getSize(); (3) tap lock icon and verify onRevealRequested callback is called exactly once; (4) assert no plaintext is in the widget tree by verifying find.text() for any non-bullet, non-label string returns zero matches; (5) test in both ThemeMode.light and ThemeMode.dark and assert no contrast violations using SemanticsController. Golden tests are optional but recommended for visual regression.
The encrypted-field-display confirmation dialog adds interaction steps that may frustrate coordinators who access sensitive fields frequently, leading to requests to bypass the flow or skip read-receipt logging, which would violate Blindeforbundet's compliance requirements.
Mitigation & Contingency
Mitigation: Design the confirmation dialog to be as minimal as possible (one clear sentence, single confirm action) and ensure it does not reappear for the same field within a single screen session. Validate the UX with Blindeforbundet coordinators during the TestFlight pilot before finalising.
Contingency: If coordinators raise strong objections, escalate to Blindeforbundet's data protection officer to determine whether a lighter confirmation pattern (e.g., biometric confirmation instead of dialog) satisfies their compliance obligation.
The activity-history-list infinite scroll requires paginated Supabase queries. Contacts with hundreds of activities (e.g., an HLF peer mentor with 380 annual registrations) could cause slow page loads or memory pressure on older devices if pagination boundaries are set too large.
Mitigation & Contingency
Mitigation: Use a page size of 20 records with cursor-based pagination. Implement list item recycling using Flutter's ListView.builder. Benchmark memory usage with 400+ item simulation on a low-end test device before TestFlight release.
Contingency: If performance degrades on older devices, reduce page size to 10 and add a time-window filter (last 30 days, last 6 months, all) so the default view loads a manageable record count for most coordinators.
The cognitive load rule engine (from the Cognitive Accessibility feature) mandates no more than 7 fields per screen section. If a contact model has more than 7 editable fields, the edit-contact-screen layout must be split into sections, adding complexity not accounted for in the initial scope.
Mitigation & Contingency
Mitigation: Audit the full contact field list from all four organisations before implementation. Group fields into logical sections (personal info, contact details, affiliation) so no single section exceeds 7 fields. Use the cognitive-load-rule-engine component if it is already delivered by the Cognitive Accessibility feature.
Contingency: If the rule-engine component is not yet available, implement a simple manual section layout with accordion-style expansion for less-frequently edited fields to stay within the 7-field guideline without blocking delivery.