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

[Silvia Pfeiffer]

On Wed, Jun 20, 2012 at 2:51 PM, Simon Pieters <simonp at opera.com> wrote:
> On Wed, 20 Jun 2012 05:43:20 +0200, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>
>> Hi all,
>>
>> I recently experimented with keyboard accessibility of media elements.
>>
>> I found that browsers don't provide a default tabfocus on media
>> elements nor do they provide keyboard interactivity. I had to put
>> explicit @tabindex attributes onto the media elements to allow them to
>> at least receive focus. This is particularly irritating in a
>> screenreader.
>>
>> As the video is specified right now, it is not a tabfocusable element
>> [1] and only interactive [2] when it has controls. This is sufficient
>> for audio elements, which have no visual representation without
>> controls, but isn't right for video, which always renders at least a
>> poster (or a black area). Also, if there are controls specified, they
>> should actually be tabfocusable.
>
>
> 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?


>> Even video without controls should allow keyboard focus and should
>> provide for default keyboard interaction: at minimum it should allow
>> for ENTER and/or SPACE to toggle play/pause - and clicking on it
>> should work, too.
>
>
> 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.


>> 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?

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".

Thanks,
Silvia.