IssueTracker

Hi. Thanks for reporting this. Fixed in this changelist. This should be available in alpha-04

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.tv:tv-material:1.0.0-alpha04

Also there's new code:

@OptIn(ExperimentalMaterialApi::class)
@Composable
fun MyScreen2() {
    Box {
        var value by remember { mutableStateOf(Value.None) }
        LazyColumn(Modifier.background(Color(0xFFEEEEEE))) {
            item {
                Spacer(
                    Modifier
                        .height(200.dp)
                        .fillMaxWidth()
                )
            }
            items(50) {
                ListItem(
                    Modifier
                        .fillMaxWidth()
                        .then(if (it == 0) Modifier.height(100.dp) else Modifier)
                        .clickable { }) {
                    Text("Item #${it + 1}")
                }
            }
        }
        Box(
            modifier = Modifier
                .fillMaxWidth()
                .height(120.dp)
                .background(MaterialTheme.colors.surface.copy(alpha = 0.9f))
                .then(when (value) {
                    Value.None -> Modifier
                    Value.TestTag -> Modifier.testTag("tag")
                    Value.TraversalGroup -> Modifier.semantics { isTraversalGroup = true }
                })
        ) {
            Text("Screen title: 1.6.0-beta01", Modifier.align(Alignment.Center), fontWeight = FontWeight.Bold)
        }
        Column(
            modifier = Modifier
                .align(Alignment.BottomEnd)
                .selectableGroup()
                .background(Color.Black.copy(0.1f))
                .padding(16.dp)
        ) {
            Spacer(Modifier.height(4.dp))
            for (enum in Value.entries) {
                Row(
                    horizontalArrangement = Arrangement.Center,
                    verticalAlignment = Alignment.CenterVertically,
                    modifier = Modifier
                        .sizeIn(48.dp, 48.dp)
                        .clickable { value = enum }
                ) {
                    RadioButton(
                        selected = value == enum,
                        onClick = null,
                    )
                    Text(
                        when (enum) {
                            Value.None -> "None"
                            Value.TestTag -> "TestTag"
                            Value.TraversalGroup -> "TraversalGroup"
                        }
                    )
                }
            }
        }
    }
}

Thanks for the update and for filing the bug originally. Indeed aosp/2798058 was meant to fix this issue and it sounds like it did at least in the case of testTag.

The full list of built-in properties that do not cause pruning is those that are defined as plain SemanticsPropertyKey instead of AccessibilityKey in SemanticsProperties.kt (and do not delegate construction to an AccessibilityKey either). As of today, the complete list is testTag, testTagsAsResourceId, invisibleToUser, textSubstitution, isShowingTextSubstitution, indexForKey and editable.

Re: traversalGroup, making it continue to cause prune is by design.

• First on the general principle that it is an accessibility-related property and all of the others cause pruning too.
• Also because traversalGroup is the only semantics property on non-clickable Material Surfaces. And as described in point 3 of aosp/1660323, these are designed to block touch input, and if elements underneath them cannot be reached by touch, then for consistency they should not be reachable by TalkBack linear traversal either.

Re: traversalIndex there is more flexibility: the only rationale for that one was the general principle but I'm guessing it would probably not break any behavior to switch it to a plain SemanticsPropertyKey.

Anyway, either way to consider a further change, I would like to hear more about the real-life use case motivating the question. What is the scenario where you must use traversalGroup to solve one problem but at the same the pruning causes an different problem? (And I would be more likely to consider a change in Compose if I'm convinced there's no reasonable workaround on the app side.)

I tried on this project, and I couldn't make it work without setting traversalGroup = true on RevealingTopBar. In AndroidComposeViewAccessibilityDelegateCompat in geometryDepthFirstSearch(), code takes different paths depending on whether node is traversal group or not, and path where isTraversalGroup = true works great for accessibility traversal order, but causes RevelaingTopBar node to prune nodes underneath it, because SemanticsProperties.IsTraversalGroup defined as AccessibilityKey, i.e. sets isImportantForAccessibility = true. Same for SemanticsProperties.TraversalIndex - it is only used in AndroidComposeViewAccessibilityDelegateCompat.sortByGeometryGroupings() for sorting, but also causes undesired pruning.

As for Material Surface, if the change for IsTraversalGroup and TraversalIndex is to be implemented, you can add another semantics property to it, that will cause pruning. Perhaps IsContainer is a good candidate for such semantics property, it will work the same as IsTraversalGroup, but will also prune.

Here two videos: TraversalFalse demonstrates, that no pruning occurs, but traversal order is broken; and TraversalTrue demonstrates, that traversal order is good, but unwanted pruning occurs.

testTag no longer causes pruning in Compose 1.6, and traversalGroup/traversalIndex will no longer cause pruning in Compose 1.7 (due this summer).

isTraversalGroup/traversalIndex no longer prune again with a recent patch that we’re aiming to incorporate in our next alpha release. Marking as fixed.