E-mail List Archives
Thread: Carousel next and previous buttons
Number of posts in this thread: 8 (In chronological order)
From: escetic@gmail.com
Date: Tue, Dec 19 2017 1:47PM
Subject: Carousel next and previous buttons
No previous message | Next message →
Hi All,
Using any example of an paused accessible carousel, when a screen reader user presses enter on a previous or next button, should:
1) Should focus be placed within the content on the previous or next slide and should this be announced.
2) Should nothing announce and the onus be on the user to navigate into the slide content themselves.
3) Is either 1) or 2) acceptable?
Let's us https://wet-boew.github.io/v4.0-ci/demos/tabs/tabs-carousel-en.html as an example of accessible sliders.
My requirements to devs have thus far been that on pressing a previous or next button focus should automatically go to the slide content which should announce preferably its heading, first, followed by slide (e.g. 2 of 3), followed by content, etc.
What does everyone think?
Thank you in advance!
Rob C
From: Birkir R. Gunnarsson
Date: Tue, Dec 19 2017 5:44PM
Subject: Re: Carousel next and previous buttons
← Previous message | Next message →
That requirement is fine.
Another (in some ways easier) implementation is to have an live region
with the page title and/or position, e.g.
<div aria-live="polite" aria-atomic="true">
Slide title (x of y)
</div>
When user presses either button the slide title gets inserted into this div.
If this is part of a slide show with a known number of slides you can
do the second part also.
The aXe tool uses this approach when you navigate through groups of issues.
There is a live region that says "issue 1 of 3" and if you press the
next button the focus stays on it and the live region is updated to "2
of 3".
If you implement the widget with tabs and the user presses the next or
previous buttons, the focus should land on the tab control for the
active tab.
On 12/19/17, = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:
>
>
> Hi All,
>
> Using any example of an paused accessible carousel, when a screen reader
> user presses enter on a previous or next button, should:
>
> 1) Should focus be placed within the content on the previous or next slide
> and should this be announced.
>
> 2) Should nothing announce and the onus be on the user to navigate into the
> slide content themselves.
>
> 3) Is either 1) or 2) acceptable?
>
> Let's us https://wet-boew.github.io/v4.0-ci/demos/tabs/tabs-carousel-en.html
> as an example of accessible sliders.
>
> My requirements to devs have thus far been that on pressing a previous or
> next button focus should automatically go to the slide content which should
> announce preferably its heading, first, followed by slide (e.g. 2 of 3),
> followed by content, etc.
>
> What does everyone think?
>
> Thank you in advance!
>
> Rob C
> > > > >
--
Work hard. Have fun. Make history.
From: Lovely, Brian
Date: Wed, Dec 20 2017 6:50AM
Subject: Re: Carousel next and previous buttons
← Previous message | Next message →
I tend toward an "inform and empower" policy when it comes to coding with screen readers in mind. I don't suppose any of us think that a screen reader user wants an entire page read out; that's just too much information to absorb, and the user doesn't have the ability to decide what gets read out and when. While this is an extreme example, I think it can inform our decisions on a smaller scale.
I wouldn't read anything automatically, nor would I recommend shifting focus from the slide controls. A carousel, for better or worse, is a common feature that users recognize. A screen reader user who encounters a "previous" or "previous slide" button is likely to examine the surrounding elements and will then discover that they have encountered a carousel. It's the user's decision to consume the slide contents or not. As to shifting focus off the button when it is activated, what if a user wants to advance the carousel by more than one slide? Imagine how irritating it would be to activate the "next" button, have to navigate back to it, activate it again, and so on.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Tuesday, December 19, 2017 3:48 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Carousel next and previous buttons
Hi All,
Using any example of an paused accessible carousel, when a screen reader user presses enter on a previous or next button, should:
1) Should focus be placed within the content on the previous or next slide and should this be announced.
2) Should nothing announce and the onus be on the user to navigate into the slide content themselves.
3) Is either 1) or 2) acceptable?
Let's us https://wet-boew.github.io/v4.0-ci/demos/tabs/tabs-carousel-en.html as an example of accessible sliders.
My requirements to devs have thus far been that on pressing a previous or next button focus should automatically go to the slide content which should announce preferably its heading, first, followed by slide (e.g. 2 of 3), followed by content, etc.
What does everyone think?
Thank you in advance!
Rob C
The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
From: Birkir R. Gunnarsson
Date: Wed, Dec 20 2017 7:27AM
Subject: Re: Carousel next and previous buttons
← Previous message | Next message →
Good thinking there.
Another thing I forgot to mention is that you need to make sure a
screen reader user knows this is a carousel.
So use the region role and an aria-label around the slide content,
something like
<div role="region" aria-label="carousel">
<h2>slide title</h2>
content
</div>
You can put the control button inside or outside the ara.
Also makesure slide titles start with headings for easy navigation.
Then I would go with the live region I described earlier so the sreen
reader user gets a feedback that pressing the button changed the
content.
On 12/20/17, Lovely, Brian via WebAIM-Forum
< = EMAIL ADDRESS REMOVED = > wrote:
> I tend toward an "inform and empower" policy when it comes to coding with
> screen readers in mind. I don't suppose any of us think that a screen reader
> user wants an entire page read out; that's just too much information to
> absorb, and the user doesn't have the ability to decide what gets read out
> and when. While this is an extreme example, I think it can inform our
> decisions on a smaller scale.
>
> I wouldn't read anything automatically, nor would I recommend shifting focus
> from the slide controls. A carousel, for better or worse, is a common
> feature that users recognize. A screen reader user who encounters a
> "previous" or "previous slide" button is likely to examine the surrounding
> elements and will then discover that they have encountered a carousel. It's
> the user's decision to consume the slide contents or not. As to shifting
> focus off the button when it is activated, what if a user wants to advance
> the carousel by more than one slide? Imagine how irritating it would be to
> activate the "next" button, have to navigate back to it, activate it again,
> and so on.
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of = EMAIL ADDRESS REMOVED =
> Sent: Tuesday, December 19, 2017 3:48 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: [WebAIM] Carousel next and previous buttons
>
>
>
> Hi All,
>
> Using any example of an paused accessible carousel, when a screen reader
> user presses enter on a previous or next button, should:
>
> 1) Should focus be placed within the content on the previous or next slide
> and should this be announced.
>
> 2) Should nothing announce and the onus be on the user to navigate into the
> slide content themselves.
>
> 3) Is either 1) or 2) acceptable?
>
> Let's us https://wet-boew.github.io/v4.0-ci/demos/tabs/tabs-carousel-en.html
> as an example of accessible sliders.
>
> My requirements to devs have thus far been that on pressing a previous or
> next button focus should automatically go to the slide content which should
> announce preferably its heading, first, followed by slide (e.g. 2 of 3),
> followed by content, etc.
>
> What does everyone think?
>
> Thank you in advance!
>
> Rob C
> > > http://webaim.org/discussion/archives
> > >
> The information contained in this e-mail is confidential and/or proprietary
> to Capital One and/or its affiliates and may only be used solely in
> performance of work or services for Capital One. The information transmitted
> herewith is intended only for use by the individual or entity to which it is
> addressed. If the reader of this message is not the intended recipient, you
> are hereby notified that any review, retransmission, dissemination,
> distribution, copying or other use of, or taking of any action in reliance
> upon this information is strictly prohibited. If you have received this
> communication in error, please contact the sender and delete the material
> from your computer.
> > > > >
--
Work hard. Have fun. Make history.
From: Tim Harshbarger
Date: Wed, Dec 20 2017 10:03AM
Subject: Re: Carousel next and previous buttons
← Previous message | Next message →
I wonder if this might be an example of the difference between making user interfaces accessible and designing accessible user interfaces.
Making the user interface accessible basically involves ensuring someone can click the buttons and move to the next or previous slide. If they want to know if they are on the right slide, they can use a screen reader to explore the interface--that is if they use a screen reader.
Designing an accessible user interface means understanding how people might use the interface to perform tasks. For example, adding a live region to read some or all of the slide after the button is pressed to advance the slide, facilitates the task of letting a screen reader user know if they want to spend more time exploring that slide or if they need to go to the next slide to find what they might be looking for.
One approach just looks at the UI and makes it accessible. The other approach is to look at how people will utilize that UI and figure out how to facilitate those tasks in an accessible manner.
Just a thought.
Thanks,
Tim
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Wednesday, December 20, 2017 8:27 AM
To: Lovely, Brian < = EMAIL ADDRESS REMOVED = >; WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Carousel next and previous buttons
Good thinking there.
Another thing I forgot to mention is that you need to make sure a
screen reader user knows this is a carousel.
So use the region role and an aria-label around the slide content,
something like
<div role="region" aria-label="carousel">
<h2>slide title</h2>
content
</div>
You can put the control button inside or outside the ara.
Also makesure slide titles start with headings for easy navigation.
Then I would go with the live region I described earlier so the sreen
reader user gets a feedback that pressing the button changed the
content.
On 12/20/17, Lovely, Brian via WebAIM-Forum
< = EMAIL ADDRESS REMOVED = > wrote:
> I tend toward an "inform and empower" policy when it comes to coding with
> screen readers in mind. I don't suppose any of us think that a screen reader
> user wants an entire page read out; that's just too much information to
> absorb, and the user doesn't have the ability to decide what gets read out
> and when. While this is an extreme example, I think it can inform our
> decisions on a smaller scale.
>
> I wouldn't read anything automatically, nor would I recommend shifting focus
> from the slide controls. A carousel, for better or worse, is a common
> feature that users recognize. A screen reader user who encounters a
> "previous" or "previous slide" button is likely to examine the surrounding
> elements and will then discover that they have encountered a carousel. It's
> the user's decision to consume the slide contents or not. As to shifting
> focus off the button when it is activated, what if a user wants to advance
> the carousel by more than one slide? Imagine how irritating it would be to
> activate the "next" button, have to navigate back to it, activate it again,
> and so on.
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of = EMAIL ADDRESS REMOVED =
> Sent: Tuesday, December 19, 2017 3:48 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: [WebAIM] Carousel next and previous buttons
>
>
>
> Hi All,
>
> Using any example of an paused accessible carousel, when a screen reader
> user presses enter on a previous or next button, should:
>
> 1) Should focus be placed within the content on the previous or next slide
> and should this be announced.
>
> 2) Should nothing announce and the onus be on the user to navigate into the
> slide content themselves.
>
> 3) Is either 1) or 2) acceptable?
>
> Let's us https://wet-boew.github.io/v4.0-ci/demos/tabs/tabs-carousel-en.html
> as an example of accessible sliders.
>
> My requirements to devs have thus far been that on pressing a previous or
> next button focus should automatically go to the slide content which should
> announce preferably its heading, first, followed by slide (e.g. 2 of 3),
> followed by content, etc.
>
> What does everyone think?
>
> Thank you in advance!
>
> Rob C
> > > http://webaim.org/discussion/archives
> > >
> The information contained in this e-mail is confidential and/or proprietary
> to Capital One and/or its affiliates and may only be used solely in
> performance of work or services for Capital One. The information transmitted
> herewith is intended only for use by the individual or entity to which it is
> addressed. If the reader of this message is not the intended recipient, you
> are hereby notified that any review, retransmission, dissemination,
> distribution, copying or other use of, or taking of any action in reliance
> upon this information is strictly prohibited. If you have received this
> communication in error, please contact the sender and delete the material
> from your computer.
> > > > >
--
Work hard. Have fun. Make history.
From: escetic@gmail.com
Date: Thu, Dec 21 2017 12:12PM
Subject: Re: Carousel next and previous buttons
← Previous message | Next message →
Hi Brian,
You raise a good point but there are some considerations giving me pause.
First, when a user clicks a button I assume they want something to happen, rather than nothing, that we all want some kind of immediate feedback that activating the button has worked as intended. Secondly, I would would want to hear which slide I'm on, at least, and presumably also the heading or title of the slide (otherwise I'd have to memorize which slide is which). I also think on first encountering the carousel, assuming I don't want to skip it altogether, I may want to advance through all slides first, listening to their content, before I get to a point where I know I want to advance from the current slide to slide 6.
If prev/next buttons are also supplemented with arrow key functionality then these could work as an easy method to get from the current slide to slide 6, advancing the slides but bypassing all content but slide number and heading? Meanwhile, prev/next buttons could assume the user wants to hear each slide content?
What do you think?
Rob C
> On Dec 20, 2017, at 8:50 AM, Lovely, Brian via WebAIM-Forum < = EMAIL ADDRESS REMOVED = > wrote:
>
> I tend toward an "inform and empower" policy when it comes to coding with screen readers in mind. I don't suppose any of us think that a screen reader user wants an entire page read out; that's just too much information to absorb, and the user doesn't have the ability to decide what gets read out and when. While this is an extreme example, I think it can inform our decisions on a smaller scale.
>
> I wouldn't read anything automatically, nor would I recommend shifting focus from the slide controls. A carousel, for better or worse, is a common feature that users recognize. A screen reader user who encounters a "previous" or "previous slide" button is likely to examine the surrounding elements and will then discover that they have encountered a carousel. It's the user's decision to consume the slide contents or not. As to shifting focus off the button when it is activated, what if a user wants to advance the carousel by more than one slide? Imagine how irritating it would be to activate the "next" button, have to navigate back to it, activate it again, and so on.
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of = EMAIL ADDRESS REMOVED =
> Sent: Tuesday, December 19, 2017 3:48 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: [WebAIM] Carousel next and previous buttons
>
>
>
> Hi All,
>
> Using any example of an paused accessible carousel, when a screen reader user presses enter on a previous or next button, should:
>
> 1) Should focus be placed within the content on the previous or next slide and should this be announced.
>
> 2) Should nothing announce and the onus be on the user to navigate into the slide content themselves.
>
> 3) Is either 1) or 2) acceptable?
>
> Let's us https://wet-boew.github.io/v4.0-ci/demos/tabs/tabs-carousel-en.html as an example of accessible sliders.
>
> My requirements to devs have thus far been that on pressing a previous or next button focus should automatically go to the slide content which should announce preferably its heading, first, followed by slide (e.g. 2 of 3), followed by content, etc.
>
> What does everyone think?
>
> Thank you in advance!
>
> Rob C
> > > > >
> The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
> > > >
From: escetic@gmail.com
Date: Thu, Dec 21 2017 12:16PM
Subject: Re: Carousel next and previous buttons
← Previous message | Next message →
Thank you for this Birkir, this is helpful. And yeah, my requirements state that as soon as a carousel receives focus the screen reader should announce the presence of the carousel and any other helpful contextual information or additional instructions for using it.
> On Dec 20, 2017, at 12:03 PM, Tim Harshbarger < = EMAIL ADDRESS REMOVED = > wrote:
>
> I wonder if this might be an example of the difference between making user interfaces accessible and designing accessible user interfaces.
>
> Making the user interface accessible basically involves ensuring someone can click the buttons and move to the next or previous slide. If they want to know if they are on the right slide, they can use a screen reader to explore the interface--that is if they use a screen reader.
>
> Designing an accessible user interface means understanding how people might use the interface to perform tasks. For example, adding a live region to read some or all of the slide after the button is pressed to advance the slide, facilitates the task of letting a screen reader user know if they want to spend more time exploring that slide or if they need to go to the next slide to find what they might be looking for.
>
> One approach just looks at the UI and makes it accessible. The other approach is to look at how people will utilize that UI and figure out how to facilitate those tasks in an accessible manner.
>
> Just a thought.
>
> Thanks,
> Tim
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
> Sent: Wednesday, December 20, 2017 8:27 AM
> To: Lovely, Brian < = EMAIL ADDRESS REMOVED = >; WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Carousel next and previous buttons
>
> Good thinking there.
> Another thing I forgot to mention is that you need to make sure a
> screen reader user knows this is a carousel.
> So use the region role and an aria-label around the slide content,
> something like
> <div role="region" aria-label="carousel">
> <h2>slide title</h2>
> content
> </div>
> You can put the control button inside or outside the ara.
> Also makesure slide titles start with headings for easy navigation.
> Then I would go with the live region I described earlier so the sreen
> reader user gets a feedback that pressing the button changed the
> content.
>
>
> On 12/20/17, Lovely, Brian via WebAIM-Forum
> < = EMAIL ADDRESS REMOVED = > wrote:
>> I tend toward an "inform and empower" policy when it comes to coding with
>> screen readers in mind. I don't suppose any of us think that a screen reader
>> user wants an entire page read out; that's just too much information to
>> absorb, and the user doesn't have the ability to decide what gets read out
>> and when. While this is an extreme example, I think it can inform our
>> decisions on a smaller scale.
>>
>> I wouldn't read anything automatically, nor would I recommend shifting focus
>> from the slide controls. A carousel, for better or worse, is a common
>> feature that users recognize. A screen reader user who encounters a
>> "previous" or "previous slide" button is likely to examine the surrounding
>> elements and will then discover that they have encountered a carousel. It's
>> the user's decision to consume the slide contents or not. As to shifting
>> focus off the button when it is activated, what if a user wants to advance
>> the carousel by more than one slide? Imagine how irritating it would be to
>> activate the "next" button, have to navigate back to it, activate it again,
>> and so on.
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>> Of = EMAIL ADDRESS REMOVED =
>> Sent: Tuesday, December 19, 2017 3:48 PM
>> To: = EMAIL ADDRESS REMOVED =
>> Subject: [WebAIM] Carousel next and previous buttons
>>
>>
>>
>> Hi All,
>>
>> Using any example of an paused accessible carousel, when a screen reader
>> user presses enter on a previous or next button, should:
>>
>> 1) Should focus be placed within the content on the previous or next slide
>> and should this be announced.
>>
>> 2) Should nothing announce and the onus be on the user to navigate into the
>> slide content themselves.
>>
>> 3) Is either 1) or 2) acceptable?
>>
>> Let's us https://wet-boew.github.io/v4.0-ci/demos/tabs/tabs-carousel-en.html
>> as an example of accessible sliders.
>>
>> My requirements to devs have thus far been that on pressing a previous or
>> next button focus should automatically go to the slide content which should
>> announce preferably its heading, first, followed by slide (e.g. 2 of 3),
>> followed by content, etc.
>>
>> What does everyone think?
>>
>> Thank you in advance!
>>
>> Rob C
>> >> >> http://webaim.org/discussion/archives
>> >> >>
>> The information contained in this e-mail is confidential and/or proprietary
>> to Capital One and/or its affiliates and may only be used solely in
>> performance of work or services for Capital One. The information transmitted
>> herewith is intended only for use by the individual or entity to which it is
>> addressed. If the reader of this message is not the intended recipient, you
>> are hereby notified that any review, retransmission, dissemination,
>> distribution, copying or other use of, or taking of any action in reliance
>> upon this information is strictly prohibited. If you have received this
>> communication in error, please contact the sender and delete the material
>> from your computer.
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > > > > > >
From: Lovely, Brian
Date: Thu, Dec 21 2017 12:19PM
Subject: Re: Carousel next and previous buttons
← Previous message | No next message
Ultimately, I would prefer to rely on user testing. I see your point(s), but just don't know what the majority of users would prefer. ...and to your point, if there are "jump buttons" (typically small buttons each of which jump the carousel to one slide), then there is a mechanism for going to a particular slide without having to rely on prev/next.
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, December 21, 2017 2:13 PM
To: Lovely, Brian < = EMAIL ADDRESS REMOVED = >; WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Carousel next and previous buttons
Hi Brian,
You raise a good point but there are some considerations giving me pause.
First, when a user clicks a button I assume they want something to happen, rather than nothing, that we all want some kind of immediate feedback that activating the button has worked as intended. Secondly, I would would want to hear which slide I'm on, at least, and presumably also the heading or title of the slide (otherwise I'd have to memorize which slide is which). I also think on first encountering the carousel, assuming I don't want to skip it altogether, I may want to advance through all slides first, listening to their content, before I get to a point where I know I want to advance from the current slide to slide 6.
If prev/next buttons are also supplemented with arrow key functionality then these could work as an easy method to get from the current slide to slide 6, advancing the slides but bypassing all content but slide number and heading? Meanwhile, prev/next buttons could assume the user wants to hear each slide content?
What do you think?
Rob C
The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.