W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2017

Re: Key events conflict with browser

From: Michael A. Peters <mpeters@domblogger.net>
Date: Sat, 30 Sep 2017 10:53:48 -0700
To: w3c-wai-ig@w3.org
Message-ID: <4fa7560d-7865-2a07-5687-23454259366d@domblogger.net>
Actually the scrolling issue seems resolved too. Well sort of, it looks 
like the menu scrolls but the focus() changes it scrolls back to where 
it should with the now-focused item always shown.

On 09/30/2017 10:35 AM, Michael A. Peters wrote:
> Okay changing it to keyup instead of keydown seems to have fixed the
> problem of the play/pause button getting toggled (at least in firefox)
> but the scrolling issue still exists.
> On 09/30/2017 10:11 AM, Michael A. Peters wrote:
>> I'm create a custom HTML5 audio interface that has support for chapters,
>> captions, and subtitles. Browser audio interfaces don't, and able player
>> is too difficult to modify for my needs as it requires a build system
>> and in my past experience with javascript build systems, they often have
>> components that want a newer version of node.js than my distribution
>> ships with which in turn requires updating other libraries and I end up
>> pulling my hair out.
>> Anyway I'm building my own, and it is working very well.
>> However - for chapter selection, I'm using a list that ordinarily is
>> hidden. The current displayed chapter acts as a button that show the
>> list and gives focus to the current chapter.
>> Since some audios may potentially have numerous chapters, the list has a
>> fixed height and uses overflow-y: scroll.
>> That causes the first problem. When there are enough items to cause a
>> scroll and I interpret keyCode for 38 or 40 to navigate the list, the
>> browser then also scrolls the list which is not desirable.
>> Is there a way to tell the browser not to?
>> Second issue -
>> After the user selects the chapter they want, I give focus to the
>> play/pause button as that is the button that when it has focus has other
>> keyCode events that do things like fast forward, rewind, and download.
>> But it seems that the space and return keys, even though pressed before
>> the play/pause button has focus, are then interpreted to toggle the
>> play/pause button as well which is NOT desired.
>> This doesn't happen when I click the chosen chapter with a mouse,
>> play/pause still gets focus but doesn't toggle. Only when I use keyboard
>> to select the chosen chapter from the list.
>> Is there a way to clear the context of the return / space bar so it
>> isn't interpreted by the play/pause button?
>> I know both these issues would vanish with a select list but it seems
>> browsers won't let me style a select list.
>> I know accessibility is more important that aesthetics but it would be
>> nice, if possible, to have both.
Received on Saturday, 30 September 2017 17:54:11 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 30 September 2017 17:54:13 UTC