Showing posts with label javascript. Show all posts
Showing posts with label javascript. Show all posts

Thursday, 14 March 2013

24 Trials of an accessible video player


Over the last week and a half I have been trialling the video player with different groups of students. The groups were trade students, students with English as a second language and students with a mild intellectual disability participating in a general work education class.

It was nice to leave the computer for a bit, talk to some real people and see them using the video player with ease.

The students were asked to watch some videos and after doing this they were then to try to “break” the video player. Luckily no-one succeeded. The students were later asked these questions:

  • What do you think would make the video player better
    – there were no responses to this question other than “it was fine”, “it worked” and “it would be good if the video had little thumbnails so you can see the detail of what he is talking about.” (I pointed out that the second video actually had that – and this statement is about the video not the video player)
  • What did you not like about the player?
    – again the responses were positive.
  • Can you tell me what each of the buttons on the video player are for?
     – The common controls were identified easily. Some weren’t able to name the captions button but knew that it put up subtitles. No-one figured out what he audio description button did. I believe this is because they had no use for it (until later in the testing). One student suggested that the fast forward and backward buttons were skip one frame forward and back.
  • Are there any other comments?
     – “The subtitles were good because I can read English better than I can understand it”
After the feedback I asked some students, approximately half of the students involved in the trial including the general work education class, to use the player pretending to be blind, deaf or have a motor skill disability.

For the students pretending to be blind I started the NVDA screen reader software and turned off their monitor so they “couldn’t see” anymore. I told them to use the Tab and enter keys for navigation. All students could navigate the entire page and video player. These students also gained an understanding of the importance of an audio description.

My “deaf” students had to turn down the sound on the computer/video player or take out their ear phones. These students used the captions to understand the content of the video. Some did need reminding to turn the captions on.

The remaining students with “poor motor skills” had to navigate the page and the video player without using a mouse. All could do this without issue.

I would have to say the testing of the video player went quite smoothly although three technical issues cropped up. Two quite small and fixable and one appearing to be a browser issue.

Issue one:
When trying to change the colour of the captions in full screen mode the Caption Settings dialog box is not keyboard accessible. I found this about ten minutes before the first session. I believe this has something to do with a variable being switched on while in full screen mode that makes it easier to navigate the video player. This variable needs to be switched off when the dialog opens.

Issue two:
Right clicking on the video itself reveals a menu that can be used to control the player, in Chrome at least. Selecting pause from the menu pauses the video but doesn’t switch the play-pause icon on the player itself. Not sure about that one…

Issue three:
Twice the video froze. The students and I could not restart the video without refreshing the page. I am not sure what the problem is although it is likely to be multiple mp4 videos running on a single Chrome web page. This issue was mentioned in a previous post.

Monday, 4 March 2013

23 Fullscreen video


One of the most enjoyable features of modern browsers is their ability of displaying page elements fullscreen. Video, for example, should have the option of playing fullscreen and not just being a box on the page.

Amazingly a fullscreen option, for me, has been very complex to produce for an accessible video player currently in development. This is for a few reasons:

  • Fullscreen is reasonably new and initially it seems an easy concept though it becomes a little unclear how it works
  • Most of the keyboard is disabled for security reasons
  • If there is more than one video player on the web page how is the current video identified and then shown fullscreen
  • While in fullscreen mode how can the current video player maintain keyboard focus. (While in fullscreen the keyboard still has access to the Tab key.)


How I think fullscreen works

Initially I thought that fullscreen might be a new window that appears with the content inside it. This would mean that fullscreen operated like a dialog, or popup, that is seen a lot on web pages. But this isn’t the case. Also fullscreen is definitely not modal. This means that keyboard focus would be contained within the element that is currently fullscreen and access to other elements on the page disabled.

The element running at fullscreen is not removed from the page tab order, nor is anything else on the page (which is currently hidden by the fullscreen element). To me this means that fullscreen clearly doesn’t make a new window or popup dialog.

Essentially the object running at fullscreen is zoomed into. It makes things bigger and removes the browser chrome. As the object is only zoomed into it is not removed from the page tab order. There are no new containers created that I know of or need to care about.

So something will need to happen to capture focus and make fullscreen function like a modal dialog box if fullscreen and accessible page elements is your goal.


Why are some of the keyboard keys disabled?

