HTML 5 has the
video elements that conveniently allow an author to add multimedia to their pages in an intuitive way. The advantage to the consumer is that the files will play in the browser with no plugins, and the data will be in the browser and therefore can be manipulated with scripts.
These elements are supported in Safari 3.1, Firefox 3.5 beta and labs builds of Opera but as yet the proprietary format bickering is unfinished and no single codec is agreed upon. (Until we can use the
video element, there is a way to embed Flash video on a page with valid HTML 5.)
To anyone who’s used to the horrors of YouTube-style
object monsters, the syntax is refreshing:
<video src="xxx.yyy" autoplay controls>
<a href=""xxx.yyy"">Download this video</a>
The autoplay attribute
autoplay is an attribute which makes the media play as soon as it can without prompting the user. This would be a problem for those who work in shared offices and who aren’t expecting depressing midi versions of classic rock songs to blare out when following a link, and would be a huge problem for people who rely on sound for understanding the Web, such as those using a screenreader or talklets, as the sound in a video would drown out all other content on the page.
This attribute can therefore cause annoyance or barrier and I wonder whether these negatives have been considered when the use cases for this attribute were deemed significant enough to merit its inclusion in the specification.
(Update 9 May: See also Autoplay is bad for all users. Hat-tip John Foliot.)
It’s not as if every video content provider is anxious to force their videos to play; some, such as YouTube, do but others, like Vimeo, don’t. Video sites catering to the gentleman’s leisure movie market (ahem) are similarly split: RedTube and YouPorn do begin automatically; Pornorama doesn’t. (See what I have to go through to research this stuff?!?!)
Update 8 May: I’m now reluctantly accepting that
autoplay should stay because, as Simon Pieters points out
Removing the attribute will not make pages stop autoplaying video. Instead they will use script to make videos autoplay, and then it becomes harder for the user to prevent videos from autoplaying. (You could have a pref in the UA to disable autoplay.)
The controls attribute
controls is a boolean attribute which, if present, means that you want the browser to give stop/ play/ pause buttons etc. If it’s absent, it’s assumed that you are scripting your own controls. The
controls spec says
User agents may make the following features available, however, even when the attribute is absent: … controls to affect playback of the media resource (e.g. play, pause, seeking, and volume controls), but such features should not interfere with the page’s normal rendering. For example, such features could be exposed in the media element’s context menu.
Given that autoplaying audio may significantly interfere with the page’s normal rendering in a screenreader, I think that the spec should say that user agents must provide a mechanism to mute or pause media. I’ve written to the working group to suggest this.
Update 8 May: So far, the response has been disappointing, with some pointing to the fact that the operating system has the ability to mute content. The trouble is that muting via the operating system will mute the screenreader as well as the autoplayed media. As a blind developer commented on twitter, “you’d be pretty unpopular if you did that to me”
The draft User Agent Accessibility Guidelines (UAAG) 2.0 has guideline 4.9 “Provide control of content that may reduce accessibility” with a success criterion
4.9.7 Stop/Pause/Resume Multimedia: The user can stop, pause, and resume rendered audio and animation content (including video and animated images) that last three or more seconds at their default playback rate. (Level A)
Given that the HTML 5 spec already strays way out into accessibility territory by pronouncing on alt text, and is as much for implementors as for content authors, I think it should confirm what the draft UAAG says.
Accessibility of content
You’ll notice that in the code example above, the content of the
video element is fallback content for browsers that can’t render the new element. In this case, it’s a link wher the user can get the video file to view offline. (This is exactly the same model as the content of an
iframe in HTML 4).
video spec says
Note: In particular, this content is not fallback content intended to address accessibility concerns. To make video content accessible to the blind, deaf, and those with other physical or cognitive disabilities, authors are expected to provide alternative media streams and/or to embed accessibility aids (such as caption or subtitle tracks) into their media streams.
This is radical stuff, but I think that it’s the right way to go. These days, content from one source is embedded into countless websites – see Flickr or YouTube. It’s wishful thinking to assume that everyone who wishes to syndicate the content will copy and paste accessibility information; we can see this in specs like oEmbed which is “a format for allowing an embedded representation of a URL on third party sites. The simple API allows a website to display embedded content (such as photos or videos) when a user posts a link to that resource” yet its authors don’t think that alternate text was worth including when embedding a picture.
So it’s better that the originator of the content writes/ provides the accessibility information just once and it’s accessible wherever it’s embedded through some kind of interface in the browser. (I expected the spec for
controls to say that, whether or not the attribute is present, the user agent must provide a mechanism for accessing the embedded alternative content, but it is silent on this.)
So philosophically, I support the write-once-carry-everywhere model for media accessibility. But how would I author it? I’ve made a few videos with Windows Movie Maker that I’ve uploaded to YouTube, and published my songs in the (proprietary) mp3 format, but I have no idea which formats carry synchronised captioning or transcription information within them, or what authoring tools I can use.
Are there any?
(Related plug: under the banner of standards.next, I’m talking about HTML 5 at a free meet-up in London on —the day after @media—with Molly, Remy Sharp, Dean Edwards and hopefully others. Details.)