high priority medium complexity testing pending testing specialist Tier 6

Acceptance Criteria

All interactive elements (buttons, toggles, dropdowns, inputs) have non-empty semanticsLabel or Semantics widget wrapping with meaningful description
All text and icon elements meet WCAG 2.2 AA contrast ratio: minimum 4.5:1 for normal text, 3:1 for large text and UI components
All tappable targets are at minimum 44x44 dp in size (WCAG 2.5.5 Target Size)
Screen reader (TalkBack/VoiceOver) navigation order matches the visual reading order on all 6 screens
Modal dialogs (confirmation, delete) trap focus correctly — screen reader cannot navigate behind the modal
Wizard step progress is announced to screen readers when advancing between steps (e.g., 'Step 2 of 5: Credential Configuration')
All error messages are programmatically associated with their input fields (via Semantics or similar) and announced by screen readers
Loading states are announced via live region equivalent (Semantics liveRegion: true) so screen reader users know when content is loading
Status badges (Synced, Error, In Progress) are not conveyed by color alone — include text or icon with accessible label
All images and icons that convey meaning have alt text or aria-label equivalent via Flutter Semantics
A written audit report is produced listing: each screen, each issue found, severity (blocker/high/medium), fix applied or deferred

Technical Requirements

frameworks
Flutter
flutter_test
data models
accessibility_preferences
performance requirements
Semantics tree must not add perceptible rendering overhead — use ExcludeSemantics only where genuinely decorative
security requirements
Ensure no credential or PII field values are leaked via semantics tree into accessibility logs
Masked credential fields must have semanticsLabel 'Password field, value hidden' — not the actual masked value
ui components
Semantics widget wrappers on all custom components
MergeSemantics for compound widgets (label + value pairs)
ExcludeSemantics for purely decorative elements

Execution Context

Execution Tier
Tier 6

Tier 6 - 158 tasks

Can start after Tier 5 completes

Integration Task

Handles integration between different epics or system components. Requires coordination across multiple development streams.

Implementation Notes

Begin the audit by enabling Flutter's Semantics Debugger overlay (showSemanticsDebugger: true on MaterialApp) to visually inspect the semantics tree on each screen — this surfaces missing labels quickly without a physical device. For contrast auditing, extract all color values from the design token system (styles.css / Dart constants) and run them through a contrast checker against their paired background colors. Focus particularly on the status badges (Synced/Error/In Progress) which are high-risk for color-only communication. For the wizard progress indicator, wrap the step counter in a Semantics widget with liveRegion: true so VoiceOver/TalkBack announces step changes automatically.

Credential input fields should use obscureText: true in Flutter TextFormField and wrap with Semantics(label: 'API key input, value hidden'). Common Flutter pitfalls to address: IconButton with no tooltip (add tooltip: parameter), Switch without wrapping label (use SwitchListTile), custom gesture detectors missing Semantics (add onTap semantics action).

Testing Requirements

Write automated accessibility widget tests using Flutter's SemanticsController (find.bySemanticsLabel) to verify all primary interactive widgets have accessible labels on each of the 6 screens. Use flutter_test's expectLater with matchesGoldenFile for contrast-sensitive UI snapshots. Write tests verifying focus trap in modal dialogs using FocusNode traversal assertions. Manually test using TalkBack (Android) and VoiceOver (iOS) on physical device or simulator — document findings per screen in the audit report.

Run the Flutter accessibility scanner (SemanticsController.ensureSemantics) in widget tests to surface missing semantics programmatically. All blocker and high severity issues must be fixed before task is marked complete; medium issues may be deferred with ticket.

Component
Integration Setup Wizard
ui high
Epic Risks (4)
medium impact high prob technical

The multi-step Integration Setup Wizard must render different credential fields, field mapping targets, and validation rules depending on the selected integration type. If the type-specific branching logic is implemented as conditional widget trees rather than driven by the Integration Type Registry, the wizard becomes unmaintainable and adding new integration types requires UI code changes.

Mitigation & Contingency

Mitigation: Design the wizard to be metadata-driven from the Integration Type Registry from day one. Credential form fields, required field validation, and mapping target lists are all fetched from the registry, not hardcoded in widgets. Implement one integration type end-to-end first (Xledger) to validate the pattern before building the others.

Contingency: If the metadata-driven approach proves too complex for the initial delivery, implement Xledger and Dynamics as hardcoded wizard variants and create a registry-driven refactor as a follow-up technical debt ticket with a fixed deadline.

medium impact medium prob dependency

The Excluded Features Configuration Panel must wire directly into the feature flag system to suppress HLF app features. If the feature flag system does not yet expose a writable admin interface, this panel cannot save its configuration, blocking the HLF-specific acceptance criteria.

Mitigation & Contingency

Mitigation: Verify that the Organization-scoped Feature Flags feature (a declared dependency) exposes a Dart API for programmatic flag writes before starting this panel. Coordinate with the feature flags team to ensure the write API is available. If needed, schedule this panel as the last item in the epic.

Contingency: If the feature flag write API is unavailable at implementation time, store excluded features in the integration's JSONB settings column and wire them into a local feature flag provider that merges database state with the standard flag system at app startup.

high impact medium prob scope

The Field Mapping Editor's usability for non-technical org admins is high-risk. If the visual mapping interface is confusing, admins will configure incorrect mappings that cause silent data corruption in accounting exports — a serious financial risk discovered only at month-end reconciliation.

Mitigation & Contingency

Mitigation: Conduct usability testing with at least one admin user from Blindeforbundet on the field mapping editor prototype before full implementation. Provide descriptive labels and sample data values for all fields. Add a 'test mapping' preview that shows a transformed sample record before saving.

Contingency: If usability testing reveals the visual editor is too complex, implement a simplified list-based mapping editor (select app field → select external field, one row at a time) as a fallback, deferring the drag-and-drop visual editor to a future iteration.

medium impact medium prob technical

The Credential Management Form's masked fields and connection-test flow may conflict with screen reader requirements — VoiceOver and JAWS must be able to navigate the form, understand which fields are already configured, and receive feedback on connection test results without exposing credential values in accessible text.

Mitigation & Contingency

Mitigation: Design accessible semantics labels for masked fields (e.g., 'API key: configured, last 4 characters: abcd') from the start. Use Flutter's Semantics widget to provide screen-reader-specific text that differs from visual display. Test with VoiceOver on iOS and TalkBack on Android during development, not only at QA.

Contingency: If accessibility conflicts with security requirements for the credential form, implement a separate 'accessibility mode' flow where credential configuration is done through a separate confirmation step that provides more explicit semantic feedback without risk of value exposure.