On Wed, 20 Jun 2012 07:47:12 +0200, Silvia Pfeiffer
<[email protected]> 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
