🏠 Overview › 🎯 Features ›🎯 Visual Design Accessibility

Visual Design Accessibility

Feature Detail

medium complexity extracted Accessibility & Universal Design Confidence: 100%
7
Components
198
Shared
16
User Stories
Yes
Analyzed

Description

A design token system that enforces WCAG 2.2 AA contrast ratios, accessible type scales, and safe touch-target sizing across the entire app. All text, icons, and interactive controls must meet or exceed 4.5:1 contrast for normal text and 3:1 for large text and UI components. The design token layer makes these constraints machine-enforceable rather than dependent on designer vigilance. Specific requirements from the workshops include: scalable text that respects the OS dynamic type setting without breaking layouts, avoidance of thin or italic font weights for body copy, minimum 44×44 pt touch targets for all tappable elements, and sufficient spacing between interactive controls to prevent mis-taps. The existing design token system must codify all of these as non-overridable base values.

Analysis

Business Value

Meets the WCAG 2.2 AA standard required by all partner organisations and Norwegian public-sector accessibility regulations. Reduces support burden from users struggling to read or tap UI elements, and ensures the app is usable in varying lighting conditions common in field-based peer mentor work.

Implementation Notes

Define contrast-safe colour pairs in the design token system and enforce via CI lint (e.g. flutter_accessibility_lints or a custom token validator). Use TextTheme with explicit fontWeight (FontWeight.w400 minimum for body) and never apply italic to form labels. Wrap all custom tappable widgets in a sized GestureDetector or InkWell with a minimum HitTestBehavior area of 44pt.

Components (205)

User Interface (1)

ui Interactive Control Spacing System low

Service Layer (3)

service Contrast Ratio Validator Service medium service Dynamic Type Scale Service medium service Token Accessibility Enforcer medium

Data Layer (1)

data Accessibility Token Manifest low

Infrastructure (2)

infrastructure CI Accessibility Lint Runner medium infrastructure Flutter Accessibility Lint Configuration low

Shared Components

These components are reused across multiple features

User Interface (59)

ui Role Switch Widget medium Shared ui Role-Aware Bottom Navigation medium Shared ui Activity Type Selection Screen low Shared ui Speech-to-Text Field Overlay medium Shared ui Receipt Capture Widget medium Shared ui Peer Mentor Single Selector low Shared ui Proxy Audit Badge Widget low Shared ui Export Period Picker low Shared ui Contact Card Widget low Shared ui Contact Search Bar low Shared ui Peer Mentor Card Widget low Shared ui Activity History List low Shared ui Multi-Chapter Affiliation Chip Widget medium Shared ui Certification Status Badge low Shared ui Duplicate Activity Warning Dialog medium Shared ui Mentor Multi-Select Widget medium Shared ui Map Filter Panel medium Shared ui Claim Status Badge low Shared ui Export Date Range Picker low Shared ui Custom Date Range Picker low Shared ui Duplicate Activity Warning Dialog low Shared ui Proxy Activity Form medium Shared ui Proxy Peer Mentor Selector medium Shared ui Expected Return Date Picker low Shared ui Pause Activation Screen low Shared ui Pause Status Indicator low Shared ui Admin KPI Stat Widget low Shared ui Organisation Hierarchy Navigator high Shared ui Bufdir Period Selector Widget low Shared ui Export History List medium Shared ui Activity Type Donut Chart medium Shared ui Monthly Activity Bar Chart medium Shared ui Statistics Period Filter Bar low Shared ui Statistics Summary Cards low Shared ui Notification Badge Widget low Shared ui Certificate Expiry Status Indicator low Shared ui Animated Stat Card Widget medium Shared ui In-App Notification Banner low Shared ui Accessible Modal Sheet Widget high Shared ui Live Region Announcer medium Shared ui Semantics Wrapper Widget medium Shared ui Sensitive Field Warning Dialog high Shared ui Confirm Before Submit Screen medium Shared ui Inline Contextual Help Widget low Shared ui Labelled Navigation Bar low Shared ui Plain Language Error Display low Shared ui Single-Action Screen Layout medium Shared ui Wizard Progress Indicator low Shared ui Accessible Text Style System medium Shared ui Accessible Touch Target Wrapper low Shared ui Contrast-Safe Color Palette Widget medium Shared ui Accessible Bottom Navigation Bar medium Shared ui Modal Close Button low Shared ui Persistent Back Button low Shared ui Vertical Scroll Container low Shared ui Organization Card Widget low Shared ui Terminology-Aware Text Widget low Shared ui FeatureGate Widget low Shared ui Chapter Switcher medium Shared

