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 11:00:15 -0700
To: w3c-wai-ig@w3.org
Message-ID: <1c69ef3b-e628-c426-adea-3a490decaf81@domblogger.net>
scrolling still an issue in chromium but there it is entire page that 
moves. I can live with that, if there isn't a solution.

On 09/30/2017 10:53 AM, Michael A. Peters wrote:
> 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 18:00:39 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 30 September 2017 18:00:40 UTC