It’s believed that some, less than savoury developers, could use the fullscreen option to convince users that they are looking at their own computer screen while they are actually still on a malicious website. Then they could capture important personal information while the user is sure that they are in a secure place.

So this means that if I would like to use P for a play button - I can’t. Therefore the tab key is needed to access video player controls and other items that are running fullscreen.

NOTE: There are some ways of enabling the keyboard while in fullscreen though it is not consistently supported by browsers and in the end it wasn’t needed for this project.


Show the current video player fullscreen

This was the easiest part really, just need the order of events to fire at the right time. I identified the current video player on the mouse and key down events and accessed that information at a later point. Sometimes identifying an element on the up event is too late, or harder to sequence. This is especially the case when using a JavaScript library developed by others and you aren’t always sure when the event is firing.

NOTE: Did you know when the tab key is pressed that the next element is focused on when the key down event happens not on the key up event. Keyboards are different to mice. This helps a user move through the page quickly by holding down the tab key rather than pressing and releasing the key perhaps hundreds of times. This is true of all keys on the keyboard.


Maintaining keyboard focus

In the end the answer was easy. Thanks to Bronwyn Lapham.

Initially there was a lot of searching for answers to maintaining keyboard focus on or within an element and there were many trials and many errors. A method of turning off the tab indexes of elements not contained within in the current fullscreen video player was developed and worked reasonably well. My first programming teacher once described his programming on an example he put together as “a bit agricultural”. It gets the job done but isn’t very elegant. That was the code that I produced.

Bronwyn forwarded an article “Making an accessible dialog box” that I thought wouldn’t help because fullscreen doesn’t work like a dialog box; it zooms into an element.

While the article did specifically talk about ARIA roles and modality etc it also provided some code that I have not seen before although is apparently used by everyone. Finally I have caught up.

This following “.. technique was popularised by Peter-Paul Koch and is now in use by most JavaScript libraries” was used to create a tab enabled fullscreen video player. The code and more is explained thoroughly in the article above so I won’t do it again here and the adjustments were minor and dealt mainly with variable scope.

document.addEventListener("focus", function(event) {

    var dialog = document.getElementById("my-dialog");

    if (dialogOpen && !dialog.contains(event.target)) {
        event.stopPropagation();
        dialog.focus();
    }

}, true);

document.addEventListener("keydown", function(event) {
    if (dialogOpen && event.keyCode == 27) {
        // close the dialog
    }
}, true);
 


It is REALLY important to note that I needed to change the keydown event to keyup. I believe this is because while in fullscreen mode the escape key (27) on keydown only exits fullscreen mode. No other code seems to fire on that event – this is my assumption I didn’t challenge it to hard. Changing to keyup was successful because the player exited fullscreen on the keydown event. The escape key was now again available for the keyup event.

Thankyou Bronwyn (and Peter-Paul Koch), without this article I might have been able to do it but this was a much better way of getting everything to work. Not agricultural at all.


Wednesday, 13 February 2013

21 Making code more robust

Ok, so this week sees me looking at the code and thinking that it could be a lot neater, more general and apply to more situations.  I find when I begin programming a new project I make my code very specific. I 'talk' to my objects directly by name rather than the better method of being general by referring to parents and children of them.

Being direct makes it easier, in my mind anyway, to get results quickly. This is because I know where I am going wrong when things aren't working for the path to the object is clear, or, clearly wrong. But lately I can see the flaw in this in starting this way.

It's no good to be specific with code that you may use more than once on a page. I have to control more than one video player for example. Therefore I will have to speak generally to all video players which is much more efficient than speaking to one at a time.

I've made a start hopefully it makes it better.



Sunday, 20 January 2013

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.

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?

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, 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'.


Tuesday, 22 May 2012

11 Thoughts on HTML5 video and subtitles

In due time, HTML5 will make the work of a web developer more efficient and effective. Once the final video format is chosen, embedding video in HTML5 webpages will become less complex.  In addition, the implementation of subtitles using the <track> tag will eventually require less or no JavaScript fixes.

In the meantime, a Flash fall-back will be necessary as IE8 is expected to be used widely until 2015 when Microsoft stops support for Windows XP and it currently does not support the <video> tag.

There is still some degree of complexity in creating subtitles, in that there is a lack of available software for easy and less time consuming file conversion to HTML5 compatible formats. However, this may change at some stage as the available features in Universal Subtitles/Amara were better than expected and have the potential to be developed further.

