chore: expand pressable region to make selecting token easier in batchSell cp-7.82.0

[infiniteflower]

Description

Users reported that selecting/deselecting tokens on the Batch Sell token-select screen felt unresponsive — taps on the checkbox frequently didn't register, requiring two or three attempts.

The root UX cause is hit-target size: the checkbox and the token row were two separate press targets, and the checkbox itself is only ~22px. Taps that landed just outside the checkbox were missed.

This PR makes the entire token row a single press target. The checkbox becomes display-only and the whole row (including the checkbox column) toggles selection through one TouchableOpacity. This is implemented as an opt-in capability on the shared TokenSelectorItem so other consumers are unaffected:

• TokenSelectorItem gains shouldIncludeChildrenInPressTarget and pressTargetAccessibilityLabel. When enabled, children render inside the row's TouchableOpacity (with pointerEvents="none"), and the row press target exposes accessibilityRole="checkbox", accessibilityState={{ checked }}, and the provided label.
• BatchSellTokenRow opts in, and its Checkbox is now purely visual (pointerEvents="none", hidden from the accessibility tree, no-op onChange).

Default behavior for all existing TokenSelectorItem callers is unchanged (the flag defaults to false).

Note: earlier exploratory changes (a setSelectedTokens functional-update refactor and row memoization) were intentionally reverted after analysis — they did not address the actual cause. This PR is scoped to the hit-target fix only.

Changelog

CHANGELOG entry: Fixed unresponsive token selection in Batch Sell by making the entire token row tappable instead of just the small checkbox.

Related issues

Fixes: SWAPS-4616

Manual testing steps

Feature: Batch Sell token selection

  Scenario: user toggles a token by tapping anywhere on its row
    Given Batch Sell is enabled and the user has multiple sellable tokens on a supported chain
    And the user is on the Batch Sell token-select screen

    When the user taps anywhere on a token row (token info, balance area, or the checkbox)
    Then the token's selection toggles on the first tap
    And the checkbox reflects the selected state

  Scenario: user selects and deselects quickly
    Given the user is on the Batch Sell token-select screen

    When the user taps several token rows in quick succession to select and deselect them
    Then every tap registers and the selection count / primary button label updates accordingly

  Scenario: accessibility
    Given a screen reader (VoiceOver/TalkBack) is enabled

    When focus lands on a token row
    Then it is announced as a checkbox with its checked state and the token label

Screenshots/Recordings

Before

N/A

After

N/A

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Performance checks (if applicable)

• I've tested on Android
  • Ideally on a mid-range device; emulator is acceptable
• I've tested with a power user scenario
  • Use these power-user SRPs to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

For performance guidelines and tooling, see the Performance Guide.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: SmokeSwap
• Selected Performance tags: None (no tests recommended)
• Risk Level: low
• AI Confidence: 88%

click to see 🤖 AI reasoning details

E2E Test Selection:
The changes are confined to Bridge/Swap UI components:

1. TokenSelectorItem.tsx: Added two new optional props (shouldIncludeChildrenInPressTarget and pressTargetAccessibilityLabel) with default values of false/undefined, so existing behavior is unchanged for all other usages. The new behavior routes child press events through the parent TouchableOpacity and adds proper accessibility attributes (checkbox role, checked state).

2. BatchSellTokenRow.tsx: Uses the new props to fix accessibility for the batch sell token row - the entire row becomes the press target instead of just the checkbox, and the checkbox is hidden from the accessibility tree to avoid duplicate announcements.

3. TokenSelectorItem.test.tsx: Unit tests covering the new functionality.

These are accessibility improvements to the Bridge/Swap token selection UI. The changes are low-risk (new optional props with safe defaults, no breaking changes to existing behavior), but they do affect the Bridge/Swap flow's token selector interaction model. SmokeSwap is the appropriate tag to validate the swap/bridge token selection flows still work correctly. Per SmokeSwap's description, SmokeConfirmations should also be selected when selecting SmokeSwap, but since these changes are purely UI/accessibility improvements to the token selector (not the confirmation flow itself), and the risk is low, SmokeSwap alone is sufficient. However, to be conservative and follow the tag dependency guidance, I'll include SmokeConfirmations as well.

Performance Test Selection:
The changes are purely UI/accessibility improvements to the Bridge/Swap token selector component. They add new optional props for accessibility handling and restructure how children are rendered within the press target. These changes do not affect performance-sensitive flows like app launch, login, onboarding, or asset loading. No performance test tags are warranted.

View GitHub Actions results