Windowscommunitytoolkit: Question: accessibility on hamburger menu

[dgomezc]

In windows template studio we are improving the accessibility and we need set a name to the main button of the hamburger menu so that it can be read by the Windows narrator.

Is there a way to set a name for the main menu button on the hamburger menu?

Windows Template Studio - #494 Accessibility: Narrator support verified

[skendrot]

It already has a name

[Odonno]

@skendrot @dgomezc Do you refer to AutomationProperties Name? In my opinion, we should change "Main button" to "Hamburger button". is that enough?

[skendrot]

Menu button would be better

[nmetulev]

@dgomezc is "Main button" (the way it is now) sufficient or are you looking for something else?

[skendrot]

It's currently 'Main button'

[nmetulev]

You are correct, edited my comment :)

[nmetulev]

@dgomezc Up?

[nmetulev]

Up?

[dgomezc]

@nmetulev Ok, "Main button" works. Maybe you could consider to allow to customize the "AuomationProperties.Name" in the future.

[mrlacey]

Just changing the hardcoded automation property name isn't enough as it doesn't allow for translation

[nmetulev]

How does the new NavigationView handle this, any idea?

[mrlacey]

In SDK v16257 the button is styled with "PaneToggleButtonStyle" and doesn't set a value for AutomationPropertes.Name instead the control displays a ToolTip which is used as the name for narrator, inspect, etc.
The toolkit version doesn't include a tooltip and so accessibility tools a forced to use the explicit AP.Name value. As there's no need for this button to use localized content the normal rules for localization and accessibility don't apply and so without including a tooltip (which should obviously be localized) then this button should have a localized value for the AP.Name.

Without even looking I would have guaranteed it didn't hard code anything.

Note also that there are many controls with hard coded English language values for automation property names. It may also be worth reviewing these others too

BladeView: AutomationProperties.Name="Cancel"
Expander: AutomationProperties.Name="Expand"
HamburgerMenu: AutomationProperties.Name="Menu items", AutomationProperties.Name="Option items", AutomationProperties.Name="Content"
HeaderedTextBlock: AutomationProperties.Name="Header content", AutomationProperties.Name="Text content"
RangeSelector: AutomationProperties.Name="Min thumb", AutomationProperties.Name="Max thumb"

That this is a requirement for XAML controls on the contribution page may need revising too.

[nmetulev]

Makes sense. How do you feel about submitting a PR to resolve these? :)

[mvegaca]

I'm working on this PR :)

[mvegaca]

PR done, we will be pending on next release to close WTS Issue

[nmetulev]

Thanks @mvegaca. I noticed you added new dependency properties for the affected controls. Curious if adding the tooltip option @mrlacey describes above would work just as well?

[mrlacey]

If the toolkit team wants to make the HamburgerMenu control behave like the NavigationView (in FCU) then this would mean adding the tooltip(s) - for "Open Navigation" and "Close Navigation". I would expect this logic to come with the control, not be something that the consumer would have to implement. I'd also expect to see Two properties (or resource Ids) for setting each of the string values.

I think that adding the extra properties is overkill, especially in some cases.
I flagged that there were lots of things that need reviewing and they certainly shouldn't all be handled the same way.

Sorry, but I don't have the bandwidth to look at everything here fully but even with a simple control like the HeaderedTextBlock makes me wonder if having multiple AutomationProperties is right for it. I'd want/expect the control to be described via narrator as a single item. If it really is intended for use like a read-only TextBox with a label I'd want it to be handled like a TextBox that is described with the control referenced in AutmationProperties.LabeledBy.

This change also serves to elevate the text that is included with the controls to be localizable. It's probably worth some discussion with the wider toolkit team to discuss how this (and all included) localizable text should be handled by the toolkit. The text we're talking about is also all very standard and so all translated versions will already exist for all Windows supported languages. There's a discussion to be had here over whether the toolkit includes localized translations, allows the user of the control to specify the values, or both (default translations of all strings are included but can be overridden.)

What's needed is more than a quick hack to try and unblock a WTS issue.

[nmetulev]

Coming back to this, we should be approaching this the same way the platform has handled it in platform controls including the NavigationView.

That being said, I'm looking at how to actually change the tooltip and AP.Name of the NavigationView in the latest insider SDK. I'm struggling to actually do this as it seems that the Close Navigation and Open Navigation tooltips are set from code behind. Or am I missing anything?

[nmetulev]

Closing this issue and PR as the HamburgerMenu is deprecated and the NavigationView is already localized. See this comment for more details