Google are currently working on providing subtitles in YouTube by developing voice recognition. However this needs further refinement as when voice recognition was tested with video accompanied by good quality audio; approximately 10% of what was said was correct. Discussion of these results can be viewed here: http://www.youtube.com/watch?v=krq1msguNFo.

It was not possible to locate information that indicated how iOS or Android will support HTML5/web based subtitles in the future. This was a little disappointing as these devices seem to be behind the rapid uptake of HTML5 among web developers. Perhaps changes will occur when the HTML5 specification is completed.

Currently there is a lack of tools that will create, or help to create, WebVTT format files. It is expected that this will change as the format is very similar to the fairly common SRT format and may not require major changes to existing software. Over the life of the project it has been noted that changes were still happening and there was an increase in available tools. (Such is the rate of change that the information in this document was frequently changed to include new developments.)

BubbleJS http://bubbles.childnodes.com/ provides a promising future for both triggering subtitles successfully and providing a high functioning video player. The BubbleJS player can trigger actions that happen outside of the video player such as opening, closing, animating, effecting colour changes etc. on other html objects. This is an excellent result for education in that it provides a video player with accessible video that interacts with other page elements to present information related to the video, in engaging and innovative ways. Hopefully the setup of BubbleJS becomes easier.

Working with video on the web has, over the years, become much easier and a lot of time savings can be found in good processes and work practices. Hopefully the time saved can be dedicated to the creation of subtitles and accessible video for all internet users.

Related posts:

Accessible HTML5 video for all
How to create a basic HTML5 webpage
Fall back to Flash
Current HTML5 subtitle support
Subtitle creation process
Link subtitles to video
Making subtitles work now
A Flash solution
Making it work now, on an Android device
Making it work now, on an Apple device
Thoughts on HTML5 video and subtitles - conclusion

10 Making it work now, on an Apple device

Apple iOS devices such as the iPhone, iPod and iPad work differently with video in web pages. Rather than playing the video directly in the webpage the video opens in the inbuilt iOS video player. This means that any subtitles provided by the web page will not be visible as the video is not displayed in the webpage.

The best way to provide a solution is to return to Handbrake so that subtitles can be directly encoded onto the video. This section will provide instructions on this process.

A video demonstration of the steps below is available here: http://www.youtube.com/watch?v=SiBJtF7bQOs

Step 1:
Encode the video with subtitles*. ( The subs.srt file will be used for this purpose)
  • Open the Handbrake application
  • Locate and use the original video file, do not use any of the videos previously encoded and compressed, using these videos would only produce a poor quality result as you would be recompressing an already compressed video.
  • Make the exported file name html5exsubs.mp4
  • Select the tab labelled ‘Subtitles’
  • Select the ‘Add External SRT’ button
  • Navigate to the ‘website’ folder
  • Choose the subs.srt file
  • Press the Start button to begin the encoding process.
  • When encoding is finished move the new MP4 file to the ‘website’ folder
Links to the completed videos and website folder can be found at the bottom of the page.


Step 2:
Link the new subtitled video to the webpage.
  • Change the first <source> tag from this
<source src="html5videoex.mp4" type="video/mp4" />
  • To this:
<source src="html5exsubs.mp4" type="video/mp4" />

Upload the new video file and the changes to the webpage and test the webpage on an iOS device such as an iPad.
  • Select the subtitles button when the video loads in the video player to see the encoded subtitles with the video.


NOTE*: Encoding subtitles directly into the video does not mean the HTML based webpage no longer needs the <track> tag. The above is a ‘fix’ for providing subtitles on an iOS device only.


It didn’t work on the iPad?

Not all versions of iPads are the same.  At the time of writing, iPad 1,2 and 3 were available. When testing the procedure outlined above, both iPad 1 and iPad 2 gave different results. On some iPads the video played well however on others there was a conflict between playr.js JavaScript library and the iPad, as playr.js JavaScript library tried to override the iPad in how the video was played.

This problem can be is solved by amending the JavaScript for Android so that subtitles are consistently available on iPad devices as per instructions below:

Step 1
Amend the JavaScript for Android in the <head> of the html5video.htm webpage so it appears as below:

