[Bug] Send recipient field has nested button semantics and unnamed controls

📱 Interface Affected

• Web (app.uniswap.org)
• Wallet Extension
• Wallet Mobile App

---

🧩 App Version

• Version (if known): current public production release
• Production build
• Development build

---

💻 System / Environment Info

• Browser: browser-independent source-level semantics issue
• OS / Platform: web
• Device: desktop/laptop
• Wallet used: not wallet-specific
• Network: not network-specific

---

🔁 Steps to Reproduce

1. Open the Web app's Send flow.
2. Navigate to the recipient field using a keyboard and/or screen reader.
3. Inspect the recipient control semantics.
4. After selecting a recipient, inspect the X control used to clear the recipient.

The current implementation in apps/web/src/pages/Swap/Send/SendRecipientForm.tsx uses RecipientWrapper = styled(TouchableArea, ...) around the editable SendRecipientInput.

On web, TouchableAreaFrame renders as a div with role="button" (packages/ui/src/components/touchable/TouchableArea/TouchableAreaFrame.web.tsx). That means the recipient text input is nested inside an element exposed as a button.

The visible To text is also not programmatically associated with the text input, and the X clear-recipient TouchableArea has no accessible name.

---

✅ Expected Behavior

• The editable recipient input should not be nested inside a control exposed as role="button".
• The visible To label should be programmatically associated with the recipient input (or the input should otherwise have an equivalent accessible name).
• The clear-recipient X control should expose a concise accessible name such as Clear recipient.

---

❌ Actual Behavior

• A role="button" wrapper contains the editable recipient input, producing nested interactive semantics.
• The recipient input has no programmatic accessible name corresponding to the visible To label.
• The icon-only clear-recipient control is unnamed.

These are relevant to WCAG 2.2, particularly 1.3.1 (Info and Relationships), 3.3.2 (Labels or Instructions), and 4.1.2 (Name, Role, Value).

---

📸 Screenshots or Screen Recording

Not required to identify the source-level semantics issue; the relevant implementation is in the two files noted above.

---

🧾 Additional Context

I found this while doing a source-level WCAG 2.2 review of the production web interface. I also noticed a few other accessibility issues in shared/web interaction patterns.

I realize this repository is a public production mirror and does not accept PRs. If a broader accessibility pass would be useful, I'm happy to continue the review and share a concise, prioritized set of findings and remediation notes rather than filing unrelated one-off reports.

Start with apps/web/src/pages/Swap/Send/SendRecipientForm.tsx and inspect how RecipientWrapper, SendRecipientInput, the visible To text, and the clear-recipient TouchableArea are composed. Read packages/ui/src/components/touchable/TouchableArea/TouchableAreaFrame.web.tsx to confirm the web semantics, then verify that the recipient control has an accessible name, the clear control is named, and no button role contains the input.