Gate wallet transfer and receipt billing account selection behind a Save button (a11y On Input, PR 12)

[MelvinBot]

Explanation of Change

This addresses a WCAG 3.2.2 "On Input" accessibility violation, part of the batched plan in issue #74834 (PR 12). Two account-selection pages committed the change and navigated away the instant a row was tapped, so the layout/context changed without the user explicitly confirming — disorienting for screen-reader and low-vision users.

Both pages now stage the tapped account in local state and only commit it when the user presses the Save button (via confirmButtonOptions on SelectionList), matching the pattern already shipped in PRs 3–8. The staged row is highlighted, and the Save button is disabled until the staged selection differs from the current value. Footer/guard actions are intentionally left immediate:

• ChooseTransferAccountPage — the bank-account row selection is staged and committed (saveWalletTransferAccountTypeAndID + goBack) on Save; the "Add new bank account / debit card" footer MenuItemAction stays immediate.
• ChangeReceiptBillingAccountPage — the row selection reuses the existing local selectedOptionState (highlight) and is committed (changePolicyUberBillingAccount + goBack) on Save; the centralBillingAccountEmail guard is preserved.

🤖 Generated by MelvinBot. Checks run locally: lint-changed ✅, typecheck-tsgo ✅. React Compiler compliance check couldn't run in this environment (base-ref resolution); no manual memoization was added, so CI will validate. Full npm test / storybook smoke deferred to CI.

Fixed Issues

$ #74834
PROPOSAL: #74834 (comment)

Tests

• Verify that no errors appear in the JS console

Offline tests

QA Steps

// TODO: These must be filled out, or the issue title must include "[No QA]."

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

[codecov]

Codecov Report

❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.

Files with missing lines	Coverage Δ
...eceiptPartners/ChangeReceiptBillingAccountPage.tsx	87.50% <71.42%> (-2.50%)	⬇️
...ages/settings/Wallet/ChooseTransferAccountPage.tsx	0.00% <0.00%> (ø)
... and 10 files with indirect coverage changes

[MelvinBot]

🤖 I ran the testing steps for this PR on Android (standalone NewDot) but was unable to reach either page this PR modifies with the test account, so I could not verify the Save-button gating behavior.

Why it's blocked: both pages require account state that a fresh Melvin test account doesn't have:

• ChooseTransferAccountPage (Settings → Wallet → Transfer balance → Choose account) requires an existing Expensify Wallet balance + at least one linked bank account. On this account, Settings → Wallet shows only the empty-state prompts ("Add bank account" / "Add personal card") — there's no wallet balance and no "Transfer balance" control, so the Choose account page can't be entered. (See screenshot below.)
• ChangeReceiptBillingAccountPage (Workspace → Receipt partners → Uber → Central billing account) requires a workspace with the Uber receipt partner enabled and a central billing account — setup this test account also doesn't have.

Neither precondition can be satisfied in a read-only verify run (e.g. linking a real bank account via Plaid is out of scope), so this reflects a test-environment limitation, not a failure of the PR itself.

Evidence — Settings → Wallet empty state

To get these verified on Android, the flows need to be run on an account that already has a funded Expensify Wallet with a linked bank account (for the transfer-account page) and an admin workspace with Uber central billing enabled (for the receipt-billing page). The behavior to confirm on each:

1. A Save button is shown at the bottom; it's disabled until a new selection is made.
2. Tapping a non-selected row stages the selection (row highlights) without navigating away, and enables Save.
3. Pressing Save commits the selection and navigates back.

---

view run

[MelvinBot]

🤖 I ran the testing steps for this PR on Web but was unable to reach either page this PR modifies with the test account, so I could not verify the Save-button gating behavior. (Same blocker I hit on Android.)

Why it's blocked: both pages require account state a fresh Melvin test account doesn't have:

• ChooseTransferAccountPage (Settings → Wallet → Transfer balance → Choose account) requires an enabled Expensify Wallet with a balance + at least one linked bank account. On this account, Settings → Wallet shows only "Add bank account", "Add personal card", and an "Enable wallet (Beta)" prompt — no balance and no "Transfer balance" entry point, so the Choose account page can't be reached. (See screenshots.)
• ChangeReceiptBillingAccountPage (Workspace → Receipt partners → Uber → Central billing account) requires a workspace with the Uber receipt partner enabled and a central billing account — also not set up on this account.

These are test-environment preconditions, not a failure of the PR.

Evidence — Settings → Wallet empty state (web)

To get these verified on Web, the flows need an account that already has a funded/enabled Expensify Wallet with a linked bank account (for the transfer-account page) and an admin workspace with Uber central billing enabled (for the receipt-billing page). The behavior to confirm on each:

1. A Save button is shown at the bottom; it's disabled until a new selection is made.
2. Clicking a non-selected row stages the selection (row highlights) without navigating away, and enables Save.
3. Clicking Save commits the selection and navigates back.

---

view run

[truph01]

@MelvinBot Mark this PR as ready

[melvin-bot]

@truph01 Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[MelvinBot]

🤖 Done — this PR is now marked Ready for review.

---

view run

[JmillsExpensify]

No product review required.

[MelvinBot]

I looked into the failing checks — there's nothing here I can fix with a code push. All three failures are human process gates, not code/test failures:

• PR Author Checklist / checklist — the author checklist items in the PR body are unchecked.
• PR Reviewer Checklist / checklist — the reviewer checklist hasn't been completed.
• Check independent approval — requires an independent reviewer approval.

Every actual code check is green (ESLint, typecheck, test jobs 1–8, Bun tests, Storybook, React Compiler compliance, perf tests, etc.).

To get these to pass, the author/reviewer need to complete the checklists in the PR and obtain the required approval — no code change is needed from me.

---

view run