E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 10 (In chronological order)

From: Sonja Weckenmann
Date: Tue, May 09 2023 8:19AM
Subject: Carousel with multiple items - recommended keyboard operation when activating Next-button
No previous message | Next message →

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

From: Dean.Vasile
Date: Tue, May 09 2023 8:25AM
Subject: Re: Carousel with multiple items - recommended keyboard operation when activating Next-button
← Previous message | Next message →

If you could not see the screen
Would you be able to tell that they were six cards visible?
You need to test this with a screen reader to see how it behaves?
The previous and next slide buttons should be clearly indicated
There should be a play pause button if the slides continuously change.


Dino

617-799-1162

Dino's Canteen 1618
11 Eglin St,
Hanscom AFB
Bedford, MA

> On May 9, 2023, at 10:19 AM, Sonja Weckenmann < = EMAIL ADDRESS REMOVED = > wrote:
>
> 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
> > > >

From: glen walker
Date: Tue, May 09 2023 12:06PM
Subject: Re: Carousel with multiple items - recommended keyboard operation when activating Next-button
← Previous message | Next message →

If you're asking solely about where the keyboard focus should be after
selecting "next" (or "prev"), my general rule of thumb is to never force
the focus off what the user just clicked on. There are only a few
situations where I programmatically move the focus. One is if the element
that was just clicked on is no longer available. Perhaps you clicked on
"close" from a dialog so now the dialog is no longer available, then the
focus has to be moved somewhere. Or if you open a dialog, the focus should
be moved into the dialog.

But on a carousel (if you choose to use one), clicking on next should leave
the focus on next. As a keyboard user, I might want to scroll through all
the carousel items. If you keep moving my focus back to a slide, I have to
keep tabbing back to "next" in order to advance.

So if you leave the focus where it is, the next question might be, "how
does a screen reader user know that new content was added?". If the
carousel container is labelled properly and the user understands the
purpose of the carousel, then clicking "next" will already be understood
that new content will be added. The user might not know if totally new
content is added (6 new slides) or if some of the previous content was
removed but some of it is still there and some new content was added. This
is where UX testing comes into play. You could announce that 3 new slides
were added or you could say nothing. Let users try it out and decide which
one makes more sense to them.

From: Mark Magennis
Date: Wed, May 10 2023 3:26AM
Subject: Re: Carousel with multiple items - recommended keyboard operation when activating Next-button
← Previous message | Next message →

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

From: Jon Gunderson
Date: Thu, May 11 2023 8:32AM
Subject: Re: Carousel with multiple items - recommended keyboard operation when activating Next-button
← Previous message | Next message →

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 ADDRESS 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
>
>

From: Mark Magennis
Date: Thu, May 11 2023 9:21AM
Subject: Re: Carousel with multiple items - recommended keyboard operation when activating Next-button
← Previous message | Next message →

Thanks Jon, I'll take a look at that.

From: Mark Magennis
Date: Thu, May 11 2023 9:59AM
Subject: Re: Carousel with multiple items - recommended keyboard operation when activating Next-button
← Previous message | Next message →

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

From: Bryan Garaventa
Date: Thu, May 11 2023 10:32AM
Subject: Re: Carousel with multiple items - recommended keyboard operation when activating Next-button
← Previous message | Next message →

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

From: Jon Gunderson
Date: Thu, May 11 2023 1:28PM
Subject: Re: Carousel with multiple items - recommended keyboard operation when activating Next-button
← Previous message | Next message →

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 ADDRESS 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
>
>

From: Sonja Weckenmann
Date: Sun, May 14 2023 10:53AM
Subject: Re: Carousel with multiple items - recommended keyboard operation when activating Next-button
← Previous message | No next message

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 ADDRESS 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
>>
>>