Setting a borderRadius style on a View causes accessibilityLabel to not be read by narrator

[kochie-aim]

Environment

Run the following in your terminal and copy the results here.

1. npx react-native --version:
   4.13.0

2. npx react-native run-windows --info:
   System:
   OS: Windows 10 10.0.19042
   CPU: (8) x64 Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz
   Memory: 2.64 GB / 15.80 GB
   Binaries:
   Node: 10.15.0 - C:\Program Files\nodejs\node.EXE
   npm: 6.13.6 - C:\Repos\pay.pidl.sdk\tests\apps\pidl-react-native-windows\node_modules.bin\npm.CMD
   npmPackages:
   react: 16.13.1 => 16.13.1
   react-native: 0.63.2 => 0.63.2
   react-native-windows: 0.63.3 => 0.63.3
   Installed UWP SDKs:
   10.0.17763.0
   10.0.18362.0

What device(s) are you targeting? Choose any from Desktop, Xbox, Hololens)

• Target Device(s): Desktop, Xbox

Which version of Visual Studio are you using? Specify Visual Studio 2017 or Visual Studio 2019

• Visual Studio Version: 2019

Which build configuration are you running? Choose from Debug, DebugBundle, Release, ReleaseBundle

• Build Configuration: Debug/Release

Steps To Reproduce

Provide a detailed list of steps that reproduce the issue.

1. Create a View
2. Create a Text element inside the View with the text "Test Text"
3. Set accessibilityLabel={"Test Text"} on the View
4. Set accessibilityRole={"button"} on the View
   4: Set style={{ borderRadius: 8 }} on the View

Expected Results

With narrator on, View should be focusable. When focused, narrator should read the accessibilityLabel out loud as "Test Text"

Actual Results

The view is focusable, but accessibility focus instead focuses the entire app. If accessibilityRole is not set on the View , the View becomes focusable by the narrator but is read as a custom role. If borderRadius is removed, the element becomes focusable by the narrator but will the lack the desired border radius style.

[rectified95]

I tested the scenario you mention using the snippet below, and I can hear narrator read: "test text one button", which is the expected result you mention.

<View accessibilityLabel={"Test Text one"}
            accessibilityRole={"button"} 
            style={{borderWidth: 0.5, borderRadius: 8, padding: 5}}>
  <Text style={{fontSize: 11}}>
    text one
  </Text>
</View>

I have also tested a few other setups and I can say the following:

• a View is by default not focusable - to make it so, you need to either specify the focusable prop or accessibilityRole
• specifying focusable without accessibilityRole will make Narrator read out role as custom
• specifying accessibilityLabel without accessibilityRole or focusable will not make a View focusable. Can you clarify what setup you were running when you wrote: If accessibilityRole is not set on the View , the View becomes focusable by the narrator but is read as a custom role.? Are you testing everything in regular or scan mode of Narrator?
• borderRadius does not seem to have any effect on Narrator - adding or removing it form any of my test cases didn't change what was read out. If you were testing this in RNTester, you may have run into an issue with JS edit reloading where actually a different set of JS props was bundled - I'd say most likely you removed borderRadius but also accessibilityRole which may have made it seem like borderRadius was at fault.

Can you double-check with my/your snippet and confirm it doesn't work for you? What's your testing environment - a standalone app or RNTester? If it's the latter, be sure to run yarn build before launching.

[kochie-aim]

Thank you for the reply.

• Thanks for the tips on the focusable prop, will add that in.

• Clarification for: If accessibilityRole is not set on the View , the View becomes focusable by the narrator but is read as a custom role: I'm testing things with the windows 10 narrator just tabbing through the elements in my standalone app.

• Thanks for providing a snippet. Testing it out I'm still seeing the same behavior as before on my end. I modified your snippet slightly with a white border, but these screenshots might help better explain the issue I'm seeing.

This first screenshot shows the behavior in my app with the snippet above (plus a white borderColor for visibility). The first view is focused by the app and has that thicker white border around it. However, the "narrator focus" which is that blue outline is wrapped around the whole app and the accessibilityLabel and accessibilityRole are not read.

In this second screenshot, I've removed the borderRadius style and once again focused the first button. The "narrator focus" is now on the first view as expected with that blue outline and the accessibilityLabel and accessibilityRole are read.

Since you're not seeing this issue, perhaps there's something in my xaml file or some other app config file that is interfering with the narrator.

[rectified95]

@kochie-aim I've been able to reproduce this issue in a standalone app - wasn't hitting it in Playground. Will investigate further.

[rtselvan]

@rectified95 Please let us know if we can help us with testing once you have a fix ready. What's on your thought on getting it fixed in 0.64 or 0.65 release?

[rectified95]

It's been marked for v65.

Also, as an FYI:
I want to update my earlier comment, where I said that setting just accessibilityRole will make a View focusable - we have a PR out fixing that, so that unless focusable is set a View won't be so.
#6728

[stecrain]

@rectified95 I spent a bit of time looking into this as it impacts the product I work on.
This issue is particularly strange, most of the JSX in my app does not repro this issue, but if I take the repro and place it in my app then I can repro.

I found that TransferProperties in FrameworkElementViewManager can get called when oldView and newView referencing the same xaml element, and when that happens we end up setting AutomationProperties.AccessibilityView to AccessibilityView.Raw on the ContentControl of the Focusable element.

As a Temporary solution I found that this can be mitigated just slightly adjusting the order of some operations in TransferProperties.

This is the snipped as it exists today.
auto accessibilityView = xaml::Automation::AutomationProperties::GetAccessibilityView(oldView); xaml::Automation::AutomationProperties::SetAccessibilityView(newView, accessibilityView); xaml::Automation::AutomationProperties::SetAccessibilityView(oldView, winrt::Peers::AccessibilityView::Raw);

Changing to this prevents the issue

auto accessibilityView = xaml::Automation::AutomationProperties::GetAccessibilityView(oldView); xaml::Automation::AutomationProperties::SetAccessibilityView(oldView, winrt::Peers::AccessibilityView::Raw); xaml::Automation::AutomationProperties::SetAccessibilityView(newView, accessibilityView);

When oldView and newView reference different controls this is equivalent as the previous code, but when they are referencing the same control it prevents stomping over the AccessibilityView on the Control.

IMO there is still an underlying issue, I don't think TransferProperties should be called when oldView and newView are the same element

[rectified95]

Thanks for the investigation @stecrain ! It's very helpful.

I just noticed that while I'm getting a repro in 0.63.2, I am not seeing the issue in "0.64.0-preview.3" - can you try upgrading your app to v64?

I've tested your suggestion and will create a PR adding it to 0.63.