Build token-driven component theme factories
epic-visual-design-accessibility-theme-integration-task-004 — Implement factory methods inside the theme builder that produce ButtonTheme, ElevatedButtonThemeData, InputDecorationTheme, CardTheme, and ChipTheme instances entirely from design tokens. Each factory must read radius, padding, elevation, and color values from the DesignTokenProvider, ensuring no component theme contains magic numbers.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 3 - 413 tasks
Can start after Tier 2 completes
Handles integration between different epics or system components. Requires coordination across multiple development streams.
Implementation Notes
Organise factories as static methods on a ComponentThemeFactory class, each accepting a ColorScheme and DesignTokenProvider. For MaterialStateProperty-based colors (e.g., disabled state), define a sealed class or extension to avoid repetitive MaterialStateProperty.resolveWith boilerplate. The DesignTokenProvider should expose typed getters (double radius(TokenRadius), EdgeInsets spacing(TokenSpacing), double elevation(TokenElevation)) rather than raw keys to prevent typos. For InputDecorationTheme, ensure the focusedBorder uses the primary color token at full opacity and the enabledBorder uses outline token at 0.5 opacity — this aligns with Blindeforbundet and NHF's high-contrast requirements.
ChipTheme must set labelStyle from the text theme's labelMedium role, not a hardcoded TextStyle.
Testing Requirements
Unit tests (flutter_test): (1) each factory returns a non-null theme object, (2) changing a spacing token changes the button padding, (3) changing the radius token changes card border radius, (4) minimum touch target 48 dp is present in button minimumSize, (5) no Color literals exist in factory output (inspect via reflection/toString). Widget tests: render each component type with the produced theme and verify tap targets meet 48×48 dp via tester.getSize(). One golden snapshot per component type at default and high-contrast tokens to catch visual regressions. 85% coverage target on the factory file.
One or more of the four partner organisations may supply brand primary colors that cannot be paired with any standard foreground at 4.5:1 contrast (for example, a mid-range hue that is too light for dark text and too dark for white text). Rejecting these colors programmatically could cause a political dispute with the organisation and delay the feature.
Mitigation & Contingency
Mitigation: Before implementation begins, run all four organisations' existing brand primary colors through the contrast-ratio-validator against both white (#FFFFFF) and a near-black (#1A1A1A). Share the results with each organisation's contact person ahead of the theme builder sprint so any problematic colors can be adjusted collaboratively with advance notice.
Contingency: If an organisation insists on a non-compliant brand color, produce a compliant near-match (lightened or darkened along the hue's luminance axis) and present both options with contrast ratio evidence. Document the adjusted token in the manifest with an explicit note that the original brand color was non-compliant, and obtain written sign-off from the organisation.
Flutter's ThemeData contains over 30 component theme properties. If the theme-builder only addresses the most common ones (Button, InputDecoration, Card) and leaves others at Flutter defaults, downstream feature teams may unknowingly use default-themed widgets that do not meet sizing or contrast requirements.
Mitigation & Contingency
Mitigation: Produce a full inventory of all ThemeData component theme properties and map each to either a token-driven override or an explicit pass-through decision documented in the theme builder code. Prioritise the inventory by frequency of use in the existing codebase (identified via Grep). Include a check in the CI lint runner that flags widgets using Flutter default component themes not covered by the theme builder.
Contingency: If the full inventory scope exceeds the sprint budget, ship with the highest-frequency components covered and add a tracked backlog item for each uncovered component theme, pairing with a temporary lint suppression comment that includes the backlog reference.