Service Layer (52)

service Authentication Service medium Shared service Authentication Session Manager medium Shared service Biometric Authentication Service medium Shared service Biometric Authentication Service medium Shared service Biometric Authentication Service medium Shared service Permission Checker Service medium Shared service Role State Manager medium Shared service No-Access Route Guard low Shared service Activity Type Metadata Resolver low Shared service Chapter Scope Resolver medium Shared service Organisation Hierarchy Resolver medium Shared service Coordinator Notification Service medium Shared service Duplicate Activity Detection Service high Shared service Mentor Filter Service low Shared service Receipt Threshold Validator low Shared service Approval Status Notification Service medium Shared service Threshold Evaluation Service medium Shared service Declaration Encryption Service high Shared service Organization Feature Flag Service low Shared service Participant Deduplication Service high Shared service Reporting Period Service medium Shared service Activity Attribution Service low Shared service Proxy Duplicate Detection Service medium Shared service Pause Management Service medium Shared service Pause Notification Service medium Shared service Admin Export Service medium Shared service Admin Row-Level Security Guard high Shared service Organisation Hierarchy Service high Shared service User Management Service high Shared service Role Access Validator low Shared service Peer Mentor Stats Aggregator medium Shared service Push Notification Dispatcher medium Shared service Notification Preference Service low Shared service Scenario Deep-Link Router medium Shared service Scenario Notification Content Builder medium Shared service Badge Criteria Integration medium Shared service Activity Summary Aggregator low Shared service Focus Management Service medium Shared service Screen Reader Detection Service medium Shared service Sensitive Field Privacy Guard high Shared service Plain Language Content Service medium Shared service Wizard State Manager medium Shared service Tab State Manager medium Shared service Organization Route Guard medium Shared service Tenant Context Service high Shared service Label Key Resolver Service low Shared service Organization Labels Notifier medium Shared service FeatureFlagProvider (Riverpod) medium Shared service Access Scope Service high Shared service Hierarchy Aggregation Service high Shared service Hierarchy Service high Shared service Unit Assignment Service medium Shared

Data Layer (33)

data Authentication Repository low Shared data Auth Token Store low Shared data Secure Session Storage low Shared data Activity Type Cache Provider medium Shared data Receipt Storage Adapter medium Shared data Proxy Contact List Provider low Shared data Contact Repository medium Shared data Contact Detail Repository medium Shared data Peer Mentor Repository low Shared data Mentor Status Repository low Shared data Contact Chapter Repository medium Shared data Contact Cache Sync Repository low Shared data Organisation Rate Configuration Repository low Shared data Multi-Organization Data Isolator medium Shared data Bufdir Aggregation Repository low Shared data Report File Storage Client low Shared data Certification Status Repository low Shared data Peer Mentor Status Repository medium Shared data Statistics Cache Manager low Shared data In-App Notification Repository low Shared data Pause Status Record Repository low Shared data Activity Aggregation Repository medium Shared data Notification Preferences Repository low Shared data Scenario Notification Repository medium Shared data Sensitive Field Configuration low Shared data Error Message Registry low Shared data Help Content Registry low Shared data Wizard Draft Repository low Shared data Design Token Provider medium Shared data Organization Repository medium Shared data Terminology Local Cache Adapter low Shared data Organization Unit Repository high Shared data Unit Assignment Repository medium Shared

Infrastructure (54)

