Skip to content

Feature/accessibility improvements - #348

Open
janetpius-cmd wants to merge 4 commits into
ethos-protocol:mainfrom
janetpius-cmd:feature/accessibility-improvements
Open

Feature/accessibility improvements#348
janetpius-cmd wants to merge 4 commits into
ethos-protocol:mainfrom
janetpius-cmd:feature/accessibility-improvements

Conversation

@janetpius-cmd

Copy link
Copy Markdown

Summary

  • Touch targets: fixed StatusChip (VaultCard) to meet the 48dp Android minimum; audited rest of Screens.kt/Views.swift (all else compliant); added AccessibilityScanTest.kt (ATF via Espresso) wired into a new accessibility-scan CI job.
  • Contrast: added EthosProtocolTheme(highContrast: Boolean) override for the warning/offline-banner color roles dynamic color can't guarantee WCAG AA for; added a manual contrast-sampling section to the QA checklist.
  • Font-scale snapshots: added ScreenshotFontScaleTest.kt (1.0x/1.3x/2.0x matrix over vault list, deposit, withdraw), auto-picked up by the existing verifyPaparazziDebug CI step; trimmed the checklist's font-scale section accordingly.
  • Live-region announcements: added explicit announceForAccessibility/UIAccessibility.post calls on offline↔online transitions (Android + iOS), plus a checklist step to verify it manually and a note that the Add Exponential Backoff Jitter to Reconnect Logic #254 WebSocket indicator should reuse the pattern once built.

Closes #284
Closes #285
Closes #286
Closes #287

Changes

Testing

Parity checklist

This project maintains a feature-parity table in PARITY.md that
tracks which features are implemented on iOS vs Android. Please answer the
questions below before requesting review.

  • This PR does not add, change, or remove any user-facing feature on either
    platform — no PARITY.md update needed.

    — OR —

  • This PR adds/changes/removes a user-facing feature. I have updated PARITY.md:

    • Updated the status symbol(s) for the affected row(s).
    • Added or updated "Notes" if the implementation is partial or has caveats.
    • Removed or updated any rows in the "Known gaps" table that this PR closes.

Related issues

Fix VaultCard's StatusChip (the dense row called out in the issue) to
meet the 48x48dp Android minimum touch target by wrapping it in a
Box(Modifier.sizeIn(minWidth/minHeight = 48.dp)). Audit the rest of
Screens.kt and Views.swift interactive controls (IconButtons,
notification actions, iOS toolbar buttons) and document findings in
docs/touch-target-audit.md — all were already compliant.

Add an automated regression guard: AccessibilityScanTest.kt runs the
Android Accessibility Test Framework (ATF) via Espresso's
AccessibilityChecks against VaultListScreen, wired into a new
accessibility-scan CI job in android-ci.yml so a shrinking tap target
fails the build instead of being caught manually later.
Add EthosProtocolTheme(highContrast: Boolean) which overrides the
error and tertiaryContainer/onTertiaryContainer color roles (used by
the expiring-soon warning and offline banner) with fixed values
audited to meet WCAG AA (4.5:1) contrast, since Material3 dynamic
color derives its palette from the wallpaper and can't guarantee
that for every generated palette.

Add a "Dynamic-color contrast pass" section to
docs/manual-qa-checklist.md describing how to manually sample
wallpaper-derived palettes and verify status colors, plus
docs/contrast-audit-readme.md documenting the change and why the
audit stays manual rather than automated.
Add ScreenshotFontScaleTest.kt with a Paparazzi snapshot matrix at
1.0x/1.3x/2.0x font scale for the vault list, deposit, and withdraw
flows named in docs/manual-qa-checklist.md's font-scale pass — the
portion the checklist calls out as "a good candidate to convert into
ScreenshotDarkTest/ScreenshotLightTest-style automated snapshot
coverage." Picked up automatically by the existing
verifyPaparazziDebug Gradle task, so no CI job changes were needed.

Trim the checklist's font-scale section to note the automated
coverage and narrow the remaining manual work to iOS (no snapshot
tooling wired up yet) and the 2FA screens (not yet in the matrix).
TalkBack/VoiceOver stays manual, as screen-reader behavior isn't
captured by snapshots.
Add explicit screen-reader announcements on offline<->online state
transitions: View.announceForAccessibility in VaultListScreen's
LaunchedEffect(state.isOffline) on Android, and
UIAccessibility.post(.announcement) in VaultListView's
.onChange(of: vaultStore.vaultsCacheAge == nil) on iOS. The banner
being labeled only covered the case where it's already visible on
first render; a transition while the screen is open needs an
explicit announcement call.

Add a checklist item to docs/manual-qa-checklist.md's TalkBack/
VoiceOver pass to verify both directions of the transition announce
correctly, and note that the WebSocket connection-status indicator
proposed in ethos-protocol#254 doesn't exist yet but should reuse this pattern.
docs/offline-banner-live-region-readme.md documents why this stays a
manual check rather than an automated test.
@drips-wave

drips-wave Bot commented Aug 29, 2026

Copy link
Copy Markdown

@janetpius-cmd Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

1 participant