[Player] visual design and placement of controls #206

Open
James-Green opened this Issue May 6, 2016 · 1 comment

Projects

None yet

3 participants

@James-Green

Just starting this issue to collect comments from EO per Caleb's action item from our May 6 telecon. Let us know your ideas and we'll see what we can change as a possible update to the video player.

@nitedog nitedog modified the milestone: Second Release May 13, 2016
@nitedog nitedog added the Player label May 18, 2016
@nitedog nitedog changed the title from VIDEO PLAYER visual design and placement of controls to [Player] visual design and placement of controls May 18, 2016
@terrill
terrill commented May 25, 2016

Not sure if you're wanting this conversation to be focused specifically on WAI's media player, but I thought it would be helpful to take a broad look at media players in general, starting with Able Player as a baseline. As the project lead for Able Player, I can share the choices that went into the current interface.

The greatest barrier to adoption is that everybody wants a minimal player these days, and they inevitably ask if they can eliminate some of those buttons and controls. So an overarching question I have is: Is accessibility dependent on having buttons and controls? They all serve an important purpose, but is there an alternative way to present them that would satisfy the desire for a minimalist design without sacrificing functionality or usability? I'd love to hear creative solutions.

Meanwhile, here's a run-down of are all possible buttons and controls on the Able Player controller, with some commentary on each. I've also attached a screen shot below of a fully-loaded video player:

  • Play/Pause - every media player has a play button, which changes to pause during playback. There's been some discussion of moving it, but I think this is arguably the first action users are likely to want to take, and therefore should be the first UI element encountered.
  • Stop - we recently replaced this in Able Player as feedback was overwhelmingly negative. Its function was to stop playing and reset the video to the beginning. People seem to think Pause is enough, although some are ok with the Restart button. Some of the aversion may have been visual, as it represented with a solid square (which is the longstanding convention), but this may have looked a little too blocky or commanded a disproportionate amount of visual attention.
  • Restart - This replaced the Stop button in Able Player version 3. It returns to the start of the video. If the media is playing at the time, it immediately resumes playback. If the video is paused at the time, it has the same functionality as the original Stop button.
  • Rewind and Forward - These allow a user to scrub the media backward or forward a few seconds, using an interval that's automatically set based on the duration of the video. Some people don't like these buttons because a user can use the seek bar for the same purpose. However, I think these buttons can be a lot more intuitive and are easier to use than the seek bar for a lot of people, including screen reader users, voice input users, and mousers with limited dexterity. Prior to version 3 we had these buttons positioned on either side of the seek bar because we liked the symmetry of that, but I think it makes more sense functionally to position them side-by-side (the new design).
  • Volume - We used to have three Volume buttons (Mute, Volume Up, and Volume Down). This was easy to use but not at all popular among the minimalist crowd. Now we have a single button that exposes a vertical slider.
  • Slower/Faster - I've been asked whether these are required for accessibility. I don't think they're required by WCAG 2.0 at any level, but they sure are useful! People who are having a hard time understanding the video can slow it down (might be somebody with a cognitive disability or a person who's having difficulty understanding the speaker or a musician trying to figure out a crazy guitar lick). It's also great to be able to speed up a video if you're busy and need to get through it quickly but don't want to skip content). Few other media players have this functionality, and maybe it technically is expendable, but I think not providing it would deprive users of an extremely useful feature. Since it's not a common feature, there's no standard icon. We settled on up/down arrows, but I've found that most users don't know what they mean initially, but they learn if they try them. In version 3 we introduced an experimental alternative: A turtle icon for slower, and a rabbit icon for faster. We plan to do some user testing to see how folks respond to those. See our Able Player example with animal icons.
  • Closed Captions - If captions and/or subtitles are available, you have to have a CC button to toggle them on/off. Able Player is also using this button as a means of triggering a popup menu to select a language if multiple languages are available (either captions or subtitles).
  • Sign Language - This button in Able Player toggles the display of a separate video that features someone signing the content. So far it's rarely used in practice, but if it's available the button is automatically added.
  • Descriptions - If descriptions are available, these, like captions, need a button by which they can be toggled on or off. Able Player actually does have a means by which this button can be eliminated (data-use-descriptions-button="false") if descriptions are judged to be essential for a particular application and should therefore always be on.
  • Transcript - This button toggles the display of an interactive transcript. If your media (either or audio or video) has audio content it should be captioned, and if captions are provided the transcript is generated automatically from caption content (plus chapters and descriptions, if those are also available). The button controls the display of the transcript in a pop-up window. This button can be eliminated if you prefer presenting the transcript in an external container rather than a pop-up, but I wouldn't recommend depriving users of the transcript. It's extremely useful for everyone to be able to quickly scan or read the transcript and use that to play the media at a particular point.
  • Chapters - This button displays a pop-up menu with chapters (built from a WebVTT chapters track). As with the transcript, this button can be eliminated if you prefer displaying the chapters in an external container.
  • Preferences - A lot of people don't want this button, but I think user choice plays an integral role in accessibility. They can use it to control the visual display of captions, select modifier keys that enable the player to operated with keyboard shortcuts from anywhere on the page, and select preferences related to descriptions and transcripts. I don't feel this is expendable.
  • Full-screen - Full-screen is a desirable and useful feature, although it can be disabled by setting data-allow-fullscreen="false". This attribute shouldn't be used solely to deprive users of features, but there are use cases where the media is part of a larger application and should not be played out of context.

It's important to note that buttons only appear if they're relevant to a particular video (e.g., if you don't offer chapters, description, sign language, or captions none of those buttons will appear, nor will the transcript button). Of course it's preferable to include those features, and in some cases critical for accessibility.

Also: It's important to keep in mind that buttons must be high contrast and should be large enough to be easy targets for mousers with limited dexterity.

Here's a screen shot:

ableplayer-loaded

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment