W3C

Site Navigation

Nearby

Results of Questionnaire ISSUE-142: No alternative text description for video key frame (poster) - Straw Poll for Objections

The results of this questionnaire are available to anybody.

This questionnaire was open from 2011-03-10 to 2011-03-17.

4 answers have been received.

Jump to results for question:

  1. Objections to the Change Proposal for no poster short alternative text
  2. Objections to the Change Proposal to introduce a new child element to the video element.

1. Objections to the Change Proposal for no poster short alternative text

We have a Change Proposal to specify that there is no poster short alternative text. If you have strong objections to adopting this Change Proposal, please state your objections below.

Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.

Details

Responder Objections to the Change Proposal for no poster short alternative text
Laura Carlson What this all boils down to is the ability to access content. If <video poster> provided no content <video poster> would not exist.

This change proposal states: "we provide the possibility of indicating an image which is more indicative of the content". [1]

HTML5 should have a mechanism to provide that indication to people with disabilities. Currently it does not. <firstframe> provides that possibility. It offers a mechanism to equitably obtain that same content currently in <video poster> to people with disabilities.

[1] http://www.w3.org/html/wg/wiki/index.php?title=ChangeProposals/NoPosterAlt&oldid=9214
Kornel Lesinski
Philip Jägenstedt
Leif Halvard Silli I strongly object. This CP doesn't ensure that unsighted always can be provided access to:

A) sufficient or equal info before deciding to run a video;
B) alternative text for info that sighted get even without running the video;
(Point A) and B) are different sides of same coin.)
C) Also see Comments under C) below.

DETAILS:

A) <img>s are consumed instantly (by AT users too). But videos are consumed in 2 steps, where step 2 (running the video) depends on evaluation of
1) costs of running the video (time costs, quality costs/technical limits);
2) perceived benefits (info on the video's subject & "teasers")
PROBLEM 1: Different defaults: The benefits are more diffult to evaluate without a firstframe image than with a firstframe image. But, luckily for sighted, there always *is* a firstframe image even without whether @poster or <firstframe src=*>. Solution: a <firstframe src=* alt=*> with the authoring guidelines John propososes (see his General Principles section: http://www.w3.org/html/wg/wiki/ChangeProposals/PosterElement#General_Principles), helps authors to provide for unsighted what sighted get by default.
PROBLEM 2: Different needs: Just as for <img>, what unsighted need in text format is different from what sighted need in text format. E.g. imagine that the video's firstframe displays text. Solution: <firstframe alt=*> allows authors to take care of the difference.
PROBLEM 3: Same expectations: The firstframe image creates useful expectations about what to see: When starting a video, the exciting scene (or info) on the firstframe image might be preceded by dull footage or advertising. Someone who sees the firstframe image (all the sighted!) or at least read its description, would be less likely to stop playing the video early than someone with minimal clue about what to expect. Solution: <firstframe> allows authors to build up similar expectations within the unsighted audience as within the sighted audience.

B) To a sighted, the firstframe image can have value in itself. Speaking for myself, when news articles contain video I tend to "jump over" them, but I still eagerly consume their firstframe images. Thus, a firstframe image without a description is information-loss for the unsighted. An HTML standard where <img src=ExitingMoment > is covered by @alt and its usage guidelines, but were <video src=VideoWithAnExitingMomentAsTheFirstframeImage > does not have similar possibilities or guidelines, would be a missed opportunity.

C) Comments to certain claims:

C1) CP says: "it should be described as part of the description of the video element itself". But by which feature? <track> is synced with the video file and not with the still picture of the firstframe image. It should be as easy to change the firstframe text as it is to change the firstframe image - one shouldn't need to edit whether a <track> file or a video source file. John's CP also demoes that the firstframe could specify for whom the film is suitable: one should not need to read a longer, general video description to locate this. Plus that some of the firstframe's teaser effects could be lost if the firstframe text is mixed together with a general description of the video.

C2) The CP claims that because the firstframe image is "conceptually part of the media resource itself" it "should be described as part of the description of the video element itself". However, from a different angle, a firstframe image description *would* then be a video description, if but of a detail of it.

C3) The name: <firstframe> at first seemed unoptimal (e.g. because John's CP says that it could be used for <audio>). However, if we ignore <audio> (which has no image feature), and instead consider Sylvia Pfeiffer's point (http://www.w3.org/Bugs/Public/show_bug.cgi?id=10642#c76) that the user don't know whether the image stems from (in John's proposal) <firstframe src> or the movie file, then <firstframe> make very good sense.

C4) CP says that "'poster' is the term commonly used in the industry". May be. But for example such a thing as <param name="poster" value="*"> does not seem to exist for whether QuickTime, MediaPlayer or Flash.

C5) Comment on a poll comment by Philip Jägenstedt: Whether the firstframe image text must accurately reflect the firstframe image or simply be a text that could serve as a useful textual teaser, seems like an authoring guide question. For instance, if the video's firstframe shows what this CP describes as "a fade from black, the green MPAA rating, the roaring lion, etc", then it may not make sense to *require* the firstframe text to reflect this. John's CP says the author in such cases MAY omit <firstframe> (note: <firstframe> always requires @alt). However, if the author doesn't omit it, could the author then provide a text that was a tad more useful than the firstframe image itself? My answer would be: Yes, but then the author should also update the firstframe image.

2. Objections to the Change Proposal to introduce a new child element to the video element.

