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. [email protected] 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. [email protected] 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

[mraccess77]

"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

[mattur]

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

[mraccess77]

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

[johnfoliot]

In the end the summary attribute was deprecated in HTML5 - to improve

accessibility. Actually, nobody in the accessibility/disability community agreed with that, and removing the @summary attribute was at one time undecided under a Formal Objection, one that was only removed in the interest of moving HTML 5 forward to meet a specific and urgent deadline - and NOT as @mattur asserts because the accessibility community came around to the flawed thinking of non-disabled engineers, who didn't understand the problem.

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." Perhaps, but that isn't how it's often used today. Bottom line: There are two visual assets in play - the video file (moving pictures / .mp4), and the static image file (.jpg / .png / etc.) and BOTH need textual alternatives, *ESPECIALLY* when that image/first frame contains text (examples provided previously), at which point the textual alternative for that file is to replicate the text in the graphic, and NOT to offer a textual summary of the video file. Anyone who's spent any time working in web accessibility understands this instinctively, and we've spent the past 2 decades+ educating developers about the different types of images seen on any web page (informative images, active (link) images, decorative images, complex images that require both an "accessible name" as well as an "accessible description", images that have text contained within the graphic, etc.). Given that the @Placeholder attribute was never intended to be used to label form inputs, yet is routinely used for that purpose today, we have evidence that what hixie et. al. *intended* with regard to @poster, versus what we see in real life rarely align. The argument remains today that *any* graphic file can be referenced by the @poster attribute (including via absolute URL to another domain/server), leaving a gaping hole wide open for misuse and abuse. The problem remains today.

but a text alternative for the image alternative is superfluous, and as

such likely to cause more issues than it solves. ​Said no blind user ever​. It's a baseless argument with no empirical evidence or data to be found: it is the assumption of sighted engineers who've never had to deal with the use-case of a graphic file with important information not being properly described or read to them. The discussion was lengthy, detailed and for the most part unanimous from the non-sighted community: they both needed and wanted this. Even in this thread, it is clear that those users who require textual alternatives on a routine basis are still requesting this capability.

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. ​Conjecture with no evidence. . Meanwhile, we lack a means to provide a basic requirement for non-sighted users today. JF

…

On Thu, Jul 19, 2018 at 4:57 PM, Jonathan Avila ***@***.***> wrote: • 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. — 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-cxh7CyOnwOQCpd2BbQK4En48GD4Uks5uIQC9gaJpZM4T64nu> .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. [email protected] Advancing the mission of digital accessibility and inclusion

[chaals]

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.

[chaals]

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.

[OwenEdwards]

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.

[johnfoliot]

Hi Owen, I think there are a few different ways forward here: we can go back to Web Platform WG and ask for new elements or attributes to fill the gap, or we can look to provide the same functionality via a (potentially) new aria-* attribute. Using an aria solution would certainly address the needs of non-sighted users, but it would take some additional "wiring up" (perhaps a browser extension or similar) to make the textual alternatives available to other users who may not be using a screen reader or other Accessibility API aware tool. While my personal preference would be to get 'native' functionality/support directly in the browser, if browser vendors aren't keen to pursue this at this time, we can certainly explore the aria route instead. As a current member of the APA WG, and a past member of the Media Accessibility Task Force that was stood up around the original HTML5 effort, there are a few additional media-related gaps that we'd like to also follow up on (for example, there is no direct mechanism today to link a transcript to a media asset programmatically - another existing gap on our radar). While I cannot speak definitively here, I suspect that this will be discussed at more length at TPAC, which is less than 3 months away (Oct 22 - 26). The APA agenda for TPAC is still under development, but I will endeavor to keep you (and this list) abreast of details as they evolve. JF

…

On Thu, Aug 2, 2018 at 1:27 PM, Owen Edwards ***@***.***> wrote: 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 <#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. — 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-c_UnPDFsueGGvdCPZ6r6y2C7lXROks5uM0SagaJpZM4T64nu> .

-- *John Foliot* | Principal Accessibility Strategist Deque Systems - Accessibility for Good deque.com

[siusin]

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 [email protected].