Forum› Xamarin.Forms
How to set IsInAccessibleTreeProperty to false for the UWP AppBar?
JohnHardman
GBUniversity admin
GBUniversity admin
When using Windows Narrator with an app built with XF 4.8 (using NavigationPages, predominantly non-modal), Narrator reports for the AppBar. I want Narrator to report for ToolbarItems (which it does), but not for the AppBar itself. Is there any way for an app to set AutomationProperties.IsInAccessibleTreeProperty to false for the AppBar?
cc. @ElvisXia
Tagged:
0
Answers
@JohnHardman Hi, I tried to reproduce your issue, and from my demo, Narrator is reading the ToolbarItems like: "Add app bar button, one of ... "
I'm wondering if this is same in your scenario. If it's the same, since the ToolbarItems are AppBarButton in UWP native, then Narrator is reading the AutomationProperties.Name + Native Control Name by design.
And here is details for native implementation of AppBar and ToolBarItems: https://github.com/xamarin/Xamarin.Forms/blob/master/Xamarin.Forms.Platform.UAP/Platform.cs#L495
As I mentioned above, Narrator does report the ToolbarItems, but it also separately reports the AppBar which I don't want.
This can be seen using the sample at https://github.com/xamarin/xamarin-forms-samples/tree/master/UserInterface/Accessibility - that doesn't have any ToolbarItems, but still reports the AppBar.
In that code, you can see the ToolbarItem accessibility being implemented as follows:
button.Command = new MenuItemCommand(item); button.DataContext = item; button.SetValue(NativeAutomationProperties.AutomationIdProperty, item.AutomationId); button.SetAutomationPropertiesName(item); button.SetAutomationPropertiesAccessibilityView(item); button.SetAutomationPropertiesHelpText(item); button.SetAutomationPropertiesLabeledBy(item);The problem seems to be that there is nothing equivalent for the AppBar:
As far as I can see, there's nothing public that gives me access to the AppBar (a.k.a. toolbar provider). Everything seems to be internal. It would seem that either that code block should set IsInAccessibilityTree to false for toolbarProvider, or the toolbarProvider should be exposed in some way so that app developers can set up accessibility however they want for the AppBar.
Hi @JohnHardman, I tried with the official sample, but unfortunately not able to reproduce. Narrator is not reporting AppBar for me. I also tried to change Narrator's settings to different level of detail/context, neither reports for AppBar.
I navigated with mouse click/Tab/Left and Right arrow key, none of these reports for AppBar, let me know if there's anything I need to do to reproduce the issue, thanks.
And here's some version info from my side:
OS:
Narrator version: version build in 2020
Xamarin.Forms: 4.8.0.1269
Microsoft.NETCore.UniversalWindowsPlatform: 6.0.12
With Narrator running, use Narrator's navigation keys to navigate the accessibility tree, not the UI tree.
I use 'o' for next item and 'u' for back item, although the documentation at https://support.microsoft.com/en-us/windows/appendix-b-narrator-keyboard-commands-and-touch-gestures-8bdab3f4-b3e9-4554-7f28-8b15bd37410a lists other keys.
@JohnHardman Thank you for clarification, and yes it's reporting for AppBar.
And as you've noticed, XF is not exposing AppBar for developers in UWP in current implementation, and the actual CommandBar for UWP is hiding really deep in code. Will do more investigation about the possibility of setting the AutomationProperty for AppBar. You can also consider file a feature request in github.
Thanks @NicoleLu - yes, I'll raise it in GitHub when I get a moment
Logged at https://github.com/xamarin/Xamarin.Forms/issues/12724
Hi @JohnHardman, we've made some more investigation and here's some updates:
It turns out the AppBar is included in the Accessibility tree on purpose, check UI Automation Tree Overview:
Moreover, the AppBar being in the Accessibility tree gives semantic context to a non-sighted user about how to interact with the AppBar’s contents. For example, some screen readers use different keyboard navigation within the AppBar than outside of it, so it’s important to know that we’re inside an AppBar.
So, it's recommended to follow the OS standard behavior to keep the AppBar in Accessibility tree.
Thanks @NicoleLu . When the AppBar contains no toolbar items, status information etc, it's debatable, and possibly depends on whether the user is non-sighted or low-sighted. When I make use of screen readers (typically because lighting conditions make reading a screen impossible), I do so as if non-sighted. In this scenario, I prefer the AUI to be minimalised, so that I can navigate efficiently. Even if defaults are not changed, I would suggest at least exposing the AppBar so that a custom renderer could modify the properties for a particular app so that an app can do what is most appropriate for it.
@JohnHardman I checked the github issue you've filed, and see it has been added into Accessibility backlog as an enhancement, the engineers has taken this suggestion, thank you for laying out your considerations!