critical priority low complexity database pending backend specialist Tier 0

Acceptance Criteria

AccessibilitySettings is an immutable Dart data class (use @immutable annotation or freezed)
Class includes: bool screenReaderOverride, AnnouncementVerbosity verbosity (enum), bool sensitiveFieldWarningEnabled, Duration announcementDelay
AnnouncementVerbosity enum has at minimum: minimal, standard, verbose values
Default constructor provides sensible defaults: screenReaderOverride=false, verbosity=standard, sensitiveFieldWarningEnabled=true, announcementDelay=500ms
toJson() returns a Map<String, dynamic> with all fields serialized to JSON-compatible primitives
fromJson(Map<String, dynamic>) factory constructor correctly deserializes all fields
fromJson handles missing keys gracefully by falling back to defaults (for forward/backward compatibility)
Duration is serialized as integer milliseconds in JSON
copyWith method is available for immutable updates
All fields are documented with inline dartdoc comments explaining their effect on screen reader behavior

Technical Requirements

frameworks
Flutter
Riverpod
data models
AccessibilitySettings
AnnouncementVerbosity
performance requirements
toJson/fromJson must be synchronous and complete in under 1ms for a single settings object
security requirements
No sensitive user data stored in accessibility settings — only preference flags and durations

Execution Context

Execution Tier
Tier 0

Tier 0 - 440 tasks

Implementation Notes

Prefer manual toJson/fromJson over code generation to avoid adding build_runner dependency unless it already exists in the project. If the project already uses freezed or json_serializable, use those for consistency. Store Duration as int milliseconds: 'announcementDelayMs': delay.inMilliseconds. For fromJson safety: use (json['screenReaderOverride'] as bool?) ??

false pattern for each field. Place this file in lib/src/accessibility/models/accessibility_settings.dart. The AnnouncementVerbosity enum should be in the same file or a sibling file. This model is purely a data container — keep it free of any Flutter widget or platform dependencies.

Testing Requirements

Write unit tests covering: (1) default construction produces expected defaults, (2) toJson produces correct map structure, (3) fromJson round-trips perfectly (serialize then deserialize equals original), (4) fromJson with missing keys uses defaults, (5) copyWith correctly overrides individual fields, (6) Duration millisecond serialization is correct. Use flutter_test. No mocking required for this pure data class.

Epic Risks (2)
high impact medium prob technical

Flutter's SemanticsService behaves differently between iOS (VoiceOver) and Android (TalkBack) in edge cases — e.g., announcement queuing, focus-gain timing, and attribute support. If the facade does not correctly abstract these differences, announcements may be silent or misfired on one platform, causing regression on the other platform to go unnoticed until device testing.

Mitigation & Contingency

Mitigation: Write platform-divergence unit tests early using SemanticsServiceFacade mocks. Validate announcement delivery on a physical iPhone (VoiceOver) and Android device (TalkBack) at the end of each sprint. Document known platform differences in the facade's inline API comments.

Contingency: If a platform difference cannot be abstracted cleanly, expose a platform-specific override path in the facade and implement targeted workarounds per platform, accepting the added complexity in exchange for correct behaviour.

medium impact medium prob scope

Accessibility preferences stored in local storage may need new fields as higher-tier epics are implemented (e.g., announcement verbosity, sensitive-field guard toggle). Schema changes to an already-persisted store risk data migration failures or silent defaults on existing installs, breaking user preferences.

Mitigation & Contingency

Mitigation: Design the AccessibilitySettingsRepository with a versioned JSON schema from the start, using merge-with-defaults on read so new fields fall back gracefully. Define the full expected field list upfront based on all downstream epic requirements before writing the first record.

Contingency: If migration fails on a live install, fall back to full reset-to-defaults with a one-time in-app notification informing the user that accessibility preferences have been reset and inviting them to reconfigure.