Forum Xamarin.Forms

How to set IsInAccessibleTreeProperty to false for the UWP AppBar?

JohnHardmanJohnHardman GBUniversity admin
edited October 2020 in Xamarin.Forms

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

Answers

  • NicoleLuNicoleLu Member, Xamarin Team Xamurai

    @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

  • JohnHardmanJohnHardman GBUniversity admin

    @NicoleLu said:
    @JohnHardman Hi, I tried to reproduce your issue, and from my demo, Narrator is reading the ToolbarItems like: "Add app bar button, one of ... "

    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.

    @NicoleLu said:
    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

    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:

                var toolbarProvider = GetToolbarProvider();
    

    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.

  • NicoleLuNicoleLu Member, Xamarin Team Xamurai

    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:

    Edition Windows 10 Enterprise
    Version 20H2
    Installed on ‎8/‎10/‎2020
    OS build 19042.572
    Experience Windows Feature Experience Pack 120.2212.31.0

    Narrator version: version build in 2020

    Xamarin.Forms: 4.8.0.1269
    Microsoft.NETCore.UniversalWindowsPlatform: 6.0.12

  • JohnHardmanJohnHardman GBUniversity admin

    @NicoleLu said:
    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.

    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.

  • NicoleLuNicoleLu Member, Xamarin Team Xamurai

    @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.

  • JohnHardmanJohnHardman GBUniversity admin

    @NicoleLu said:
    @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

  • NicoleLuNicoleLu Member, Xamarin Team Xamurai

    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:

    The control view also includes noninteractive UI items that contribute to the logical structure of the UI. These include item containers such as list view headers, toolbars, menus, and the status bar. Other noninteractive items that appear in the control view are graphics with information and static text in a dialog box.

    Noninteractive items used only for layout or decorative purposes, such as panels used to lay out controls in a dialog box, do not appear in the control view.

    The control view of the UI Automation tree closely maps to the UI structure perceived by an end user. This makes it easier for the assistive technology product to describe the UI to the end user and help that end user interact with the application.

    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.

  • JohnHardmanJohnHardman GBUniversity admin
    edited November 2020

    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.

  • NicoleLuNicoleLu Member, Xamarin Team Xamurai

    @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!

Sign In or Register to comment.