Open dmansergh opened 3 years ago
I think this explains the following difference in Windows Narrator output when using my sample application:
@dmansergh I encountered this issue too. I'm not using MahApps, so I don't know if this will help you, but using AutomationProperties.LabeledBy
worked for me when AutomationProperties.Name
didn't. If you're able to add a Label or TextBlock this might work for you.
Describe the bug
'Accessibility Insights for Windows' is a tool used to test the accessibility of Windows applications. A WPF application with a MahApps ComboBox with IsEditable=True causes 'Accessibility Insights for Windows' to report: "The Name property of a focusable element must not be null."
If the WPF application does not use MahApps then 'Accessibility Insights for Windows' does not report any issues. If the ComboBox does not set IsEditable=True then 'Accessibility Insights for Windows' does not report any issues.
The failure includes a link to https://docs.microsoft.com/en-us/accessibility-tools-docs/items/wpf/edit_name?branch=master which suggests how this sort of error should be fixed.
I assume the failures is related to the PART_EditableTextBox part of the ComboBox style in MahApps.Metro\src\MahApps.Metro\Styles\Controls.ComboBox.xaml
Steps to reproduce
Expected behavior
'Accessibility Insights for Windows' should report no issues - like it does when not using MahApps or when IsEditable=False.
Actual behavior
'Accessibility Insights for Windows' reports a failure for the edit portion of the ComboBox: "The Name property of a focusable element must not be null."
Environment
Screenshots