WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Carousel with multiple items - recommended keyboard operation when activating Next-button

for

From: Bryan Garaventa
Date: May 11, 2023 10:32AM

Hi,
The following may be of help.
https://whatsock.com/Templates/Carousels/ManualRotate/index.htm

This has the ability to adjust the number of slides from single to multiple as desired, plus how many are shown at one time, whether it is auto or manual rotate, and so on. The code for this is included within Apex 4X, available at
https://github.com/whatsock/apex

In addition to using Tab and Shift+Tab for navigation, you can use the arrow keys to switch between slide groups as well.

This was developed using JAWS and NVDA on Windows and VO on iOS to ensure the greatest level of accessibility.

All the best,
Bryan Garaventa
https://www.linkedin.com/in/bgaraventa

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Mark Magennis
Sent: Thursday, May 11, 2023 8:59 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] [EXTERNAL] Carousel with multiple items - recommended keyboard operation when activating Next-button

Jon,

I've taken a look at the ARIA Practices carousel coding pattern and I doubt that it is appropriate for the OP's circumstance. It seems to be aimed at carousels that contain a single item like those typically used for marketing image 'slide shows' at the top of a home page. I have been reviewing a carousel that seems similar to the OP's in that it contains multiple cards which are all links to courses and is scrolled a group at a time, not a single card at a time. Given the nature of this carousel and its situation within the page my opinion is that role="region" is unnecessary and doesn't add any clarification or aid navigation, so its aria-label is also redundant and although it is good to name the strip for users who tab into it skipping past its heading, this can best be done on the <ul>. The aria-roledescription="carousel" and aria-roledescription="slide" are equally unnecessary and I believe complicate things because "carousels of slides" is a visual metaphor that may well be suited to a set of marketing images but this content is best presented to screen reader users simply as lists of links to courses with buttons to see more. So there are 'carousels' and there are 'carousels' and they are all different and need to be coded differently.

I also noted in testing that the addition of aria-roledescription="slide" to the link's container caused JAWS to announce each link as a "slide" but not a link when arrowing to it, so users wouldn't know that these are links.

All in all, whilst these patterns are good to have it's important to make sure they fit the context of the information and functionality you are trying to present, and sometimes they need some tweaking.

Mark

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Jon Gunderson
Sent: Thursday 11 May 2023 15:33
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] [EXTERNAL] Carousel with multiple items - recommended keyboard operation when activating Next-button

There is design guidance and two carousel examples in the W3C ARIA Authoring Practices that should be helpful:
https://www.w3.org/WAI/ARIA/apg/patterns/carousel/

If not it would be great to get feedback on what questions you have that the practices do not address.

Jon


On Wed, May 10, 2023 at 4:27 AM Mark Magennis < <EMAIL REMOVED> >
wrote:

> Very good question. There are pros and cos of each approach. I suspect
> you've already considered all of these but are still wondering if
> anyone has any new insights. I don't know if you'll find any new
> insights here but here are my thoughts.
>
> If focus remains on the button, this supports sighted keyboard users
> who want to view multiple sets of cards without having to interact
> with any of them. Bang bang bang you can skip quickly through them
> looking for something of interest. When the user sees a card they want
> to interact with they can easily tab or reverse tab to it. If focus
> was moved to the first card in the new group each time, they would
> continually have to tab back to the Next button to go to the next
> group. Depending on how many groups they want to view and how much
> tabbing this would entail it may be a minor annoyance or a major
> annoyance, although I doubt that it would make the carousel confusing
> or particularly difficult to use. Do you have any data on how many
> groups users tend to view? My company uses carousels of this type and
> we recently generated some stats on how many times users use the Next
> button. I can't tell you the results because they are commercial info
> but I can say that some users do view a surprisingly large number of
> groups with one going through over 60! It will depend on the nature of
> the task of course but it might be something you might take into
> account in your design choices if you have that data, or if you have specific use cases you are prioritising.
>
> Screen reader users can't view the cards without actually going
> through them of course, so each time they go to the Next group they
> will always have to navigate through the cards. Then after reading
> them, to go to the next group they would have to navigate back to the
> Next button. How much work this is depends on where the Next button
> is. I expect it will be either before or after the group or there will
> be two Next buttons, one before and one after. When considering this
> aspect of the design bear in mind that there will also need to be a
> corresponding Previous button or buttons. The number and positioning
> of these buttons will affect how coherent the control is - how easy it
> is to create a clear mental model which you already know is vital. But
> it will also affect how much work the user has to do to reach the
> buttons. But if you have one Next button after the group and focus
> remains on it and the reads through the cards backwards by reverse
> tabbing or reverse arrowing then when they get to the start, they will
> have to go back through them or past them to reach the next button.
> Some users may work out very efficient ways of doing this over time using the list, button, link, or heading navigation, but many won't.
>
> If focus is moved to the first of the new group of cards then this
> would appear to me to be probably quite coherent for a screen reader
> user, not particularly onerous for a sighted keyboard user, and I
> would probably go for it if. A screen reader user asks for "Next group
> please" and they are at the start of the next group. After reading
> through the group they find the Next button again. Seems
> straightforward. For screen reader users with no vision, the fact that
> the new group has visually replaced the previous group is probably
> immaterial. They know that to jump between groups they use the Next and Previous buttons and it's probably all they need to know.
> I say "probably" because although this supposition is based on my
> experiences working and user testing with screen reader users, I have
> never user tested a carousel and you can never be sure how people are
> going to make sense of it (or not make sense of it) until you actually
> get a few of them to use it. Would it be possible for you to build a
> couple of mockups and get some feedback from real users?
>
> Hope these thoughts are of some use.
>
> Mark
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> Sonja Weckenmann
> Sent: Tuesday 9 May 2023 15:20
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: [EXTERNAL] [WebAIM] Carousel with multiple items -
> recommended keyboard operation when activating Next-button
>
> Hi,
>
> What would you recommend in terms of keyboard operation for a carousel
> that shows several items in the displayed area (e.g., 6 cards are
> visible): Assuming that when activating the "Next" button, 3 new cards
> are displayed, should the focus remain on the Next-button or should
> the focus be set to the first new card in the visible area (that is
> then the fourth card)?
>
> Starting point is semantic markup and labelling according to the
> Authoring Practice Guide to help users create a mental model of the widget.
>
>
> Thanks a lot for your thoughts.
> Best,
> Sonja
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >