[possible bug] jPlayer 2.6.0 breaks all links on a page for keyboard users. Found a partial fix, but....

27 views
Skip to first unread message

Jonathan2

unread,
Apr 22, 2014, 4:14:23 AM4/22/14
to jpl...@googlegroups.com
Good morning;

I've got a fairly critical and urgent problem; a line in the main jPlayer script is breaking ALL links on a page for users that rely on the keyboard (blind, disabled etc).

Example:

Visit: http://www.bbc.co.uk/news/ , press "tab" 8 times, "weather" will be highlighted. Press enter/return and you will be on the weather site.
This is 100% universal standard across all browsers and all operating systems and is expected and relied up for keyboard-only users.

Now try this: 

Visit http://jplayer.org/latest/demo-01-supplied-mp3/,  tab 8 times and try getting "home".

And just to be sure it's not something about the site, try http://jplayer.org/, tab 8 times, press enter, and you get the support page, as it should be.

This is also a particular issue for the playlist, as users can't "click" a playlist item with the keyboard.

I found and commented out event.preventDefault(); // Key being used by jPlayer, so prevent default operation. which lives here at line 450. 

Great! My links were working, keypresses were still working, I could now tab onto jplayer control keys to activate them with the enter key (still have to sort out why the keys lose focus but working on it!).

Except... when you hit a playlist item with the enter key now, it loads the file. Incidentally, I've changed the playlist links to reduce the clutter for screenreader users; they play when you click but retain default download functionality when you right click. I know I always complain when people don't post full links to working sites, but I really can't! But my playlist looks like this:

<div class="jp-playlist">
    <ul role="listbox" class="lead" style="display: block;">
        <li class="jp-playlist-current">
            <div><a tabindex="0" class="jp-playlist-item jp-playlist-current" href="http://localhost/audio/01_Introduction_and_track_list.mp3">Introduction and track list</a>
            </div>
        </li>
        <li>
            <div><a tabindex="0" class="jp-playlist-item" href="http://localhost/audio/02_In_Season._Spring_watch.mp3">In season - Spring watch</a>
            </div>
        </li>
    </ul>
</div>


I spend most of yesterday going through Stackoverflow, jQuery site etc trying to work around this myself, but gave up.

So what I would really like is for everything to function as it does after removing the event.preventDefault() line but for JUST the playlist region to accept "enter" as a method of playing the currently highlighted item.

Also, is there are way of "overriding" an existing function, in this case keyBindings = function(event)
Messing with the core code every time jplayer updates is going to be a pain, and I guess that line is there for good reasons in use cases I'm not dealing with.

OR is there a jQuery function I've not found which restores "click on enter" functionality for all links? Everything I tried either didn't work cross-browser, or got nullified by jplayer.

Many thanks for any help!

Jonathan2

unread,
Apr 23, 2014, 3:43:32 AM4/23/14
to jpl...@googlegroups.com
I realise the forum isn't the place for bug reports, so I've filed a more concise version at https://github.com/happyworm/jPlayer/issues/206

Mark Panaghiston

unread,
Apr 28, 2014, 11:26:02 AM4/28/14
to jpl...@googlegroups.com
Yes this does appear to be a rather large oversight when making the keyboard controls feature.

To disable the offending option, use:
keyBindings: {
  fullScreen: null
}

I'll have to have a think about this... We already have in this list here of elements to ignore:
// The list of element node names to ignore with key controls.
$.jPlayer.keyIgnoreElementNames = "INPUT TEXTAREA";

That list is used to stop the form inputs from triggering the key bindings.

At first glance, we may be able to add in the link and buttons node names and that will do the trick.
$.jPlayer.keyIgnoreElementNames = "INPUT TEXTAREA A BUTTON";

Thinking about what we are doing... The user is selecting a node using tab, and that node is in focus on the page when the user hits enter... That node will be the one raising the events, so ignoring key presses on links and buttons might be the way...

I'm just trying to avoid this problem every occurring again... So maybe we should check in another way... Rather than testing the node name, we should test if there is an element in focus. Do not confuse with the naming of "focus" I used for the last jPlayer instance used... So if you hit enter and there is no DOM element in focus, then we process the key press... However, if the tab key is used to put a link in focus, then the key press will be ignored, due to the DOM element being in focus...Well, that is the theory... Now to see if it is easy to figure out what is in focus on the DOM.
Reply all
Reply to author
Forward
0 new messages