Tony Hirst has just blogged about the Office for Disability Issues new accessible media player AKA the "Most Accessible Media Player on the Web". Both he and Will Woods have alluded to work that The Open University is undertaking. I thought I'd fill in the gaps.

The OU is at the start of a 6 month development to create a multimedia player that (we hope):

  1. Will be an "attractive" player that the average designer/ blogger would be happy to use on their site.
  2. Can be used in a variety of contexts - our Moodle-based virtual learning environment, OpenLearn, OU-Drupal sites, blogs, Cloudworks...
  3. Will deliver content mostly from the OU podcast site in the contexts mentioned above.
  4. Will be accessible to users with disabilities - both in terms of control, and display of alternatives like transcripts and captions.
  5. Usable on a variety of devices, including mobiles and tablets.
  6. Will be delivered in a maintainable way.

Taking points 1 and 2 together, my personal mantra is "If its accessible, but not attractive then we haven't succeeded". So we are talking unobtrusive accessibility.

Taking the final point regarding delivery. The main method for embedding the player, will be using a REST-ful web service, based on the oEmbed specification. This service is available for many providers, including YouTube, Flickr, Slideshare, Vimeo... See the oohEmbed and Embedly sites. This will be transparent to the end-user and the author of content. An author on a Wordpress blog will merely type something like:

 [embed] http://podcast.open.ac.uk/pod/mst209-fun-of-the-fair#079b8e506c [/embed]

The blog software will handle the rest. oEmbed is used or consumed by various software/sites, including Wordpress 2.9 onwards, the new Twitter, Ars Technica, StatusNet, and our own Cloudworks/ CloudEngine. Many multimedia providers can be plugged in with little effort, a great benefit, so authors will be able to embed from YouTube, Flickr and OU-podcast in the same way. The promotion of a service-based approach does not preclude bloggers from using conventional embed codes/snippets.

The player itself will probably be Flash-based on desktops, and will fallback to HTML5 for tablets and mobiles. This is dictated by the encoding infrastructure on the podcast site, and the current state of the various video and audio codecs.

The controls/ buttons for the player will be HTML and Javascript-based, not Flash-based. This follows examples like Chris Heilmann's Easy YouTube player, and builds on my own MALT Wiki prototype (MALT Wiki is used by Cloudworks, and is oEmbed-based).

We will be using third-party Flash and Javascript components where possible, and implementing the player and web service.

As to the evaluations that we have done. Back in March 2009, I evaluated players including YouTube, Easy YouTube, jwPlayer, NCAM's ccPlayer and Flowplayer. See slide 18 of this presentation and this spreadsheet. I tested with screen readers (JAWS, and NVDA), and also compared APIs for the players (how "scriptable" they were), licenses and so on.

As part of the current player project I wrote a design brief with screen shots of various existing players outside and inside the OU. This included YouTube, EasyYouTube and the ODI media player - a late addition. It was not an evaluation per se. It instead presented what was out there - we may want to use some features, we may not.

In the current project plan, we have built in accessibility testing, using expert evaluation. And we hope to do testing with real users too, using the Jennie Lee laboratories.

I'll conclude by saying that we hope the player will be accessible and will meet the needs of authors/ bloggers and end users. I don't think we will claim to be "the most accessible player on the Web". After all that sets you up for a world of criticism!

Feedback and ideas are as ever welcome.

Comments

html5

Great stuff - and a brilliant blog….. just one thing, did you notice how the Google logo reacted when you ‘shook’ the window?

No problem Nick - I should

No problem Nick - I should have emailed you to point it out.

Hmm, Silvia Pfeiffer points out that while we wait for full WebVTT support, flash and Javascript solutions are not searchable on the web - search will be a massive win.
http://twitter.com/silviapfeiffer/status/35520764308365312

Also have you seen Mike Wald's synote? Your solution would benefit that, plus scope for collaboration?
http://www.synote.ecs.soton.ac.uk/
Happy to introduce you.

Don't forget OSS Watch are here to help with the open development of your solution. Just email us at info@

Hi Steve... I very much take your point

Hi Steve,

My apologies. I had disabled comments by mistake :( - they're back on.

I very much take your point. I'm a big fan of HTML5 and open-source/ standards, and they influence many of my projects, including CloudEngine.

Two points in response:

  1. We felt we had to take a pragmatic approach to HTML5 and encoding, based on what the OU's podcast infrastructure can support, and the capabilities/ maturity of the various codecs. It's my understanding that it is difficult to seek efficiently within videos encoded using WebM or Ogg Theora - a feature that is very useful.
  2. A major benefit of the oEmbed service-based approach is that it allows the video/ audio embed code to be modified once by the provider (us/ the podcast site). Depending on cache settings, those modifications are then seen wherever the embed code is used. So, at a later time (hopefully not much later), we can modify the embed to be HTML5 falling back to Flash.

My feeling is that oEmbed will be useful in helping lots of the big multimedia sites transition to HTML5.

So, not ideal, but I hope this helps allay your concerns!

Nick