20 HTML5 video and Chrome’s one video per page problem

Being a web developer for nearly ten years has taught me to expect the unexpected when creating web pages for the many different browsers used around the world. CSS, accessibility, JavaScript and many other web technologies can’t be relied upon to produce the same results.

But this is a quirk that I didn’t expect – it isn’t possible to have more than one mp4 video on a page in the Chrome browser.

Perhaps we should expect that Chrome will not work well with mp4 video since moving to support the webm format at the beginning of 2011. http://blog.chromium.org/2011/01/html-video-codec-support-in-chrome.html. But Chrome does still play mp4 and in fact makes its default selection mp4 not webm.

Attempting to play multiple mp4 videos in Chrome causes these problems:

·         Chrome does not load one or more of the mp4 videos.

·         Causes Chrome to crash.

·         Will at best play only one video at a time.

The overarching problem is the state of HTML5 and browser implementation of it. When embedding video on web pages we are told current best practice is to have different video sources for different web browsers – mp4 for Safari, iOS, Android and IE and then  webm for Mozilla and Chrome (even though Chrome will still play the mp4). You may even elect to have Flash in there as well. A browser will then select the video it can play and will ignore the rest. It’s an elegant solution to the current issue of differing video format support in browsers. The big problem with this method is that Chrome defaults to the mp4 file. That is fine if only one video is on the page but causes serious problems when there are more.

So what is the answer, how is it fixed?

Use mp4 only in the video tag and show Chrome (and Firefox) the webm file. Chrome happily plays multiple webm files.

I know that seems counterintuitive after all that has just been written. I also know that Firefox, and of course Chrome, will be unable to play mp4 files effectively which is why we need a scripting fix.

JavaScript to the rescue

A JavaScript fix is needed, there isn’t anything else that can be done that I am aware of. Also keep in mind the two video file formats mp4 and webm are still required.

The video tag on your page should be (at a minimum) similar to:

<video width="640" height="360">

<source src="video/example.mp4" type="video/mp4" /> 

</video>

JavaScript, or in my case jQuery, is used to change the .mp4 file extension of the “src” to .webm when the page loads and the video/mp4 type attribute to video/webm when the page loads.

Below is the JavaScript (well jQuery) function that I have used: (the content argument in the function is the html that will be searched through looking for the video tag)

function SwapMP4forWEBM(content){

  if(jQuery.browser.chrome || jQuery.browser.mozilla){

    content.find("video").each(function(){

      $(this).find("source").attr("src", $(this).find("source").attr("src").replace(".mp4", ".webm"))

      $(this).find("source").attr("type", $(this).find("source").attr("type").replace("mp4", "webm"))

    })

  }

  return content.html()

}

That’s it.

Of course it is possible to do it the other way around; webm to mp4, but then you’ll just have to check for more browsers anyway. Added to this is the early iPad quirk of making sure that the mp4 file is the first one in the list of video files, otherwise it confuses the iPad and it can’t find the video to play. While the method really should work anyway on iPad(swapping webm for mp4) I haven’t tried it and why poke the tiger with a big stick if you don’t need to.

19 Accessible HTML5 video player and ARIA

An accessible video player should tell a user what controls they are interacting with and what values those controls currently have. A play button that turns into a pause button must report its current state visually and, for those with a screen reader, audibly. A user also wouldn’t know the current volume, or what the current time of the video is, when the values of those controls don’t update.

These values need to be updated programmatically. I chose to use ARIA as this appears to be the way that the internet is heading and they supply a lot more attributes to play with than just the standard title and alt. A slider can have aria-valuemin, aria-valuemax, aria-valuenow and aria-valuetext for example. Much more information to potentially give a user.

What is ARIA? From the W3C ARIA website http://www.w3.org/WAI/intro/aria.php

‘WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.’

Aria seems to have been around awhile now but it is only at the W3C Candidate Recommendation stage (Stage 2 of a 5 stage recommendation process) as of January 2011. So really it’s just coming online – very similar to HTML 5. It’s all quite new.

So the problem that I found in the implementation of ARIA is, as everyone else has found, patchy browser implementation. Code (JavaScript) used to update the ARIA information is reasonably straightforward. The standard static ARIA attributes and the code updated ARIA attributes provide excellent feedback to a screen reader in Firefox but the code generated attributes provide no feedback in Chrome. Code that does provide feedback in Chrome is triggered twice. At least my code is.

In Chrome I need to make sure that on the slider tag the ARIA attribute role is equal to slider (slider supplied by jQuery). That’s ok. But Firefox doesn’t care if the role attribute is set or not.

The process of incorporating ARIA on the page, into the video player and then updating the ARIA attributes isn’t to complex. What is frustrating is the amount of experimentation required to figure out if it is in fact working properly or not.

I think that it is safe to say that we should try to make our pages as accessible to all users as possible and that ARIA will help to make the web a better place for all. With this in mind we must deal with the frustrations of browser and screen reader limitations and do the best we can until there is a standard that is complete and fully implemented by all.

It should happen shouldn’t it?