Collect feedback on carousel pattern introduced in APG 1.1 Release 3 (January 2019)

[mcking65]

Feedback Summary for the meeting agenda

1. CSS - display: none, hidden slide is focusable, composite widget
2. Grouped carousel keyboard interaction
3. Carousel example without automatic image rotation(similar to number 5 request)
4. aria-roledescription support issue (aria-roledescription in JAWS wnolfm/a11y-slider#12 (comment))
5. Basic carousel without auto rotate(no play/pause button)

[alrdytaken]

Tab sequence

Issue: Behaviour is a result of implementation details

Keyboard Interaction
Tab and Shift + Tab: Move focus through the interactive elements of the carousel as specified by the page tab sequence -- scripting for Tab is not necessary.

This leads to inconsistent behaviour between differing implementations of the sliding effect.
In example:
• The provided example hides non visible slides by using display: none, which excludes them (or there focusable children) from the page tab sequence
• In a more common approach, using overflow: scroll and manipulating the scroll position to move slides in and out of the visible area, the slides (and there focusable children) are not removed from the page tab sequence (unless hurting performance with scroll event listeners)

Issue: Behaviour of carousels with multiple visible slides

• Going back and forth between slides feels the more clunky, the more focusable slides you have. Imagine the provided example with 5 slides, each focusable. After having focused all 5 visible slides you need to go all the way back, threw those 5 slides to reach the next-slide-button again.
• Even worse in the second example above where the hidden slides are focusable, aswell.

Question: Why not a composite widgets

Implementing a carousel as a composite widget, which exists as a single navigation stop within the larger navigation system of the web page. and provide a separate navigation mechanism for users to navigate to elements that are descendants or owned children of the composite element. solves the issues.

[chrisdholt]

Question: "Grouped" keyboard interaction model

I'm trying to understand the divergence in the proposed "group" pattern from the functional behavior of tabs for the slide pickers to a native button implementation. It seems that the intended model for grouped is the convergence between the tabbed and basic implementation.

Why the shift from treating these as tabs to then treating them as buttons?
It seems like this is called out in the spec as well:

Because each slide selector button adds an element to the page tab sequence, this style is the least friendly for keyboard users.

Would the above still be true if the tabbed interaction model was implemented?

I'm trying to understand the delta between the two implementations of the slide picker controls. The primary difference to the control seems to be the addition of rotation and next/previous controls though I'm not sure that requires a completely divergent keyboard interaction model. That seems problematic and confusing for both implementors and users. Are there concerns regarding navigation redundancy by exposing next/previous and individual buttons to fire content? A possible additional benefit of maintaining the tabbed interaction model is that the next/previous controls could be hidden from screen readers which would eliminate any concerns regarding duplicate navigation as the keyboard interaction model for tabs supports next/previous behavior.

[jamesedjac]

Issue: The Carousel Design Pattern Does Not Implement User Expected Methods of Pausing Carousels

Description

The Carousel Design Pattern does not support pausing the carousel when the user manually changes the slide, which is historically the most common method for allowing users to pause carousel rotation.
For examples of carousels that behave this way see:

• https://www.amazon.com/
• https://www.microsoft.com/en-us/

Recommended Change

The following requirement (or one to the same effect) should be added:

• When a user interacts with the carousel controls (The Rotation Control, Next Slide Control, Previous Slide Control or Slide Picker Controls) or any interactive elements within the Carousel, using any input device (including keyboard, mouse, or touch screen), carousel auto-rotation is paused and does not resume unless the user explicitly restarts it using the Rotation Control

Why is this change important?

Supporting standard methods for pausing animated content is critical for supporting 2.2.2 Pause, Stop, Hide for may users including users with ADHD and other impairments that impact attention and/or cognitive load.

Users with ADHD

I can best speak to users with ADHD. To understand why this support is critical, it’s helpful to have some understanding of how ADHD impacts attention. One of the ways it was explained to me when I was first diagnosed is that the ADHD brain gives pretty much all sensory input the same level of urgency.

This means that animated web content such as a carousel or pop up notification can cause the same disruption and cognitive load as a more intense disruption. For me, this kind of animation can demand the roughly the same attention and cognitive resources as a fire alarm going off or someone saying my name loudly. For people who have more of an inattentive sub type of ADHD than I do, everything may seem equally unimportant, but this kind of animation will still cause them to lose focus on what they are working on, because they would not be able to screen it out the way a typical user could.

This is not universally true of all stimulus for all people (some people with ADHD are more sensitive to sound rather than motion for instance) and can vary based on things like how much sleep a person has had, or how much additional cognitive load they are under. But, keeping in mind that any stimulus could have this level of disruption is the right stance to take when making design considerations, and automatically rotating carousels are a big pain point for me on the web.

It’s also helpful to remember that 2.2.2 is explicitly mentioned in Conformance Requirement 5, because distracting animation can impact users’ ability to interact with elements on the whole page. This can include interacting with the controls to pause carousels themselves, making it difficult to figure out how a particular carousel can be turned off if it does not support standard methods.

For myself, there have definitely been times where a page had a pause button, but did not pause when the slide was rotated by the user, and the slide rotation was so disruptive I could not find the pause button before needing to take a break from using the web site or application (Unlike controls for changing the slide, pause buttons are not styled consistently, have different levels of visibility, are rare, and are not consistently placed). In addition, the more time I spend looking for a method to pause a slide, the more cumulative cognitive load it adds, and spending 3 seconds vs. 10 seconds trying to pause a carousel can be the difference between whether or not I need to take a break and walk away from the computer after finally pausing it.

In short, it’s critical that the first method I attempt to pause the carousel works, and given the state of carousels on the web, the first method I attempt will always be to manually rotate the slider.

Other Users

In addition, users with cognitive impairments that mean they need more time to read the current slide would also benefit from it being paused when they have explicitly chosen a specific slide to read. And it just makes sense for rotation to stop if a user has made an explicit chose to read a particular slide

Additional Reasons to Support this Change

In addition to the user impacts outline above, supporting standard methods for pausing carousels makes sense because the ARIA Authoring Practices require standard interaction methods in many other design patterns. For instance, the Button and Checkbox patterns both require the standard keyboard interactivity. While those two examples are defined as part of the HTML spec, given that there is no existing widely adopted standard for carousels, we should instead default to user expectations.

Why the Methods in the Design Pattern are not Sufficient

The Design Pattern does require that the carousel stop rotating when the user hovers over it. However, unlike for when elements in the carousel receive keyboard focus, the Design Pattern does not require the rotation to remain paused when the mouse hover leaves the control.
This is a very good requirement, and I support it fully, but it is not sufficient to support 2.2.2 Pause, Stop, Hide for sighted users, particularly users with ADHD. This is because the intent of this criterion is to avoid distracting users as they interact with content that is parallel to the animated content and not just the carousel content itself.
For instance, I could hover my mouse over the carousel, but that prevents me from moving the mouse in order to interact with content on the same page without resuming the animation. It also requires me to continually track the position of the carousel with the mouse if I use the mouse wheel to scroll the page. Similar scenarios are actually covered in the WCAG 2.0 Understanding Documentation for 2.2.2:

• “For a mechanism to be considered "a mechanism for the user to pause," it must provide the user with a means to pause that does not tie up the user or the focus so that the page cannot be used.”
• “Having an animation stop only so long as a user has focus on it (where it restarts as soon as the user moves the focus away) would not be considered a "mechanism for the user to pause" because it makes the page unusable in the process and would not meet this SC.”

I suppose that on desktop, I could hover over the carousel to pause it long enough to find the pause button. But I don’t think this is reliable as in the past I have had instances where finding the pause button would require scrolling the page or is still difficult to spot, and some implementations may require the user to move the mouse across space between the carousel slide and pause button, which could cause the rotation to resume before the button could be pressed. More importantly, this hover requirement does not support users on mobile devices.

[Wildebrew]

The use of aria-roledescription sounds good in theory but it has virtually non-existent screen reader support. It's worse than that.

In fact a Jaws bug makes it near impossible to interact with an element that has an aria-roledescription property (see my comment at the end of that thread).

NVDA does not announce the aria-roledescription at all (which is an improvement over the Jaws experience).

I would recommend a certain baseline support for the attribute before the official APG pattern recommends its use, especially when there are bugs that make carousels near impossible to use if authored according to the pattern.

[tasnook]

Would love a version without auto rotate

I really appreciate all the work that has been done on this example. Carousels have been an excruciating pain in my side for years.

Feedback: I would really like to see an alternative version of the Carousel example that does not auto rotate at all and the play/pause button is removed.

Also, I agree with @Wildebrew 's comment. I've seen little to no screen reader support for aria-roledescription.

[sclsweb]

I'm writing in support of the comments by @jamesedjac ("Issue: The Carousel Design Pattern Does Not Implement User Expected Methods of Pausing Carousels") based on use of the Auto-Rotating Image Carousel Example, with some additional detail. My apologies if this is not the proper place for a member of the general public to leave feedback.

When you click the next/previous button, the button gains focus, which pauses automatic rotation. If you switch to a second browser tab/window, focus moves to that tab/window -- meanwhile the carousel auto-advances in the background. If you return to the browser tab with the carousel, focus returns to the next/previous button that originally had focus, and the auto-rotation pauses again -- but at a different slide from where you originally left off, which is confusing. The expectation of the users who tested this was that auto-rotation would remain paused at the same slide while focus moved to a second tab/window and that the same slide would still be in situ when they came back to it in the original tab.

[mcking65]

@sclsweb

Please have a look at the latest version in the editor's draft:
Auto-Rotating Image Carousel Example with Buttons for Slide Control | WAI-ARIA Authoring Practices 1.2.

Sorry we are so delayed getting the 1.2 version of APG on w3.org.

[mcking65]

Closing; feedback addressed in multiple updates now visible in editor's draft and scheduled for publication ion approximately November 15, 2021.