Wednesday, 19 December 2012

18 Fullscreen video - hide everything accept the video player

Internet based videos need the option of playing full screen, I think that everyone expects this now. The player still needs to be accessible but nothing else on the page should be; links or any other items for example. 

Why should the user be able to tab to an item that is no longer needed if the video is playing full screen? Of course the answer is that they shouldn't, it is really confusing when it happens.

The video player being developed is currently in a <div> tag called #vidPlayerContainer. I want to keep that item visible and hide everything else. To do this I change the CSS display to none for all other objects. Doing this removes all of those items from the tab order.

To do that I used this nice piece of jQuery I found on Stackoverflow which does just that, it runs whenever the full screen mode changes:

$('body > :not(#vidPlayerContainer)').toggle();

The code says find anything inside the body and toggle it on or off as long as it is not #vidPlayerContainer. Pretty neat and a lot more concise than the horrible loops (and hoops) I was planning to jump through.

It's still possible, fortunately/unfortunately, to tab to the browser chrome in some browsers, which feels a bit annoying. I'll look into that further in the new year.

Happy New Year everyone.


Sunday, 9 December 2012

17 Creating a new batch of subtitles

This week sees me doing a bit of subtitling work.

As mentioned in previous posts the best place (in my opinion) for creating subtitles for video (for free) is the Amara/Universal Subtitles site.

While saving my subtitles I noticed a small change - it is now possible to save the subtitles into different formats other than SRT. No unfortunately not WebVTT but it is possible to save directly into the required Flash subtitle format TTML.

One small subtitle conversion step removed from the subtitling process.

It keeps getting easier.

Thursday, 29 November 2012

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.


Thursday, 15 November 2012

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.






Thursday, 8 November 2012

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.

Wednesday, 31 October 2012

13 Making an accessible HTML5 video player - first steps

Early attempts at making an accessible video player have been quite positive, buttons are working and are accessible with a keyboard and screen reader. There are no keyboard traps and the video player works in all HTML5 enabled browsers. Embedding the video player on the page is still quite simple and no special Javascript initialisation is required. There are no HTML5 tricks or work rounds required to get it to work.

So what have I learnt so far? I've learnt about fullscreen video playback.

An interesting point to note about video players in fullscreen.


Before this project started many different video players were reviewed. One in particular was found to be very accessible though not at all accessible in fullscreen mode. When the player was in fullscreen mode all controls disappeared and it was possible to tab to other items on the web page that were covered by the fullscreen video. This was very confusing but it is true of many video players and in fact many HTML items that are shown in fullscreen mode.

Problem number one for this project; how to turn off access to all other tab enabled HTML objects when the video is showing in fullscreen.

It turns out to be fairly easy, anything that has a CSS property of display:none is removed from the tab order.  Javascript is used to 'hide' all items that are not part of the video player in fullscreen mode and 'show' them when not in fullscreen mode. Currently JQuery's toggle function is doing this work.

The video controls that are part of your player also need to move depending on the current mode of the player. Currently the controls that are being used sit underneath the video when in normal mode but when the  player is set to fullscreen there is obviously no room for the controls to sit underneath. CSS is used to resize and move the controls when the video player enters and leaves fullscreen mode. Again the JQuery toggle function is used to achieve this.

I am sure that there are other ways of doing this and I leave this post thinking about my next internet search "Creating a modal window with Javascript'.


Monday, 8 October 2012

12 Accessible Modern Video For All - Stage 2

Our team were pleased to receive funding for the continuation of the Accessible Modern Video For All project. This second stage will attempt to create an accessible HTML5 and JavaScript based video player for modern web browsers. This video player will be designed to meet accessibility standards including WCAG2 level AA.

While there are many video players available that are quite accessible none have been identified as being completely accessible to all users. These players may be missing some valuable information such as labels for controls, feedback on the position of sliders (volume or time), provision of colour, font and font size choices for captions. One excellent example appeared to be completely accessible except for feedback on sliders that was unclear and difficult to access and it was also unfortunately completely inaccessible when run in full screen mode.

Common HTML5 and JavaScript based video players can also be notoriously difficult for the layperson to include on the web page and may not meet the HTML5 standard (as it is at this point in time) at all.

Our plan is to keep it as easy as possible for everyone to implement and maintain a video player on a web page and to make that video player accessible to all. We hope to contain all JavaScript, that can confuse people, in external files and to use HTML5 markup only to keep implementation as simple as possible.

The video player will be tested with students who work in noisy environments, students who come from culturally and linguistically diverse backgrounds and students who may have hearing or visual impairments.

Our team is excited by this opportunity and we hope we are ultimately successful in providing an accessible modern video player for all.