Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add remaining and UWP-specific accessibility features #918

Closed
rozele opened this issue Nov 28, 2016 · 3 comments
Closed

Add remaining and UWP-specific accessibility features #918

rozele opened this issue Nov 28, 2016 · 3 comments

Comments

@rozele
Copy link
Collaborator

rozele commented Nov 28, 2016

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.

@rozele rozele added this to the Core View Managers milestone Nov 28, 2016
@rigdern
Copy link
Contributor

rigdern commented Oct 3, 2017

Here's the work that I believe is involved:

  1. 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?
  2. Allow XAML controls to get focus (Eric did a prototype in prototype(View): add isTabStop prop to focus #1386)
  3. Allow controling the tab order through XAML's TabIndex property
  4. Expose keyboard events to JavaScript
  5. Expose event when high contrast is toggled
  6. Implement live region support (Android exposes this through the accessibilityLiveRegion prop)

@rozele
Copy link
Collaborator Author

rozele commented Oct 4, 2017

@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?

@rozele
Copy link
Collaborator Author

rozele commented Jul 23, 2018

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.

@rozele rozele closed this as completed Jul 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants