Why was the accessibilityHidden prop added?

[schlaegerz]

I am curious why this package decided to create a new prop for accessibility hidden.

For android and iOS we already have these props if I want to hide it for accessibility:
accessibilityElementsHidden={true} // iOS
importantForAccessibility="no-hide-descendants" // android

Now with the most recent change we have to add a third prop?
accessibilityHidden={true}

Is there a particular reason we would keep it seperate from the other two (ios and android)?

[intergalacticspacehighway]

@schlaegerz I think the rationale here is consistency to have all the aria-* equivalents with accessibility*.
Mobile (android/iOS) and web platforms have completely different accessibility requirements. There is no one-one mapping and overall it was really confusing which prop to use. (e.g. accessibilityElementsHidden or importantForAccessibility).

I think the new decision makes the library logic simple and as a developer you just have to think of aria* to accessibility*.

Why not just support aria-* then?
To be RN specific. I think there is surely some discussion with the react-native-windows team. They are also using this as a convention to put accessibility as prefix. for e.g. accessibilityPositionInSet, accessibilitySetSize in rn-windows.

[necolas]

To add to that: RN accessibility props are a mix of native accessibility props without much attention given to converging on cross platform names. There is also a lot of accessibility features missing. Both web and windows have this problem with the existing RN API. We already did all the design work in the ARIA spec so a future version of RN could coverge on that, as we have been doing on web and windows

[schlaegerz]

Thanks for the answers! It makes a lot of sense. Glad this is now documented in this issue.