AccessibilityRole mapping limits for custom components across iOS and Android

When building custom composite components in React Native, teams often rely on the Accessibility API to expose correct semantics to screen readers. The accessibilityRole prop is intended to map a component to a native accessibility element, such as a button or header, on both iOS and Android. However, the exact boundaries of this mapping for custom components that wrap multiple native views remain unclear.

React Native translates accessibilityRole into platform-specific accessibility metadata—UIKit traits on iOS and class or role hints on Android via View and AccessibilityNodeInfo. Because custom components may combine several native elements, the resulting announcement can diverge between platforms. The interaction with the accessible prop, which flattens children into a single focusable element, adds further uncertainty about whether the parent role or child semantics take precedence.

Which accessibilityRole values are reliably mapped to equivalent native semantics for custom composite components across iOS and Android? Does grouping with the accessible prop change how the role is interpreted differently on each platform? Where can developers confirm the current cross-platform mapping behavior for a specific React Native version?