You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
When moving accessibility focus off-screen, scroll the screen. #1714
Simplest way to fix this is probably to keep one item before and after the currently visible items in a lazy list alive even though they're off-screen, and to then autoscroll when accessibility focus is moved to those items.
Lists with multiple slivers don't behave correctly when switching from one sliver to another. In order to fix this, we need to expose each sliver individually as a "android.widget.ScrollView" to Android's accessibility API and we also need to know if a sliver has hidden elements beyond its trailing and leading edge. The sliver is only allowed to claim to be scrollable in a particular direction if elements can be exposed when scrolling in that direction (#1675).
Exposing the slivers doesn't seem right to me, unless I misunderstood what you meant. e.g. a SliverPadding containing a SliverList should presumably act exactly the same as a SliverList alone; a viewport with ten SliverToBoxAdapters should presumably act the same as a viewport with five two-item SliverLists which should act the same as a single ten-item SliverList.
Those are the trivial cases that should behave exactly as you say. However, it gets more complicated: Let's imagine we have a pinned SliverAppBar and a SliverList:
Let's imagine we are scrolled all the way to the bottom of the list (app bar is at its smallest hight), that leaves us with the following semantics tree:
If you now swipe through all accessibility nodes starting at the bottom, the accessibility focus will eventually switch from node 12 (last node in the ListSliver) to node 4 (the AppBarSliver) without doing a scroll. If you continue swiping through the nodes upwards of node 4, Android will realize that you're trying to leave a scrollable container and issue a scroll action which scrolls down the ListSliver. This behavior is not correct. Instead, the list should have scrolled when the accessibility focus moved away from node 12 (which is essentially the boundary between the two Slivers at play here). To achieve this, we will have to expose the sliver boundaries to the Android Accessibility API somehow (and Android's accessibility API also needs to be know if a given sliver is still scrollable or if it should move the accessibility focus on to the next sliver).
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
Hixie commentedon Jun 26, 2017
Simplest way to fix this is probably to keep one item before and after the currently visible items in a lazy list alive even though they're off-screen, and to then autoscroll when accessibility focus is moved to those items.
This would also fix #170.
goderbauer commentedon Jul 10, 2017
flutter-team-archive/engine#3856 addressed this on Android for simple lists containing just one Sliver.
Lists with multiple slivers don't behave correctly when switching from one sliver to another. In order to fix this, we need to expose each sliver individually as a "android.widget.ScrollView" to Android's accessibility API and we also need to know if a sliver has hidden elements beyond its trailing and leading edge. The sliver is only allowed to claim to be scrollable in a particular direction if elements can be exposed when scrolling in that direction (#1675).
Hixie commentedon Jul 10, 2017
Exposing the slivers doesn't seem right to me, unless I misunderstood what you meant. e.g. a SliverPadding containing a SliverList should presumably act exactly the same as a SliverList alone; a viewport with ten SliverToBoxAdapters should presumably act the same as a viewport with five two-item SliverLists which should act the same as a single ten-item SliverList.
goderbauer commentedon Jul 11, 2017
Those are the trivial cases that should behave exactly as you say. However, it gets more complicated: Let's imagine we have a pinned SliverAppBar and a SliverList:
Let's imagine we are scrolled all the way to the bottom of the list (app bar is at its smallest hight), that leaves us with the following semantics tree:
If you now swipe through all accessibility nodes starting at the bottom, the accessibility focus will eventually switch from node 12 (last node in the ListSliver) to node 4 (the AppBarSliver) without doing a scroll. If you continue swiping through the nodes upwards of node 4, Android will realize that you're trying to leave a scrollable container and issue a scroll action which scrolls down the ListSliver. This behavior is not correct. Instead, the list should have scrolled when the accessibility focus moved away from node 12 (which is essentially the boundary between the two Slivers at play here). To achieve this, we will have to expose the sliver boundaries to the Android Accessibility API somehow (and Android's accessibility API also needs to be know if a given sliver is still scrollable or if it should move the accessibility focus on to the next sliver).
That's what I meant by my previous comment.
Hixie commentedon Jul 11, 2017
Oh man, that's a tricky case. Good luck? :-)
goderbauer commentedon Sep 7, 2017
This has been fixed in Android. I am going to open a separate bug for iOS.
[quick_actions] Update README.md (flutter#1714)
github-actions commentedon Aug 17, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.