E-mail List Archives
Thread: Detecting keyboard usage
Number of posts in this thread: 8 (In chronological order)
From: Alastair Campbell
Date: Tue, Sep 17 2013 6:10AM
Subject: Detecting keyboard usage
No previous message | Next message →
Hi everyone,
I've an odd issue with accessibalising a carousel. Yes, yes, I know we
shouldn't use them, that's not an option here.
It already has a visible pause button, alt text etc etc.
The issue is that I would like it to pause automatically when a keyboard
user is interacting with the page. (Again, I know that isn't ideal, but it
"has to" auto-play.)
That is straightforward to do with non-screen reader usage, you can detect
use of the tab key and pause it.
I thought detecting focus would be ideal, and with a little experimentation:
http://alastairc.ac/testing/detect-keyboard.html
I can detect "focusin", and it works with people tabbing, and with
VoiceOver.
However, in NVDA (due to the virtual cursor approach I assume) the event is
not triggered, i assume it would be the same for Jaws.
It is a similar story for use of the arrow keys, they don't get passed on.
Does anyone know of a reliable way of detecting keyboard usage? (And why
doesn't this impact ARIA widgets?)
Regards,
-Alastair
From: Cameron Cundiff
Date: Tue, Sep 17 2013 6:37AM
Subject: Re: Detecting keyboard usage
← Previous message | Next message →
According to NVDA's bug tracker<http://community.nvda-project.org/ticket/57>;,
browser focus should track the virtual cursor. I think the real problem may
be that Firefox does not support the
`focusin`<https://bugzilla.mozilla.org/show_bug.cgi?id=687787> event.
Try the `focus` event instead.
Though it may not make any difference, delegate() in jquery is deprecated
as of jquery 1.7, use on() instead.
On Tue, Sep 17, 2013 at 8:10 AM, Alastair Campbell < = EMAIL ADDRESS REMOVED = > wrote:
> Hi everyone,
>
> I've an odd issue with accessibalising a carousel. Yes, yes, I know we
> shouldn't use them, that's not an option here.
>
> It already has a visible pause button, alt text etc etc.
>
> The issue is that I would like it to pause automatically when a keyboard
> user is interacting with the page. (Again, I know that isn't ideal, but it
> "has to" auto-play.)
>
> That is straightforward to do with non-screen reader usage, you can detect
> use of the tab key and pause it.
>
> I thought detecting focus would be ideal, and with a little
> experimentation:
> http://alastairc.ac/testing/detect-keyboard.html
>
> I can detect "focusin", and it works with people tabbing, and with
> VoiceOver.
>
> However, in NVDA (due to the virtual cursor approach I assume) the event is
> not triggered, i assume it would be the same for Jaws.
>
> It is a similar story for use of the arrow keys, they don't get passed on.
> Does anyone know of a reliable way of detecting keyboard usage? (And why
> doesn't this impact ARIA widgets?)
>
> Regards,
>
> -Alastair
> > > >
From: Léonie Watson
Date: Tue, Sep 17 2013 7:18AM
Subject: Re: Detecting keyboard usage
← Previous message | Next message →
Alastair Campbell wrote:
" Does anyone know of a reliable way of detecting keyboard usage? (And why
doesn't this impact ARIA widgets?)"
Screen readers that utilise a virtual buffer will automatically switch into
application mode when they encounter certain ARIA widgets. This stops the
screen reader from intercepting the keys, and passes them back through to
the browser instead.
Léonie.
From: Alastair Campbell
Date: Tue, Sep 17 2013 5:16PM
Subject: Re: Detecting keyboard usage
← Previous message | Next message →
Thanks Cameron,
Focus gives the same results, and Jaws doesn't trigger either focus or
keypress, except when using tab. Considering the Jaws documentation on the
topic and that NVDA generally takes the same approach, I think it's by
design.
Leonie, thanks, I knew that some widgets trigger application mode, but some
don't and still track key usage. I think the difference is that on those
widgets you would press either enter or tab to activate a control. In this
case I'm trying to anticipate something and detect keyboard interactions
before the person has pressed tab or enter, either of which puts the focus
where you would expect.
In this case it wouldn't make sense to use an application role (or other
widget that switches mode), so I think we'll have to drop the idea.
Oh well,
-Alastair
>
>
From: Jonathan C. Cohn
Date: Tue, Sep 17 2013 8:02PM
Subject: Re: Detecting keyboard usage
← Previous message | Next message →
Perhaps judicious use of the role=application would provide what you want? A region of HTML surrounded by role=application will turn off jaws virtual cursor and probably the browse modes of NVDA and Window-Eyes too. Also, please note that advanced users of VoiceOver that use quickNav have an equivalent to browse mode. Also, if you are in role-application you will need to have keypressed events for all standard navigation keys.
Best wishes,
Jonathan
On Sep 17, 2013, at 8:10 AM, Alastair Campbell wrote:
> Hi everyone,
>
> I've an odd issue with accessibalising a carousel. Yes, yes, I know we
> shouldn't use them, that's not an option here.
>
> It already has a visible pause button, alt text etc etc.
>
> The issue is that I would like it to pause automatically when a keyboard
> user is interacting with the page. (Again, I know that isn't ideal, but it
> "has to" auto-play.)
>
> That is straightforward to do with non-screen reader usage, you can detect
> use of the tab key and pause it.
>
> I thought detecting focus would be ideal, and with a little experimentation:
> http://alastairc.ac/testing/detect-keyboard.html
>
> I can detect "focusin", and it works with people tabbing, and with
> VoiceOver.
>
> However, in NVDA (due to the virtual cursor approach I assume) the event is
> not triggered, i assume it would be the same for Jaws.
>
> It is a similar story for use of the arrow keys, they don't get passed on.
> Does anyone know of a reliable way of detecting keyboard usage? (And why
> doesn't this impact ARIA widgets?)
>
> Regards,
>
> -Alastair
> > >
From: Alastair Campbell
Date: Wed, Sep 18 2013 2:20AM
Subject: Re: Detecting keyboard usage
← Previous message | Next message →
Hi Jonathan,
I'm afraid that would cause more confusion than a straight carousel. The
first item in it is a 'pause' button, I was just trying to get that to
pause automatically so it becomes a 'play' button for keyboard users.
Switching to application mode would mean that non-screen reader users would
think it doesn't work (there's no visible indication you need to use the
arrow keys), and screen reader users unfamiliar with ARIA (or not expecting
it) would also be confused.
Thanks,
-Alastair
From: Joe Chidzik
Date: Wed, Sep 18 2013 3:23AM
Subject: Re: Detecting keyboard usage
← Previous message | Next message →
> I'm afraid that would cause more confusion than a straight carousel. The first item
> in it is a 'pause' button, I was just trying to get that to pause automatically so it
> becomes a 'play' button for keyboard users.
What about having hidden link at the top of the page. If this received the focus, you would know it was via the keyboard, and could use this as a trigger to pause the carousel.
Though, would a simpler solution not be to just let the carousel run through once, and then pause for all users, regardless of input methodology? It is likely that even with judicious keyboard detection, some keyboard users will slip through the net.
Joe
From: Alastair Campbell
Date: Wed, Sep 18 2013 4:12AM
Subject: Re: Detecting keyboard usage
← Previous message | No next message
Joe Chidzik wrote:
> What about having hidden link at the top of the page. If this received the
> focus, you would know it was via the keyboard, and could use this as a
> trigger to pause the carousel.
>
I was trying to detect focus on a link (or keypress), check out the test
page:
http://alastairc.ac/testing/detect-keyboard.html
The problem is that neither event will reliably fire when you use a Windows
screenreader to navigate with arrows or other browse mechanisms (e.g. skip
headings). It's a problem for me, but perhaps there are lots of examples
where sites would accidentally capture arrowing?
Though, would a simpler solution not be to just let the carousel run
> through once, and then pause for all users, regardless of input
> methodology? It is likely that even with judicious keyboard detection, some
> keyboard users will slip through the net.
>
The simplest would be to not use a carousel, but I'm afraid we are stuck
with one that must auto-rotate, we did well to get the pause button in!
Even if it ran through once, you could navigate into it whilst it runs and
get bounced-out as it changes.
Thanks,
-Alastair