You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
UWP has a rich UI automation API which we should expose to react-native. This may involve breaking out accessibility features as a module that is pulled in for the base View class.
The text was updated successfully, but these errors were encountered:
Implement custom AutomationPeers for the kinds of controls we want to expose to the accessibility tree (e.g. button, list). We can pick the appropriate custom AutomationPeer based on the value of a prop. We can consider reusing the accessibilityTraits prop (iOS) or the accessibilityComponentType prop (Android). Or maybe we should have a new prop for UWP?
@rigdern
2. We still need to differentiate in JavaScript when to use a Control vs. a plain Canvas to keep a concise view hierarchy for performance (probably could do something similar to the fast text prototype #1256)
3. this is a trivial addition to #1386
4. #1386 includes KeyUp and KeyDown events per focused view, do you think you'll also need a global key listener?
This is a broad bit of work which has been addressed by a number of PRs recently. Closing in favor of more specific accessibility issues that may arise.
UWP has a rich UI automation API which we should expose to react-native. This may involve breaking out accessibility features as a module that is pulled in for the base View class.
The text was updated successfully, but these errors were encountered: