WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Sonja Weckenmann
Date: May 14, 2023 10:53AM


Hi,

Thank you for your helpful thoughts. Personally, I would also leave
focus on the next button and yes, perhabs it might be helpful to
communicate the amount of new items via a live region.

I also think that the examples of the APG are still relevant, but one
has to think about meaningful labels for the set of items. Thanks also
for pointing out the output of aria-roledescription in JAWS.

Sorry I don't have a link to an example, I was discussing the topic with
an external colleague who was asked for a recommendation.

Sonja


Am 11.05.2023 um 21:28 schrieb Jon Gunderson:
> Mark,
>
> I think the ARIA example is still relevant, instead of a "slide" there is a
> group of 6 items, not clear what the items represent.
> In this case the region could have an accessible name with information on
> how many items are in the total set and which items are being shown at this
> time.
>
> If the items are part of a set, using ordered lists with aria-setsize,
> aria-posinset would be useful for screen readers to orient what items are
> being displayed and how many are in the total set.
>
> Is there a URL to an example?
>
> Jon
>
>
>
> On Thu, May 11, 2023 at 10:59 AM Mark Magennis < <EMAIL REMOVED> >
> wrote:
>
>> 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
>>> >>>
>> >> >> at http://webaim.org/discussion/archives
>> >> >> >> >> >>
> > > >