<script type="text/javascript">
$(document).ready(function(){
if(navigator.userAgent.toLowerCase().indexOf("android") > -1) {
$("<div id='flashContent'></div>").insertBefore("video");
swfobject.embedSWF($("video object").attr("data")+"?", "flashContent", $("video object").attr("width"), $("video object").attr("height"), "9.0.0");
$("video").remove();
}

if(navigator.userAgent.match(/iPhone/i) || navigator.userAgent.match(/iPad/i) || navigator.userAgent.match(/iPod/i)){
$("video").removeAttr("class")
}
})
</script>

This JavaScript removes the ‘class’ attribute from the <video> tag that triggers the playr.js script to create the video player. This means that the video will display in the webpage as normal HTML5 video does on an iPad and the subtitles will be available when the video is played in the native iPad video player.

Related posts:

Accessible HTML5 video for all
How to create a basic HTML5 webpage
Fall back to Flash
Current HTML5 subtitle support
Subtitle creation process
Link subtitles to video
Making subtitles work now
A Flash solution
Making it work now, on an Android device
Making it work now, on an Apple device
Thoughts on HTML5 video and subtitles - conclusion

Downloads

09 Making it work now, on an Android device

Androids are more complex. The video opens in a native Android player and does not play in the webpage directly because the subtitle track is ignored by the internal Android video player. While it is possible to embed subtitles on the video (as described in the post Making It Work Now on an Apple Device) the current Android video player does not give the option of selecting them.

Therefore a Flash alternative that does supply subtitles is required. To supply the Flash alternative a Flash fall-back in the HTML5 <video> tag is needed in combination with a JavaScript fix that:
  • removes the <video> tag completely (which, as a by-product removes the HTML5 Flash fall-back)
  • re-embeds the Flash video.
In order to implement HTML5 and video in the easiest most conformant and future proof way, two JavaScript libraries were used;  SWFObject and jQuery, and a short customised script.


Note: Custom JavaScript could have been written to do everything mentioned above though it is easier to implement the proposed fixes using these common JavaScript libraries. JQuery is becoming more widely used and it is not unlikely that it is already available on the page that will hold the video that requires this fix.

Add the required JavaScript to the page

Step 1:
Download the required JavaScript libraries SWFObject and jQuery.
At the time of writing the current versions are SWFObject2.2 and jQuery 1.7.2 use the latest versions that you can find to ensure cross browser compatibility.

Step 2:
  • Place the JavaScript files into the ‘website’ folder*.
Note*: When the SWFObject folder is unzipped it creates a number of folders that contain examples of how to use it and 2 SWFObject JavaScript files. Both files will work though the one file that is used in the examples below is the minified version found in the folder: swfobject_2_2/swfobject/swfobject.js.
  • The files now in the ‘website’ folder should appear as below:
  • videoplayer.fla
  • videoplayer.swf
  • SkinUnderPlayStopSeekCaptionVol.swf
  • html5videoex.mp4
  • html5videoex.webm
  • html5video.htm
  • subs.vtt
  • subs.xml
  • playr.js
  • playr.css
  • images (folder)
  • jquery-1.7.2.min.js (or similar depending on current version)
  • swfobject.js (or similar depending on current version)
Links to the downloaded JavaScript files, videos and website folder can be found at the bottom of the page.


Step 3:
  • Open html5video.htm in a preferred web editor
  • Paste the following HTML into the <head> of the document above the playr.js link. Ensure that the same order as below is kept as it is important.


<link rel="stylesheet" type="text/css" href="playr.css" />
<script src="jquery-1.7.2.min.js" type="text/javascript" language="javascript"></script>
<script src="swfobject.js" type="text/javascript" language="javascript"></script>
<script src="playr.js" type="text/javascript"></script>


Step 4:
This step will:
  • include some custom code that inserts a flash object
  • use information from the flash fall-back in the video tag
  • remove the <video> tag completely
  • complete the process on an Android device only.
  1. Insert the code below between the swfobject.js and playr.js <script> tags.
The code below waits until the page is ready. Once the page is ready it looks for the Android* operating system (OS) and if it finds the Android OS it:
  • creates a <div> for the new Flash to be embedded in
  • embeds the Flash video into the newly created <div> using information that is obtained from the Flash fall-back in the <video> tag
  • deletes the <video> tag from the page as it is no longer required


