Bumping this since I think it got lost in the scro...
# compose
z
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.
a
@Anastasia [G] @Filip Pavlis @Alexandre Elias [G]
a
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
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...
z
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:
Copy code
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.
Ah, content description merging is new?! It’s not in beta07:
Copy code
val ContentDescription = SemanticsPropertyKey<String>(
        name = "ContentDescription",
        mergePolicy = { parentValue, _ -> parentValue }
    )
(We can’t use beta08 yet because of a compiler plugin bug.)
a
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 🙂
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
I'm still actively chatting with TalkBack team on the way forward on this long-term
z
thanks for the heads up, we’ll keep an eye on the implementation when we do future compose upgrades.
a
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)
👍🏻 1
z
If accessibility is using the unmerged tree, is the only remaining purpose of the merged tree testing?
a
yeah in the medium term, in the longer term we think it might remain useful for other platforms' accessibility data structures
👍🏻 1
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
z
Ah, good to know, thanks