[whatwg] make <video> always focusable and interactive content

[Simon Pieters]

On Wed, 20 Jun 2012 07:47:12 +0200, Silvia Pfeiffer  
<silviapfeiffer1 at gmail.com> wrote:

>> They are in Opera. The spec allows it.
>
> Yes, thankfully one browser has video keyboard interaction.
>
> Video is not listed in the tabfocusable list, though. How does the
> spec allow/encourage that?

This list?  
http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#focus

I guess it should add "media elements that are exposing a user interface"  
and finally have a "may" for just about anything, since this is UI and  
browsers should be allowed to make things focusable if they want. It is  
unusual for the spec to have UI requirements at all.


>> Why? Video without controls is expected to have author-provided  
>> controls.
>> Trying to squeeze in hard-to-discover invisible browser-provided  
>> controls in
>> that case would likely just confuse users and make authors curse  
>> browsers
>> and try to preventDefault() and tabindex=-1 their video elements (or  
>> switch
>> back to Flash) so that their own controls is what their users interact  
>> with.
>
> Hmm... I guess so. The problem that I have is that it's not guaranteed
> that there are accessible controls when there is no @controls
> attribute. That means that screen readers don't even see the "image",
> nor would they provide access to the context menu, through which
> "play" is usually possible. But maybe that's a bug on the
> screenreaders rather than the spec - they should always have video as
> an interactive element.

Yeah, it might make sense for screenreaders to provide special access to  
video elements, to cater for pages that have inaccessible custom controls.  
They also make <h1> "focusable" even though it isn't normally in browsers.

>
>>> Potentially it should have up/down arrows to change
>>> the volume and left/right arrows to seek back/forward by e.g. 10sec.
>>> As it's currently specified, browser cannot provide such interaction
>>> when there are no controls, since the element is not generally
>>> specified as an interactive element [2].
>>
>>
>> It can, actually. "interactive content" is just a category for the  
>> purpose
>> of the content model, it doesn't have implications like the above. (For
>> instance, if you have a <video> without controls attribute, and the user
>> enables the controls from the context menu, the element still isn't
>> "interactive content" but it shows controls.)
>
> That's a browser-specific hack, though, and not quite in the spirit of
> the spec, isn't it?

No, it's literally the spec's model.  
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#expose-a-user-interface-to-the-user  
is decoupled from the controls attribute.  
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#the-video-element  
says "If the element has a controls attribute: Interactive content."

Another case is when scripting is disabled, where <video> (without  
controls="") is not "interactive content" but still "exposes a user  
interface to the user".

I noticed the spec doesn't say that UAs are allowed to show controls on  
demand (from the context menu), so I filed  
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17553

> Maybe the answer is in general: it's an implementation issue. However,
> the spec doesn't really encourage such
> implementations/interpretations. The spec should then say something
> like: if there is a screenreader running or a context menu available
> that provide for controls, then the elements are also regarded as
> "interactive content".

You can't change the content model of a document based on what the user is  
running. That doesn't make sense. Content model is about how authors are  
allowed to nest their elements. It doesn't apply to UAs at all. When the  
author is writing and validating the document, nobody knows whether the  
user is going to read the page with a screenreader or not, or have  
scripting enabled or not. Maybe you actually mean something different from  
the spec's "interactive content" term?

-- 
Simon Pieters
Opera Software