Re: Issue 142: Video Poster [Was: Reminder: January Change Proposal Deadlines]

On Wed, Jan 5, 2011 at 8:51 PM, John Foliot <jfoliot@stanford.edu> wrote:
> David Singer wrote:
>>
>> 1)  I meant to say, if you wish to have a page that shows an image that
>> is semantically distinct from the video which eventually replaces it
>> when some event happens, you have all the tools you need in
>> HTML/CSS/script already, and if you use these tools, then that image
>> can be fully associated with alt text etc. as it is a normal HTML
>> image.
>
> David,
>
> I think here, you have hit the nail squarely on the head. This is indeed
> the use-case and problem scenario: sure, the tools to do this exist in the
> toolbox already and, in fact, my buddy Faruk Ates coded up an example for
> me as part of my efforts here:
>
>        http://john.foliot.ca/experiments/video/poster2.html
>
> - not only does the placeholder image have an @alt value, I've also
> petulantly added an @longdesc attribute to an otherwise valid HTML5
> document to make 2 points (1 - that using @longdesc in HTML5 documents
> still works, and who cares about validation when accessibility wins? 2 -
> We still need a means to link to a longer textual description of images
> that is *user-controlled*)
>
> The larger problem however is to achieve this, there is a fair bit of
> coding required, whilst *visually* it achieves the same effect as
> "...poster="path to image"...",
>
>        http://john.foliot.ca/experiments/video/poster.html
>
> ...and so what we will end up with is that many developers will take the
> easier way out - it's simple human nature, and as you yourself have
> pointed out, we have no way of 'policing' what developers will do.


I don't think it's an "easy way out". I don't actually see the need as
a developer to choose the difficult road. I cannot actually think of a
use case where I would want to use this kind of markup when there is
already the simpler markup available with the @poster attribute. While
we didn't have the @preload attribute, there would have been a need -
namely a Web page that has many video elements and wanting to avoid
all the video elements downloading their setup information during page
load time to avoid making the user wait or even breaking their Web
browser with this load. But we now have @preload="none" so we don't
need this any more. We can for example say:

<video controls aria-describedby="kitten" poster="poster2.png"
title="A perfectly valid html5 video example">
    <source src="dizzy.webm" />
    <source src="dizzy.mp4" />
    <source src="dizzy.ogv" />
  </video>

<p><a href="videotranscript.html">Read the transcript for this video.</a></p>

<p id="kitten" style="margin-top: 415px;">A short HTML5 video of a
kitten chasing a flashlight. Original video created by Remy Sharp and
found at <a href="http://html5demos.com/video">http://html5demos.com/video</a></p>

This example includes all your accessibility needs for the
video+poster and it is independent of whether the poster image is
provided as a separate image or as the first frame of the video - in
the latter case you just remove the poster attribute.

We have all of the following:

1/ a short text alternative on the video element through @title (I
don't know whether this is the right attribute, but it is available at
this stage). The short text alternative has the same functionality as
the preview image, namely to entice the user to start watching the
video.

2/ a long text alternative on the video element in the form of @aria-describedby

3/ a full text alternative on the video element in the form of the transcript



> We are already establishing a design pattern that places all of the
> 'supporting' content that the multi-media resource of <video> requires as
> children elements of <video> (notably, the <track> element). <track> is an
> element rather than an attribute as this way we can also 'layer-on'
> additional attributes (like @lang, ARIA attributes, etc.) - elements are
> always "stronger" than attributes.
>
> So... let's create another child element of <video>: call it <poster> or
> call it <firstframe>; call it whatever we need to call it, but it's 'role'
> (hello ARIA) is to represent the placeholder image that will be removed
> once the video is activated.
>
<..>
> <video src="trailer.m4v">
>        <firstframe src="mpaa_rating.png" alt="This video is rated G for
> all audiences">
> </video>
>
>  - or -
>
> <video src="trailer_with_mpaa_rating.m4v">
>        <firstframe alt="This video is rated G for all audiences">
> </video>



As you examples demonstrate, this creates a short text alternative on
a subelement of the video element - a @alt attribute on the
<firstframe>. The vision-impaired user that tabs through the elements
on the page actually tabs onto the video element as a single entity.
In your example, would the screen reader then read out this short text
alternative from the <firstframe> element? If so, why would we not
just use it on the <video> element directly?



>> If, on the other hand, the image is a transient place-
>> holder that has the same semantics as the video, and is predominantly
>> there to avoid having blank space on the page, then the existing state
>> is fine (provided we have good accessibility provisions for the video
>> itself, which I currently am unsure about).
>
> This raises a related question: should <video> (sans an author declared
> poster frame, and for argument offers the first frame, which is an empty
> frame) require/take on a short textual description?


That is indeed the much more important question to ask. In fact, I
would suggest this group drop all discussions about text alternatives
on poster attributes and focus on whether we have covered all text
alternative requirements on the video element (and audio element for
that matter). By solving that question we will also solve the question
about text alternatives on poster.

I would like to get back to some discussions started about this in the
following thread:
http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/0246.html
and in particular this link:
http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/att-0246/embeddedcontent.html

There, the following text alternatives were listed that the <video>
element currently supports
2. @title
3. embedded content (which one could argue provides everything
required for long text alternatives)
5. @aria-labelledby
6. @aria-describedby

What the email argues for <video> was that <video> needs only the following:
1. long text alternative - in the form of a transcript
2. label - in the form of @title
3. idiosyncratic direct accessibility - in the form of embedded content
These are all possible at this stage.

What it argues that <video> doesn't need is:
1. a short text alternative 	
2. a caption
3. a summary

I personally think that we could need these three for videos, too, but
wanted to have a discussion on this.

The first could be satisfied through an @alt tag (that also thus
covers the poster).
The second already works through <figcaption>, so we don't need
something special here (see the video example at
http://dev.w3.org/html5/spec/Overview.html#the-figure-element ).
And the third would work with @summary, though I don't really think
that's necessary either.

So, I am still curious what people think about all this?

Cheers,
Silvia.

Received on Thursday, 6 January 2011 13:20:51 UTC