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.

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.

What is ARIA? From the W3C ARIA website http://www.w3.org/WAI/intro/aria.php

‘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?

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.