Bumping this since I think it got lost in the scrollback last night. Is it intentional that `content...

# compose

[Zach Klippenstein (he/him) [MOD]]

Bumping this since I think it got lost in the scrollback last night. Is it intentional that contentDescription doesn’t get merged up? More details in the thread on the original message.

[Adam Powell]

@Anastasia [G] @Filip Pavlis @Alexandre Elias [G]

[Alexandre Elias [G]]

contentDescription should get merged up, you can see the merging policy here: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/[…]lin/androidx/compose/ui/semantics/SemanticsProperties.kt;l=42

[Alexandre Elias [G]]

two possibilities to consider that might explain your symptoms: 1) you have additional contentDescriptions, in which case assertContentDescriptionContains would fix it, 2) the child with the contentDescription is itself mergeDescendants which would exclude it from merging

[Alexandre Elias [G]]

we have been changing contentDescription-related code recently so I wouldn't totally exclude a bug in our merging or assertion code, but it's hard to see where one might sneak in...

[Zach Klippenstein (he/him) [MOD]]

1) you have additional contentDescriptions, in which case assertContentDescriptionContains would fix

Wondered about this because i’ve been bit before, but I’ve looked at the actual semantics node and there’s no content description properties there at all.

2) the child with the contentDescription is itself mergeDescendants which would exclude it from merging

I thought about this too but was pretty sure we weren’t doing it. I’ve double-checked, and we’re not.

The material components seem to have the same problem. This test, for example, fails:

rule.setContent {
      // As far as i can tell from the source, IconButton merges descendants and does not provide its own contentDescription.
      IconButton(
        onClick = {},
        modifier = Modifier.testTag(testTag)
      ) {
        // Icon does not merge its descendents, so this content description should merge up.
        Icon(painterResource(R.drawable.abc_vector_test), contentDescription)
      }
    }

    rule.onNodeWithTag(testTag).assertContentDescriptionContains(contentDescription)

I’m gonna try to debug the actual semantics merging now to see what’s going on.

[Zach Klippenstein (he/him) [MOD]]

Ah, content description merging is new?! It’s not in beta07:

val ContentDescription = SemanticsPropertyKey<String>(
        name = "ContentDescription",
        mergePolicy = { parentValue, _ -> parentValue }
    )

(We can’t use beta08 yet because of a compiler plugin bug.)

[Alexandre Elias [G]]

ah, yeah, that would explain it, I should've thought to ask what version you're on. yes, we're actively changing accessibility stuff until the last minute 🙂

[Alexandre Elias [G]]

fwiw the reason this has been changing is because TalkBack has a behavior if you pass it contentDescription in the system accessibility data structure where it overrides the entire subtree. in Compose we would prefer clearAndSetSemantics to be the only thing that does that so we're not terribly fond of this behavior. recently we worked around it in the accessibility implementation and switched the merged tree to what most developers expect

[Alexandre Elias [G]]

I'm still actively chatting with TalkBack team on the way forward on this long-term

[Zach Klippenstein (he/him) [MOD]]

thanks for the heads up, we’ll keep an eye on the implementation when we do future compose upgrades.

[Alexandre Elias [G]]

there's a big patch under review in this area aosp/1720991 although it should not change a lot of developer-expected behavior (just fix a bunch of weird minor bugs in TalkBack)

[Zach Klippenstein (he/him) [MOD]]

If accessibility is using the unmerged tree, is the only remaining purpose of the merged tree testing?

[Alexandre Elias [G]]

yeah in the medium term, in the longer term we think it might remain useful for other platforms' accessibility data structures

[Alexandre Elias [G]]

Note also that mergeDescendants property still has a big impact on accessibility since we represent it as screenReaderFocusable which makes TalkBack do the merging, using essentially the same algorithm that Compose does

[Zach Klippenstein (he/him) [MOD]]

Ah, good to know, thanks