medium priority low complexity frontend pending frontend specialist Tier 2

Acceptance Criteria

The proxy-audit-badge (component 111-proxy-audit-badge) is rendered on activity items where proxyFlag is true and is absent on items where proxyFlag is false
The badge has a Semantics widget wrapper with a descriptive label (e.g., 'Registered by proxy') that is read aloud by VoiceOver and TalkBack
If the badge is tappable (e.g., shows a tooltip or navigates), its touch target is at least 44x44pt using GestureDetector or InkWell with a SizedBox constraint
If the badge is purely informational (non-interactive), it is excluded from the focus order using `ExcludeSemantics` or `Semantics(excludeSemantics: true)` to avoid cluttering screen reader navigation
Badge placement is consistent: right-aligned within the item tile or immediately after the type label — matches design specification
No layout overflow occurs when both the proxy badge and a long typeLabel are present on the same tile at 320pt screen width
Widget test verifies badge is present for proxyFlag=true and absent for proxyFlag=false

Technical Requirements

frameworks
Flutter
data models
ActivityHistoryItem (proxyFlag: bool)
performance requirements
Conditional rendering uses a simple `if (item.proxyFlag)` guard — no expensive computation
security requirements
Badge must accurately reflect the proxyFlag value from the database — do not infer proxy status from other fields
ui components
111-proxy-audit-badge (existing component, import and reuse — do not duplicate)

Execution Context

Execution Tier
Tier 2

Tier 2 - 518 tasks

Can start after Tier 1 completes

Implementation Notes

Before implementing, read the existing 111-proxy-audit-badge widget source to understand its public API — specifically whether it requires a label parameter or derives its own semantics internally. If the badge already has its own Semantics wrapper with a hardcoded label, do not add a duplicate outer wrapper (this causes duplicate announcements on screen readers). If the badge is interactive, confirm with the design team whether tapping it should show a tooltip ('This activity was recorded by a coordinator on behalf of a peer mentor') — this is valuable for WCAG 2.2 understanding criterion. Keep the integration minimal: one `if (item.proxyFlag) const ProxyAuditBadge()` statement inside the existing _ActivityHistoryTile row.

Do not restructure the tile layout for this change.

Testing Requirements

Two widget tests: (1) pump _ActivityHistoryTile with proxyFlag=true — assert that the proxy-audit-badge widget is found in the widget tree using `find.byType(ProxyAuditBadge)`; (2) pump with proxyFlag=false — assert the badge is NOT found. Additionally, add a Semantics test using `tester.getSemantics(find.byType(ProxyAuditBadge))` to verify the label is non-empty when the badge is present.

Run on both iOS and Android semantic trees if possible.

Component
Activity History List
ui low
Epic Risks (3)
medium impact medium prob scope

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.

medium impact medium prob technical

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.

low impact high prob scope

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.