I agree - a media element with controls ought to be keyboard-accessible by default. Right now it doesn't appear that you can even make an audio or video element play in WebKit even if it is focused.
Firefox seems to treat the whole set of controls as one focusable element - you can use the spacebar to play/pause and the arrow keys plus modifiers to skip around. I couldn't figure out a way to access the volume control. An alternative approach would be to make each individual subcontrol focusable - the play/pause button, the seek slider, and the volume slider, plus potentially other controls for video. - Dominic On Tue, Sep 13, 2011 at 12:04 PM, Deepak Sherveghar <bpw...@motorola.com>wrote: > Hi All, > > As with current Webkit behavior, only media elements with tab-index > attribute specified can be focused with keyboard (TAB key). > > From a usability as well as accessibility perspective, we should be able to > focus (via keyboard using TAB key) > media elements that have controls attribute specified but do not have a > tab-index attribute specified. > ie: <video controls src="../media/content/test.mp4"></video> //should be > focused by tabbing. > > This would help in making the media element keyboard accessible. > > Firefox and Opera both support this behavior ie: focus media element by > tabbing without the need for tab-index. > you can verify this using the link : > http://yves.vg/testcases/webkit/video.html > I have already implemented this and uploaded my patch in BUG 67190. > My approach to support this is as follows: > In HTMLMediaElement.cpp., add > > bool HTMLMediaElement::supportsFocus() const > { > // Return true if control attribute present else If no controls > specified, we should still be able to focus the element if it has tabIndex. > return controls() || HTMLElement::supportsFocus(); > } > > Antonio Gomes suggested that "since my patch would be changing a general > behavior of all webkit based browsers > (and according to the spec it is up to the UA to implement that or not), we > could have a discussion in webkit-dev mailing list first." > > Also Ian 'Hixie' Hickson is of the opinion that: > "Whether something is "interactive content" or not has no bearing on > whether it is focusable or not: the definition of focusable doesn't > refer to whether something is "interactive content": > http://www.whatwg.org/specs/web-apps/current-work/complete.html#focusable > Whether something should be focusable or not is essentially up to the > browser vendor (you). I would recommend making it possible > to focus video controls if they are present, of course. But that's not a > spec conformance matter, it's a usability matter." > > According to me, making media element focusable without tab-index (but > control attribute specified), would be first step in making the > media element keyboard accessible which would further help us make the > media element 'Interactive" > (W3C Draft categorizes video and audio in "Interactive Content") using > keyboard (ie play/pause media using space bar) > > Need suggestion or feedback on this. > Whether we should go ahead with this or follow any other approach ???? > > Also a bug on second aspect of media element ie: to make it interactive > using keyboard is already being filled by Yves Van Goethem : > BUG: 31786 : https://bugs.webkit.org/show_bug.cgi?id=31786. I have marked > 31786 bug as dependent on BUG: 67190. > > Thanks in advance. > -Deepak Sherveghar > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
