Implement UIManager.sendAccessibilityEvent

[acoates-ms]

The AccessibilityInfo.setAccessibilityFocus method calls directly into UIManager.sendAccessibilityEvent which we do not currently implement. This causes an error when this method is called on windows.

[acoates-ms]

From @kmelmon comments in #5849:

Oops I didn't realize it's just supposed to move narrator focus. I'm asking around, meanwhile I see some hits in Windows that suggest raising the AutomationFocusChanged event might work (eg %SDXROOT%\xbox\shellapps\Shared\Xbox.Foundation.UI\Narrator\NarratorReader.cpp line 125)

        // Raise the focus changed automation event, to ensure that this element receives narrator focus so that it reads the element and textToRead together.
        auto automationPeer = FrameworkElementAutomationPeer::FromElement(focusedElement);
        if (automationPeer != nullptr)
        {
            automationPeer.RaiseAutomationEvent(AutomationEvents::AutomationFocusChanged);
        }

[kmelmon]

Marko from Accessibility team said:

"The closest that would come to this on Windows/UIA would be to raise a focus changed event AND make sure that the element’s HasKeyboardFocus and IsKeyboardFocusable properties both report true. Without the latter, Narrator wouldn’t follow the focus changed event, assuming it was bogus. "

It appears we'll need to implement a custom AutomationPeer in order to make HasKeyboardFocus and IsKeyboardFocusable both return true.

It seems there's a bit of a mismatch between Windows and RN here: The RN docs on setAccessibilityFocus are here:
https://reactnative.dev/docs/accessibilityinfo#setaccessibilityfocus

Note this comment:
Note: Make sure that any View you want to receive the accessibility focus has accessible={true}.
This implies that if you set accessible = true, then the component should be accessibility focusable. This is different than XAML, which requires that the element be keyboard focusable. We may be able to implement Marko's suggestion, or we may need to back off from this requirement altogether as it could be problematic to live with this mismatching behavior. Even Marko has some doubts it will work reliably (he felt the solution is somewhat of a hack).

[chiaramooney]

Would advocate to move this issue to 0.65 target. Spoke with Keith, Jon, and heard from accessibility team and each were unclear whether Windows can support the functionality of this API. Current proposed solution is a bit of a hack and would force system into behavior outside of its designed workflow.