Status Update
Comments
kl...@google.com <kl...@google.com> #2
ap...@google.com <ap...@google.com> #3
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.
ap...@google.com <ap...@google.com> #4
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?
ap...@google.com <ap...@google.com> #5
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 ...
ba...@gmail.com <ba...@gmail.com> #6
For
For #4, currently, I think elements on top will be focused last (if it is not completely covering the node below it). Maybe we should consider changing it (don't break the finding node for touch explore though)?
je...@google.com <je...@google.com>
lp...@google.com <lp...@google.com> #8
is...@gmail.com <is...@gmail.com> #9
headings, another mode could allow navigation between fixed components on
screen like the app bar and fab (as an idea).
Since it hasn't been exposed in the compose API yet, I wanted to highlight
this limitation of the existing traversal APIs; most of the accessibility
APIs were added before I was an Android dev so this is a unique chance for
feedback ☺️
On Tue, 27 Apr 2021, 20:24 , <buganizer-system@google.com> wrote:
Description
Currently Compose UI tests use an unconfined coroutine dispatcher for all coroutines that are part of the composition (e.g.
LaunchedEffect
,rememberComposeScope
, and even the coroutine running theRecomposer
itself).This is inconsistent with how coroutines are dispatched in non-test environments, where we use the main immediate dispatcher. It is also dangerous because unconfined dispatchers can change the order that code will run in sneaky ways.