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

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. 

*THIS* hurts accessibility!

We can, however (I believe), set the conditions so that they will
generally do the right thing as part of the "path of least resistance",
which is why I am working on a proposal that makes doing the right thing
easier for authors to do, and more logical in the approach (I hope).

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. 



> 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? What of other embedded
objects? If the answer for <video> is yes, then should not <audio> also be
capable/required to take on a short textual description? <canvas>?
<iframe>? 

If we all believe that these other embedded objects, like <video>,
requires the ability to have textual alternatives, then we should file the
bugs and get this into the queue: either add @alt to the list of Global
Attributes, or modify the other embedded elements to be able to take on
@alt.

If however we generally believe that <video> is different than those other
elements in that it alone should have the ability to take on a short
textual alternative, then we need a means to do so.  I suggest that this
new child element of the <video> 'container' is the more appropriate place
to do so.

(David - As to the general accessibility of videos, I think we've managed
to identify all of the requirements, and have identified the outstanding
issues, but if there is something that you or others think we've missed
please speak up now)


> 
> 2) It's a minor point about where text is.
> 
> Contrast
> <image src="..." alt="this text is in the markup" />
> with
> <image src="...">
>   <alt lang="en-US">this text is body text</alt>
> </image>

An ALT element? That's a new one on me. (Not that I'm opposed to the idea,
but I've not heard/seen of this before).


> 
> The first has user-presented text in markup;  the second has it
> (correctly, I feel) in the body text, where it's amenable to styling,
> language attribution (as in this example), and so on.

A child element of <video> would also be amenable to styling, @lang
attribution, etc.


> 
> I fully support the design principle of providing accessibility (I hope
> this doesn't need saying).

No, it does not David!!

**********

Eric Carlson wrote:
>
> And I have asked *you* numerous times, without getting an
> answer, how an element with the poster attribute is different
> from an element with the "poster image" as the first frame of
> the video file? 

<snip>

> Why should these two cases require different markup? How will
> this lead to a better user experience for anyone?

I think if we move the semantic/conceptual role of the placeholder image
to its own element we can avoid the confusion. The answer is that
<firstfame> need not require @src to be valid:

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

It's simple, it's clean, it's easy to understand, it applies the semantic
to the actual 'item' (i.e. the first frame and *NOT* the video itself),
and it will be very easy to teach (an important consideration). From the
DOM perspective I believe(?) that parsing it is essentially the same as an
attribute of video, whilst now having the ability to add additional
attributes to the role indicator.

JF

Received on Wednesday, 5 January 2011 19:57:44 UTC