Re: html5-video keyboard controls

On Tue, 4 Aug 2015, Mandana Eibegger wrote:
> i am wondering how to make this accessible in the best way.

Yay!

> ISSUE 1: proper markup
>
>    <button ...>play [or pause - depending on the state]</button>

Based on your questions below, I'm assuming you have already planned to put the appropriate  attributes for keyboard navigation in the buttons, but I'm going to call it out specifically so that other people reading this thread will remember it's necessary.

> does it make sense, to use the nav-element as a container for the controls? 
> or would this be misleading?

That would be misleading. If I reach an element marked up as navigation, I expect it will help me navigate the site, or, at the very least, the page. People using screen readers may well choose to skip navigation blocks, if they know they are where they want to be on the page (at the video), and they are simply looking for the controls. The specification wants nav elements to link to other documents or other parts of the page.

> ISSUE 2: tabbing
>
> i think it is not a very good practice, if the user has to tab through all 
> controls by default.

As a keyboard/voice user, I disagree with you on this one. Your philosophy is a good one when it comes to certain drop-down menus (especially deeply nested ones), mega menus, or other complex sets of controls. However, there are not very many controls on a media player.  As a user, if I see six or seven controls on a media player, I want to be able to know that  if I tab five times, I will hit the fifth visible control.

> would this procedure be understandable for the users? and if, would the 
> enter-key be the appropriate key to use?

The only way this will be understandable for users is if the explanation of how to make it happen ("In order to reach the controls, press Enter when the play button is highlighted, and then tap through the controls") is visually available on the screen in a way which is obvious, and not hidden behind a low-contrast question mark somewhere in the bottom right-hand corner of the screen. Which is the usual place sites seem to be documenting their keyboard shortcuts these days!

It needs to be visually available to all users, and it needs to be available before the player itself or associated with the player object via aria, otherwise screen reader users won't know the help is available.

Keyboard users (which is to say, keyboard, voice, and screen reader users) are never going to guess at the controls of an application. The only way they are going to figure out any nonstandard control is if it is the same nonstandard control used on the site you can assume your users hit constantly: Google, Gmail, Facebook, YouTube, or whatever the appropriate level of ubiquity is for your user base. And for what it's worth, you'll find if you do some web searching that the number of users who haven't figured out the YouTube keyboard commands is shockingly high.

Perhaps it's not that shocking, given their documentation on YouTube's own site being both hidden and inaccurate.

So if you don't want your application to work in the ways that are standard either because:

- They are true on the ubiquitous sites everyone uses, or
- They are the way HTML controls work out of the box in that person's browser, that is, for most people, Tab to reach and Enter to activate

The only solution is well-maintained and visible documentation.

> ISSUE 3: keyboard-shortcuts for controlling the video-properties
>
> once the application has focus, keyboard-shortcuts could be used to control 
> the properties. for instance
> - use space bar for play/pause
> - use +/- to adjust the volume
> - page-up/page-down to jump to the end/beginning
> etc ...

You don't want to use any keys that the person might be using in the browser anyway. I frequently want to use the page up and page down keys while I have a video playing. Have you ever been watching a video, but wanted to check out the description or the related videos or the comments? That is a clear use case for not capturing the page down key. Space bar is also used by many keyboard users for page down, but that comes back to the situation of "what we are used to working on other sites." Space is so frequently used to play/pause the video, that keyboard users are used to it.

Personally I would avoid the arrow keys except when a control is focused where it makes sense for the arrow keys to be used (e.g. the volume, the slider, any pop-up menu controls), and avoid numbers for the same reason, but again there is the question of ubiquity.

When I specced out the keyboard controls for a video player recently, my decision was to start with YouTube's keyboard defaults and only make changes if I had a good reason, because it comes back to what the users expect.

I understand that pointing towards a specific corporate instance of the video player as a jumping off point is not at all web standards friendly. But unless the controls are going to be quite obviously documented in a location users will see whether they seek it out or not, my argument is either follow the default behavior that is given to you by the web standards, or follow the convention the users already know, otherwise accessibility falls apart.

Deborah Kaplan

Received on Tuesday, 4 August 2015 17:14:45 UTC