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.

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.