fix: tapOn '<text>' fails for React Native Pressable with accessibilityLabel on iOS (#1409)

[qwertey6]

Proposed changes

tapOn: "<text>" fails to find React Native buttons that have accessibilityLabel set on iOS — even though users clearly see the text on screen. This has been broken for 2.5 years (#1409, opened in 2023) and affects every React Native app that uses the recommended accessibility pattern.

Impact

• Resolves tapOn "text" not working when accessibilityLabel is available on iOS #1409 — open since June 2023 with multiple confirmations from the community, including someone who identified the exact line of broken code
• Likely resolves tapOn on Tab Button Succeeds but Does Not Trigger Navigation (Works in Studio, Fails in CLI) #2448 — "tapOn succeeds but doesn't trigger navigation" on React Native iOS tabs has the same root cause (matching the wrong element)
• One-line fix in IOSDriver.kt:mapViewHierarchy plus a clarifying comment

Root cause

When a React Native Pressable has accessibilityLabel set, iOS collapses child Text elements into the parent's accessibility label. The element's title and value are empty — only label is populated.

Maestro's iOS hierarchy mapping (IOSDriver.kt:197) populates the text attribute from title or value:

attributes["text"] = element.title?.ifEmpty { element.value } ?: ""

So for these Pressables, text is always "". The user types tapOn: "Continue with Google" and Maestro can't find the element.

Reproduction

<Pressable
  accessibilityLabel="Continue with Google"
  accessibilityRole="button"
  onPress={handler}
>
  <Ionicons name="logo-google" />
  <Text>Continue with Google</Text>
</Pressable>

- tapOn: "Continue with Google"  # FAILS — element not found

The hierarchy dump from maestro hierarchy shows:

{
  "accessibilityText": "Continue with Google",
  "title": "",
  "value": "",
  "text": "",
  "bounds": "[24,582][378,630]",
  "enabled": "true"
}

The element exists, the bounds are correct, the user can see it — but text is empty so the most natural selector fails.

Why the existing workarounds aren't acceptable

1. tapOn { label: "Continue with Google" }: Users shouldn't need to know the difference between text: and label:. They see text on screen, they expect tapOn: "that text" to work.
2. tapOn: ".*Continue with Google.*" (regex): Finds the element via the existing Filters.textMatches accessibilityText fallback, but Maestro then taps the bounds-center of whatever element matches — which can be a parent View instead of the Pressable. This is the root of tapOn on Tab Button Succeeds but Does Not Trigger Navigation (Works in Studio, Fails in CLI) #2448's "tap succeeds but onPress doesn't fire."
3. Removing accessibilityLabel: Bad workaround. The label exists for screen reader users (localization, icon+text combos, etc.).
4. Coordinate taps: Defeats the entire purpose of using Maestro.

Fix

attributes["text"] = element.title
    ?.takeIf { it.isNotEmpty() }
    ?: element.value
        ?.takeIf { it.isNotEmpty() }
    ?: element.label

Falls back to element.label (the iOS accessibility label) when title and value are both empty. The accessibilityText attribute still uses element.label as its canonical source, so Filters.textMatches's existing fallback through accessibilityText continues to work as before.

This also indirectly fixes the "tap doesn't fire onPress" symptom from #2448: when text is populated on the Pressable itself, normal element ranking picks the deepest text-bearing match (the Pressable) rather than a parent View, and the bounds-center tap lands on the actual touchable area.

Why this hasn't been fixed for 2.5 years

The maintainer noted that "It doesn't look like anyone in the community has been motivated to attempt a fix." A community member identified the exact code location in March 2025 but no PR followed. This change is small (10 lines + comment) and well-isolated.

Testing

• Builds and unit tests pass
• The change is purely additive: when title or value is set (e.g., UIButton, text fields), behavior is unchanged. The fallback only triggers when both are empty.
• Verified against the hierarchy dump from a real React Native app exhibiting this bug

Depends on: #3141 → #3140 → #3139 → #3138 (stacked PR chain for parallel iOS execution and performance)

Issues fixed

Closes #1409
Likely fixes #2448 (same root cause class)