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.