We have a Change Proposal to introduce a new child element to the video element.

Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.

Details

Responder Objections to the Change Proposal to introduce a new child element to the video element.
Laura Carlson
Kornel Lesinski * The proposal confuses poster frames with movie posters. It is not purpose of this attribute to serve as a movie poster, and I have not seen any indication of this happening in practice.
* In my experience most videos don't have carefully chosen poster frames that are good description of the video, and many videos have accompanying description which makes description of poster frame unnecessary.
* Description of only a single frame — which sometimes is not even chosen by the video author — can be misleading about video's content.
* I think it's unreasonable to expect that authors would describe both video and poster frame separately, and author's effort is better spent on describing the video itself.
* In case when poster frame is especially interesting, its description could be made part of the video description (it seems unlikely to me that one would like to learn about the poster and not about the video).

The proposal is mainly based on concern that authors *could* use image that contains unique and valuable information about the video. However, this does not happen in practice:

Poster frames on sites like YouTube or Vimeo are just one of the frames of the video. These frames are not specially crafted images that would be a good proxy for the entire video contents. Sometimes these frames capture unimportant scenes from the video, or taken out of context give wrong impression of the video. Such accidental misleading poster frames are a problem for me (sighted user), and I don't think we should be giving *equally bad* experience to users who can't see them.

Some video poster frames, e.g. on InfoQ website, are just website's logo, which tells nothing about the video itself, and website name is obvious from context.

On Guardian and NY Times websites videos seem to have manually chosen poster frames. However, these videos are accompanied by very good descriptions, which are much better than descriptions of poster frames could be (e.g. video about climate change affecting sea life has poster frame with a fisherwoman — even a pefect description of the poster frame would be only an incomplete description of the video).

Videos on movie-oriented websites don't use movie poster for poster frame. Trailers often start with screen describing video rating, and less often logo of a movie studio. This is valuable information, but description of the first frame would only coincidentally contain it (and e.g. if video has rating screen, then users would not get information about movie studio and vice-versa). Instead of relying on poster frame containing *some* information and poster frame description copying it, we should encourage authors to provide information in more reliable and straightforward manner (e.g. Apple trailers website always includes both rating and studio information in movie description, and poster frames are not reliable source of that information).
Philip Jägenstedt I strongly object to describing the poster frame separately from the video to AT users. This distinction is not made for sighted users, who have no way of knowing if what they are seeing is the first frame of a video or a poster frame. The poster frame is "intended to be a representative frame of the video" and as such, the description of the video should also be a suitable description of the poster frame. If the poster frames brings attention to any specific aspect of the video, it would be appropriate for the video's description to also stress that aspect. Making the suggested disctinction would encourage inappropriate use of the poster frame.

I strongly object to removing the poster attribute, as it is already implemented by browsers and used by web pages. Adding a short text alternative for the placeholder/poster image (which I object to) does not require changing this part of the syntax.

As a necessary consequence, I also object to renaming the concept from "poster frame" to "first frame", even though I acknowledge that "poster frame" is by no means a perfect name for the feature.

I object to introducing a <firstframe> void element that is likely to appear before the <source> elements. In all browsers that do not implemented support for <firstframe>, any following <source> elements would become child elements of <firstframe> and thus would not be considered in the resource selection algorithm. In effect, that video would be completely broken in those browsers. (Yes, this is also a problem with <track> and introducing new void elements in general.)

The fact that authors can use any image as the poster frame is not sufficient justification. Any frame of the video can also contain arbitrary content, yet there is no mechanism for providing short text alternatives for specific frames on the HTML level. Further, it seems highly unlikely that people who use the poster incorrectly (to include content that is not representative of the video resource itself) would be aware enough to make the effort of making that inappropriate use accessible.

Finally, just like the poster attribute can be used incorrectly, it's possible to use multiple <source> elements with media attributes so that wildly different videos are used depending on the environment. Yet, there is no suggestion to provide a separate text alternatives for each <source>. I object to catering for abuse of the poster attribute but not doing the same for <source> elements.

Comments on Leif Halvard Silli's objections not covered by the above:

There is no disagreement that short text alternatives for the video are important.

There is no contradiction between "conceptually part of the media resource itself" and "should be described as part of the description of the video element itself". The point is quite clear: a short text alternative that is representative of the video would also be suitable as a short text alternative for the poster frame, as the poster frame is representative of the video. No one has suggested that the poster frame be explicitly described in the short text alternative of the video, on the form of "The poster frame contains... and the video itself is about...". That would just as inappropriate as having a separate description for the poster frame.

That <video> does not have a (dedicated) short text alternative is part of the point. Having a dedicated short text alternative for the poster frame but not for the video itself is extremeley backwards. Thus the suggestion that discussion "move on to short and long text alternatives for a media resource as a whole". Note that aria-labelledby and aria-describedby are mentioned as potential solutions in the <firstframe> proposal. This is outside the scope of ISSUE-142, though.
Leif Halvard Silli

More details on responses

  • Laura Carlson: last responded on 12, March 2011 at 13:20 (UTC)
  • Kornel Lesinski: last responded on 12, March 2011 at 19:48 (UTC)
  • Philip Jägenstedt: last responded on 13, March 2011 at 09:32 (UTC)
  • Leif Halvard Silli: last responded on 14, March 2011 at 08:40 (UTC)

Everybody has responded to this questionnaire.

Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire

Report issues on GitHub project w3c/wbs-design or by mail to sysreq.