Could you give some examples of what such alternative text would look like? I'm having trouble imagining this actually improving accessibility.

For example, what would the right alternative text be for the various poster images on this page be?:

   http://googleblog.blogspot.com/2010/09/125-video-shortlist-announced-today-for.html

(In reply to comment #1)
> Could you give some examples of what such alternative text would look like? I'm
> having trouble imagining this actually improving accessibility.
> 
> For example, what would the right alternative text be for the various poster
> images on this page be?:
> 
>   
> http://googleblog.blogspot.com/2010/09/125-video-shortlist-announced-today-for.html

I actually cannot give suggestions for alternative text for those images, as I am a completely blind screen-reader user.  Hopefully somebody else will be able to suggest appropriate alternative descriptions.

I would suggest, generally, that the same practice be followed for providing alt for poster images as is followed for providing alt for any image.  That is, the content author has explicitly set a poster for the video, for any of a number of reasons.  Perhaps this is set as a company logo, a key frame from the video to entice the visitor to press play, etc.  As a user who cannot perceive the image I would like the author to be able to provide text to be used as an alternative to the poster image, so that the meaning and purpose they are attempting to provide visually may be provided textually to me.

So presumably the title of the video would be sufficient?

If so, surely you'd want this regardless of whether a poster image has been explicitly provided or not, right?

(In reply to comment #3)
> So presumably the title of the video would be sufficient?
> 
> If so, surely you'd want this regardless of whether a poster image has been
> explicitly provided or not, right?

No.  You presume incorrectly.  The title of the video, is different than the alternative text for the post.

Title should always be required

Poster alt should be required whenever a poster has been explicitly set.

Title: 2010 Marathon Coverage
Poster alt: Sally Smith crossing the finish line with her hands upraised.

(In reply to comment #4)
> (In reply to comment #3)
> > So presumably the title of the video would be sufficient?
> > 
> > If so, surely you'd want this regardless of whether a poster image has been
> > explicitly provided or not, right?
> 
> No.  You presume incorrectly.  The title of the video, is different than the
> alternative text for the post.
> 
> Title should always be required
> 
> Poster alt should be required whenever a poster has been explicitly set.
> 
> Title: 2010 Marathon Coverage
> Poster alt: Sally Smith crossing the finish line with her hands upraised.

What if poster isn't explicitly set, but that's what the default poster (either the first frame of the video or set inside the media file) shows the same thing as what you describe in your example?

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > So presumably the title of the video would be sufficient?
> > > 
> > > If so, surely you'd want this regardless of whether a poster image has been
> > > explicitly provided or not, right?
> > 
> > No.  You presume incorrectly.  The title of the video, is different than the
> > alternative text for the post.
> > 
> > Title should always be required
> > 
> > Poster alt should be required whenever a poster has been explicitly set.
> > 
> > Title: 2010 Marathon Coverage
> > Poster alt: Sally Smith crossing the finish line with her hands upraised.
> 
> What if poster isn't explicitly set, but that's what the default poster (either
> the first frame of the video or set inside the media file) shows the same thing
> as what you describe in your example?

You're correct, the poster should have an alt if it is explicit or not.  For a blank screen the alt can be ""

I'm confused. Why would you (a blind user) want to know what the poster frame is? How does it affect you?

(In reply to comment #7)
> I'm confused. Why would you (a blind user) want to know what the poster frame
> is? How does it affect you?

I don't even know how to answer this question. Other than segregating me from the users who can visually perceive the content, which is a civil rights and not a technical issue...

As I explained above, the author is setting a poster.  There is therefor a visual image on the page, it conveys meaning (or at least has the ability to convey meaning), I want the meaning as much as someone who can see the image.

(In reply to comment #7)
> I'm confused. Why would you (a blind user) want to know what the poster frame
> is? How does it affect you?

vision impairment is not binary, people are not either totally without sight or have 20/20 vision, there are may gardiations. a good proportion of people who are categorised as 'legally blind' have some vision, but  rely on a screen reader  for the majority of their interaction with web content, when they see a fuzzy blobs on an image whether it be a video poster frame or on a canvas or an image, the provision of a text alternative may well be useful in helping them make sense of what those blobs are.

Also why wouldn't a blind user want to know?

I give you a very classy example: Casablanca

If you switch off your screen and use NVDA or VoiceOver and navigate to
http://en.wikipedia.org/wiki/Casablanca_(film)

Please go to the first film poster on the wiki and read the ALT attribute. Does it create any image in your head? Does it give you a sense of the flair of the film?

I'm someone who is blind and who goes regularly to the cinema. I take the description of film posters as part of my decision of going into a particular screening. It will be the same for the decision if I want to press play on the <video/> element. But most importantly it's a very important information which puts you into a particular expection mood for a film. Why should someone who is blind be excluded?

(In reply to comment #7)
> I'm confused. Why would you (a blind user) want to know what the poster frame
> is? How does it affect you?

Like Artur explained in comment #10, an image can set the mood or convey meaning to the overall context. Excluding blind users from this information would be discriminating.

Please see HTML5: Techniques for providing useful text alternatives [1] for further information (see also bug #9845).

[1] http://dev.w3.org/html5/alt-techniques/#images-enhance

(In reply to comment #11)
> (In reply to comment #7)
> > I'm confused. Why would you (a blind user) want to know what the poster frame
> > is? How does it affect you?
> Like Artur explained in comment #10, an image can set the mood or convey
> meaning to the overall context. Excluding blind users from this information
> would be discriminating.
> Please see HTML5: Techniques for providing useful text alternatives [1] for
> further information (see also bug #9845).
> [1] http://dev.w3.org/html5/alt-techniques/#images-enhance

Note: currently you MUST NOT add a text alternative to images that may set the mood or convey meaning to the overall context in HTML5 (http://dev.w3.org/html5/spec/embedded-content-1.html#a-purely-decorative-image-that-doesn-t-add-any-information)

> Please see HTML5: Techniques for providing useful text alternatives [1] for
> further information (see also bug #9845).
> [1] http://dev.w3.org/html5/alt-techniques/#images-enhance

Has been raised as an issue by ian and is the subject of a call for change proposals
http://www.w3.org/html/wg/tracker/issues/122

(In reply to comment #10)

Wikipedia page for Casablanca describes official poster of the movie, but poster of a video element isn't the same thing.

For more practical example of a video poster I've found Casablanca trailer on YouTube: http://www.youtube.com/watch?v=28Ud8O3KBSM. This video's poster image is a frame from middle of the video which happens to be man in a bar and text "Paul Henreid".

I don't think this is useful, and description of the video itself (not merely one of its frames) may be better indicator of what video is about and what mood it has.

(In reply to comment #13)
> (In reply to comment #10)
> 
> Wikipedia page for Casablanca describes official poster of the movie, but
> poster of a video element isn't the same thing.
> 
> For more practical example of a video poster I've found Casablanca trailer on
> YouTube: http://www.youtube.com/watch?v=28Ud8O3KBSM. This video's poster image
> is a frame from middle of the video which happens to be man in a bar and text
> "Paul Henreid".
> 
> I don't think this is useful, and description of the video itself (not merely
> one of its frames) may be better indicator of what video is about and what mood
> it has.

Either allowing authors to set a poster is useful, or it is not. If it is at all useful, then this information must be conveyed to those who cannot access the image.

(In reply to comment #4)
> Title: 2010 Marathon Coverage
> Poster alt: Sally Smith crossing the finish line with her hands upraised.

I think this is a clear example of how poster alt would be useful. Note I am not sure what point comment 13 is making; there will always be examples of bad alt text out there.

(In reply to comment #7)
> I'm confused. Why would you (a blind user) want to know what the poster frame
> is? How does it affect you?

Outside of demonstrating a complete lack or empathy or understanding of user needs, is there a technical question here that needs clarification? 

The bug has been clearly defined, the use case has been documented and explained, and we now need to have spec language that addresses the need. Why would the editor need to know how that affects one person? There are millions of non-sighted users in the world today, and each one has different needs, desires, requirements and circumstances.

If a page author is presenting a visual image of any sort on a page, then there is a conscious decision to do so, and in selecting that image: there is a transfer of information happening between the author and the end user. We must ensure that when that transfer happens, we are capable of ensuring that we do so to all users, not just sighted users. We need a mechanism to do this - never mind that it will be abused, misused or ignored by some - it will also be used properly by many others and will benefit those users who require such.

Is there a legitimate technical reason why this cannot be achieved?

Since `poster` might not be provided and the first frame may be displayed, or a poster frame provided by the video container (like M4A), the alternate text for a poster should not be tied to a poster attribute/tag itself. This implies that alt text is only applicable if the poster attribute is used and that isnt the only case.

Suggest just adding alt to <video> itself.

<video src="video.ogg" alt="Roger Bannister completing the 4 minute mile" />

(In reply to comment #15)
> (In reply to comment #4)
> > Title: 2010 Marathon Coverage
> > Poster alt: Sally Smith crossing the finish line with her hands upraised.
> 
> I think this is a clear example of how poster alt would be useful. Note I am
> not sure what point comment 13 is making; there will always be examples of bad
> alt text out there.

My point is that poster frame may not be representative of the video. That's not merely problem of bad alt, but bad poster frames to begin with.

Poster frame is not original content, it is just placeholder for unloaded video. Because in practice poster frames are often automatically selected (e.g. first or middle frame of the video) they are often poor representation of video as a whole.

A poster frame for video of "Sally Smith crossing the finish line" might as well happen to be "A reporter standing with microphone in front of a crowd". 

A use case of "user with no or poor vision wanting to know what video is about and what mood it has" might not be served by poster description as well as by description of the video as a whole.

(In reply to comment #18)
> (In reply to comment #15)
> > (In reply to comment #4)
> > > Title: 2010 Marathon Coverage
> > > Poster alt: Sally Smith crossing the finish line with her hands upraised.
> > 
> > I think this is a clear example of how poster alt would be useful. Note I am
> > not sure what point comment 13 is making; there will always be examples of bad
> > alt text out there.
> My point is that poster frame may not be representative of the video. That's
> not merely problem of bad alt, but bad poster frames to begin with.
> Poster frame is not original content, it is just placeholder for unloaded
> video. Because in practice poster frames are often automatically selected (e.g.
> first or middle frame of the video) they are often poor representation of video
> as a whole.
> A poster frame for video of "Sally Smith crossing the finish line" might as
> well happen to be "A reporter standing with microphone in front of a crowd". 
> A use case of "user with no or poor vision wanting to know what video is about
> and what mood it has" might not be served by poster description as well as by
> description of the video as a whole.

(In reply to comment #18)
> (In reply to comment #15)
> > (In reply to comment #4)
> > > Title: 2010 Marathon Coverage
> > > Poster alt: Sally Smith crossing the finish line with her hands upraised.
> > 
> > I think this is a clear example of how poster alt would be useful. Note I am
> > not sure what point comment 13 is making; there will always be examples of bad
> > alt text out there.
> My point is that poster frame may not be representative of the video. That's
> not merely problem of bad alt, but bad poster frames to begin with.
> Poster frame is not original content, it is just placeholder for unloaded
> video. Because in practice poster frames are often automatically selected (e.g.
> first or middle frame of the video) they are often poor representation of video
> as a whole.
> A poster frame for video of "Sally Smith crossing the finish line" might as
> well happen to be "A reporter standing with microphone in front of a crowd". 
> A use case of "user with no or poor vision wanting to know what video is about
> and what mood it has" might not be served by poster description as well as by
> description of the video as a whole.

There is the more generic use case described below:
vision impairment is not binary, people are not either totally without sight or
have 20/20 vision, there are may gardiations. a good proportion of people who
are categorised as 'legally blind' have some vision, but  rely on a screen
reader  for the majority of their interaction with web content, when they see a
fuzzy blobs on an image whether it be a video poster frame or on a canvas or an
image, the provision of a text alternative may well be useful in helping them
make sense of what those blobs are.

If the poster frame is not purely decorative it should have a text alternative, so whether its a frame from the movie, the movie poster, or an ad for budweiser this information should be provided.

There is a definite technical problem with providing alt text for an automatically chosen poster image as this would, presumably, be chosen by the user agent and so could not be determined when the HTML is created.

However, if a site developer has chosen to add an explicit poster image to a video implies that there is some information/mood which the developer specifically wishes to be conveyed. They must therefore be allowed a method of conveying this same information to all users, including those using screen readers.

This would also be different to the title of the movie as Everett's comment pointed out.

Perhaps in terms of implementing this alt text, a better idea may be to add another attribute to the video element rather than as a child element to the video:

<video poster="poster.jpg" posteralt="Poster alt text">
..
</video>

This would mean that the content within the video element is still purely for user agents which don't understand it, and this would also mean that it is backwards compatible and existing html which is already using the video element would not need updating (and we wouldn't then need user agents to support both the attribute based for older sites and child element based for newer sites).

(In reply to comment #20)

I think it's wrong to assume that explicitly added poster attribute implies poster frame explicitly chosen by the author. Video hosting sites and markup authoring tools may add poster frame automatically (as a performance optimisation). This seems to be standard practice in current Flash players.

BTW: is this discussion appropriate for the bug comments? Perhaps it should be taken to the mailinglist?

I'm at a complete loss as to why a poster frame would need alt text. This isn't a civil rights issue, it's just a matter of pragmatism: the point of a poster frame is just to represent the video, a job that is entirely served by the video's title.

Comment 4, comment 6, and comment 8 all just assert that this is a needed feature, without saying why.

Regarding comment 9, why would a user with a visual impairment not want to know: well, why would they? Heck, why would a user with 20/20 vision want to know what the poster frame is? The poster frame's only job is to look pretty and manipulate the user into starting the video, what it shows is of minimal importance to the user. What matters is what the video shows, not what the poster frame shows. Comment 18 is right on as far as that goes.

As per comment 13, I entirely agree that the mood of the video should be conveyed to users who cannot see the poster frame. But that's not an alternative to the poster frame, it's content that should be available to _all_ users. Providing such mood-setting content to only a subset of the population even though everyone could use it _is_ segregation, if we're going to start talking in those terms.

Comment 17 suggests an alt="" for the whole video, but that misses the point even further: the suggested text is a title, not an alternative for the video! It should be provided in a title="" attribute or a caption for the <video> (e.g. in a <figcaption>).

I would be entirely in agreement with a suggestion that the content of videos should be made clear to all users, using more than just the poster frame. But that's not alternative text.

Note that posters (as per comment 10) are a whole different issue. We're talking specifically about the frame of video that is shown before the video has loaded. I don't understand why it would be any more special than any of the other frames of the video, as far as getting alternative text is concerned.


EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: The rationale provided is that text is needed to help users of ATs determine the topic and mood of the video. However, that information is not (necessarily) provided by the poster frame, and thus cannot be considered an alternative to the poster frame. It is also not an alternative to the video. It is the title or caption of the video, for which we already have a multitude of mechanisms such as title="", <figcaption>, <h1>, and aria-labelledby="".

Where authors are intentionally presenting content as an image the image must have an alternative text representation.  The title of a video is not sufficient to replace the poster image in every scenario.

(In reply to comment #21)
> (In reply to comment #20)
> 
> I think it's wrong to assume that explicitly added poster attribute implies
> poster frame explicitly chosen by the author. Video hosting sites and markup
> authoring tools may add poster frame automatically (as a performance
> optimisation). This seems to be standard practice in current Flash players.
> 
> BTW: is this discussion appropriate for the bug comments? Perhaps it should be
> taken to the mailinglist?

Okay, it's a fair point that many poster frames may be added automatically and so the presence of an explicit poster attribute does not directly imply that it's been chosen by the author. However, that's no reason to not have an ability to supply alternative text for it. That's a bit like saying that images shouldn't have an alt attribute because some images may be server generated.

> Regarding comment 9, why would a user with a visual
> impairment not want to know: well, why would they? 
> Heck, why would a user with 20/20 vision want to
> know what the poster frame is? 

Following this reasoning, why do you allow authors to specify a poster frame in the first place? There is/was clearly a reason to allow authors to provide a poster frame other than the first frame of a video, so for all of the reasons why you allow authors the ability to add a poster frame, there is likely a user who will respond to that reason. By allowing for a specified poster frame, you have provided the author with a tool.

This is not about whether you agree or disagree with an author's choice, it is about ensuring that when an author makes an available authoring choice using tools we provide that there is an accessible means of ensuring that they can be inclusive (which *is* a human rights issue). Nobody needs to 'justify' these author choices, we simply need to ensure they can be done with accessibility in mind - that the mechanism exists to do so.


> The poster frame's only job is to look pretty
> and manipulate the user into starting the video, 

So by your own admission then, that graphical image has a purpose - it is, in your own words, to "manipulate the user into starting the video". Not to allow the user to start the video (that's what the start control does), but to invoke an emotional response so that they are actually "manipulated" into starting the video. Do you believe then that non-sighted users cannot also be "manipulated" to perform an action?


> what it shows is of minimal
> importance to the user. 

If this were true, then why does the author have the ability to specify an image other than the first frame of a video as the "poster frame"? 


> Note that posters (as per comment 10) are a whole different issue. We're
> talking specifically about the frame of video that is shown before the video
> has loaded. I don't understand why it would be any more special than any of the
> other frames of the video, as far as getting alternative text is concerned.


Once a video is started, non-sighted users will rely on descriptive audio (http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Media_Accessibility_Checklist#dv) or descriptive text (http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Media_Accessibility_Checklist#tvd) to further understand the 'imagery' as it changes.

What is unclear to me is why the Editor continues to argue with blind users who are telling him what they need and want. He can apply all the logic he can dream up to justify not supporting this request, but it does not give him the perspective of a blind user.

This is an engineering problem, give us an engineering solution; don't block this because you cannot imagine what it is like to be a blind user, or lack the imagination to understand why this is important.

I guess one can imagine a mixed viewing situation where sighted users and blind users discuss a web page with several videos on it and they discuss the poster frames they see. A blind or vision-impaired user will not be able to participate in such a discussion unless they get a description of what is visible on the images. E.g. "go click on the video with the singing girl". This also applies to the first frame displayed if no explicit poster frame is provided. Since it's either this first frame or the explicitly linked image, covering them both the same way makes sense.

Further, when a site decides to not make use of the provided poster image functionality but overlays an image on the video element because they want explicit control on clicks or something, there will also be a need for a alt attribute.

So, maybe a @posteralt on video would make sense?

(In reply to comment #26)
> This
> also applies to the first frame displayed if no explicit poster frame is
> provided. Since it's either this first frame or the explicitly linked image,
> covering them both the same way makes sense.

The trouble with providing poster alt text when no explicit poster image is given is that we can't be sure that the UA will choose the first frame. It may choose the middle frame, or the first non-blank frame.

If the poster alt text is given but it does not match the UA chosen poster image then this is probably worse than having no alt text at all (although not being an AT user myself I'm happy to be corrected!)

The only way around this, I suppose, would be to specify the exact algorithm for choosing an automatic poster frame, but I'm certain that's a bad idea!

In response to comment #22:

Hi Ian,

You wrote:
"The poster frame's only job is to look pretty and manipulate the user into starting the video, what it shows is of minimal importance to the user."

Do you really want to tell me that pretty looking and manipulative images are of minimal information?
Never heard such a rubbish. That's completely beyond me.

BTW: Your response to my comment #10 is pretty poor. I would appreciate if you try the proposed steps and only continue this thread afterwards. Please let me know which screen reader you used for it.

(In reply to comment #27)
> (In reply to comment #26)
> > This
> > also applies to the first frame displayed if no explicit poster frame is
> > provided. Since it's either this first frame or the explicitly linked image,
> > covering them both the same way makes sense.
> 
> The trouble with providing poster alt text when no explicit poster image is
> given is that we can't be sure that the UA will choose the first frame. It may
> choose the middle frame, or the first non-blank frame.

Maybe in theory. But in practice all browser use the very first frame, because that is the first data downloaded together with the metadata. We might as well specify the use of the first frame for default posters in the spec if there is a loophole for compatibility across browsers.

This seems quite simple to me.  Is it that hard to imagine that there could ever be an instance where a description of the key frame would be useful to a blind user?  I can point to dozens of examples where the alt attribute is not useful or necessary.  Does that mean that alt attributes are never useful?  Certainly not.

Here's a contrived, but plausible example of where such alternative text could be useful:
Say my daughter's school puts up a page of videos from their recent sports fair.  On the page, they have several videos from the various events.  I think my daughter might be in one of them, but I'm not sure which one.  Fortunately, while the titles are appropriate: "500 yard dash", "jump rope marathon", "push-up competition", ETC., they don't provide the information I need.  Fortunately, one of the key frames happens to show my daughter.  If there were appropriate alt text on that key frame, it might say, "Jennifer, Emma, Alejandra, and Nicky jumping rope."  Without that alternative text, this information might otherwise be unavailable to me.

(In reply to comment #30)

> Here's a contrived, but plausible example of where such alternative text could
> be useful:
> Say my daughter's school puts up a page of videos from their recent sports
> fair.  On the page, they have several videos from the various events.  I think
> my daughter might be in one of them, but I'm not sure which one.  Fortunately,
> while the titles are appropriate: "500 yard dash", "jump rope marathon",
> "push-up competition", ETC., they don't provide the information I need. 
> Fortunately, one of the key frames happens to show my daughter.  If there were
> appropriate alt text on that key frame, it might say, "Jennifer, Emma,
> Alejandra, and Nicky jumping rope."  Without that alternative text, this
> information might otherwise be unavailable to me.

That would be useful indeed, but seems like accidental feature. "Jennifer, Emma, Alejandra, and Nicky jumping rope." sounds like good description of the video, and would be useful regardless whether first frame happens to contain all these children, or only one of them, or is completely black.

I'd like to add that this bug is a solution with search for a problem. This isn't the best approach. We should start by enumerating accessibility problems of video and then evaluate which of the possible solutions can solve them best. 

Several problems have been mentioned, and each of them is only sometimes solved if poster frame happens to contain exact thing that is desired (i.e. poster frame may contain any part of the video, but it doesn't mean one can use poster frame description to get information about any part of the video). A direct solution to these problems may be much more useful and reliable.

(In reply to comment #31)
> That would be useful indeed, but seems like accidental feature. "Jennifer,
> Emma, Alejandra, and Nicky jumping rope." sounds like good description of the
> video, and would be useful regardless whether first frame happens to contain
> all these children, or only one of them, or is completely black.

It might make a good description, unless the video consists of dozens of shots of different children.  My daughter just happens to be in the key frame.  Accidental feature?  Yes.  But that hardly matters.  The key frame contains that information, and if I can't see it, and if there is no description of that key frame, I don't have access to that information.

(In reply to comment #31)
> (In reply to comment #30)
> That would be useful indeed, but seems like accidental feature. "Jennifer,
> Emma, Alejandra, and Nicky jumping rope." sounds like good description of the
> video, and would be useful regardless whether first frame happens to contain
> all these children, or only one of them, or is completely black.

However, if the footage may be of the 2008 Flora London Marathon, for example, in which there are thousands of competitors. You may have chosen a poster frame of Liz Yelling crossing the finish line. Would you really want to include the names of all the thousands of competitors in the video title? Probably not.

However, a sighted user may see the poster frame and think "Hey - That's Liz Yelling. I think I might watch this video". A non-sighted user would not be afforded that information which is essentially discriminatory.

(In reply to comment #32)
> I'd like to add that this bug is a solution with search for a problem. This
> isn't the best approach. We should start by enumerating accessibility problems
> of video and then evaluate which of the possible solutions can solve them best. 

This.  This feels to me like "tacked-on" accessibility, when really what we need is to re-evaluate the accessibility of the <video> element from the ground up.

As for the jump-rope example in comment #30, devil's advocate here... If the webmasters of that particular school chose a key frame from a different part of the video to use as the poster (a key-frame which did not contain an image of your daughter), then you would be just as lost *with* an alternative text attribute as without.

Regardless, the poster is "content", and content must be equipped with channels to describe it to users who are not capable of viewing the original.  However, the addition of a new element (eg. <poster>) is always going to be resisted by the Editors, at least initially, because of the danger of syntax creep and the need to provide new documentation for each which will inevitably delay the recommendation of HTML5 even longer.

I've read the specification page, but I'm still not sure how fallback works for the <video> element wrt flow content (like <object>?), but if you are moving the poster attribute into a child element of the <video> element, would it not make sense to use <img> rather than a newly named element?  <img> already requires the alt attribute, and no new documentation (or at least not much) would be needed.

Again, the way fallback flow content display works for <video> would be a factor.  Just thought I'd suggest a possible solution that does not require as much "work" for the Editors. ;)

I think a better example for use of alternative text for the poster would be if the poster is an image that isn't contained in the video at all.  For instance, if it's a title card for a video series.

In such a case the title of the video might be: "Law of Gravitation"

The poster image for such a video may contain actual textual information that is displayed before the video is played, especially helpful if the video is to be embedded on a remote site where the surrounding content is not enough context to describe the video further.

In this case, the alternative text attribute for the poster would be essential and may contain such text as: "Feynman Lecture Series - Cornell University (1964)"  This is valuable information which, if only visible on the title-card, would be unavailable to visually impaired users.

(In reply to comment #35)
> (In reply to comment #32)

> As for the jump-rope example in comment #30, devil's advocate here... If the
> webmasters of that particular school chose a key frame from a different part of
> the video to use as the poster (a key-frame which did not contain an image of
> your daughter), then you would be just as lost *with* an alternative text
> attribute as without.

Yes, but a sighted user would be just as lost. At least if there is alt text available then a non-sighted user has the same chance of not being lost as a sighted user (if you see what I'm saying - probably not explaining it very well!)

> Regardless, the poster is "content", and content must be equipped with channels
> to describe it to users who are not capable of viewing the original.  However,
> the addition of a new element (eg. <poster>) is always going to be resisted by
> the Editors, at least initially, because of the danger of syntax creep and the
> need to provide new documentation for each which will inevitably delay the
> recommendation of HTML5 even longer.

Agreed - hence in Comment #20 I suggest accomplishing this by adding a posteralt attribute to the video element. Much simpler and has the advantage of being backwards compatible with the existing spec and UA implementations. Everyone's a winner! :)

We have found several cases were an ALT-text for the poster frame would be of use for visual impaired users to gain an equivalent access to the video. I think this is clear after the exchange of arguments on this bug ticket.

With Ian's words, we now have to find a semantic way to express in words the pretty looking and manipulative poster frame.

What are the suggestions on the table at the moment?

I wonder if this is a confused proposal.  The poster frame is an alternative to the video, before it's playing/loaded.  Surely we should have
a) short alternative text for the audio/video
b) a link to a transcript
c) a link to a long description

of the multimedia itself, not the proxy for it?

(In reply to comment #39)
> I wonder if this is a confused proposal.  The poster frame is an alternative to
> the video, before it's playing/loaded.  Surely we should have
> a) short alternative text for the audio/video

IMO, whether you call it a "short alternative text for the audio/video" or a "poster alt" is just a matter of perspective. We can look at the poster image as some kind of "visul short text". (Btw, indeed, sometimes the poster contains text ...)

> b) a link to a transcript
> c) a link to a long description

+1

> of the multimedia itself, not the proxy for it?

Would it not be most meaningful if the short alternative text has the same message as the poster? Perhaps, sometimes it tell more than the poster tells - perhaps even something other than what the poster tells, but it seems logical that they are related.

Also, sometimes a poster plays a double role: a img role and a poster role.

(In reply to comment #29)
> (In reply to comment #27)
> > (In reply to comment #26)
> > > This
> > > also applies to the first frame displayed if no explicit poster frame is
> > > provided. Since it's either this first frame or the explicitly linked image,
> > > covering them both the same way makes sense.
> > 
> > The trouble with providing poster alt text when no explicit poster image is
> > given is that we can't be sure that the UA will choose the first frame. It may
> > choose the middle frame, or the first non-blank frame.
> 
> Maybe in theory. But in practice all browser use the very first frame, because
> that is the first data downloaded together with the metadata. We might as well
> specify the use of the first frame for default posters in the spec if there is
> a loophole for compatibility across browsers.

It's not necessarily the first frame - some media formats allow an explicit choice of poster frame to be embedded in the media container itself. However, I do believe that in practice it is ubambiguous what the poster frame will be and this is unlikely to vary among implementations.

(In reply to comment #39)
> I wonder if this is a confused proposal.  The poster frame is an alternative to
> the video, before it's playing/loaded.  Surely we should have
> a) short alternative text for the audio/video
> b) a link to a transcript
> c) a link to a long description
> 
> of the multimedia itself, not the proxy for it?

"The poster  attribute gives the address of an image file that the user agent can show while no video data is available.

Note: The image given by the poster attribute, the poster frame, is intended to be a representative frame of the video (typically one of the first non-blank frames) that gives the user an idea of what the video is like."
- http://dev.w3.org/html5/spec/Overview.html#attr-video-poster

We have 2 problems: If I cannot see the 'image' that the poster frame displays, how do I know "what the video is like"?

While the spec suggests that @poster is 'intended' to be a representative frame of the movie, it is not however forbidden that the image in question can in fact be *any* image, and the fact that authors can specify *any* image leaves open the door that not only can they, they likely will.  For this reason we must ensure that when they do so, they can so so in an accessible fashion.

If the poster frame is the first frame of a movie, then likely the short alternative text for the audio/video is sufficient, however if the replacement image is not a frame of the video than alternative text that tells non-sighted users what the image conveys is required.

I think that enough use-cases have been brought forward to show where there is a need, thus the only question remains: how do we achieve this? More than one person has championed a new attribute: @posteralt

* Is there a technical reason why we cannot have this attribute in HTML5? 
* A philosophical reason that trumps the accessibility requirement? 
* Are there any other alternative proposals?

(In reply to comment #42)
> (In reply to comment #39)
> > I wonder if this is a confused proposal.  The poster frame is an alternative to
> > the video, before it's playing/loaded.  Surely we should have
> > a) short alternative text for the audio/video
> > b) a link to a transcript
> > c) a link to a long description
> > 
> > of the multimedia itself, not the proxy for it?
> 
> "The poster  attribute gives the address of an image file that the user agent
> can show while no video data is available.
> 
> Note: The image given by the poster attribute, the poster frame, is intended to
> be a representative frame of the video (typically one of the first non-blank
> frames) that gives the user an idea of what the video is like."
> - http://dev.w3.org/html5/spec/Overview.html#attr-video-poster
> 
> We have 2 problems: If I cannot see the 'image' that the poster frame displays,
> how do I know "what the video is like"?
> 
> While the spec suggests that @poster is 'intended' to be a representative frame
> of the movie, it is not however forbidden that the image in question can in
> fact be *any* image, and the fact that authors can specify *any* image leaves
> open the door that not only can they, they likely will.  For this reason we
> must ensure that when they do so, they can so so in an accessible fashion.
> 
> If the poster frame is the first frame of a movie, then likely the short
> alternative text for the audio/video is sufficient, however if the replacement
> image is not a frame of the video than alternative text that tells non-sighted
> users what the image conveys is required.
> 
> I think that enough use-cases have been brought forward to show where there is
> a need, thus the only question remains: how do we achieve this? More than one
> person has championed a new attribute: @posteralt
> 
> * Is there a technical reason why we cannot have this attribute in HTML5? 
> * A philosophical reason that trumps the accessibility requirement? 
> * Are there any other alternative proposals?

My opinion after reading the discussion here is:

a) There may be circumstances where a text equivalent for the poster frame is useful (in particular in cases where the poster frame does not actually appear in the video, which is a valid use case; or in cases where it was very carefully selected).

b) There are circumstances where it is not useful to provide a text equivalent for the poster frame, because it would not add useful information on top of describing the video itself; often the poster frame is effectively a mostly-decorative placeholder.

c) There are also circumstances where it is not practical to provide one (e.g. in automatically chosen cases).

So it seems like it may be useful to have a way to provide a text equivalent for the poster frame, but not make it mandatory.

If such a mechanism were to be added, it would be better to use an element instead of an attribute, so that the text equivalent can use semantic markup and is not limited to plain text.

(Chair hat off for the above comments, in case it needs mentioning.)

I think Maciej is right, but I wonder how common it will be for the description of the multimedia (audio/video) to be significantly different from the description of the poster.  I guess it's possible that the poster conveys *additional* information over and above what the movie contains, but I would have thought this was an unlikely case, and perhaps even one that we don't need to encourage.

I guess I am more keen on descriptive and transcriptive text for the movie, and once we have that cleanly done, then ask the question "do we need it *as well* for the poster?"

(In reply to comment #44)
> I think Maciej is right, but I wonder how common it will be for the description
> of the multimedia (audio/video) to be significantly different from the
> description of the poster.  I guess it's possible that the poster conveys
> *additional* information over and above what the movie contains, but I would
> have thought this was an unlikely case, and perhaps even one that we don't need
> to encourage.

By not providing an alt attribute for the poster we are not discouraging its use for any purpose, we are only making it more difficult for authors to provide accessible alternatives for the way in which they use poster.


> 
> I guess I am more keen on descriptive and transcriptive text for the movie, and
> once we have that cleanly done, then ask the question "do we need it *as well*
> for the poster?"

I don't see why we would ask if we need to make the poster accessible "as well" as the video.  As far as I see it the poster and video are two distinct pieces of content, in the same way that the cover of a DVD case is not the video within, the poster is not the video.  Is it true that often, perhaps in most cases, that the poster will be a frame, likely the first frame, of the video, yes.  Does this mean that it is not important for authors to be able to provide an alternate textual equivalency for the poster, no.

(In reply to comment #44)
> I think Maciej is right, but I wonder how common it will be for the description
> of the multimedia (audio/video) to be significantly different from the
> description of the poster. 

I'd actually flip that question around, and ask how common will it be for the alternative text for the poster to be significantly different than the description of the video? If the value is greater than null (which I think we all can agree it is/will be), then we owe it to ensure that a means to do so exists. 

> I guess it's possible that the poster conveys
> *additional* information over and above what the movie contains, but I would
> have thought this was an unlikely case, and perhaps even one that we don't need
> to encourage.

The fact that the author can specify an image other than the first key-frame of the media opens up the likelihood that authors will do so. We can actively discourage them from doing so if we believe that to be right, but I wonder aloud if that is indeed a correct stance? The Draft Spec introduces @poster for a reason, and further allows authors to choose any image (again for a reason), so unless we either remove @poster from the Spec outright, no amount of discouragement alone will totally succeed in ensuring the non-existence of images as the poster frame that will require alternative text. 

> I guess I am more keen on descriptive and transcriptive text for the movie, and
> once we have that cleanly done, then ask the question "do we need it *as well*
> for the poster?"

At issue is that the image is not the movie, and the movie is not the image: one might replace the other based upon user-choice (pressing play) or not (don't press play) and, as has been previously discussed, the poster need not even be a frame taken from the movie, it can be *any* image the author chooses to insert. So to answer the question, yes we *do* need both, and I'd prefer that we not make finding the solution for one problem conditional on solving a different problem first.

(In reply to comment #43)

> If such a mechanism were to be added, it would be better to use an element
> instead of an attribute, so that the text equivalent can use semantic markup
> and is not limited to plain text.

@Maciej, where would you place the element you have in mind? Inside or outside <video/>?  

Note that Everett's proposal *is* to use an element:

  <poster src=" URI " alt="Alternative description of poster image." />

An advantage to this solution: if the image is unavailable, then the @alt text could serve as fallback. While it would be nice to allow semantic markup (and if you have a good solution, then I am all for it), it is allready accepted to use @alt for image alternative text.

@John: I think there could be a technical advantage to reusing @alt. 
@Ian: Clearly, <video alt="Foo."> could be contrieved, but <poster alt="Foo."/> shouldn't be.
   
W.r.t. inside/outside <videeo>:  in bug 10938, I propose an "accessibility stocking" - an inline element (intitially suggested to be called <textual>) that can be wrapped around embedding elements: Any textual content inside <textual> will serve as short alternative text for the video. A <poster/> element could also be placed inside <textual> as well:

<textual>
   <poster src=photo.jpg
                 alt="Photo of Putin having caught a Siberian tiger">
    Video footage shot to demo how Russia protects their endagered tigers.
    <video src="vid"></video>
</textual>

(<textual> could also be placed inside <video>, I guess. However, <video> is designed to not reveal its content unless the codec isn't working or the the video resource is unavalailable. Btw, <textual> is also intended to solve the link-to-transcript problem and link-to-long-description problem.)

Removing TrackerRequest as the current state is REOPENED

(In reply to comment #44)
> I think Maciej is right, but I wonder how common it will be for the description
> of the multimedia (audio/video) to be significantly different from the
> description of the poster.  I guess it's possible that the poster conveys
> *additional* information over and above what the movie contains, but I would
> have thought this was an unlikely case, and perhaps even one that we don't need
> to encourage.

For people with sight, the poster always provides extra information about the video, because it provides insight into a particular shot of the video. If an author goes to the effort of providing a separate image as a poster, they should be able to provide a short description of that image for accessibility needs, too.

I would, however, think that introduction of a new element inside the video element is overkill. I was simply thinking of the following as being sufficient:

<video src="video.ogv" poster="image.png" posteralt="Ian Hickson - editor of HTML5 spec" title="a video about HTML5" controls>
</video>

 
> I guess I am more keen on descriptive and transcriptive text for the movie, and
> once we have that cleanly done, then ask the question "do we need it *as well*
> for the poster?"

The descriptive and transcriptive texts are very important, but they are for after you have made the decision to consume the video. The alt texts are input into making the decision to view the video, just like the poster is for people with sight.

(In reply to comment #49)
> (In reply to comment #44)

> I would, however, think that introduction of a new element inside the video
> element is overkill. I was simply thinking of the following as being
> sufficient:
> 
> <video src="video.ogv" poster="image.png" posteralt="Ian Hickson - editor of
> HTML5 spec" title="a video about HTML5" controls>
> </video>

> The descriptive and transcriptive texts are very important, but they are for
> after you have made the decision to consume the video. The alt texts are input
> into making the decision to view the video, just like the poster is for people
> with sight.

Instead of a new @posteralt, how about simply @alt?

<video src="video.ogv" poster="image.png" alt="Ian Hickson - editor of
 HTML5 spec" title="a video about HTML5" controls>
</video>

Video@alt would not need to be direcly linked to the poster, specificly - it should play the same role: be a text whichs offers intput into making the decision to view the video.

To reuse @alt would proably make it simpler to implement in existing user agents.

(In reply to comment #50)
> (In reply to comment #49)
> > (In reply to comment #44)
> 
> > I would, however, think that introduction of a new element inside the video
> > element is overkill. I was simply thinking of the following as being
> > sufficient:
> > 
> > <video src="video.ogv" poster="image.png" posteralt="Ian Hickson - editor of
> > HTML5 spec" title="a video about HTML5" controls>
> > </video>
> 
> > The descriptive and transcriptive texts are very important, but they are for
> > after you have made the decision to consume the video. The alt texts are input
> > into making the decision to view the video, just like the poster is for people
> > with sight.
> 
> Instead of a new @posteralt, how about simply @alt?
> 
> <video src="video.ogv" poster="image.png" alt="Ian Hickson - editor of
>  HTML5 spec" title="a video about HTML5" controls>
> </video>
> 
> Video@alt would not need to be direcly linked to the poster, specificly - it
> should play the same role: be a text whichs offers intput into making the
> decision to view the video.
> 
> To reuse @alt would proably make it simpler to implement in existing user
> agents.

That would indicate that @alt is an alternative text for the video element, which it's not - the @title fulfills that role, IIUC. What I wanted to point out is that there is a need for both, an alternative short text for the video element and another one for the image. If @alt and @title satisfy that, fine. But I think it may confuse authors as to the role that @alt plays, since in other elements is the alternative text for the element, not for an attribute therein.

(In reply to comment #51)

> > To reuse @alt

> That would indicate that @alt is an alternative text for the video element,

HTML5 decides what @alt on <video> means.  @alt would anyhow only be a short alternative text - if the video or audio indeas is very short (perhaps it only demos how pronounce a hard German word, for instance), then @alt could be enought, I guess.

Understanding @alt as a practical "textual substitute"( see Vlad Alexander [1]) rather than a full textual description, would in my view be helpful also for <video>.
[1] http://rebuildingtheweb.com/en/offer-to-save-longdesc/

@alt, by the way, has a strong connection to images: in <img alt=*>, <area alt=*>, <input type="image" alt=*> it is connected to images, in some form. So I am not as pessimitic that authors will "jump to conclusions" about what @alt means. (The only place in HTML4 were it is not linked to images is for the <applet> element.)

> which it's not - the @title fulfills that role, IIUC.

Question:  If the @src of <video> is bogus, or if the @poster attribute is bogus,  or if the user agent is textual, then how would suggest that the element should be represented? 

To me it seems logical if @alt then would display.  @title never displays unless you activate it somehow. Besides, it doesn't make sense to me to give @title any different semantics for <video> than it has for <img> - for <img>, then it offers additional information, perhap it contains copyright or creator info and so on.

> What I wanted to point
> out is that there is a need for both, an alternative short text for the video
> element and another one for the image. If @alt and @title satisfy that, fine.
> But I think it may confuse authors as to the role that @alt plays, since in
> other elements is the alternative text for the element, not for an attribute
> therein.


I think what is needed is this: @poster as well as @alt should be defined the same way. As you put it "The alt texts are input  into making the decision to view the video, just like the poster is for people  with sight." 

Unless you meant to suggest that @alt should contain a "textual substitute" for the very content of the video itself, then thtere is at leaste no technical problem, right. I agreee that @title eventually could contain info about the video itself. 

As I see it, the link between @alt and poster image should not be too stron, just as the link between the @alt in <area> and its image map image is also not "too strong": it is the practical issues that matter. E.g. the @alt in an <area> does not describe in detail the part of the image that it is connected to - it usually consentrates on describing the link which <area> contains.

The author must decide: would a direct description of the image frame that @poster contains be the best way to attract attention to the movie? Or would some other description do it better? Often videos can be used in place of images, e.g. in news articles - the poster will serve an illustrative role in itself. In those case I think it would make sense to let the @alt contain a description of the image - especially if the scene is telling.

PS: If "textual substitute" is equal to an "in your face" textual replacment (unlike @title, which is optional), and if you are interested in in having one textual substitute representation for the "video itself", as well as another textual substitute representation for the "poster image itself", then  I don't think it would be overkill to use an <img> elment for poster. (But if we don't need more than one textual substitute representation of the video, then I think @alt is perfect.)

(In reply to comment #52)
> (In reply to comment #51)
> 
> > > To reuse @alt
> 
> > That would indicate that @alt is an alternative text for the video element,
> 
> HTML5 decides what @alt on <video> means.  @alt would anyhow only be a short
> alternative text - if the video or audio indeas is very short (perhaps it only
> demos how pronounce a hard German word, for instance), then @alt could be
> enought, I guess.
> 
> Understanding @alt as a practical "textual substitute"( see Vlad Alexander [1])
> rather than a full textual description, would in my view be helpful also for
> <video>.
> [1] http://rebuildingtheweb.com/en/offer-to-save-longdesc/
> 
> @alt, by the way, has a strong connection to images: in <img alt=*>, <area
> alt=*>, <input type="image" alt=*> it is connected to images, in some form. So
> I am not as pessimitic that authors will "jump to conclusions" about what @alt
> means. (The only place in HTML4 were it is not linked to images is for the
> <applet> element.)
> 
> > which it's not - the @title fulfills that role, IIUC.
> 
> Question:  If the @src of <video> is bogus, or if the @poster attribute is
> bogus,  or if the user agent is textual, then how would suggest that the
> element should be represented? 
> 
> To me it seems logical if @alt then would display.  @title never displays
> unless you activate it somehow. Besides, it doesn't make sense to me to give
> @title any different semantics for <video> than it has for <img> - for <img>,
> then it offers additional information, perhap it contains copyright or creator
> info and so on.
> 
> > What I wanted to point
> > out is that there is a need for both, an alternative short text for the video
> > element and another one for the image. If @alt and @title satisfy that, fine.
> > But I think it may confuse authors as to the role that @alt plays, since in
> > other elements is the alternative text for the element, not for an attribute
> > therein.
> 
> 
> I think what is needed is this: @poster as well as @alt should be defined the
> same way. As you put it "The alt texts are input  into making the decision to
> view the video, just like the poster is for people  with sight." 
> 
> Unless you meant to suggest that @alt should contain a "textual substitute" for
> the very content of the video itself, then thtere is at leaste no technical
> problem, right. I agreee that @title eventually could contain info about the
> video itself. 
> 
> As I see it, the link between @alt and poster image should not be too stron,
> just as the link between the @alt in <area> and its image map image is also not
> "too strong": it is the practical issues that matter. E.g. the @alt in an
> <area> does not describe in detail the part of the image that it is connected
> to - it usually consentrates on describing the link which <area> contains.
> 
> The author must decide: would a direct description of the image frame that
> @poster contains be the best way to attract attention to the movie? Or would
> some other description do it better? Often videos can be used in place of
> images, e.g. in news articles - the poster will serve an illustrative role in
> itself. In those case I think it would make sense to let the @alt contain a
> description of the image - especially if the scene is telling.
> 
> PS: If "textual substitute" is equal to an "in your face" textual replacment
> (unlike @title, which is optional), and if you are interested in in having one
> textual substitute representation for the "video itself", as well as another
> textual substitute representation for the "poster image itself", then  I don't
> think it would be overkill to use an <img> elment for poster. (But if we don't
> need more than one textual substitute representation of the video, then I think
> @alt is perfect.)

I may have used @title for the wrong purpose. @aria-label would probably have been a better use to provide alt text for the video element. Or if we want to introduce @alt for the alt text for the element, that's fine, too and consistent with what it means in other elements.

I just wouldn't want to use @alt to mean the alt text for the poster, because that would confuse people.

Also I don't see a need to introduce an <img> element, since that comes with other features such as img maps and stuff which we really don't need in the video poster.

Thus, @posteralt seems to make the most sense. It has to be in parallel to whatever alt text we have for video and tightly linked to the poster itself, because that's the only thing that it describes.

So, probably this is better:

<video src="video.ogv" poster="image.png" alt="Ian Hickson - editor of
 HTML5 spec" aria-label="a video about HTML5" controls>
</video>

(In reply to comment #53)

   [ snip ]
> I just wouldn't want to use @alt to mean the alt text for the poster, because
> that would confuse people.
   [ snip ]
> Thus, @posteralt seems to make the most sense.
   [ snip]
> So, probably this is better:
> 
> <video src="video.ogv" poster="image.png" alt="Ian Hickson - editor of
>  HTML5 spec" aria-label="a video about HTML5" controls>
> </video>

Indeed. :-)  Because here you used @alt, and not @posteralt. Please note a problem, though, in your code: ARIA enabled AT will not discern the @alt from the @aria-label, it is all smashed into one string, from the user's point oview. I therefore think @title could be just fine - in that example.

We disagree about how problematic @alt eventually would be - I belive close to zero problems w.r.t. understanding its correctly. (Defining it properly, might be more difficult, though ...) 

I agree that @posteralt makes some sense - when I look at it and read its name. However, it would be interesting to hear from UA and AT vendors as well as ARIA experts if it would not be an advantage to reuse @alt. At the very least I discovered, when did some heavy ARIA testing the last month, that @alt is supported - it doesn't matter which element you place it on, ARIA enabled ATs will pick it up. "It just works."

> It has to be in parallel to
> whatever alt text we have for video and tightly linked to the poster itself,
> because that's the only thing that it describes.

Please note that @alt, when used on <img>, has a variety of meanings. I think, likewise, one must pick what @alt for <video> means in the context. What, for instance, if the frame of the video simply contains some info about the film, or its title? If the title of the video has already been mentioned in the preceding element, then why repeat it inside @alt?  But if the video poster is an essential part of the content of the page/article/section, then @alt should indeed describe the image.

AFAICT, title="" isn't necessarily the title (as in "Casablanca") of the video, so it could also be appropriate. If there's some reason it isn't, then reusing alt="" would be the most straightforward. It would represent the initial state of the video, whether that be the first frame of video or the poster image.

(In reply to comment #53)
>
> So, probably this is better:
> 
> <video src="video.ogv" poster="image.png" alt="Ian Hickson - editor of
>  HTML5 spec" aria-label="a video about HTML5" controls>
> </video>

Sorry for the typo, I meant:

<video src="video.ogv" poster="image.png" posteralt="Ian Hickson - editor of HTML5 spec" aria-label="a video about HTML5" controls>
</video>

or alternatively

<video src="video.ogv" poster="image.png" posteralt="Ian Hickson - editor of HTML5 spec" alt="a video about HTML5" controls>
</video>

Use of @alt for an alternative short description of the video is common for other elements, so we shouldn't break that here.

I've also briefly spoken with a blind person who is doing development on screen readers and they thought it reasonable to have two alt texts, one for the video and one for the poster, since they provide potentially differing information (if the poster is available). But it was accepted as a pedantic difference and unsure if it would be worth the effort.

Maybe it would be possible to encourage users to explain the poster content in the @alt attribute, too, e.g.

<video src="video.ogv" poster="image.png" alt="a video about HTML5, poster showing Ian Hickson - editor of HTML5 spec" controls>
</video>

We do, however, need to agree on what the attribute is for alternative short description for video - is it @alt or is it @aria-label - or something completely different?

(In reply to comment #56)

> Maybe it would be possible to encourage users to explain the poster content in
> the @alt attribute, too, e.g.
> 
> <video src="video.ogv" poster="image.png" alt="a video about HTML5, poster
> showing Ian Hickson - editor of HTML5 spec" controls>
> </video>
> 

"poster" or "poster frame" is a term of art in this context. Typical users won't know what it means. It should not go in text that will be presented to end users.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: The request here is just cargo-cult accessibility and would not actually improve the life of any users, while costing authors in wasted time and effort.

(In reply to comment #58)
> EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
> satisfied with this response, please change the state of this bug to CLOSED. If
> you have additional information and would like the editor to reconsider, please
> reopen this bug. If you would like to escalate the issue to the full HTML
> Working Group, please add the TrackerRequest keyword to this bug, and suggest
> title and text for the tracker issue; or you may create a tracker issue
> yourself, if you are able to do so. For more details, see this document:
>    http://dev.w3.org/html5/decision-policy/decision-policy.html
> 
> Status: Rejected
> Change Description: no spec change
> Rationale: The request here is just cargo-cult accessibility and would not
> actually improve the life of any users, while costing authors in wasted time
> and effort.

Cargo-cult accessibility?

(In reply to comment #59)
> Cargo-cult accessibility?

First citation by Ian:
> "people said headers/id were a good way to do accessibility, and so that was 
> emulated, without understanding what was being done."

http://lists.w3.org/Archives/Public/www-html/2007May/0520.html

Applied to programming:
http://en.wikipedia.org/wiki/Cargo_cult_programming

The upshot is that Ian appears to be saying that the visual information presented in a keyframe couldn't possibly have semantic value to someone who cannot see it, and as a result, those foolish enough to suggest such a thing are fundamentally no more advanced than bush people. 

Which leaves one to wonder why an image presented via <img> or <input type="image"> should accept fallback content, but not an image that iconifies a video. I suspect the answer to this would be because Ian feels @alt is also "cargo-cult accessibility," in which case we should just fast-forward to the long, worthless process of escalation leading to a WG decision, followed by another fork between the W3C and WHATWG versions of HTML5, rather than re-litigate one of the most basic requirements for accessibility of web content.

(In reply to comment #58)
> EDITOR'S RESPONSE: 
> 
> Status: Rejected
> Change Description: no spec change
> Rationale: The request here is just cargo-cult accessibility and would not
> actually improve the life of any users, while costing authors in wasted time
> and effort.

Geez, given that this bug was FILED BY A BLIND PERSON (who outta know what they need/want) I am hard pressed to understand how the Editor has come to this stroke of reasoned genius. What ever happened to Users over Authors over Implementers over Theoretical Purity? 

Once again the editor walks away from issues he clearly has no understanding of by implying that he is MegaBrain and how dare we question his judgment. (He is apparently also now SuperDad, and will watch over his kids 24 hours a day - 365 days a year, but I digress...)

No matter, this bug is now tagged with the TrackerRequest keyword, which means that it should be in the Issue Tracker.  A quick check (http://www.w3.org/html/wg/tracker/issues) suggests that this may not be the case, and I respectfully request that the Chairs advise whether this will be escalated to an actual Issue (which requires calls for Change Proposals, etc.) as clearly the editor has no idea what is being asked for, or why - or he simply doesn't care.

I really believe there is a simple solution to this.

All that would be required is an extra sentence to encourage users to explain the poster content as part of the alternative text of the video element.

This can be come a WAI recommendation, too.

Raised as an Issue http://www.w3.org/html/wg/tracker/issues/142

> (In reply to comment #58)
> Cargo-cult accessibility?

April 2007 alt as a "cargo cult talisman" by Maciej:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/010837.html

(In reply to comment #62)
> I really believe there is a simple solution to this.
> 
> All that would be required is an extra sentence to encourage users to explain
> the poster content as part of the alternative text of the video element.

I agree.  Can we look at (a) alternative text (b) (shudder) long description and (c) connection to a transcript, for time-based resources, and only then ask if the poster needs special support?  As I said, the poster is basically there to be a proxy for the media resource, and I am not enthusiastic about the need for alternatives for proxies for resources (and not hopeful that they will be understood and used well).

Agree with David; IMO the poster is only an interstitial element at best. Accessibility for the video element is best done through subtitling, linked transcripts, etc.

In response to comment #58:

Hi Ian,

At least two blind persons (including me) commented on this ticket and argued for the need of an alternate text for the poster image and how it would improve their lives.

I don't think that your sarcastic reasoning "cargo-cult accessibility" has any grounds.

You didn't respond on my question why "pretty looking and manipulative images" should be hidden for blind or visually impaired users.

Believe or not, blind users care about images:
http://www.flickr.com/groups/blind_photographers/pool/

It's sad that such a simple issue needs to be escalated to the full HTML Working Group despite having several suggestions how to accommodate the request.

(In reply to comment #66)
> Agree with David; IMO the poster is only an interstitial element at best.
> Accessibility for the video element is best done through subtitling, linked
> transcripts, etc.

Sorry Frank, but must disagree.

Given the fact that the author can specify *any* image as a poster frame image, it becomes content in-and-of-itself: there is no mandate or technical means to ensure that the image used is a frame from the video, or that it even directly relates to the video. 

It may be *presumed* that this would be the normal way that authors would use a poster frame image (http://www.w3.org/Bugs/Public/show_bug.cgi?id=10642#c22), but there is no practical or programmatic means of ensuring this: consider a Film Festival site, where each film's "poster" would be a branding exercise for the Festival and have nothing to do with the film itself - the image might even include (yech) text... the point is, we have no idea *what* kind of image will be used here, and further have no way of 'policing' how a poster image will be used.

As such, the image used as the poster frame requires a means of directly linking the 'alternative text' for that image to the image.

Silvia Pfeiffer suggested:
> All that would be required is an extra sentence to encourage users to
> explain the poster content as part of the alternative text of the video
> element. (http://www.w3.org/Bugs/Public/show_bug.cgi?id=10642#c62)

Once again, this presumes that the image is directly related to the video, a presumption we should not be making.

(In reply to comment #68)
> (In reply to comment #66)
> > Agree with David; IMO the poster is only an interstitial element at best.
> > Accessibility for the video element is best done through subtitling, linked
> > transcripts, etc.
> 
> Sorry Frank, but must disagree.
> 
> Given the fact that the author can specify *any* image as a poster frame image,
> it becomes content in-and-of-itself: there is no mandate or technical means to
> ensure that the image used is a frame from the video, or that it even directly
> relates to the video. 
> 
> It may be *presumed* that this would be the normal way that authors would use a
> poster frame image (http://www.w3.org/Bugs/Public/show_bug.cgi?id=10642#c22),
> but there is no practical or programmatic means of ensuring this: consider a
> Film Festival site, where each film's "poster" would be a branding exercise for
> the Festival and have nothing to do with the film itself - the image might even
> include (yech) text... the point is, we have no idea *what* kind of image will
> be used here, and further have no way of 'policing' how a poster image will be
> used.
> 
> As such, the image used as the poster frame requires a means of directly
> linking the 'alternative text' for that image to the image.
> 
> Silvia Pfeiffer suggested:
> > All that would be required is an extra sentence to encourage users to
> > explain the poster content as part of the alternative text of the video
> > element. (http://www.w3.org/Bugs/Public/show_bug.cgi?id=10642#c62)
> 
> Once again, this presumes that the image is directly related to the video, a
> presumption we should not be making.


It is specified through a @src attribute on a <video> element and shown as a replacement for the video before the video starts playing back. I think your assumption that it may have nothing to do with the video only holds true when that image is not used in the @src attribute, but otherwise it has a very strong link to it. Even in your example: once the user clicks on the play button, the image is removed and replaced by the video and therefore they are strongly linked to each other.

However, my argument is not that we do not need a text alternative for the poster. I do argue that we need that. But I also argue that when we have a text replacement for the video, we can include the text replacement for the poster in that piece of text - it does not have to be separate.

So, as an example: an alternative text for film festival videos may be:
"Video poster shows .....blah. Video is about .... blah."

(In reply to comment #69)
> 
> However, my argument is not that we do not need a text alternative for the
> poster. I do argue that we need that. But I also argue that when we have a text
> replacement for the video, we can include the text replacement for the poster
> in that piece of text - it does not have to be separate.
> 
> So, as an example: an alternative text for film festival videos may be:
> "Video poster shows .....blah. Video is about .... blah."

If the poster alt text is not separate it will be much harder to detect programmatically. So tools like a validator / a11y checker / similar cant help authors by checking for video elements that have a poster image but is missing alt text for the poster image. Like when the author forgot to add one.

(In reply to comment #69)
> (In reply to comment #68)
> > (In reply to comment #66)
> > > Agree with David; IMO the poster is only an interstitial element at best.
> > > Accessibility for the video element is best done through subtitling, linked
> > > transcripts, etc.
> > 
> > Sorry Frank, but must disagree.
> > 
> > Given the fact that the author can specify *any* image as a poster frame image,
> > it becomes content in-and-of-itself: there is no mandate or technical means to
> > ensure that the image used is a frame from the video, or that it even directly
> > relates to the video. 
> > 
> > It may be *presumed* that this would be the normal way that authors would use a
> > poster frame image (http://www.w3.org/Bugs/Public/show_bug.cgi?id=10642#c22),
> > but there is no practical or programmatic means of ensuring this: consider a
> > Film Festival site, where each film's "poster" would be a branding exercise for
> > the Festival and have nothing to do with the film itself - the image might even
> > include (yech) text... the point is, we have no idea *what* kind of image will
> > be used here, and further have no way of 'policing' how a poster image will be
> > used.
> > 
> > As such, the image used as the poster frame requires a means of directly
> > linking the 'alternative text' for that image to the image.
> > 
> > Silvia Pfeiffer suggested:
> > > All that would be required is an extra sentence to encourage users to
> > > explain the poster content as part of the alternative text of the video
> > > element. (http://www.w3.org/Bugs/Public/show_bug.cgi?id=10642#c62)
> > 
> > Once again, this presumes that the image is directly related to the video, a
> > presumption we should not be making.
> 
> 
> It is specified through a @src attribute on a <video> element and shown as a
> replacement for the video before the video starts playing back. I think your
> assumption that it may have nothing to do with the video only holds true when
> that image is not used in the @src attribute, but otherwise it has a very
> strong link to it. 


I meant of course: @poster attribute on the <video> element, sorry for the confusion.

(In reply to comment #70)
> (In reply to comment #69)
> > 
> > However, my argument is not that we do not need a text alternative for the
> > poster. I do argue that we need that. But I also argue that when we have a text
> > replacement for the video, we can include the text replacement for the poster
> > in that piece of text - it does not have to be separate.
> > 
> > So, as an example: an alternative text for film festival videos may be:
> > "Video poster shows .....blah. Video is about .... blah."
> 
> If the poster alt text is not separate it will be much harder to detect
> programmatically. So tools like a validator / a11y checker / similar can�t help
> authors by checking for video elements that have a poster image but is missing
> alt text for the poster image. Like when the author forgot to add one.

Yes, but it is also impossible to render two different alternative texts for a single element unit. It's not like the <video> element and the poster are two separate elements - they are a single entity that is presented to sighted users as a single object on screen. How should two different alternative texts for a single object even be rendered?

(In reply to comment #72)
> Yes, but it is also impossible to render two different alternative texts for a
> single element unit. It's not like the <video> element and the poster are two
> separate elements - they are a single entity that is presented to sighted users
> as a single object on screen. How should two different alternative texts for a
> single object even be rendered?

Hi Silvia,

The User Agent Accessibility Guidelines may be helpful:

QUOTE:
Guideline 3.1 Provide access to alternative content.

3.1.1 Identify Presence of Alternative Content The user has the ability to have indicators rendered along with rendered elements that have alternative content (e.g. visual icons rendered in proximity of content which has short text alternatives, long descriptions, or captions). In cases where the alternative content has different dimensions than the original content, the user has the option to specify how the layout/reflow of the document should be handled. (Level A).

3.1.2 Configurable Default Rendering: The user has a global option to specify which types of alternative content by default and, in cases where the alternative content has different dimensions than the original content, how the layout/reflow of the document should be handled. (Level A)

3.1.3 Browse and Render: The user can browse the alternatives, switch between them, and render them according to the following (Level A):

   1. synchronized alternatives for time-based media (e.g., captions, audio descriptions, sign language) can be rendered at the same time as their associated audio tracks and visual tracks, and
   2. non-synchronized alternatives (e.g., short text alternatives, long descriptions) can be rendered as replacements for the original rendered content.

3.1.4 Rendering Alternative (Enhanced): Provide the user with the global option to configure a cascade of types of alternatives to render by default, in case a preferred type is unavailable. If the alternative content has a different height or width, then the user agent will reflow the viewport. (Level AA)
UNQUOTE

http://www.w3.org/TR/UAAG20/#principle-perceivable

(In reply to comment #73)
> (In reply to comment #72)
> > Yes, but it is also impossible to render two different alternative texts for a
> > single element unit. It's not like the <video> element and the poster are two
> > separate elements - they are a single entity that is presented to sighted users
> > as a single object on screen. How should two different alternative texts for a
> > single object even be rendered?
> 
> Hi Silvia,
> 
> The User Agent Accessibility Guidelines may be helpful:
> 
> QUOTE:
> Guideline 3.1 Provide access to alternative content.
> 
> 3.1.1 Identify Presence of Alternative Content The user has the ability to have
> indicators rendered along with rendered elements that have alternative content
> (e.g. visual icons rendered in proximity of content which has short text
> alternatives, long descriptions, or captions). In cases where the alternative
> content has different dimensions than the original content, the user has the
> option to specify how the layout/reflow of the document should be handled.
> (Level A).
> 
> 3.1.2 Configurable Default Rendering: The user has a global option to specify
> which types of alternative content by default and, in cases where the
> alternative content has different dimensions than the original content, how the
> layout/reflow of the document should be handled. (Level A)
> 
> 3.1.3 Browse and Render: The user can browse the alternatives, switch between
> them, and render them according to the following (Level A):
> 
>    1. synchronized alternatives for time-based media (e.g., captions, audio
> descriptions, sign language) can be rendered at the same time as their
> associated audio tracks and visual tracks, and
>    2. non-synchronized alternatives (e.g., short text alternatives, long
> descriptions) can be rendered as replacements for the original rendered
> content.
> 
> 3.1.4 Rendering Alternative (Enhanced): Provide the user with the global option
> to configure a cascade of types of alternatives to render by default, in case a
> preferred type is unavailable. If the alternative content has a different
> height or width, then the user agent will reflow the viewport. (Level AA)
> UNQUOTE
> 
> http://www.w3.org/TR/UAAG20/#principle-perceivable


Hi Laura,

We are talking about two non-synchronized short text alternatives to a single element that consists of a single image representation which is sourced potentially from two different Web resources, but maybe not. I can't see where such a situation is described in your quoted text nor can I think of a useful way to render the two text alternatives for the one video through a screen reader when tabbing onto the video. I don't think that situation has occurred in other elements before.

Just to make sure: I totally believe we need to have multiple synchronized alternatives for different purposes. But that is not the issue under discussion.

> However, my argument is not that we do not need a text alternative for the
> poster. I do argue that we need that. But I also argue that when we have a text
> replacement for the video, we can include the text replacement for the poster
> in that piece of text - it does not have to be separate.

It does have to be separate, because the purpose of the poster and the purpose of the video content are distinct. For one thing, the poster could be content not found in the video, like rendered text of the video's title. For another, the poster itself serves the purpose of arousing interest among users in playing the video.

People who can't see still want to know _why_ this content is important before playing it. If that information is not important enough for a blind user, then it should follow that it provides no meaningful information to a sighted user. In which case, @poster should be removed, because it adds no value to HTML5. Of course none of that is true, which is why the issue was raised.

Worse, proposing to use one field for these distinct purposes is something that doesn't really belong in the specification. It indicates we're not making a technical decision, but rather just routing around damage. It's the kind of advice that belongs in WCAG techniques, but only after the HTML WG has failed to provide the necessary functionality for users. Half-steps like this have no place in the spec itself.

(In reply to comment #75)
> > However, my argument is not that we do not need a text alternative for the
> > poster. I do argue that we need that. But I also argue that when we have a text
> > replacement for the video, we can include the text replacement for the poster
> > in that piece of text - it does not have to be separate.
> 
> It does have to be separate, because the purpose of the poster and the purpose
> of the video content are distinct. For one thing, the poster could be content
> not found in the video, like rendered text of the video's title. For another,
> the poster itself serves the purpose of arousing interest among users in
> playing the video.
> 
> People who can't see still want to know _why_ this content is important before
> playing it. If that information is not important enough for a blind user, then
> it should follow that it provides no meaningful information to a sighted user.
> In which case, @poster should be removed, because it adds no value to HTML5. Of
> course none of that is true, which is why the issue was raised.
> 
> Worse, proposing to use one field for these distinct purposes is something that
> doesn't really belong in the specification. It indicates we're not making a
> technical decision, but rather just routing around damage. It's the kind of
> advice that belongs in WCAG techniques, but only after the HTML WG has failed
> to provide the necessary functionality for users. Half-steps like this have no
> place in the spec itself.


I do not follow your argument for why they need to be separate. The purpose of the poster or displayed video frame is to express something that will make people want to watch the video. It is therefore not distinct, even it if contains content that is not in the video. Maybe you misunderstand how the poster is presented? It is indeed presented as a replacement for the video imagery. It is not possible to look at the poster as a separate image - that would defeat its purpose as a video poster image. A sighted user who does not inspect the HTML code does not know whether this picture is from inside the video or not, nor does he/she need to know. Whatever is shown looks to the user like it is part of the video - and it could come from inside the video or not. So, what is shown needs to be communicated in the text alternative for the video. If the imagery shows text (be that from a poster or from the first video frame), then that text should be in the text alternative for the video. If it shows a person, then the description of that person should be in the text alternative for the video.

I believe some of the communication problems we have here is the name of the attribute: @poster. I believe that many people think this has something to do with movie posters - advertising material that is being used as separate content from the video (or rather: movie). This is not what the @poster attribute is. The @poster attribute defines nothing more than a thumbnail for the video and it stands in the video's place. If that thumbnail is used as a separate resource, it would be in an <img> element and thus have all its own text alternatives.

(In reply to comment #76)
> I do not follow your argument for why they need to be separate. The purpose of
> the poster or displayed video frame is to express something that will make
> people want to watch the video. It is therefore not distinct, even it if
> contains content that is not in the video.

It is distinct, in that it is presented before the video itself would be played.  I can see a definite advantage to having the poster's alternate text specified separately from the video content's: it allows the poster alternate text to be queried separately.  This would in fact bring the experience closer to that of the sighted user, namely, that the poster can be presented separately first, enticing the user to play the video.

Of course it may be that the first few sentences of the video content's alternate text does this job.  But it may not.

(In reply to comment #77)
> (In reply to comment #76)
> > I do not follow your argument for why they need to be separate. The purpose of
> > the poster or displayed video frame is to express something that will make
> > people want to watch the video. It is therefore not distinct, even it if
> > contains content that is not in the video.
> 
> It is distinct, in that it is presented before the video itself would be
> played.


When there is no @poster, there is also an image that is presented before the video is played. It makes no sense not to have a description for that either. They are both part of the video experience and therefore logically part of the video's text alternative.

>  I can see a definite advantage to having the poster's alternate text
> specified separately from the video content's: it allows the poster alternate
> text to be queried separately.

That would be the only reason why I could see a necessity for a separate @posteralt, as I said before. But I honestly cannot see a use case where it would be necessary to have the @poster attribute's display retrieved separately from the user when it is part of the video (of course it would be required when it was displayed separately in an <img>, but that's not the case here).

In particular can I not see this additional alternative representation of the video being read out by the screen reader.


>  This would in fact bring the experience closer
> to that of the sighted user, namely, that the poster can be presented
> separately first, enticing the user to play the video.
> 
> Of course it may be that the first few sentences of the video content's
> alternate text does this job.  But it may not.

So, let's think this through. What would realistically be in a @posteralt that would not be in a normal @alt (or @aria-label) for a video? The @alt would realistically contain a description of the image being shown as a replacement for the video. What else? It cannot provide a summary of the video, since that would be more than the sighted user gets. That kind of content would come through a @aria-describedby or the time-synchronized video description track that we are preparing for. So, realistically, the @alt (or @aria-label) contains exactly what the @poster shows. Nothing more and nothing less.

Related Sitepoint forum thread: 
http://www.sitepoint.com/forums/showthread.php?p=4738579#td_post_4738037

Ian's responses:
http://www.sitepoint.com/forums/showthread.php?p=4738579#post_message_4738825
http://www.sitepoint.com/forums/showthread.php?p=4738579#td_post_4739099

> Ian's responses:

Another:
http://www.sitepoint.com/forums/showthread.php?p=4738579#td_post_4739784

one of the ideas I have discussed with some people is having the poster attribute accept an ID  which can be the ID of an <img> element anywhere on the page. In this way a new element/attribute is not required as the alt of the <img> will be the alt for the poster.

(In reply to comment #81)
> one of the ideas I have discussed with some people is having the poster
> attribute accept an ID  which can be the ID of an <img> element anywhere on the
> page. In this way a new element/attribute is not required as the alt of the
> <img> will be the alt for the poster.

Using an img element does sound like a possible solution to this, but what web browsers that doesn't support the video element should they still display this img element?

(In reply to comment #81)
> one of the ideas I have discussed with some people is having the poster
> attribute accept an ID  which can be the ID of an <img> element anywhere on the
> page. In this way a new element/attribute is not required as the alt of the
> <img> will be the alt for the poster.

It seems unlikely that the poster frame would be displayed as an image in a separate place on the page. The whole point of the poster frame is that it is a temporary placeholder for the video, and it goes away as soon as the video starts playing.

(In reply to comment #83)
> (In reply to comment #81)
> > one of the ideas I have discussed with some people is having the poster
> > attribute accept an ID  which can be the ID of an <img> element anywhere on the
> > page. In this way a new element/attribute is not required as the alt of the
> > <img> will be the alt for the poster.
> 
> It seems unlikely that the poster frame would be displayed as an image in a
> separate place on the page. The whole point of the poster frame is that it is a
> temporary placeholder for the video, and it goes away as soon as the video
> starts playing.

i guess my thinking was more that it would be in the video element, so could also serve as fallback if video was not supported.

(In reply to comment #84)
> (In reply to comment #83)
> > (In reply to comment #81)
> > > one of the ideas I have discussed with some people is having the poster
> > > attribute accept an ID  which can be the ID of an <img> element anywhere on the
> > > page. In this way a new element/attribute is not required as the alt of the
> > > <img> will be the alt for the poster.
> > 
> > It seems unlikely that the poster frame would be displayed as an image in a
> > separate place on the page. The whole point of the poster frame is that it is a
> > temporary placeholder for the video, and it goes away as soon as the video
> > starts playing.
> 
> i guess my thinking was more that it would be in the video element, so could
> also serve as fallback if video was not supported.

It's unlikely that the poster frame would make good fallback for the video-no-supported case. It's supposed to be an affordance for starting the video. If the user's browser doesn't support HTML5 video, then instead of something to represent the not-yet-playing video, it would be more appropriate to show a message that video is not supported, or an alternate playback mechanism, such as a plugin-based video player. It's not really very likely that a visible version of the poster frame would be in the fallback.

*** Bug 13729 has been marked as a duplicate of this bug. ***