- From: Michael A. Peters <mpeters@domblogger.net>
- Date: Sat, 30 Sep 2017 10:11:43 -0700
- To: w3c-wai-ig@w3.org
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:12:09 UTC