AccessibilityInfo announceForAccessibility

[SavoySchuler]

https://facebook.github.io/react-native/docs/0.59/accessibilityinfo#announceforaccessibility
Not supported in current

[chrisglein]

Keeping current bar for M4, so this can move to M5.

[FalseLobster]

Hi folks,

Office has been looking at adding support for this for one of our react-native driven experiences.

My initial thought was that RaiseUiaNotificationEvent was a reasonable mapping for Windows. Looks like @jonthysell was suggesting RaiseAutomationEvent instead in #2888 .

If we went with my proposal, there's problem stemming from the fact that the AccessibilityInfo native module is dissociated with the underlying UI / UIA trees, which is needed by RaiseUiaNotificationEvent.

I've been toying with a few different ideas, on our end, and I wanted to hear what your take was:

• Extend the announceForAccessiblity API to take an optional view tag so we can associate with a UI Element / AutomationPeer.
• Write an AutomationPeer just for the Native Module and find some way to fit it into the tree.
• Write some Windows-only extension that supports the full suite of options under RaiseUiaNotificationEvent (requires forking feature code for the Windows platform because iOS / Android are using announceForAccessibility).
• Make a "best guess" at what AutomationPeer to use
• Use LiveRegion in the feature code

[jonthysell]

I don't know if UWP has ever expected the scenario "just say something to the narrator without any UI context". However, whether we use RaiseUiaNotificationEvent, or RaiseAutomationEvent, both presume a connection to a view. I think:

• Extend the announceForAccessiblity API to take an optional view tag so we can associate with a UI Element / AutomationPeer.

Yes, we should do this, so people who care (esp on Windows) can specify the exact view ref

• Write an AutomationPeer just for the Native Module and find some way to fit it into the tree.

• Make a "best guess" at what AutomationPeer to use

I think we can come up with a reasonable heuristic here. Use a particular view's peer if specified, otherwise use either the peer of the ReactRoot element, or based on what is currently focused.

[FalseLobster]

Yea, the RaiseUiaNotificationEvent is rather new as far as I know. It sounds like you agree with my proposed mapping at least.

I agree extending it is ideal for Windows, but I think we'd want to push that back to Facebook, so it's something to keep in mind.

I like your suggestion regarding what's in focus. My concern about "just grab the RootView" is that since Win32 Office is a brownfield react-native host with multiple react-native driven experiences we might one day have multiple RootViews for a single ReactInstance. Architecturally I don't think it's easy to get from NativeModule -> RootView, although maybe your constraints are different from ours.

[FalseLobster]

@jonthysell In our react-native implementation, I think I'm going to experiment with something like this:

AccessibilityInfo.announceForAccessibility(message: string, viewTag?: number)

where an unspecified viewTag falls back to the currently focused element. This will call the RaiseNotificationEvent under the hood.

Let me know if you have any other thoughts or concerns.