infrastructure Keyboard-Aware Layout Utility low Shared infrastructure Supabase Auth Client low Shared infrastructure Deep Link / OAuth Redirect Handler medium Shared infrastructure Secure Storage Adapter low Shared infrastructure Supabase Session Manager medium Shared infrastructure URL Launcher Utility low Shared infrastructure Local Storage Adapter low Shared infrastructure Supabase Activity Client low Shared infrastructure Organization Labels Provider low Shared infrastructure Supabase Client low Shared infrastructure Organisation Field Config Loader medium Shared infrastructure Speech-to-Text Adapter medium Shared infrastructure File Download Handler low Shared infrastructure Duplicate Reviewed Flag Middleware low Shared infrastructure Contact RLS Query Builder low Shared infrastructure Contact Form Validator low Shared infrastructure Design Token Theme low Shared infrastructure Organization Labels Provider low Shared infrastructure Supabase Client Provider low Shared infrastructure Search Debounce Utility low Shared infrastructure Expense Type Analytics Tracker low Shared infrastructure Receipt Image Picker Integration low Shared infrastructure CSV / JSON File Generator medium Shared infrastructure Coordinator Role Guard low Shared infrastructure Nightly Job Scheduler medium Shared infrastructure Supabase RLS Policy Configuration high Shared infrastructure Export File Storage Adapter low Shared infrastructure Supabase Storage Adapter low Shared infrastructure Peer Mentor Pause Management Service medium Shared infrastructure Push Notification Service medium Shared infrastructure fl_chart Adapter medium Shared infrastructure Push Notification Service low Shared infrastructure FCM Push Notification Sender medium Shared infrastructure FCM Notification Dispatcher medium Shared infrastructure Push Notification Dispatcher medium Shared infrastructure Supabase Realtime Subscription Service medium Shared infrastructure Organisation Data Isolation Guard low Shared infrastructure Push Notification Dispatcher medium Shared infrastructure Deep Link Handler medium Shared infrastructure QR Code Generator low Shared infrastructure Share Sheet Bridge low Shared infrastructure Semantics Service Facade medium Shared infrastructure Accessibility Design Token Enforcer medium Shared infrastructure Accessible Theme Builder medium Shared infrastructure Navigation Route Configuration medium Shared infrastructure Accessibility Live Region Announcer low Shared infrastructure Feature Flag Provider low Shared infrastructure Secure Storage Adapter low Shared infrastructure Supabase RLS Tenant Scope Configurator medium Shared infrastructure Label Key Registry low Shared infrastructure Terminology Riverpod Providers low Shared infrastructure WCAG Semantics Label Resolver low Shared infrastructure Feature Flag Key Constants low Shared infrastructure RLS Policy Manager high Shared

User Stories (16)

Organization Branding Applied Without Compromising Accessibility
medium 8 pts

As a As a Peer Mentor (Likeperson)

I want my organization's branding (colors, logo, terminology) to be applied to the app interface while ensuring all accessibility standards are maintained

So that I can use an app that feels like it belongs to my organization without sacrificing the contrast, text size, and interaction accessibility I depend on

Acceptance Criteria
  • Given a peer mentor from HLF opens the app, when the HLF brand theme is applied, then HLF's brand colors replace the default palette while all contrast ratios remain at or above 4.5:1 for body text
  • Given an organization administrator uploads a custom brand color via the theme-builder, when the color is applied as a primary button background, then the contrast-ratio-validator automatically selects a compliant foreground text color (white or dark) to maintain the 4.5:1 threshold
  • Given a peer mentor from Blindeforbundet uses the app, when the Blindeforbundet theme is active, then all accessibility-immutable tokens (minimum touch targets, minimum font weight, spacing rules) remain unchanged by the branding customization
  • +2 more
View Full Story →
Organization Branding Applied Without Compromising Accessibility
medium 8 pts

As a As a Coordinator

I want my organization's branding (colors, logo, terminology) to be applied to the app interface while ensuring all accessibility standards are maintained

So that I can use an app that feels like it belongs to my organization without sacrificing the contrast, text size, and interaction accessibility I depend on

Acceptance Criteria
  • Given a peer mentor from HLF opens the app, when the HLF brand theme is applied, then HLF's brand colors replace the default palette while all contrast ratios remain at or above 4.5:1 for body text
  • Given an organization administrator uploads a custom brand color via the theme-builder, when the color is applied as a primary button background, then the contrast-ratio-validator automatically selects a compliant foreground text color (white or dark) to maintain the 4.5:1 threshold
  • Given a peer mentor from Blindeforbundet uses the app, when the Blindeforbundet theme is active, then all accessibility-immutable tokens (minimum touch targets, minimum font weight, spacing rules) remain unchanged by the branding customization
  • +2 more
