Draft carousel design pattern

[ZoeBijl]

There are no roles specific to carousel. There are many valid ways of constructing them. This pattern will somehow need to provide a lot of latitude in the roles, states, and properties. We might want to even defer to examples for that aspect and explain how the roles/states/properties used provide accessibility.

Use the issue43-add-carousel-pattern branch for all pull requests related to this issue.

Preview current work in carousel pattern branch

Carousel design pattern in issue43-add-carousel-pattern branch

[mcking65]

You can now see changes made in pull request #945 by @jongund in the carousel-v2 branch at:

https://raw.githack.com/w3c/aria-practices/carousel-v2/aria-practices.html#carousel

[mcking65]

@jongund, Reviewing a completely new pattern plus two examples all in one pull request is going to be overwhelming for reviewers. It will be difficult to have discussions of each of the parts.

Because the pattern and both examples are all in a single branch, there is no way to split it into multiple pull requests. So, I would like to split the parts into three branches, one for the pattern and one for each of the two examples. An additional benefit is that merging to master for publication is not an all or nothing deal. If we don't have time to polish both examples, we could bring in just the pattern and one example.

The carousel design pattern is now in issue43-add-carousel-pattern branch.
It does not have links to examples. After at least one example is merged to master, we will add a link to the example from the pattern.

I am creating one new issue and two new branches:

1. Branch issue458-add-carousel-example
2. Issue Add carousel example with tabs as slide control #955 for developing a carousel with tabs as slide control
3. Branch issue955-add-tabbed-carousel-example

@jongund, I put the pattern content in the pattern branch, but I'm not going to populate the new example branches with the example files; I'll let you do it so the commit history shows they came from you. Just copy example/carousel folder to a place outside your repo, then switch to each branch, and put the appropriate files in, commit, and push.

[jongund]

@mcking65 I will commit the example now to the new branches

[jongund]

@mcking65 I suggest modifying the first sentence to: "A carousel presents a set of items, referred to as slides, by sequentially showing one slide at a time, the remaining slides are hidden from view. In some instances of a carousel more than one slide may be shown at a time..

[jongund]

@mcking65 the design pattern comments:

• Design pattern does not address the order of the pause/start/stop/tabbed interface, this is especially important when screen reader users are in review mode, since no elements will receive keyboard focus to stop the rotation. One recommendation is to make sure the pause button is before any content that is being rotated.

• Should the description also mention that slides typically have interactive content, usually links and often the slide image itself is a link .

• The pause/start button is recommended to change the label from "Stop slide rotation" or "Start slide rotation", why is this recommend over a toggle button pattern, is this same recommendation we would make for a media player? Or in general what is the thinking behind using a toggle button versus changing the function of a button and then changing it's label?

[mcking65]

@jongund commented:

I suggest modifying the first sentence to: "A carousel presents a set of items, referred to as slides, by sequentially showing one slide at a time, the remaining slides are hidden from view. In some instances of a carousel more than one slide may be shown at a time..

Jon, I like the idea that we explain rotation by first using the term sequentially displaying. I took it a bit further and described typical interaction to emphasize that 1) it is manual and 2) it clearly explains what is meant by rotate. I attempted to capture this in commit ee6154e.

[mcking65]

@jongund commented:

• Design pattern does not address the order of the pause/start/stop/tabbed interface, this is especially important when screen reader users are in review mode, since no elements will receive keyboard focus to stop the rotation. One recommendation is to make sure the pause button is before any content that is being rotated.

Good point, having the rotation control first is very important. I added a bullet to cover this in commit 30e3806.

• Should the description also mention that slides typically have interactive content, usually links and often the slide image itself is a link .

I don't think this is necessary.

• The pause/start button is recommended to change the label from "Stop slide rotation" or "Start slide rotation", why is this recommend over a toggle button pattern, is this same recommendation we would make for a media player? Or in general what is the thinking behind using a toggle button versus changing the function of a button and then changing it's label?

In general, in my experience, my own view is that a label that says what a command-type button will do is more clear than a toggle. Circumstances where a checkbox would be logically appropriate but the implementation is more like a button are good for toggles. ... this is by no means a rule ... it's an opinion. It might be helpful if the task force could someday land on some consensus guidance on this point.

In this particular situation, a button that is labeled "Stop automatic slide rotation" clearly indicates that automatic rotation is happening.

I wonder how clear the word "rotation" is ... I thought of "stop automatic slide changes" but that seems kind of ambiguous. Might the user think that the content of a slide is changing? Now that I think about it, the slides are not rotating, the carousel is rotating. Oh well ... perfect labels that are short are sometimes not feasible. Hmm, maybe "Stop playing slide show?"

[jongund]

@mcking65 What happens if a screen reader user is using review mode to read slide content that is rotated out of view, the review cursor goes back to the beginning of the document without any warning to the user. This is more descriptive of the issue than issuing a reading command that goes to the next slides content.

[mcking65]

@jongund commented:

@mcking65 What happens if a screen reader user is using review mode to read slide content that is rotated out of view, the review cursor goes back to the beginning of the document without any warning to the user. This is more descriptive of the issue than issuing a reading command that goes to the next slides content.

In my experience, The reading cursor does not jumpt to the top of the page when slide content is automatically rotating. There was a day, maybe 4+ years back, when JAWS would have behaved in that way. I don't have specific memories of NVDA doing that. And, I've only been using VoiceOver for 3 years now, so have no recollection of older version behavior.

Generally, you would get that kind of behavior if the entire document is being replaced dynamically. I don't think we have that concern for carousels.

[bluSCALE4]

The recent examples posted are great. I'd hoped one could include actions tied to the slides themselves as many carousels include left and right functionality within any given slide. As mentioned in the first post, there is no role for carousel so I've seen listbox, tablist, tabpanel and even saw grid touted.

[mcking65]

@bluSCALE4,

We are planning to add at least one more carousel example in the next release. You can get to the project with issues for bugs and enhancements planned for any example page by using the related issues link at the top of the example page. Here is a link to the carousel project.

Listbox does not match the semantics and interaction patterns of slide picker controls (dots for the slides) as well as tablist. It could be used, but options in a listbox do not inherrently communicate a controlling relationship to a slide panel in the same way as a tab element. Screen reader users are very familiar with the concept of a tab changing a related section of the page.

Gridcells are not a particularly good container for slides because they introduce complex interactions when a slide contains multiple interactive elements. It would be possible, but far more complex than is necessary. It is not necessary to use gridcell if you wish to provide left/right arrow keys as hotkeys for prev/next slide when focus is on the container. It is important, in that case, that the container is focused, and not a widget inside the container. The container could be a group as in the current example or a tabpanel as we will have in the example being developed for issue #955.

Given the conversation in the issue you referenced in the pure-react-carousel repo, I recommend you read the complete carousel pattern. The sections of the carousel pattern for keyboard inter action and roles, states, and properties describe how to implement a slide picker control using tabs.

[mcking65]

The pattern was completed with commit ca78f0a and is published in release 3 of the APG. Feedback is being collected in issue 970.