[opinion suggested] keyboard control for the videoPlayer
charly.molter at gmail.com
Fri Aug 5 14:00:26 UTC 2011
Hey thanks for these answers it helped me a lot to make up my mind.
I think Colin is right about the keyboard shortcuts and even the space
bar for start/pause is for me also a kind of accessibility in a sense
(it's big and easy to reach).
So in the end what I think we can do:
- Still being able to access with the usual tab control (as mentioned by Colin)
- Allow the implementor to change the default keyboard control
- And then I think we can actually as a default put both DHTML and
usual (arrows...like youtube...) controls, this is possible as they
don't really "intersect" so in that way any user used to one or the
other convention will just find it easy without any learning. (hope I
make sense there :) )
I think that this would merge both arguments and will enable most user
to control really quickly the player.
What's your opinion and that double default binding?
Thank you very much for all you feedback
On Thu, Aug 4, 2011 at 11:22 PM, Colin Clark <colinbdclark at gmail.com> wrote:
> Okay, cool. Let's unpack this a bit more. We can use a couple of guiding principles when we make decisions about keyboard navigation. I think these are probably relatively uncontroversial, but feel free to disagree:
> 1. Keyboard controls aren't just for "accessibility" or assistive technology users. Everyone uses them and benefits from them.
> 2. Keyboard shortcuts will always end up conflicting with some assisitive technology or application, somewhere, at some point.
> Video players are actually a pretty good illustration of #1. I think most people willbe pretty frustrated if they can't play or pause their video with the spacebar. It's a ubiquitous convention, and one we should support. A quick review of the most prominent media players out there--say, YouTube, Vimeo, Netflix, and iTunes--should uncover a basic subset of consistent keyboard shortcuts that many users are already familiar with.
> My best guess is that the keyboard shortcuts defined in the DHTML Style Guide and the JW Player were probably devised by looking specifically at JAWS and trying to find keys that won't conflict with it. Helpful, but since they're so unfamiliar to most users, they aren't a sufficient replacement for the familiar ones.
> So I think we need to support keyboard navigation in layers. We want our components to remain usable with the keyboard even when conflicts occur. That's why the controls remain in the tab order and are controllable with the standard arrow key conventions.
> From there, we can choose to support one or more sets of keyboard shortcuts. We're going to need to support the familiar conventions, so the question is, do we also want to also support the ones suggested by the Style Guide? And should we make these keyboard bindings configurable so that others can add to or change them?
> On 2011-08-04, at 10:22 AM, Cheetham, Anastasia wrote:
>> On 2011-08-04, at 10:10 AM, Valles, Heidi wrote:
>>> Charly and I also chatted in the channel about considering the shortcuts used by the accessible JW Player Controls from Ohio State University: http://wac.osu.edu/examples/jwpc/
>>> Scroll to the player and click the 'help' icon to see the shortcut list:
>>> • Alt + Control + P Toggle play and pause
>>> • Alt + Control + S Stop
>>> • Alt + Control + F Jump forward
>>> • Alt + Control + B Jump back
>>> • Alt + Control + D Decrease volume
>>> • Alt + Control + U Increase volume
>>> • Alt + Control + M Toggle sound mute
>>> • Alt + Control + A Toggle audio descriptions (if available)
>>> • Alt + Control + C Toggle captions (if available)
>>> • Alt + Control + R Toggle resizing of player
>>> I imagine some research went into these decisions, likely related to how they play with AT shortcuts. It's interesting they don't follow the conventions Colin mentioned, but I'm not sure why. Might be interesting to ping someone from this team to get some feedback on their choices?
>> These keystrokes seem pretty consistent with the DHTML Style Guide's recommendations for Media Players:
> Colin Clark
> Technical Lead, Fluid Project
More information about the fluid-work