View Full Story →
Avoid Thin and Italic Fonts That Impair Readability
high 3 pts

As a As a Peer Mentor (Likeperson)

I want the app to use clear, regular-weight, upright fonts throughout — without thin font weights or italic text in body content

So that I can comfortably read content if I have dyslexia, low vision, or cognitive processing difficulties, without having to decipher stylized text

Acceptance Criteria
  • Given a peer mentor reads any body text, label, or navigation item in the app, when the text is rendered, then its font weight is 400 (Regular) or heavier — no Light (300) or Thin (100/200) weights are used
  • Given a peer mentor reads a button label, form field label, or status badge, when the text is displayed, then it is not rendered in italic style
  • Given an organization configures custom typography via theme-builder, when the selected font includes a weight below 400 for body text, then the token-accessibility-enforcer overrides it to the minimum compliant weight with a warning
  • +2 more
View Full Story →
Consistent Vertical Scrolling Layout Without Horizontal Swiping
high 5 pts

As a As a Peer Mentor (Likeperson)

I want to navigate the app using vertical scrolling and explicit back buttons — not horizontal swipe gestures — as the primary navigation paradigm

So that I can use the app reliably if I have motor impairments that make precise swipe gestures difficult, or if I use assistive devices that do not support swipe navigation

Acceptance Criteria
  • Given a peer mentor navigates the activity registration wizard, when moving between steps (date, duration, notes), then navigation occurs via clearly labeled Next/Back buttons — not by swiping horizontally
  • Given a peer mentor is on any screen with a back option, when they want to return to the previous screen, then a visible back button is present in the header — not relying solely on swipe-back gesture
  • Given a peer mentor scrolls through a long form or list, when reading content, then the scroll direction is vertical and no horizontal scrolling is required to see complete content at standard viewport width
  • +2 more
View Full Story →
Spacing System Prevents Accidental Control Activation
high 5 pts

As a As a Peer Mentor (Likeperson)

I want interactive controls to be spaced sufficiently apart so that tapping one element does not accidentally trigger an adjacent control

So that I can interact with the app accurately even with limited fine motor precision, reducing errors and frustration during activity registration and form completion

Acceptance Criteria
  • Given a peer mentor views the expense type selector with multiple option chips, when any two adjacent interactive chips are rendered, then there is at least 8 dp of gap between their respective touch target boundaries
  • Given a peer mentor uses the activity registration bottom sheet with Next and Back buttons, when both buttons are visible simultaneously, then their touch targets do not overlap and there is a minimum 8 dp gap between them
  • Given a developer adds a row of action buttons to any screen, when the interactive-control-spacing-system tokens are applied, then the layout automatically enforces minimum gaps without manual per-screen spacing work
  • +2 more
View Full Story →
Dynamic Text Scaling Without Layout Breakage
high 8 pts

As a As a Peer Mentor (Likeperson)

I want to increase the system font size in my phone's accessibility settings and have the entire app scale text correctly without content being cut off, overlapping, or becoming unreadable

So that I can use the app comfortably if I have presbyopia, low vision, or simply prefer larger text for extended use

Acceptance Criteria
  • Given a peer mentor sets their device font size to 200% in iOS/Android accessibility settings, when they open the app, then all text scales proportionally and no content is clipped, truncated without scroll access, or overlaps other elements
  • Given a peer mentor views the activity registration bottom sheet at 150% font scale, when reading field labels and button text, then all text is fully visible and the bottom sheet scrolls to accommodate the expanded content
  • Given the dynamic-type-scale-service applies a type scale, when a component uses accessible-text-style-system, then no text style uses a fixed pixel size — all sizes are responsive to the system scale factor
  • +2 more
View Full Story →
Design Token System Enforces Accessibility Constraints at Build Time
high 13 pts

As a As a Peer Mentor (Likeperson)

I want the development team to be prevented by automated tooling from introducing accessibility regressions into the visual design as the app grows

So that the app's accessibility standards remain consistently high across all future feature releases, not just during initial development

