Accessible Expense Type Selection for Users with Disabilities
The expense type picker and mutual exclusion feedback must meet WCAG 2.2 AA requirements as required by all three workshop organisations. The accessibility service layer manages semantic labels, focus order, and live region announcements. Each expense type card has a minimum touch target of 44x44 dp, a descriptive semantic label combining the type name and its current selection state, and sufficient colour contrast between text, icons, and backgrounds. Disabled (mutually excluded) types are announced as unavailable with the reason included in the label. When the user selects a type or a mutual exclusion triggers, a live region announces the state change. The cognitive load rule engine ensures that no more than six expense types are shown on a single screen to prevent choice paralysis, with overflow handled via a 'More options' expansion.
User Story
Audience Summaries
Accessible expense type selection is a Phase 1 MUST HAVE requirement across all three workshop organisations — Blindeforbundet, NHF, and HLF — each serving users with distinct disability profiles including visual impairment, cognitive and motor impairments among stroke survivors, and hearing-related co-conditions. The expense registration flow is one of the highest-frequency features in the application. Failing to meet WCAG 2.2 AA compliance here would directly exclude a significant portion of the intended user base from the app's primary value-generating workflow, undermining the core mission of reducing administrative burden for all peer mentors regardless of ability. Full compliance also protects all three organisations from regulatory exposure and reputational risk associated with inaccessible public-facing digital services.
This story has hard dependencies on two upstream expense type selection stories and cannot enter development or testing until both are stable. Delivery requires involvement from accessibility specialists and QA engineers with hands-on VoiceOver and TalkBack experience across iOS and Android devices — automated tooling alone is insufficient to meet the acceptance criteria. The cognitive load rule limiting visible expense types to six requires UX sign-off on the 'Show more' expansion pattern and explicit handling for organisations with large type catalogues. This story is Phase 1-blocking: slippage delays go-live readiness across all three organisations simultaneously.
Stakeholder communication must clarify that accessibility compliance criteria apply to production builds, not internal demos, and that compliance evidence will be required for handover sign-off.
Implementation requires an accessibility service layer managing semantic labelling, focus order, and ARIA live region updates across the expense type picker. Each card must expose an accessible name combining type name, current selection state, and — when mutually excluded — the specific reason (e.g., 'Mileage, not selected, unavailable: conflicts with Public Transport'). Touch targets must be enforced at 44×44dp minimum via layout constraints, not just padding. All text-to-background colour combinations must be audited to meet 4.5:1 contrast for normal text and 3:1 for large text.
DOM focus order must follow visual top-to-bottom, left-to-right traversal. The cognitive load rule engine must cap rendered types at six with a clearly labelled 'Show more' control that expands the list without a page transition. Live region announcements (aria-live='polite') must fire on both selection changes and mutual exclusion triggers without displacing focus. Full testing must cover VoiceOver swipe navigation on iOS and TalkBack on Android, including state change announcements and 'Show more' expansion paths.
Acceptance Criteria
- Given VoiceOver or TalkBack is active, when the expense type picker renders, then each card's accessibility label reads '[Type Name], [selected/not selected], [unavailable: reason if applicable]'
- Given the peer mentor navigates with VoiceOver swipe gestures, when focus moves between expense type cards, then focus order follows visual top-to-bottom, left-to-right order
- Given a mutual exclusion is triggered, when the state changes, then a live region announcement notifies the user without moving focus away from the current element
- Given the expense type cards are rendered, when measured, then each interactive element has a minimum touch target size of 44 × 44 dp
- Given the organisation has more than six expense types, when the picker renders, then only six types are shown initially with a clearly labelled 'Show more' control
- Given the contrast ratio of text against card background is measured, when tested, then all text-background combinations meet a minimum ratio of 4.5:1 for normal text and 3:1 for large text
Business Value
All three workshop organisations serve users with diverse accessibility needs — Blindeforbundet requires screen reader support, NHF serves users with cognitive and motor impairments including stroke survivors, and HLF users may have hearing-related co-conditions. Accessibility is listed as a MUST HAVE in Phase 1 for all organisations. Failing to meet WCAG 2.2 AA in the expense registration flow would exclude a significant portion of the user base from one of the highest-frequency features, directly undermining the app's core value proposition of lowering administrative burden.