maui
maui copied to clipboard
dotnet
TalkBack doesn't navigate to headings contained in StackLayout with a SemanticProperties.Description
Description
I needed to create a page containing multiple headings, so set SemanticProperties.HeadingLevel on particular labels. I also needed to create nested groupings with nesting that's accessible to screen readers, and in order to achieve this, I set SemanticProperties.Description on some StackLayouts. This worked well on Windows with the Narrator screen reader, and I mentioned how useful this was at https://twitter.com/gbarkerZ/status/1543533603921006592?s=20&t=cRkhQlhf4LSAISDmZZjFEQ.
I then built it and ran on Android, and found that the TalkBack screen reader apparently won't navigate to any headings that lie in a StackLayout with a SemanticProperties.Description. So the necessary navigation by headings doesn't work.
My version of .NET is 6.0.400-preview.22301.10,
Steps to Reproduce
-
Build and run an Android version of the app at https://github.com/gbarkerz/MyVeryFirstMauiApp. The code of interest is in https://github.com/gbarkerz/MyVeryFirstMauiApp/blob/master/MyVeryFirstMauiApp/MainPage.xaml.
-
Turn on the TalkBack screen reader on the Android device, set TalkBack's reading control to navigate by headings, and move forward through the headings in the app.
-
TalkBack moves through most headings in the app, but bypasses the heading that's contained in the StackLayout with the SemanticProperties.Description.
Version with bug
6.0.400 (current)
Last version that worked well
Unknown/Other
Affected platforms
Android
Affected platform versions
Android 9
Did you find any workaround?
No response
Relevant log output
No response
Based on further experiments, it seems that VoiceOver on Mac behaves the same way at the app as TalkBack does on Android, in that it bypasses headings contained in StackLayouts with a SemanticProperties.Description.
GitHubTags: #.NET MAUI; #A11ySev2; #A11yMAS; #A11yTCS; #Benchmark; #Android; #WCAG2.1.1; #GH_.NETMAUI_Android_Apr2022; #AILimited;
@gbarkerz @Karan4495 This isn't really an accessibility issue with .NET MAUI
If you remove the ScrollView from the MAUI app then it all works as @gbarkerz describes. It looks like this is just how Android groups the behavior on Android
If you use the following code on Android you'll see the exact same behavior that .NET MAUI has
If you remove the ScrollView then talkback is unable to navigate to any of
<ScrollView
android:layout_width="match_parent"
android:layout_height="match_parent">
<androidx.appcompat.widget.LinearLayoutCompat
android:layout_width="wrap_content"
android:contentDescription="I am the linear layout"
android:importantForAccessibility="yes"
android:layout_height="wrap_content">
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:accessibilityHeading="true"
android:text="Hello there people"
></TextView>
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="wakka wakka"
></TextView>
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:accessibilityHeading="true"
android:text="Hello there people"
></TextView>
</androidx.appcompat.widget.LinearLayoutCompat>
</ScrollView>
@PureWeen then does this indicate that it's not really a bug and can be resolved as such?
@merriemcgaw I'd say there are two options here
- close as not a bug
- lower the severity level and research to determine if it's a platform bug. I'm not sure at the Android level if this would be perceived as "By Design" or "Talk back bug"
I lean towards option two. Keeping something like this around also gives anyone a place to indicate if they are running into this same issue.
We can do some research here and log the bug with Android to see how they mark it.
@PureWeen Thanks for the investigation, it's interesting to learn that this seems to be underlying Android behavior. It would be good to know how a related issue against Android would be considered. My original UI design seemed reasonable to me, ie having headings inside semantic groups, but at least if the current behavior doesn't change, I'll know to explicitly avoid designing this type of UI layout in an Android app in the future.
Android App demonstrating the same behavior
Android App if you remove the scrollview
Workaround: Add AutomationProperties.IsInAccessibleTree="False" to the ScrollView
Hi Shane The issue is Reproducing in the "My Application" Can you please provide us the sample app to log external bug to talk back. Thanks.
Hi @keerthiduvvuri . reposting the code example that @PureWeen added in a previous comment.
<ScrollView
android:layout_width="match_parent"
android:layout_height="match_parent">
<androidx.appcompat.widget.LinearLayoutCompat
android:layout_width="wrap_content"
android:contentDescription="I am the linear layout"
android:importantForAccessibility="yes"
android:layout_height="wrap_content">
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:accessibilityHeading="true"
android:text="Hello there people"
></TextView>
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="wakka wakka"
></TextView>
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:accessibilityHeading="true"
android:text="Hello there people"
></TextView>
</androidx.appcompat.widget.LinearLayoutCompat>
</ScrollView>
Workaround: Add
AutomationProperties.IsInAccessibleTree="False"to the ScrollView
Hi Shane As per discussion with SME we have to reduce the severity of this bug to sev3, and I have raised a third party bug to talkback which is tracked by https://dev.azure.com/CSS-IRT/CSS%20IRT/_workitems/edit/202560 and we can close this bug(I am not having access to close this bug). Thanks.