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
The current documentation says you can use Ctrl+End to move focus to the first focusable after the feed. But the visibility of that next focusable depends on how the feed is implemented and where that next focusable is. If new feed items are added on scroll and the next focusable is below the feed role you’ll never see that next focusable.
I’ve created a demo page where you can see this in action.
This means the current documentation/guidance only works if any focusables after the feed are visually next to the feed. To mitigate this my demo page includes a “load more” button that is added when you press Ctrl+End.
If the content to which the user wants to jump is adjacent, then a "skip link" pattern (which everyone can see and use with no special instructions) can do the trick.
But the problem is that in a responsive world we can never be certain content will be adjacent. Linearizing for narrow viewports / zoom is so common that it would be a mistake to rely on on a skip link.
In your example, the "Load More" button only appears if I am using my keyboard exclusively when focus has already made it into the feed content. If I scroll the page for a bit (by pressing Space or using my mouse) then all bets are off.
I think the pattern might need to be split:
A feed pattern where there is never focusable content after the feed (like a social media or chat window);
A feed pattern where "Load more" is the default until the user explicitly disables it.
If the content to which the user wants to jump is adjacent, then a "skip link" pattern (which everyone can see and use with no special instructions) can do the trick.
But the problem is that in a responsive world we can never be certain content will be adjacent. Linearizing for narrow viewports / zoom is so common that it would be a mistake to rely on on a skip link.
Wouldn’t that depend on where the skip link went? Twitter has a bunch of links and the “Who to follow” sections after the feed section in the middle. The current pattern would work (as would a skip link I think). On narrow viewports the UI changes to have the sticky navigation at the bottom. In that case the skip link/keyboard command could send focus to that, right?
How I looked at the problem was that the pattern as it stands introduces layout constraints. Those would need to be documented in the pattern. Or the pattern needs to be adjusted. Perhaps, like you suggested, it should have a “load more” button by default if content is visually below the feed?
In your example, the "Load More" button only appears if I am using my keyboard exclusively when focus has already made it into the feed content. If I scroll the page for a bit (by pressing Space or using my mouse) then all bets are off.
That’s a good point. This was mostly due to me trying to develop the example, running into this issue, and seeing what solutions could be. Not fully fleshed out in that sense. My previous paragraph would solve for this too I think? How do you see that?
The current documentation says you can use Ctrl+End to move focus to the first focusable after the feed. But the visibility of that next focusable depends on how the feed is implemented and where that next focusable is. If new feed items are added on scroll and the next focusable is below the feed role you’ll never see that next focusable.
I’ve created a demo page where you can see this in action.
This means the current documentation/guidance only works if any focusables after the feed are visually next to the feed. To mitigate this my demo page includes a “load more” button that is added when you press Ctrl+End.
Question is: how do we solve this in the APG?
Steps to reproduce:
Expected
The first focusable after the feed is scrolled into view.
Actual
The feed loads more items when your browser tries to scroll to the focusable after it.
Related issues
Partially inspired by #877.
APG #565: Review feed example.
Tagging for visibility: @mcking65 @aardrian
The text was updated successfully, but these errors were encountered: