Picker control does not properly emit SemanticProperties.Description as content-desc on Android

[hansmbakker]

Description

The Semantic Properties are the recommended way in MAUI to add accessibility metadata.

On Android (have not tested on other platforms yet), this does not work consistently across all controls making it harder to make UI tests.

For a Button control, this works correctly. The SemanticProperties.Description XAML is translated to the content-desc field //android.widget.Button[@content-desc="My semantic properties description"] and Appium will interpret that correctly as the accessibility id. The SemanticProperties.Hint XAML is correctly translated to the hint field.

Bug
For the Picker control this does not work. The SemanticProperties.Hint XAML attributes is propagated to the resulting Android app but the SemanticProperties.Description is not.

Instead, the SemanticProperties.Description is emitted as the text property of the EditText view that represents the Picker control in Android.

Steps to Reproduce

1. Create a File > New .NET MAUI App
2. Add a Button and a Picker like so:

<Button Text="My button"
      SemanticProperties.Description="This is the semantic properties description for the Button"
      SemanticProperties.Hint="This is the semantic properties hint for the Button" />
<Picker Title="My picker"
      SemanticProperties.Description="This is the semantic properties description for the Picker"
      SemanticProperties.Hint="This is the semantic properties hint for the Picker">
  <Picker.ItemsSource>
      <x:Array Type="{x:Type x:String}">
          <x:String>A</x:String>
          <x:String>B</x:String>
          <x:String>C</x:String>
      </x:Array>
  </Picker.ItemsSource>
</Picker>

4. Inspect the app using Appium with platformName = Android and appium:automationName = UiAutomator2

Expected outcome: the Picker can be found in Appium using the accessibility id which can be set by SemanticProperties.Description in XAML
Actual outcome: the SemanticProperties.Description is propagated as the text property of the EditText view in Android

Link to public reproduction project repository

https://github.com/hansmbakker/PickerAccessibilityBugRepro

Version with bug

8.0.0-preview.6.8686

Last version that worked well

Unknown/Other

Affected platforms

Android

Affected platform versions

Android API level 33

Did you find any workaround?

Use XPath to find an element, which is not recommended.

Relevant log output

No response

[hansmbakker]

Appium Inspector comparison

Button (good)

Picker (bad)

[hansmbakker]

Adding to this:
The Picker is represented by an EditText view on Android in unfocused state. When it is tapped to show its options, it is replaced in-place by a set of different views that do not have an id anymore. This makes it very awkward to use in UI tests.

[hansmbakker]

Related bug #1186 - this one was reproduced bug closed. I cannot comment there anymore, but probably would be good to have that one reopened

[PureWeen]

@hansmbakker You need to use AutomationId to locate elements

#8277

We use an AccessibilityDelegate a few places in Android to manage accessibility to work around some bugs in Android so we don't always propagate those to content-desc

[ghost]

Hi @hansmbakker. We have added the "s/needs-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[hansmbakker]

@PureWeen

• adding the AutomationId to the Picker indeed translates to the id on Android. However, having this work with accessibility id would be really welcome as it seems to be the recommended approach in Appium to select elements
• adding the AutomationId to the Picker does not work for the popup that shows the picker options (On Android, a Picker is replaced by views without id when opening it #16284)

[hansmbakker]

@PureWeen I saw you added dotnet/docs-maui#1577 - this would be really welcome to have some insight in how to more effectively write UI tests!