Tuesday, 16 April 2013

25 The project continues


The code for the accessible HTML5 video player is now as neat as I can make it and the student trials have been successful. I believe that I have made it as easy as possible to put accessible HTML5 video on a web page without users having to know JavaScript intimately (other than how to link the JavaScript source files).

Over the next month I will write up our project findings, create a short 'how to' guide and submit them along with the video player to the funding body. I hope they agree it is an accessible video player or at least it is what can be achieved within the confines of current browsers.

After so many years developing tools for the Internet I am still surprised at how diversely browsers will display the same content.

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

22 I think it works - an accessible HTML5 video player

So, I think, other than a lot of cleaning up, I have an accessible video player.

Here is what it does (so far??):

  • Can access all functions with a keyboard
  • Screen reader announces everything  - Though not always beautifully. This depends on the browser's accessibility implementation, ARIA support and how the screen reader itself behaves. Having said that you can find all of the controls
  • No keyboard trap
  • Is still accessible while in fullscreen mode
  • Has a synched second audio track that can explain what is happening in the video to people who can't see it
  • Captions of course - I'm reasonably happy with the implementation of them
  • The captions can be presented in different:
    • sizes
    • fonts
    • colours
    • coloured background
    • transparent background 0% 25% 50% 75% 100%
  • The captions can be moved around the video so captions doesn't obscure anything
  • Works on modern HTML5 browsers
  • I've left the interface fairly dry, at least so far, so the developers can implement their own designs with CSS
  • This project doesn't include a fallback to a flash version, their are plenty (?) of flash video players available and fallback was discussed in the first stage of this project.
But I still have that niggling feeling that something is missing... maybe it's just the jitters. What do you think? If it does what I say it does, is that enough?

Student testing will begin soon. We have had a small problem this year, as other projects may have also found, TAFE teachers who were teaching in 2012 aren't necessarily still available in 2013. I am in the process of organising a meeting with some teachers who I am quite sure will be very interested in trying out this player with their class. 

Luckily there are still some excellent teachers left.

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.



Thursday, 31 January 2013

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.

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?