IssueTracker

Since this hasn't been implemented yet, please consider the case where the user needs to access the FAB (or other component) while they're in the middle of an infinitely scrolling list (like a Twitter feed) when adding support.

The traversal methods had limited usefulness (but agreed with Fanny, they were useful :+1:) since they would only work at the start of a user journey. If the user wants to navigate from a list item to a FAB or an action item in the app bar and back, then it's less useful.

Yinglei, yes, I had an impression that we don't want to expose this API. Can we solve the issue with FAB without it?

As for the z-order, we currently order them as far as I remember. So whichever element is on top it will be focused first, correct?

fanny.pluvinage@ Do you have a particular use case in mind where you need to re-order elements for accessibility in z-direction?

I understand why you don't want to expose this API.

Maybe i've done something wrong, but when adding a FAB Button after a LazyColumn, the LazyColumn get the focus first even if I change the zIndex modifier = Modifier.zIndex(0f) (setting the FAB Button on top or behind, it seems that it doesn't change anything.

FloatingActionButton(onClick = { /*TODO*/ },
                    modifier = Modifier.zIndex(0f)) {
                    Icon(painter = painterResource(id = R.drawable.ic_star_rate),
                        contentDescription = "Add movie")
                }

                LazyColumn(modifier = Modifier.zIndex(1f)) {
                    items(viewModel.movies) { message ->
                        MovieItem(message, backgroundColors.random())
                    }
                }

I had a similar usecase to design a card like visual element earlier this year when I was doing SwiftUI. I was able to resolve it with .accessibility(sortPriority: 2) I'll try to send you a screenshot later, when Xcode will have finish building ...

Yes, disambiguating based on zIndex sounds like a good idea, I can't think of any reason not to do it that way. It looks like the reason ViewGroup didn't have it is simply because View System didn't have zIndex (it supported translationZ, but structurally zIndex is better suited to calculate overlap order without requiring any matrix math).