<script src="swfobject.js" type="text/javascript" language="javascript"></script>
<script type="text/javascript">
$(document).ready(function(){
if(navigator.userAgent.toLowerCase().indexOf("android") > -1) {
$("<div id='flashContent'></div>").insertBefore("video");
swfobject.embedSWF($("video object").attr("data")+”?”, "flashContent", $("video object").attr("width"), $("video object").attr("height"), "9.0.0");  //all on one line.
$("video").remove();
}
})
</script>
<script src="playr.js" type="text/javascript"></script>



IMPORTANT NOTE*: For some reason Flash video does not work on Android in a Flash video player **unless there is a question mark (?) after the path to the Flash file. A question mark is used to send information from the web page back into Flash. This is why there is a question mark in the code above - ($("video object").attr("data")+”?”, – If variables are being sent to Flash from the standard Flash embed created in the HTML5 <video> tags it is wise to remove the question mark from the JavaScript code. Here is the amended code - ($("video object").attr("data"),


NOTE**: playr.js still runs though it does not find a <video> tag and does not initialize any code that causes confusion for the Android device.


Step 5:

Upload the website and test this on an Android device.

Related posts:

Accessible HTML5 video for all
How to create a basic HTML5 webpage
Fall back to Flash
Current HTML5 subtitle support
Subtitle creation process
Link subtitles to video
Making subtitles work now
A Flash solution
Making it work now, on an Android device
Making it work now, on an Apple device

Downloads

07 Making subtitles work now

Making the <track> tag work in modern web browsers

At the time of writing there are three JavaScript solutions that offer the required subtitle functionality to the <video> tag; Playr.js, MediaElement and BubbleJS.

Playr.js
The chosen JavaScript solution for this project is playr.js.(Instructions on downloading and using playr.js are outlined in Downloading and Using Playr.js)


Media Element
MediaElement.js http://mediaelementjs.com/, appears to be a robust alternative though the configuration is more complex than other available options.

BubbleJS
BubbleJS http://bubbles.childnodes.com/  is well designed and has the most potential for the creation of interesting video interaction in the future. The downside to this however is that it has some features which make it less compliant and easy to use. For example:
  • it only supports .srt subtitles
  • it has a complex setup which makes it difficult for beginners
  • the subtitle track is linked through JavaScript not by the <track> tag in the HTML.

Downloading and using playr.js

Playr.js is downloadable here: https://github.com/delphiki/Playr

Step 1:
  • Download the repository as a zip file by selecting the ZIP icon
Download repository as a zip button found at the site mentioned in the above text.

  • Unzip the files and then place them into the ‘website’ folder created earlier.
  • Delete the files called CHANGELOG.markdown and README.markdown(  they are not important for implementing subtitles).
Your website folder should now include these files and folders:
  • videoplayer.fla
  • videoplayer.swf
  • SkinUnderPlayStopSeekCaptionVol.swf
  • html5videoex.mp4
  • html5videoex.webm
  • html5video.htm
  • subs.vtt
  • subs.xml
  • playr.js
  • playr.css
  • images (folder)
Links to the downloaded JavaScript files, videos and website folder can be found at the bottom of the page.


Step 2:
Now link the required files to the webpage.
  • Change the <head> of the HTML to appear as below:  (This will link the required JavaScript to the webpage.)


<head>
<title>My HTML5 Video Page</title>
<link rel="stylesheet" type="text/css" href="playr.css" />
<script src="playr.js" type="text/javascript"></script>
</head>



Step 3:
To enable the JavaScript a small change needs to be made to the <video> tag.
  • Update the <video> tag so that it matches below:
<video class="playr_video" width="640" height="360" controls="controls">
  • Save and test the web page in a modern browser.
Subtitles should appear on the page over the video, if they do not, use the video controls that appear underneath the video to show the captions.*

NOTE: * There is a current issue (April 2012) with Google Chrome where the subtitles will not appear unless the video is being viewed over the internet. Local computer testing does not work. Either upload the ‘website’ folder to the internet or test using another browser such as Firefox.

Related posts:

Accessible HTML5 video for all
How to create a basic HTML5 webpage
Fall back to Flash
Current HTML5 subtitle support
Subtitle creation process
Link subtitles to video
Making subtitles work now
A Flash solution
Making it work now, on an Android device
Making it work now, on an Apple device
Thoughts on HTML5 video and subtitles - conclusion

Downloads