E-mail List Archives
Thread: Carousel not accessible
Number of posts in this thread: 9 (In chronological order)
From: Gurpreet kaur
Date: Mon, Jan 15 2018 8:35AM
Subject: Carousel not accessible
No previous message | Next message →
Hi accessibility experts,
We have a carousel with auto play functionality on website. As far as we know that the behavior for the screen reader user is that " when carousel comes in focus, space should be used to play/ pause the carousel". But in our carousel, space alone is not pausing or playing the carousel. We have to use control key along with space to perform the function. This is an issue with NVDA and JAWS both.
Without screen reader, we are able to use space key alone.
So my question is, Is this behavior acceptable according to WCAG requirements? We need some direction.
Thanks
Gurpreet
From: JP Jamous
Date: Mon, Jan 15 2018 9:15AM
Subject: Re: Carousel not accessible
← Previous message | Next message →
Gurpreet,
It sounds to me as if you guys are using AccessKey and coding around it.
Before answering your question, the proper way for a carousel would be to have a pause and play button. You cannot expect your users to know that a space key would stop the carousel. However, if you provide a pause button then it is clear to keyboard and mouse users.
By expecting your users to anticipate what key to press, you are not in conformance of WCAG. The user is not told how to operate this carousel.
From: escetic
Date: Mon, Jan 15 2018 11:24AM
Subject: Re: Carousel not accessible
← Previous message | Next message →
Hi All,
The question here is whether it's normal for screen reader users to need to use the control key to pause/stop/play a carousel. I don't think it is.
Spacebar is almost a universal pattern or interaction for pausing/playing media or timed sequences, by my understanding. Does NVDA and JAWS have something going on which prevents spacebar alone from being used to pause/stop/play? Do JAWS and NVDA require developers to code it in a way which requires a modifier key such as control plus spacebar?
Rob C
> On Jan 15, 2018, at 10:35 AM, Gurpreet kaur < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hi accessibility experts,
>
> We have a carousel with auto play functionality on website. As far as we know that the behavior for the screen reader user is that " when carousel comes in focus, space should be used to play/ pause the carousel". But in our carousel, space alone is not pausing or playing the carousel. We have to use control key along with space to perform the function. This is an issue with NVDA and JAWS both.
>
> Without screen reader, we are able to use space key alone.
>
> So my question is, Is this behavior acceptable according to WCAG requirements? We need some direction.
>
> Thanks
> Gurpreet
>
> > > >
From: Jonathan Avila
Date: Mon, Jan 15 2018 1:09PM
Subject: Re: Carousel not accessible
← Previous message | Next message →
From the description it is not clear if space works anywhere on the page or requires a certain control to be focused. Control plus space is likely required because the screen reader is in browse mode and control space is not captured. Shortcuts like this can be problematic because there is no clear method for visual affordance (when no control exists ) or users of screen reader to know the keystroke. Space also provides another function on pages - to scroll except when certain controls are focused.
Jonathan
Sent from my iPhone
> On Jan 15, 2018, at 1:24 PM, " = EMAIL ADDRESS REMOVED = " < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hi All,
>
> The question here is whether it's normal for screen reader users to need to use the control key to pause/stop/play a carousel. I don't think it is.
>
> Spacebar is almost a universal pattern or interaction for pausing/playing media or timed sequences, by my understanding. Does NVDA and JAWS have something going on which prevents spacebar alone from being used to pause/stop/play? Do JAWS and NVDA require developers to code it in a way which requires a modifier key such as control plus spacebar?
>
>
> Rob C
>
>
>
>> On Jan 15, 2018, at 10:35 AM, Gurpreet kaur < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> Hi accessibility experts,
>>
>> We have a carousel with auto play functionality on website. As far as we know that the behavior for the screen reader user is that " when carousel comes in focus, space should be used to play/ pause the carousel". But in our carousel, space alone is not pausing or playing the carousel. We have to use control key along with space to perform the function. This is an issue with NVDA and JAWS both.
>>
>> Without screen reader, we are able to use space key alone.
>>
>> So my question is, Is this behavior acceptable according to WCAG requirements? We need some direction.
>>
>> Thanks
>> Gurpreet
>>
>> >> >> >> > > > >
From: Birkir R. Gunnarsson
Date: Mon, Jan 15 2018 1:20PM
Subject: Re: Carousel not accessible
← Previous message | Next message →
Another thing that could be happening here is that you code the
element to respond to keyboard events (onkeyup or onkeypress). But
screen readers, in default browse mode, fire the onclick event when
enter or space bar is pressed.
The solution could be as simple as adding an onclick event to whatever
the control is that you are using.
Since the onclick event is synthetic, make sure there is no visual
overlay that captures the onclick event before it gets to the element.
All that being said, having a simple play/pause button (coded with the
<button> element) is the most straight-forward solution to this, I
think.
Remember, auto playing content does not only bother screen reader
users, the carousel must be stoppable for all users. Having a button
would achieve that.
On 1/15/18, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
> From the description it is not clear if space works anywhere on the page or
> requires a certain control to be focused. Control plus space is likely
> required because the screen reader is in browse mode and control space is
> not captured. Shortcuts like this can be problematic because there is no
> clear method for visual affordance (when no control exists ) or users of
> screen reader to know the keystroke. Space also provides another function
> on pages - to scroll except when certain controls are focused.
>
> Jonathan
>
> Sent from my iPhone
>
>> On Jan 15, 2018, at 1:24 PM, " = EMAIL ADDRESS REMOVED = " < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>> Hi All,
>>
>> The question here is whether it's normal for screen reader users to need
>> to use the control key to pause/stop/play a carousel. I don't think it
>> is.
>>
>> Spacebar is almost a universal pattern or interaction for pausing/playing
>> media or timed sequences, by my understanding. Does NVDA and JAWS have
>> something going on which prevents spacebar alone from being used to
>> pause/stop/play? Do JAWS and NVDA require developers to code it in a way
>> which requires a modifier key such as control plus spacebar?
>>
>>
>> Rob C
>>
>>
>>
>>> On Jan 15, 2018, at 10:35 AM, Gurpreet kaur < = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>>
>>> Hi accessibility experts,
>>>
>>> We have a carousel with auto play functionality on website. As far as we
>>> know that the behavior for the screen reader user is that " when carousel
>>> comes in focus, space should be used to play/ pause the carousel". But in
>>> our carousel, space alone is not pausing or playing the carousel. We have
>>> to use control key along with space to perform the function. This is an
>>> issue with NVDA and JAWS both.
>>>
>>> Without screen reader, we are able to use space key alone.
>>>
>>> So my question is, Is this behavior acceptable according to WCAG
>>> requirements? We need some direction.
>>>
>>> Thanks
>>> Gurpreet
>>>
>>> >>> >>> >>> >> >> >> >> > > > > >
--
Work hard. Have fun. Make history.
From: escetic
Date: Mon, Jan 15 2018 2:19PM
Subject: Re: Carousel not accessible
← Previous message | Next message →
Actually, what's happening is our carousel works fine with keyboard only, without NVDA/JAWS. Space pauses the carousel, arrow keys work, etc.
It does NOT work with NVDA and JAWS using these keyboard combinations.
But we found that NVDA/JAWS must use these same keys in combination with Ctrl (e.g. Ctrl+Space, Ctrl+arrow) in order to work the same.
Our devs haven't done anything to listen for ctrl, specifically. The code only listens for onkeypress of arrow and spacebar. We think NVDA may only trigger with onclick but not onkeypress.
We're trying to figure out if needing to use ctrl-spacebar is normal and expected for NVDA/JAWS users in situations where an app is listening for the spacebar onkeypress. My understanding is that the same interactions should be possible for both keyboard only and screen reader users. If a carousel can be paused with spacebar, it should also be pausable with spacebar for NVDA and JAWS users, right?
From what I'm reading here, I suspect ctrl+key is not normal, I don't see any discussion anywhere about this and I think people are actually confused by the question.
We agree that a button would definitely be better but unfortunately that's not feasible so we must make the carousel accessible as it is.
> On Jan 15, 2018, at 3:20 PM, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
>
> Another thing that could be happening here is that you code the
> element to respond to keyboard events (onkeyup or onkeypress). But
> screen readers, in default browse mode, fire the onclick event when
> enter or space bar is pressed.
> The solution could be as simple as adding an onclick event to whatever
> the control is that you are using.
> Since the onclick event is synthetic, make sure there is no visual
> overlay that captures the onclick event before it gets to the element.
> All that being said, having a simple play/pause button (coded with the
> <button> element) is the most straight-forward solution to this, I
> think.
> Remember, auto playing content does not only bother screen reader
> users, the carousel must be stoppable for all users. Having a button
> would achieve that.
>
>
>
>> On 1/15/18, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>> From the description it is not clear if space works anywhere on the page or
>> requires a certain control to be focused. Control plus space is likely
>> required because the screen reader is in browse mode and control space is
>> not captured. Shortcuts like this can be problematic because there is no
>> clear method for visual affordance (when no control exists ) or users of
>> screen reader to know the keystroke. Space also provides another function
>> on pages - to scroll except when certain controls are focused.
>>
>> Jonathan
>>
>> Sent from my iPhone
>>
>>> On Jan 15, 2018, at 1:24 PM, " = EMAIL ADDRESS REMOVED = " < = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>>
>>> Hi All,
>>>
>>> The question here is whether it's normal for screen reader users to need
>>> to use the control key to pause/stop/play a carousel. I don't think it
>>> is.
>>>
>>> Spacebar is almost a universal pattern or interaction for pausing/playing
>>> media or timed sequences, by my understanding. Does NVDA and JAWS have
>>> something going on which prevents spacebar alone from being used to
>>> pause/stop/play? Do JAWS and NVDA require developers to code it in a way
>>> which requires a modifier key such as control plus spacebar?
>>>
>>>
>>> Rob C
>>>
>>>
>>>
>>>> On Jan 15, 2018, at 10:35 AM, Gurpreet kaur < = EMAIL ADDRESS REMOVED = >
>>>> wrote:
>>>>
>>>> Hi accessibility experts,
>>>>
>>>> We have a carousel with auto play functionality on website. As far as we
>>>> know that the behavior for the screen reader user is that " when carousel
>>>> comes in focus, space should be used to play/ pause the carousel". But in
>>>> our carousel, space alone is not pausing or playing the carousel. We have
>>>> to use control key along with space to perform the function. This is an
>>>> issue with NVDA and JAWS both.
>>>>
>>>> Without screen reader, we are able to use space key alone.
>>>>
>>>> So my question is, Is this behavior acceptable according to WCAG
>>>> requirements? We need some direction.
>>>>
>>>> Thanks
>>>> Gurpreet
>>>>
>>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > >
From: Jonathan Avila
Date: Mon, Jan 15 2018 2:27PM
Subject: Re: Carousel not accessible
← Previous message | Next message →
Reusing the spacebar which scrolls the screen is problematic. Users would not expect to press control+space. Again space and enter are not passed through to web sites in browser mode -- but control+space is. In forms mode the screen reader will pass through enter and space.
Jonathan
Jonathan Avila
Chief Accessibility Officer
Level Access, inc. (formerly SSB BART Group, inc.)
= EMAIL ADDRESS REMOVED =
703.637.8957 (Office)
Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
Looking to boost your accessibility knowledge? Check out our free webinars!
The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.
From: Bim Egan
Date: Mon, Jan 15 2018 3:54PM
Subject: Re: Carousel not accessible
← Previous message | Next message →
Hi Rob and Gurpreet,
I hope the following will help to clear the water a bit:
Jaws and NVDA should not be pausing the carousel using the key combination
Ctrl + space. As Jonathan says, this is a key combination occasionally used
to open a complex link to reveal further options: called a pass key
combination. The revealed content might be a sub-menu, for instance.
And as Birkir said, the space bar pressed on its own will fire an onclick
event, in both JAWS and NVDA.
So there's something else going on. Things to check:
A) Is the carousel movement control an <a> without an href? This could cause
the problem. It won't be very obvious if tabindex has been used to put the
control in the tab order.
B) What element is used to create the movement controller? It should be a
button, or be given the role of button.
C) Is the control the *only* markup in focus at the point when the user
should be able to stop the movement? Or, as Birkir asked, is there an
overlay that is blocking the screen reader from coming into contact with the
control?
HTH,
Bim
From: David Farough
Date: Tue, Jan 16 2018 7:58AM
Subject: Re: Carousel not accessible
← Previous message | No next message
Good morning:
I think that your Carousel Will be confusing to most screen reader
users. The Control + space keystroke is not one that we would normally
try to use. If this content is rotating by default when the page loads,
it will in all likelihood be very difficult to navigate to. And then
given that the content changes regularly the user will have a hard time
making sense of the content when it is changing constantly.
I think you need to gain a better understanding of the various modes
and interactive behaviours that screen reader users use and rely on.
Please read the following article Which provides a very good explanation
of the browse and forms modes used by screen reader applications.
https://tink.uk/understanding-screen-reader-interaction-modes/
Thanks
David Farough
(819) 420-8418
>>> < = EMAIL ADDRESS REMOVED = > 04:19 PM Monday, January 15, 2018 >>>
Actually, what's happening is our carousel works fine with keyboard
only, without NVDA/JAWS. Space pauses the carousel, arrow keys work,
etc.
It does NOT work with NVDA and JAWS using these keyboard combinations.
But we found that NVDA/JAWS must use these same keys in combination
with Ctrl (e.g. Ctrl+Space, Ctrl+arrow) in order to work the same.
Our devs haven't done anything to listen for ctrl, specifically. The
code only listens for onkeypress of arrow and spacebar. We think NVDA
may only trigger with onclick but not onkeypress.
We're trying to figure out if needing to use ctrl-spacebar is normal
and expected for NVDA/JAWS users in situations where an app is listening
for the spacebar onkeypress. My understanding is that the same
interactions should be possible for both keyboard only and screen reader
users. If a carousel can be paused with spacebar, it should also be
pausable with spacebar for NVDA and JAWS users, right?
From what I'm reading here, I suspect ctrl+key is not normal, I
don't see any discussion anywhere about this and I think people are
actually confused by the question.
We agree that a button would definitely be better but unfortunately
that's not feasible so we must make the carousel accessible as it is.
> On Jan 15, 2018, at 3:20 PM, Birkir R. Gunnarsson
< = EMAIL ADDRESS REMOVED = > wrote:
>
> Another thing that could be happening here is that you code the
> element to respond to keyboard events (onkeyup or onkeypress). But
> screen readers, in default browse mode, fire the onclick event when
> enter or space bar is pressed.
> The solution could be as simple as adding an onclick event to
whatever
> the control is that you are using.
> Since the onclick event is synthetic, make sure there is no visual
> overlay that captures the onclick event before it gets to the
element.
> All that being said, having a simple play/pause button (coded with
the
> <button> element) is the most straight-forward solution to this, I
> think.
> Remember, auto playing content does not only bother screen reader
> users, the carousel must be stoppable for all users. Having a button
> would achieve that.
>
>
>
>> On 1/15/18, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>> From the description it is not clear if space works anywhere on the
page or
>> requires a certain control to be focused. Control plus space is
likely
>> required because the screen reader is in browse mode and control
space is
>> not captured. Shortcuts like this can be problematic because
there is no
>> clear method for visual affordance (when no control exists ) or
users of
>> screen reader to know the keystroke. Space also provides another
function
>> on pages - to scroll except when certain controls are focused.
>>
>> Jonathan
>>
>> Sent from my iPhone
>>
>>> On Jan 15, 2018, at 1:24 PM, " = EMAIL ADDRESS REMOVED = "
< = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>>
>>> Hi All,
>>>
>>> The question here is whether its normal for screen reader users to
need
>>> to use the control key to pause/stop/play a carousel. I don't
think it
>>> is.
>>>
>>> Spacebar is almost a universal pattern or interaction for
pausing/playing
>>> media or timed sequences, by my understanding. Does NVDA and JAWS
have
>>> something going on which prevents spacebar alone from being used
to
>>> pause/stop/play? Do JAWS and NVDA require developers to code it in
a way
>>> which requires a modifier key such as control plus spacebar?
>>>
>>>
>>> Rob C
>>>
>>>
>>>
>>>> On Jan 15, 2018, at 10:35 AM, Gurpreet kaur
< = EMAIL ADDRESS REMOVED = >
>>>> wrote:
>>>>
>>>> Hi accessibility experts,
>>>>
>>>> We have a carousel with auto play functionality on website. As far
as we
>>>> know that the behavior for the screen reader user is that " when
carousel
>>>> comes in focus, space should be used to play/ pause the
carousel". But in
>>>> our carousel, space alone is not pausing or playing the carousel.
We have
>>>> to use control key along with space to perform the function. This
is an
>>>> issue with NVDA and JAWS both.
>>>>
>>>> Without screen reader, we are able to use space key alone.
>>>>
>>>> So my question is, Is this behavior acceptable according to WCAG
>>>> requirements? We need some direction.
>>>>
>>>> Thanks
>>>> Gurpreet
>>>>
>>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > > Ce courriel est destiné exclusivement au destinataire mentionné en titre
et peut contenir de l'information privilégiée, confidentielle ou
soustraite à la communication aux termes des lois applicables. Toute
divulgation non autorisée, toute reproduction ou réacheminement est
interdit. Si vous n'êtes pas le destinataire de ce courriel, ou n'êtes
pas autorisé par le destinataire visé, ou encore, si vous l'avez reçu
par erreur, veuillez le mentionner immédiatement à l'expéditeur et
supprimer le courriel et les copies.
This e-mail message is intended for the named recipient(s) and may
contain information that is privileged, confidential and/or exempt from
disclosure under applicable law. Unauthorized disclosure, copying or
re-transmission is prohibited. If you are not a named recipient or not
authorized by the named recipient(s), or if you have received this
e-mail in error, then please notify the sender immediately and delete
the message and any copies.