Fix tile gallery link accessibility

[chrisglein]

Description

Fix some issues with the tile gallery links

Why

Resolves #446

What

• Manually specify an accessibility label, avoiding the auto concatenation of all elements that introduced the link character.
• Specifying a "link" role gives the right type in the inspector... but doesn't come with an invoke action. Falling back to "button" no longer matches the WinUI 3 Gallery, but passes the accessibility inspection. Workaround for accessibilityRole "link" (control type "Hyperlink") does not support the invoke provider (Paper) react-native-windows#13861

Microsoft Reviewers: Open in CodeFlow

[chrisglein]

@chiaramooney is there a way to get the InvokeAction to get set up while having the role type set to "link"? It works by default for "button" but not "link".
(this is on Paper, but I assume that with implementation in place the same question would stand for Fabric)

[chiaramooney]

So specifying the "link" accessibilityRole type should map to the UIA control type Hyperlink which according to this source (https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-controlpatternmapping) should always support the invoke provider. I would confirm using Accessibility Insights if the correct UIA control type is being specified. If not, then our role to control type mapping on Paper has a bug. If the control type is Hyperlink but the invoke provider is not implemented then this is a bug on Paper with our UIA Provider code (something in DynamicAutomationProvider is wrong, potentially hyperlink is missing from the list of controls that should support invoke).

Since we are redoing our accessibility implementation from scratch on Fabric this issue should not be occurring on the new arch. See this line (https://github.com/microsoft/react-native-windows/blob/2c70908a390daa63060059fea373b4777f7d7b50/vnext/Microsoft.ReactNative/Fabric/Composition/CompositionDynamicAutomationProvider.cpp#L154C79-L154C106) where were create the IInvokeProvider if the role type is link.

[chrisglein]

So specifying the "link" accessibilityRole type should map to the UIA control type Hyperlink which according to this source (https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-controlpatternmapping) should always support the invoke provider. I would confirm using Accessibility Insights if the correct UIA control type is being specified. If not, then our role to control type mapping on Paper has a bug. If the control type is Hyperlink but the invoke provider is not implemented then this is a bug on Paper with our UIA Provider code (something in DynamicAutomationProvider is wrong, potentially hyperlink is missing from the list of controls that should support invoke).

Since we are redoing our accessibility implementation from scratch on Fabric this issue should not be occurring on the new arch. See this line (https://github.com/microsoft/react-native-windows/blob/2c70908a390daa63060059fea373b4777f7d7b50/vnext/Microsoft.ReactNative/Fabric/Composition/CompositionDynamicAutomationProvider.cpp#L154C79-L154C106) where were create the IInvokeProvider if the role type is link.

Thanks Chiara, that's super helpful. I opened microsoft/react-native-windows#13861.