The current problem with the @poster attribute of the <video> element.

Earlier this week, I posted a Change Proposal to the W3C HTML WG around a topic which seems to have drawn a bit of controversy and outright rejection from some members of the Working Group. I have suggested and proposed that when an author specifies an image file as a placeholder image for the video, that a means of properly ensuring the accessibility of that image be accounted for. To date, it has been a vigorous debate, one fueled by the fact that I can get very passionate about accessibility issues :-). But as I continue to discuss this and try and explain why I believe this is a problem, I’ve also had a chance to better refine what the root of the issue is, and at this time I think I’ve boiled it down to one of pure-play architecture and mechanics. Allow me to explain:

The mechanics of HTML

To me, at the heart of the issue is this: Video is a multimedia concept, that includes numerous media pieces combined to make a whole. In HTML that whole is expressed (marked up) as the element known as VIDEO (<video>).

HTML elements (which abstractly are objects) take on properties, which we express as attributes. The problem arises when something that is expressed as a property of an element (here, @poster as an attribute of <video>)… when that property itself *may* contain/require further properties (for example @lang or a “verbose as necessary description“) – we have no means of doing so.

Why? Attributes cannot themselves take on attributes, so any attribute assigned to the <video> element is a property of the sum, not of another sibling attribute.

The current solution to get around this problem is to create child elements, so that the linkage is maintained, but those child element can also take on the individual required attributes. Examples of this ‘solution’ in HTML are plentiful and long-standing – for example lists (where list items can take on individual attributes) and tables (where <tr>, <th> and <td> can all take on unique attributes).

It has been argued that the @poster image is an intrinsic part of the <video>, but so is the webm/mp4/ogv file(s). So too with the transcript, the caption file, the described video file, etc. etc. The sum of those various pieces, when combined by the UI, *is* the video to the individual user – one conceptually marked up ‘object’, but one that comprises multi(ple) media elements to achieve. At an abstract level, it is no different than an Unordered List, which is the sum of the various <li>s contained within the opening and closing elements of <ul>.

Currently, we have a means to apply required properties (attributes) to most of those pieces that combine to make the <video>: the actual video files are referenced by the child element of <source> which can take on multiple properties/attributes (such as @type). So too with the various textual files that various users may require to meet their individual needs via the <track> element: @srclang for multiple subtitle files, and various @kind values for captions, transcripts, described video, etc. My reasoning goes that the Italian and French sub-title files are also *intrinsically* part of the larger object that is <video>, and rightly they need and take on attributes so that we can properly express the properties of those pieces to the end user (via the DOM) – specifically the fact that one subtitle file is presented in French, the other in Italian.

Why should the poster image be any different?

The image presented to the end user, whether it is the actual first frame of the video asset, or an image created and selected by the author, will likely have properties as well – often simple/simplistic, but also potentially complex and complicated (for example, all the text in the Clockwork Orange poster). The question then becomes, how important is it to convey those properties to the end user? From an accessibility perspective, I argue important enough that a means of doing so should be provided for, so that authors who *choose* to do so can (while the advocate in me says that it should also be a mandated requirement). Continuing to assert that the poster image is somehow less a piece of the overall sum of parts that is <video> simply leaves open the door that a complex image selected for the poster frame will lack the means to be expressed to non-sighted users BY DESIGN.

This then is the foundation of my argument, and the basis of my Change Proposal. What do *you* think? Is there a flaw in that logic? I welcome your thoughts, so please speak up.

The current problem with the @poster attribute of the <video> element. by John Foliot is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.