`getByRole` with `name` option fails when `accessibilityLabelledBy` is an array

[jaknas]

Describe the bug

getByRole with the name option fails to find elements when accessibilityLabelledBy is an array.

In computeAriaLabel (helpers/accessibility.js), the code performs a direct equality comparison:

node.props.nativeID === labelElementId

When accessibilityLabelledBy is an array (e.g., ['my-label-id']), this comparison always returns false:

'my-label-id' === ['my-label-id']  // false

This is valid per React Native's type definition: accessibilityLabelledBy: string | string[]

Libraries like react-strict-dom transform aria-labelledby to an array format using .split() to properly handle space-separated IDs per the ARIA spec.

Expected behavior

computeAriaLabel should handle both string and array formats for accessibilityLabelledBy:

const idsToCheck = Array.isArray(labelElementId) ? labelElementId : [labelElementId];
const labelElement = findAll(rootElement, 
  node => isHostElement(node) && idsToCheck.includes(node.props.nativeID),
  { includeHiddenElements: true }
);

Steps to Reproduce

import { render, screen } from '@testing-library/react-native';
import { View, Text, Pressable } from 'react-native';

const TestComponent = () => (
  <View>
    <Text nativeID="my-label">Click Me</Text>
    <Pressable 
      accessible={true}
      role="button"
      accessibilityLabelledBy={['my-label']}
    />
  </View>
);

test('should find button by accessible name', () => {
  render(<TestComponent />);
  
  // Fails: Unable to find an element with role: button, name: Click Me
  expect(screen.getByRole('button', { name: 'Click Me' })).toBeTruthy();
});

test('works with string format', () => {
  // If you change accessibilityLabelledBy to string 'my-label' instead of array,
  // the test passes
});

Screenshots

N/A

Versions

  npmPackages:
    @testing-library/react-native: ^13.3.1 => 13.3.3
    react: 19.1.0 => 19.1.0
    react-native: 0.81.4 => 0.81.4
    react-test-renderer: 19.1.0 => 19.1.0

---

[mdjastrzebski]

@jaknas thanks for reporting this. Would you care to prepare a PR with a fix for this issue?