Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 135661 No keyboard accessibility for the html5 video player
Starred by 33 users Reported by, Jul 3 2012 Back to list
Status: Assigned
Last visit 17 days ago
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

issue 314033

Hotlists containing this issue:

Sign in to add a comment
Chrome Version       : 20.0.1132.47
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5:
Firefox 4.x:
IE 7/8/9:

What steps will reproduce the problem?
1. Open a page with html5 video (for example:
2. Try to tab to video player controls or use arrow keys, space, home, end keys to access video player controls 

What is the expected result?
- Left and Right arrow keys move video slider
- Up and Down arrow keys move audio slider
- Home key moves video to the beginning
- End key moves video to the end
- Space and/or Enter does the action for the control which has focus

What happens instead?
No keyboard accessibility for the html5 video player 

Please provide any additional information below. Attach a screenshot if

UserAgentString: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11

Also there are no tool tips for the control available for screen reader to read
Labels: -Area-Undefined -OS-Windows Area-WebKit OS-All Feature-Media
Status: Untriaged
I'm able to reproduce this issue with Unbuntu, gc: Google Chrome	22.0.1205.0 (Official Build 146512) 

i've contacted devs about it, and this bug on their list to do. 

It does happen with internal Matrix with all formats. Doesn't happen with the old controls. Not a regression.  
Comment 3 by, Jul 16 2012
Status: Assigned
Issue 132350 has been merged into this issue.
Issue 135719 has been merged into this issue.
Cc: addresses the accessible names part of keyboard accessibility (as per Issue 135719).

The keyboard shortcuts still need implementing.
Project Member Comment 9 by, Mar 10 2013
Labels: -Area-WebKit -Feature-Media Cr-Content Cr-Internals-Media
Project Member Comment 10 by, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Owner: ----
Blocking: chromium:314033
Comment 13 by, Mar 20 2014
Status: Available
Comment 14 by, Mar 20 2014
Issue 353102 has been merged into this issue.
An interesting tidbit of information that I just got from a colleague is that he tried to put the keyboard focus onto a video element in Chrome and then tried to capture keyboard events on the video element.

Markup like this:

<video id=TestVideo width=640 height=400>
  <source src='data/frames.webm' type='video/webm'>

Give it some CSS:

video:focus {
  border: thick solid yellow;

video.addEventListener("keydown", function() { console.log("KEYDOWN1") }, false);

He said he wasn't able to get any keyboard events from the video element unless he did the following:
* Add a tabindex=<n> attribute to the video element
* Add an onclick javascript callback to the video element that explicitly does a video.focus()  (!!!)

The missing focusability would surely also destroy accessibility.
Comment 16 by Deleted ...@, May 16 2014
To elaborate on Silvia's comment... In the code below, removing EITHER of the tabindex=1 or onclick="this.focus()" attributes of the video element disables generation of onkeydown events in latest stable Chrome 34.0.1847.137. 

    <title>Video Test</title>
    <video id="testvid" width=400 
           onkeydown="console.log('Key Pressed')" 
      <source src='data/frames.webm' type='video/webm'>
      *:focus { border: solid red; }

Chromium 31 does have the same problem, but I haven't tested any later versions. Works with any special tricks in Firefox 29.
Comment 17 by, May 20 2014
Re: #15/#16

The media element (<video> in this example, but applies to <audio> as well) will be focusable when it has controls. It's explicitly disallowed to focus it using the mouse, due to the fix of WK bug #77288 [1]. It seems quite possible to fix that same issue in some other way though (like allow the control element to be mouse-focusable to stop the propagation there instead.) It's a matter of what kind of behavior we want though - I've not seen any part of the spec that seem to mandate said behavior.

Comment 18 by, May 20 2014
Project Member Comment 19 by, May 22 2014
The following revision refers to this bug:

r174503 | | 2014-05-22T01:52:44.777652Z

Changed paths:

MediaVolumeSliderPart is not vertical

This makes some parts of the keymapping a bit more intuitive for the
volume-slider of media controls (-webkit-appearance: media-volume-slider).


Review URL:
Good catch - I didn't notice that the video element had no @controls attribute.
Project Member Comment 21 by, May 27 2014
The following revision refers to this bug:

r174794 | | 2014-05-26T09:03:58.281637Z

Changed paths:

Implement heuristic for showing media controls during playback w/o a mouse

This implements a heuristic that allows the media controls to re-appear
when playback has started and the mouse is unavailable.
The behavior is triggered by a 'focusin' event on the HTMLMediaElement,
which shows the controls. The controls then remain visible as long as
the media element itself or any part of the control retains focus, or
until the hide timer fires (which it will on a pause-play "cycle" for


Review URL:
Project Member Comment 22 by, May 27 2014
The following revision refers to this bug:

r174795 | | 2014-05-26T09:04:15.565254Z

Changed paths:

Rudimentary keyboard navigation support for <video>/<audio>

Remove the override of hasCustomFocusLogic() for HTMLMediaElement. This
allows focus navigation (<tab>ing) to reach the controls.


Review URL:
Comment 23 by, Nov 21 2014
Owner: ----
Comment 24 by, Mar 18 2015
while it supports tabbing to the video controls such as the seekbar, it is very cumbersome to do so, especially as that focus is lost when the controls fade out again.
You have to hit <tab> a undetermined number of times, until you can use arrow-keys/the keyboard to seek in the video, but if you want to change the volume as well, you have to tab further to the volume control. If you want to pause and resume, you have to tab to yet another control.

Esp. in fullscreen mode, Firefox' way of handling those media controls is far more comfortable and predictable:
Without having to tab around, you can seek back and forward by using <arrow-left> and <arrow-right>, change the volume by <arrow-up> and <arrow-down> and pause/resume by pressing <space>

I wouldn't mind having to use tab to focus a control element, if that then would allow to control all three aspects, and wouldn't have to retab after the controls auto-hide, but right now it's easier to just use another browser than trying to control video-playback using keyboard in chromium :-/
Components: -Blink Blink>Video
Comment 27 by, Mar 3 2016
Components: UI>Accessibility
Components: -Blink>Video Blink>Media>Video
Renaming Blink>Video to Blink>Media>Video for better characterization
Note: We've been documenting the shortcuts we use in our media elements. I can share the details if it would be helpful here? Most of the common commands are covered in bug report, but there are few more advanced available
This has nothing to do with the original bug submission.
I subscribe to this issue because I found the missing keyboard support on the X-Window version of Chromium.
What keyboard shortcuts the Edge browser might have on Windows does not have to do with the problem at hand.

I think the shortcuts would better follow what a good and widespread player like VLC has rather than the uncommon and less powerful ones we can see in that new Edge list : ctrl, shift and alt are modifiers that control how much the arrow keys seek or change the volume. Especially, shift allows for fine grained seeking (in the order of 1 second probably). This is a must have when you missed some subtitles. Oh, and having a shortcut to seek to the end of the stream just makes no sense to me!
Components: -Blink>Media>Video Internals>Media>Session Blink>Media
Labels: -Pri-2 Blink-Media-Triaged Pri-3
In my testing, Firefox supports arrows for position and volume and space to pause/resume (with Ctrl they change position by a smaller amount) but I didn't find a shortcut for going fullscreen for example.
Edge's shortcuts seem to be well documented and extensive.
Safari doesn't seem to support any shortcuts.

I wonder if there're websites using keyboard events that might be broken by adding keyboard shortcuts to the media element (I guess we would let the event bubble through and implement any shortcuts as the default handlers?)

No milestone yet so lowering the priority to P3. says "If the user agent exposes a user interface to the user by displaying controls over the media element, then the user agent should suppress any user interaction events while the user agent is interacting with this interface. (For example, if the user clicks on a video's playback control, mousedown events and so forth would not simultaneously be fired at elements on the page.)"

This was added to deal with a similar problem of pages using click events without calling event.preventDefault(), and the same thing would have to be done for keyboard events that are used internally. That could still make a mess of things, though, if we suppress only *some* of the events that the page expects.

Overall, though, if the benefit to end users is significant, I'm sure some solution for this could be found even if what the spec says should turn out to be insufficient.
Labels: Needs-BlinkMediaTriage
Labels: -Blink-Media-Triaged -Needs-BlinkMediaTriage
Components: -Internals>Media>Session -UI>Accessibility -Internals>Media -Blink>Media Blink>Media>Controls
Labels: -Pri-3 Hotlist-Accessibility Pri-2
Labels: Hotlist-Media-UX
Status: Assigned
Labels: M-59
Sign in to add a comment