Why Is There No Alt Attribute Associated With The Poster ... - GitHub

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?

The text was updated successfully, but these errors were encountered:

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 thank you for your comments / the clarifications on history, will update my comment to correct.

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.

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

@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).

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:

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.

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.

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

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

I agree with others like @SebastianZ by definition the poster image is giving you a glimpse into the video to allow the sighted person to make a decision before using data to play the video. People who are visually impaired should have access to an alternative without playing the video.

One could also read that WCAG 1.1.1 requires that time based media have a description of the content itself in addition to the actual captioned/audio described content.

From the understanding doc "Time-Based Media: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. (Refer to Guideline 1.2 for additional requirements for media.)" https://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html

@mraccess77

One could also read that WCAG 1.1.1 requires that time based media have a description of the content itself in addition to the actual captioned/audio described content.

One of the arguments put forward against an alt attribute for video poster images was that people would confuse a description of the content itself with a description of the content of the poster image.

I don't think anyone has suggested a description of the content itself shouldn't be provided for everyone who needs it including, but not limited to, people who are visually impaired.

However, one point that has been made is that people will mistakenly use the poster alt for the description of the content itself, thereby making that description less accessible than it would otherwise be if poster alt did not exist.

@SebastianZ

So what are the reasons spec. writers and implementers keep objecting to implement it?

Here's a direct link to the change proposal for "No Poster Alt". The core point in the proposal is:

"The video poster is conceptually part of the media resource itself. Any short text alternative should apply to the resource as a whole, not just the poster image."

So the argument could be summarised as:

• The poster image presents an image alternative for the video
• the video also needs text alternative(s),
• but a text alternative for the image alternative is superfluous, and as such likely to cause more issues than it solves.

There's much more discussion on the original bug, also linked above.

In passing, regarding the point made above about sighted vs non-sighted users, it's important to base decisions on the arguments presented, not just on who is making them.

One example from HTML5: some visually impaired users strongly objected to deprecating the summary attribute on the table element. Their argument was they could access it fine. Crucially, they were unaware the argument for deprecating it was other people with/without disabilities benefited from being able to directly access its content too.

When these visually impaired users understood the issue as one of enabling access for multiple, diverse groups of users with/without disabilities - including, but not limited to, visually impaired users - many changed their minds. In the end the summary attribute was deprecated in HTML5 - to improve accessibility.

Not everyone agreed of course, but calmly considering all the arguments on the best way to improve accessibility in this case certainly improved the quality and depth of the debate, and including a range of opinions on possible solutions is a basic requirement for any consensus-based approach, like the W3C's, to be effective.

And, one other positive that came out of the discussion: even those who disagreed could no longer in good faith present the move to deprecate summary as giving the giant middle finger to the non-sighted community. Which was nice.

• but a text alternative for the image alternative is superfluous, and as such likely to cause more issues than it solves.

I don't agree with that statement. I think there should be both an accessible name of the media asset as a whole and an alternative to the poster image. The accessible name to the video as a whole might be already communicated visually on the page below the video and could be linked with aria-labelledby. I understand that their could be confusion -- but it seems like having both is the right way. Just because something can be misused is not alone a sufficient reason to drop something. Separately regarding the summary attribute -- it was meant to communicate structural understanding of the table if you could not see the structure of the table. Most designers would certainly not want to write out this structural description on the page and now no users are getting that information. Your argument around the summary attribute is the same one I made on alt being display for all images and I was shot down on that. I would like alt on img to be available to all users and especially people with low vision who may not be able to distinguish all of the details in the image but don't use a screen reader. Yet browsers by order of the standard won't display alt.

Please keep the discussion polite professional level, covering technical issues, facts, and what they mean or imply. In particular, please do not make assumptions about the participants, or use ad hominem rhetorical arguments.

There seems to be little if any appetite from browsers to do this natively. Are there extensions that provide the functionality?

also, bumping milestone. This has been a long-standing issue, a few more weeks won't stop the world improving in its own sweet time.

Okay, this is a complicated train of thought, so please let me know if it isn't clear:

W3C's recommendation for making an audio file accessible in a web page is to use a <video> element instead of an <audio> element, and to use a poster, so that there is a space in the rendered page for WebVTT text track subtitles of the audio to be displayed for users who are deaf or hard-of-hearing (see #1430).

At that point, the poster specifically can't be a "poster frame" from the video, because there isn't any video (only audio), so it must be an image which explicitly not described by the WebVTT track. In theory, the poster could be an empty image (to just allocate a blank piece of real estate on the page), but I really can't imagine visual designers going for that. (As an aside, a nice feature for audio-only playback would be if the area for rendering text tracks "rolled up" or "dropped down" from the player controls when playback with captions starts, but that's explicitly not what the "poster" is for). Maybe the poster could be considered purely decorative, and therefore not needing a text alternative, but that can't be guaranteed. It might be "cover art", which is entirely separate from the content of the song and needs its own text alternative.

So how do site designers/developers add alternative text to that poster? Either the proposal that using a <video> element with a poster and text track to make a piece of audio accessible is flawed, or there are real situations where the poster needs an alt attribute.

Thanks all.

We're closing this issue on the W3C HTML specification because the W3C and WHATWG are now working together on HTML, and all issues are being discussed on the WHATWG repository.

If you filed this issue and you still think it is relevant, please open a new issue on the WHATWG repository and reference this issue (if there is useful information here). Before you open a new issue, please check for existing issues on the WHATWG repository to avoid duplication.

If you have questions about this, please open an issue on the W3C HTML WG repository or send an email to public-html@w3.org.