Carousel behaviour needs more clarification and a demo with matching behaviour
Opened this issue · 8 comments
How the carousel should behave when someone navigates with the tab key and/or with a screen reader is unclear and does not appear to describe what is happening in the demo. Such that the demo does not appear to behave quite as I would expect.
When navigating the carousel demo with the tab key I observed:
- first tab press moves focus to the 'next' button.
- second tab press moves focus to the first list item.
- third tab press moves focus to the in-item topic link (personally not a fan sub-links in carousel items).
- fourth-seventh tab presses move focus through the other visible items and topic links.
- eighth tab press scrolls the carousel but doesn't appear to focus on anything specific (and certainly not the next list item).
- ninth tab press appears to move focus to the last/7th item in the list and it's in-item link (rather unexpected).
- tenth tab press again doesn't appear to focus on anything specific (not sure what to expect at this point).
- eleventh tab press moves focus to the 'previous' button.
- continued tab presses then move through the remaining now visible items and topic links.
If navigating with the tab key should (after the next button) move through the full list of items, then it is not doing this. If navigating with the tab key should trigger the carousel to scroll when moving onward from the last visible item, and then focus on the next/previous buttons before continuing through the new visible items, then the demo is not not doing this correctly either.
Which and what it is supposed to do is unclear from the documentation.
When navigating with screen reader controls (not the tab key) the behaviour is more consistent with what I would expect, though it takes 8 arrow presses to move through each item in the list rather than grouping the content within each item.
One of the big challenges with carousels for keyboard/switch/screenreader navigation is balancing between jumping through a list with next/previous (or scroll forward/backward) buttons, and being able to select an item that is currently visible in the carousel.
When navigating with keyboard control, it is nicely straightforward to ignore the next/previous buttons and move focus from item to item in the list, scrolling items into view as they gain focus. However, this quickly becomes tedious if a carousel contains a long list of items and the user cannot easily jump ahead.
When navigating without sight, it isn't obvious that not all list items are visible/available or that there is a way to skip ahead in the list.
And on mobile, I've seen some carousels without the next/previous arrows, which is not ideal for users who may not understand to swipe. Triggering scroll by touching a partially visible item at the edge of the screen, and keeping the item that currently has focus in the centre, can both help with this (Amy Leak did some user research around this for something else).
It would be good to document the navigation user journey for each type of user (keyboard/switch, screen reader, mobile with/without swipe gestures, etc) to be clearer about how a carousel should behave. And to ensure the demo matches the expected behaviour.
This issue mixes concerns that would be better in separate tickets.
- There is an implementation bug that means focus is moved in a not-as-designed manner. You describe that when you say:
eighth tab press scrolls the carousel but doesn't appear to focus on anything specific (and certainly not the next list item).
ninth tab press appears to move focus to the last/7th item in the list and it's in-item link (rather unexpected).
tenth tab press again doesn't appear to focus on anything specific (not sure what to expect at this point).
- Second issue to address is about the written description of the desired behaviour being hard to understand. You refer to that when you say:
Which and what it is supposed to do is unclear from the documentation.
Would you mind splitting this into a couple tickets, which could then be addressed individually please?
Actually, because the documentation is unclear I don't know if my expectations are correct. I think it would be good to work out what the expected behaviour should be in regard a BBC GEL carousel, document that more precisely, then ensure the demo behaves in line with what is documented.
I'm not sure it would be possible to split that, as any change to the demo would be dependent on what behaviour is agreed and documented.
The documentation describes how IntersectionObserver (where supported) ensures only visible items are focusable / perceivable by screen reader. This is described in the documentation:
This not only invokes the 'fading' effect described in Recommended layout, but also removes inert items from focus order and the accessibility tree[3]. The upshot is that, like sighted mouse users, keyboard and screen reader users can only perceive and interact with items that are not inert.
Were the inert attribute not employed, a keyboard user could scroll to the end of a long set of items, only to find that the first (currently obscured) item was still first in focus order. Pressing tab would scroll the container back to the beginning and progress would be lost.
If the next list item is not in view, naturally the next element in focus order will be after the carousel component. This is by design, and solves the problem you described in your bug report:
this quickly becomes tedious if a carousel contains a long list of items and the user cannot easily jump ahead.
Only where IntersectionObserver is unsupported is every item focusable (even where invisible). This would indeed make navigation by tab tedious, but screen reader users (if not just-keyboard users) would be able to defer to landmark and heading navigation to skip past carousels.
Support for IntersectionObserver is near-universal: https://caniuse.com/#feat=intersectionobserver
@Heydon One issue that has translated into a question on our internal support channels is about the intented function of setting some elements to inert. It took me a while to understand the question, but it became clear when someone pointed to the implemented keyboard behaviour of the carousel on iPlayer:
- Press [TabKey] to move focus into the carousel, the [NextButton] is highlighted.
- Use the keyboard to activate the [NextButton], the carousel pane moves to reveal the next page of items.
- Repeat until the end of items or the user sees an item they want to interact with...
- Press [TabKey] to move focus off of the [NextButton], the first item in the carousel gets focus
The purpose of setting items to inert when they are not visible in the carousel pane, is to avoid the bad experience in step 4, where a sighted keyboarder has already navigated to the item they want to interact with by using the buttons, and when they then try to move into the currently displayed set of items, they instead jump all the way back to the beginning and find themselves on the first item.
@EmmaJP Try the steps listed above on the carousel at https://www.bbc.co.uk/iplayer to see what I mean. The expectation should be that when focus is advanced off of the [NextButton] it should then move onto one of the currently visible items, not onto whatever the first item is (regardless of whether or not it is currently visible).
Sooo... that's a lot of words from me to explain why Heydon uses the inert attribute to disable non-visible carousel items from receiving focus. I suppose the crux of this issue is to try to explain that in more readable fashion within the body of the actual guide?
Mixed into the above work is a confounding coincidence that there is also a bug in the demo, so that focus does not move as intended, but as I said before I think (once the two are picked apart) that task should be it's own separate issue.
It so happens @JamieKnightBBC is working on a way to diagram keyboard journeys, which would suit this issue very nicely indeed. @Heydon we should talk off GitHub about commissioning you to help define that if you are interested. (I'll email you.)