Acceptance Criteria
  • Given a developer creates a pull request that introduces a new color token combination, when the ci-accessibility-lint-runner executes, then token combinations violating contrast requirements cause the CI check to fail and the PR cannot be merged
  • Given a developer adds a new interactive widget without applying accessible-touch-target-wrapper, when flutter-accessibility-lint-config runs, then a lint warning flags the missing touch target enforcement
  • Given the accessibility-token-manifest is updated to reflect a new WCAG requirement, when the token-accessibility-enforcer runs against existing tokens, then any tokens no longer compliant with the updated manifest are flagged for remediation
  • +2 more
View Full Story →
Avoid Thin and Italic Fonts That Impair Readability
high 3 pts

As a As a Coordinator

I want the app to use clear, regular-weight, upright fonts throughout — without thin font weights or italic text in body content

So that I can comfortably read content if I have dyslexia, low vision, or cognitive processing difficulties, without having to decipher stylized text

Acceptance Criteria
  • Given a peer mentor reads any body text, label, or navigation item in the app, when the text is rendered, then its font weight is 400 (Regular) or heavier — no Light (300) or Thin (100/200) weights are used
  • Given a peer mentor reads a button label, form field label, or status badge, when the text is displayed, then it is not rendered in italic style
  • Given an organization configures custom typography via theme-builder, when the selected font includes a weight below 400 for body text, then the token-accessibility-enforcer overrides it to the minimum compliant weight with a warning
  • +2 more
View Full Story →
Consistent Vertical Scrolling Layout Without Horizontal Swiping
high 5 pts

As a As a Coordinator

I want to navigate the app using vertical scrolling and explicit back buttons — not horizontal swipe gestures — as the primary navigation paradigm

So that I can use the app reliably if I have motor impairments that make precise swipe gestures difficult, or if I use assistive devices that do not support swipe navigation

Acceptance Criteria
  • Given a peer mentor navigates the activity registration wizard, when moving between steps (date, duration, notes), then navigation occurs via clearly labeled Next/Back buttons — not by swiping horizontally
  • Given a peer mentor is on any screen with a back option, when they want to return to the previous screen, then a visible back button is present in the header — not relying solely on swipe-back gesture
  • Given a peer mentor scrolls through a long form or list, when reading content, then the scroll direction is vertical and no horizontal scrolling is required to see complete content at standard viewport width
  • +2 more
View Full Story →
Spacing System Prevents Accidental Control Activation
high 5 pts

As a As a Coordinator

I want interactive controls to be spaced sufficiently apart so that tapping one element does not accidentally trigger an adjacent control

So that I can interact with the app accurately even with limited fine motor precision, reducing errors and frustration during activity registration and form completion

Acceptance Criteria
  • Given a peer mentor views the expense type selector with multiple option chips, when any two adjacent interactive chips are rendered, then there is at least 8 dp of gap between their respective touch target boundaries
  • Given a peer mentor uses the activity registration bottom sheet with Next and Back buttons, when both buttons are visible simultaneously, then their touch targets do not overlap and there is a minimum 8 dp gap between them
  • Given a developer adds a row of action buttons to any screen, when the interactive-control-spacing-system tokens are applied, then the layout automatically enforces minimum gaps without manual per-screen spacing work
  • +2 more
View Full Story →
Dynamic Text Scaling Without Layout Breakage
high 8 pts

As a As a Coordinator

I want to increase the system font size in my phone's accessibility settings and have the entire app scale text correctly without content being cut off, overlapping, or becoming unreadable

So that I can use the app comfortably if I have presbyopia, low vision, or simply prefer larger text for extended use

Acceptance Criteria
  • Given a peer mentor sets their device font size to 200% in iOS/Android accessibility settings, when they open the app, then all text scales proportionally and no content is clipped, truncated without scroll access, or overlaps other elements
  • Given a peer mentor views the activity registration bottom sheet at 150% font scale, when reading field labels and button text, then all text is fully visible and the bottom sheet scrolls to accommodate the expanded content
  • Given the dynamic-type-scale-service applies a type scale, when a component uses accessible-text-style-system, then no text style uses a fixed pixel size — all sizes are responsive to the system scale factor
  • +2 more
View Full Story →
Design Token System Enforces Accessibility Constraints at Build Time
high 13 pts

As a As a Coordinator

I want the development team to be prevented by automated tooling from introducing accessibility regressions into the visual design as the app grows

So that the app's accessibility standards remain consistently high across all future feature releases, not just during initial development

