Why is there no alt attribute associated with the poster attribute on a video element (or, what's the accessible name calculation on a video element)?

[OwenEdwards]

The <video> element provides support for a poster image which acts as a visual placeholder for the video when it is not playing. The image conveys information about what video will play for a sighted user, but unlike other images (e.g. <img>, <svg>) there is no explicit mechanism to provide a textual alternative for non-sighted users. This is separate from the accessibility/alternative for the video file/stream while being played - the poster image provides additional information which is conveyed statically and may include text or other information which ought to be made available to a non-sighted user (indeed, the poster image could include information which is not present anywhere in the video).

Currently, the only mechanism to provide this kind of labeling is using aria-label or aria-labelledby; does HTML have no plan to make this native feature accessible with a native attribute?

[scottaohara]

Hi @OwenEdwards,

Thanks for bringing this up.

Per alternative text for the poster, and why it isn't part of the spec, there was a pretty lengthy discussion about this opened by @stevefaulkner back in 2010 referencing an issue opened by everett zufelt.

Per one of the arguments in the linked thread, and as the spec notes:

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.

So, it's actually a misuse of the poster to include imagery/text information that isn't part of the video itself, since that poster content should be part of the video and explained in context within the video itself.

With that said, it's been some time since the original conversation around this issue, so it might be worth bringing it up over at the WICG Discourse to incubate the idea and see if others are in agreement / have changed their mind on this.

[johnfoliot]

History: https://lists.w3.org/Archives/Public/public-html/2011Mar/0690.html FWIW, I raised a Formal Objection ( https://lists.w3.org/Archives/Public/public-html/2011Mar/0697.html) on this issue, which was never satisfactorily addressed (the FO was withdrawn to facilitate the publishing of HTML 5.0, and the topic was never re-surfaced).

Per one of the arguments in the linked thread, and as the spec notes:

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. ​> ​ So, it's actually a misuse of the poster to include imagery/text information that isn't part of the video itself, since that poster content should be part of the video and explained in context within the video itself. ​*Argument:* Just because the specification states "... ​ intended to be a representative frame of the video ​..." is in no way​ ​ a mandated requirement (it is/was simply "intended" to do that, but not *required *to do so), and in fact *content authors can provide *any* graphic image they want* as a @poster image. (I'll note in passing that the spec also states that the @Placeholder attribute for form inputs MUST not be used to label the input, yet thousands if not millions of websites do just that, forcing most screen readers today to process @Placeholder text as labels, counter to what the specification explicitly states.) ​A classic use-case is when​ a video is prefaced with a graphic file that contains a significant amount of text: [alt: "The following Preview has been approved for Appropriate Audiences by the Motion Picture Association of America, Inc. The Film advertised has been rated R - Restricted. Under 17 requires accompanying parent of adult guardian"] (source: http://bcjmedia.com/wp/wp-content/uploads/2011/08/trailer_green_screen_share.jpg ) OR [alt="Official Selection - UK Screen One International Film Festival 2017"] (source: http://www.monicamazzitelli.net/en/wp-content/uploads/2017/02/17-02-uk-screen.jpg ) Proponents opposed to the idea continue to point to what the authors are "supposed" to do (or not do), whereas I will point to what authors *are* doing. I'll also note in closing that numerous non-sighted participants weighed in on the original discussion, and universally they too wanted this ability added to HTML5, but in the end, sighted engineers over-ruled them with their flawed, sighted logic. I was frustrated about this decision then, I remain frustrated today. (oh, and for historical accuracy, the original "bug" posting against HTML5 for this did not come from Steve Faulkner, but was in fact raised by a Canadian (self-identified) non-sighted user Everitt Zufelt here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=10642) JF

…

On Fri, May 11, 2018 at 12:05 PM, scottaohara ***@***.***> wrote: Hi @OwenEdwards <https://github.com/OwenEdwards>, Thanks for bringing this up. Per alternative text for the poster, and why it isn't part of the spec, there was a pretty lengthy discussion about this initiated by @stevefaulkner <https://github.com/stevefaulkner> back in 2010 <https://www.w3.org/html/wg/tracker/issues/142>. Per one of the arguments in the linked thread, and as the spec notes: 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. So, it's actually a misuse of the poster to include imagery/text information that isn't part of the video itself, since that poster content should be part of the video and explained in context within the video itself. With that said, it's been some time since the original conversation around this issue, so it might be worth bringing it up over at the WICG Discourse <https://discourse.wicg.io/> to incubate the idea and see if others are in agreement / have changed their mind on this. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1431 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK-cxmRykq1ZDLkn3oOC9nfI8W9mIblks5txcTRgaJpZM4T64nu> .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion

[scottaohara]

@johnfoliot thank you for your comments / the clarifications on history, will update my comment to correct.

[OwenEdwards]

Thanks for the link to the history, @scottaohara. However, separate from the point which @johnfoliot makes, even if the poster is exactly a specific frame from the video, and the video is made fully WCAG 2.0 Level AA accessible with captions, audio description, and an accessible player, the poster image contains information specifically intended to be available to a user before they play the video, at which point none of the WCAG 2.0 Level AA accessibility features give any alternative (of particular note is that a transcript, which would be readable without playing the video, is sufficient at Level A but not sufficient at Level AA - so complying with Level AA by using time-synchronized audio description specifically prohibits a screen reader user from accessing information to allow making a choice about whether to play the video; information which is the very purpose of the poster image).

Consider a page with a series of thumbnail images - when clicked, each one brings up a lightbox/dialog with the full-sized image. It would absolutely not be acceptable to have an alt attribute on the lightbox but not on the thumbnail (perhaps one could argue that the lightbox image doesn't need an alt attribute because the image doesn't contain any additional information, but certainly not the other way around). A page with multiple videos, each one with a poster image, is almost identical to that situation; the thumbnail or poster is exactly a representation of the greater work (compressed in time and/or in space), intended to help the user decide which one they want to experience in more detail. With the lightbox, the additional information appears immediately - with a video, the identification of what the movie is may not appear for tens of seconds, or even minutes. I can only think that it's the fact that web video has been so terribly inaccessible to blind screen reader users for so long that this omission has been allowed to continue.

[stevefaulkner]

@OwenEdwards while I agree that it would be useful, browser vendors did not support this feature, without support from browser vendors to implement, there is no use in defining it in HTML.

[johnfoliot]

@stevefaulkner Sorry mate, I reject that answer. There is plenty out there today that is not supported by the browsers that is still fully spec'ed out (I suggest you go look at how many @autocomplete attributes are supported in browsers today for example), and I for one personally think it's criminal that WHAT WG and the browser vendors, through lack of imagination or understanding, continue to give the giant middle finger to the non-sighted community. This is just another from the list of "Ghost-of-hixie-past" problems that remains with HTML5 today. @OwenEdwards The last time this was discussed, as I recall there was considerable thought to moving this into ARIA where the browser vendors will simply pass along the information to AT like all other ARIA attributes. I think it may be time to resurface this to the ARIA WG. Perhaps indeed it's time for @aria-posteralt JF

…

On Mon, May 14, 2018 at 4:04 AM, stevefaulkner ***@***.***> wrote: @OwenEdwards <https://github.com/OwenEdwards> while I agree that it would be useful, browser vendors did not support this feature, without support from browser vendors to implement, there is no use in defining it in HTML. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1431 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK-czle9AFw1ypa3ietRG-R-2lFxKf0ks5tyUiwgaJpZM4T64nu> .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion

[chaals]

@stevefaulkner is right that without implementation this is unlikely to get into a Recommendation. @johnfoliot is IMHO right that this is not a good enough reason to skip discussing it, and potentially specifying how it might work, even if implementation relies on e.g. browser extensions to work.

I would prefer it not be done through ARIA, since that seems to be clearly directed at "people who are not me" - only those whose tools are using the accessibility API directly to present content. (Having an API to that layer might change this, but so far that's an idea in development).

[OwenEdwards]

Now I've had more time to review a lot of the previous discussion, I can see some of where this got blocked.

It looks like the browser folks just considered the "poster" image to be the same as any frame which is displayed when the video is paused, but with a feature to essentially show a frame other than the very first one if that first one isn't visually informative. Perhaps that could even be selected automatically by some algorithm, either in the browser or on the server that stores the video (YouTube, for example). In that case, it's going to be hard for a server which extracts a keyframe/thumbnail to know how to add alternative text in an automated way.

But the poster attribute is widely used as something other than a frame from the video; there's absolutely nothing which prevents a site designer from using, say, the poster that was used to advertise the movie or the cover of the DVD case, which can contain composition and text which never occurs in the movie. Maybe that's the problem in the HTML spec - that the significant difference that's intended between "poster" and "poster frame" isn't spelled out more clearly?

Honestly, I actually started this issue thinking that the alt text for the poster ought to also be the title of the video. The <video> element can have a title attribute, of course; but that isn't going to be sufficient to describe all of the information in a movie poster, is it?

At the very least, it seems like the HTML spec's language should be extended:

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.

If an image other than a representative frame of the video is used, then site authors should include a text alternative of the poster image for non-visual users.

For example:

<video controls title="Gone with the Wind" id="video-GwtW" poster="https://en.wikipedia.org/wiki/Gone_with_the_Wind_(film)#/media/File:Poster_-_Gone_With_the_Wind_01.jpg" aria-describedby="video-GwtW-description">
    <source ...>
    <source ...>
    <track ...>
    <p>Fallback content</p>
</video>

<p id="video-GwtW-description">
David O. Selznick's production of Margaret Mitchell's Story of the Old South. Gone with the Wind. In TECHNICOLOR. Starring Clark Gable as Rhett Butler ...
</p>

But I don't know if that combination of title and aria-describedby is ideal, nor that the HTML spec will recommend using ARIA to address something that's missing. The concept of alt="(alternative text for image)" and alt="" if the poster (frame) image is purely decorative or extracted from the video seems appropriate, but as with any image we stray into the "what if the description is too long for an alt attribute?" territory.

[Malvoz]

Currently the poster attribute will either force big downloads on smaller devices, or with respect of limited data plans - poor quality images on larger screens.

Was there ever considerations making poster an element? There was.

A <poster> element would allow for:

• responsive video posters.
• alt text.

<video controls title="Video title">
  <source ...>
  <track ...>
  <poster src="#" srcset="..." sizes="..." alt="...">
</video>

[SebastianZ]

Per one of the arguments in the linked thread, and as the spec notes:

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.

So, it's actually a misuse of the poster to include imagery/text information that isn't part of the video itself, since that poster content should be part of the video and explained in context within the video itself.

As it was outlined in earlier posts, the poster image contains some information. Whether that image is a frame of the video or not is irrelevant, also whether it contains useful information or not. Sighted people get that image presented, therefore visually impaired people need to be provided with an alternative. And HTML should have a way to provide that alternative.

While I agree that it would be useful, browser vendors did not support this feature, without support from browser vendors to implement, there is no use in defining it in HTML.

The need for an option to provide an alternative to the poster image is obvious. So what are the reasons spec. writers and implementers keep objecting to implement it?

Sebastian