16 Converge 2012 eLearning Conference Presentation

Last week I presented a paper on the first stage of creating an accessible video player at the Converge 2012 eLearning Conference.

The discussion was about Stage 1 of this project, essentially providing captions for video, and focused on the topics:

• Captions must be easy for people to implement
• How are captions made available.

The second topic was easy enough; I went through the process of developing and implementing captions, it was quite dry and hopefully not overly technical.

After the presentation one of the delegates came up and started to discuss alternatives to the JavaScript used for Android and iOS device 'fixes'. He offered other alternatives that I thought were a bit more complex and would need some technical setup that mine didn't. He said that there was some JavaScript setup required in the alternative but he felt that my example already had JavaScript on the page so what was the difference. By it's mere presence it is perceived as too complex or technical.

I thought he had a point and I didn't have a reasonable answer other than any solution should produce/use  HTML5 'code' only with JavaScript in support. Using HTML5 on the page only will mean when HTML5 is fully implemented developers should only need to remove JavaScript from the page and not have to redevelop it.

When I thought about it more and looked at the JavaScript that was left in my example I couldn't see anything that the user/developer would need to change. This made me see my small mistake - there is no need for that JavaScript to be on the HTML page at all, it should be 'hidden' away in a linked file somewhere. Doing this removes all code from the page making it just that little bit easier. If it is visually easy to implement people won't be frightened off by it.

I need to remember this while working on this second stage of the project - get ALL of the code off the page if at all possible.

15 HTML5 video player - sync a second audio track

This week I am thinking about a second audio track for my video that provides audio descriptions for people with visual impairment.

To describe the problem that a second track would solve let's think about an actual classroom setting with a teacher demonstrating a task to a number of students. The teacher might say something like "Ok it is very important that you take this here and wrap it 5 times around this coil - but not the other coil. Before you turn it on make sure you press this button over here before flicking the power switch." Obviously the student can hear the teacher but might be stuck in the back of the classroom behind taller students and miss the visual information. If that is the case it is completely unclear what the teacher is talking about.

Many videos available online are excellent but every now and then slip into using non-descriptive words like 'this' and 'that'. If the user can't see what 'this' and 'that' are an otherwise excellent video can be rendered useless to them.

Early in 2011 Sylvia Pfeiffer at WHATWG and W3C were working on "... new HTML markup and a JavaScript interface for dealing with audio or video content that has more than just one audio and video track." Read the whole article: HTML5 multi-track audio or video.

This HTML markup should solve the problem of video with alternate tracks though it's not yet supported in current browsers. So what about now?

It turns out it isn't that hard to have a second audio track and to keep it relatively in sync with the video that is playing.

I have done it this way (basically):

1. Place some video on a HTML5 web page (using the video tag of course... not flash :-) )
2. Give the video tag an ID of videoTrack
3. Now add the audio track to the web page also (for my test I stripped the audio from the video so I could confirm if the audio was in fact in sync with the video)
4. Give the audio tag an ID of audioTrack
5. Create a function in JavaScript that looks like the one below:

function syncTracks(){

   var audio = document.getElementById("audioTrack"); 

   var video = document.getElementById("videoTrack");

   audio.currentTime = video.currentTime

}

Pretty much as easy as that, set the current time of the audio track to the current time of the video.  Essentially all that needs to happen now is to call the syncTracks() function whenever the video is played, paused or stopped.

NOTE: The video controls should also control the audio playback.

There is a big BUT!

The currentTime property of the video only seems to start updating when the video is running for a short time. I found that the audio track and the video gets out of sync by about a second or so depending on how the user interacts with play and pause buttons.

To circumvent this I created a timer which is called when play is pressed. It waits for about a tenth of a second and THEN calls the syncTracks() function. This works much better. The sound is only ever a small fraction of a second out using this method.

Here is the timer I used:

setTimeout(function(){syncTracks()},100)

While this is not perfect it is better than the alternative of waiting for browser support for multiple tracks.

14 Accessible HTML5 video player project - subtitle choices

An accessible HTML5 video player should have subtitles - that's a given. But how should those subtitles be displayed? Should they just be white text on a black background?

Well, no.

What if the black background is covering an important occurrence in the video. The person will obviously miss it and not learn everything from the video they may need to. So should the background be transparent? By how much?

Even these few questions point to a need for subtitle settings.

The video player being developed in this project should have subtitle settings that can:

• change background colours
• adjust the transparency of the background
• change the font type
• change font colour
• increase or decrease the font size.

Apart from the settings the subtitles should be movable and sizable. 

What else should subtitles do? Should there be an option of more than one subtitle track, for another language perhaps?

When the settings are open should they be keyboard and screen reader accessible, and should the controls of the video player itself still be accessible?

Lots of questions this week.