Acceptance Criteria
  • Given a developer creates a pull request that introduces a new color token combination, when the ci-accessibility-lint-runner executes, then token combinations violating contrast requirements cause the CI check to fail and the PR cannot be merged
  • Given a developer adds a new interactive widget without applying accessible-touch-target-wrapper, when flutter-accessibility-lint-config runs, then a lint warning flags the missing touch target enforcement
  • Given the accessibility-token-manifest is updated to reflect a new WCAG requirement, when the token-accessibility-enforcer runs against existing tokens, then any tokens no longer compliant with the updated manifest are flagged for remediation
  • +2 more
View Full Story →
Touch Targets Meet Minimum Size Requirements
critical 5 pts

As a As a Peer Mentor (Likeperson)

I want all tappable elements — buttons, navigation items, checkboxes, links — to have a minimum touch target of 44×44 dp

So that I can accurately tap controls without repeated misses, even if I have reduced fine motor control, tremors, or am using the phone with gloves or a stylus

Acceptance Criteria
  • Given a peer mentor with motor impairments attempts to tap any button, icon, or interactive element, when the element is rendered, then its touch target is at least 44×44 dp
  • Given a small icon button (e.g., edit pencil, modal close) is placed in a dense layout, when the accessible-touch-target-wrapper is applied, then the visual appearance is unchanged but the hit area expands to 44×44 dp
  • Given the CI pipeline runs accessibility checks via accessibility-audit-runner, when touch target sizes are evaluated, then elements with hit areas smaller than 44×44 dp cause a lint warning or error
  • +2 more
View Full Story →
Sufficient Color Contrast for All Interactive Elements
critical 8 pts

As a As a Peer Mentor (Likeperson)

I want all text, buttons, and interactive controls to meet WCAG 2.2 AA contrast requirements (4.5:1 for normal text, 3:1 for large text and UI components)

So that I can comfortably read and interact with the app even if I have low vision, are in bright sunlight, or have age-related vision decline

Acceptance Criteria
  • Given a peer mentor views any screen in the app, when they look at body text on any background color, then the contrast ratio is at least 4.5:1 as defined by WCAG 2.2 AA
  • Given a peer mentor sees a button or interactive control, when the control label or icon is rendered, then the contrast ratio against its background is at least 3:1
  • Given the CI pipeline runs a build, when accessibility lint is executed by ci-accessibility-lint-runner, then any token combination failing the contrast threshold causes the build to fail
  • +2 more
View Full Story →
Touch Targets Meet Minimum Size Requirements
critical 5 pts

As a As a Coordinator

I want all tappable elements — buttons, navigation items, checkboxes, links — to have a minimum touch target of 44×44 dp

So that I can accurately tap controls without repeated misses, even if I have reduced fine motor control, tremors, or am using the phone with gloves or a stylus

Acceptance Criteria
  • Given a peer mentor with motor impairments attempts to tap any button, icon, or interactive element, when the element is rendered, then its touch target is at least 44×44 dp
  • Given a small icon button (e.g., edit pencil, modal close) is placed in a dense layout, when the accessible-touch-target-wrapper is applied, then the visual appearance is unchanged but the hit area expands to 44×44 dp
  • Given the CI pipeline runs accessibility checks via accessibility-audit-runner, when touch target sizes are evaluated, then elements with hit areas smaller than 44×44 dp cause a lint warning or error
  • +2 more
View Full Story →
Sufficient Color Contrast for All Interactive Elements
critical 8 pts

As a As a Coordinator

I want all text, buttons, and interactive controls to meet WCAG 2.2 AA contrast requirements (4.5:1 for normal text, 3:1 for large text and UI components)

So that I can comfortably read and interact with the app even if I have low vision, are in bright sunlight, or have age-related vision decline

Acceptance Criteria
  • Given a peer mentor views any screen in the app, when they look at body text on any background color, then the contrast ratio is at least 4.5:1 as defined by WCAG 2.2 AA
  • Given a peer mentor sees a button or interactive control, when the control label or icon is rendered, then the contrast ratio against its background is at least 3:1
  • Given the CI pipeline runs a build, when accessibility lint is executed by ci-accessibility-lint-runner, then any token combination failing the contrast threshold causes the build to fail
  • +2 more
View Full Story →