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).

"allow navigation between fixed components on screen like the app bar and fab " seems to be a feature which should implemented in talkback.

Agree.

I think it's important to distinguish between properly describing the UI and correct TalkBack behavior.

Agree.

My suggestion was that it should be possible to describe the nature of components like FABs and other app chrome like appbars by being able to mark them as chrome, similar to how it's possible to mark arbitrary views as headings. This needs to be implemented in compose and/or the view system since this is what the app developer has access to.

It adds metadata about these components that accessibility services can then use (which is separate). TalkBack could add it as a navigation type like headings, paragraphs, words etc. which allows the user to jump between layers. TalkBack could use it in the autoscroll case that Phill mentioned too (iterate through app chrome before autoscroll - though it does sound annoying, maybe it could be an opt-out setting). Switch access could incorporate it too, since it has the same issue.

Hey, so we are working on App Widgets, and one of the layout we are working with is this: http://screen/3DhenbTZNKtEqXw (only showing the silhouette, as this is under development).

There are five locations for buttons, and iterating through them should probably be from more important to less important, meaning the center first, and then around in a circle, starting probably from top-left, although this might depend on whether the UI is LTR or RTL and on the exact application.