Keyboard traps, Flash and Firefox 4

Introduction

On the 22nd March 2011 version 4 of the ever popular Firefox browser was released. With this release came a myriad of additions and improvements. On the whole the team at Mozilla have done a great job. However, this is not to say that the browser has been improved in all areas. After updating to Firefox 4 last month, one of my colleagues started experiencing an issue that is likely to cause problems for a significant number of people. The issue relates to the use of flash elements in the firefox 4 browser. If flash is used it will frequently steal focus from the user, refusing to relinquish it unless another element on the page is clicked with a mouse. For someone using a mouse this is likely to be an annoyance but will not cause any major issues. However, for a person using a keyboard to navigate through the page this can seriously affect their ability to access content on your website. Since a person using a keyboard will not be able to move focus away from flash elements this technically constitutes a keyboard trap.

What is a keyboard trap?

For more information on keyboard traps please refer to our blog post Keyboard traps. In essence a keyboard trap is triggered when focus cannot be moved away from an element on a page. Success criterion 2.1.2 of the WCAG 2.0 guidelines states that:

If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface

This is classified as a Single A level success criterion (the most basic level of accessibility defined in the WCAG 2 guidelines). As such the keyboard trap mentioned above will cause almost every single website that makes use of flash to fail this success criterion and thus be considered inaccessible.

Shouldn’t the browser vendor fix this?

Ideally, yes. However, the browser is now in circulation and as such we need to think creatively about how we can circumnavigate the issues that firefox 4 presents for keyboard users. As front end developers we deal with browser inconsistencies on a day to day basis. Since the issue identified above is significantly severe we should also attempt to resolve it wherever possible.

So how have we dealt with this issue?

At Nomensa we have developed two seperate applications that required a solution to this specific issue:

1. Our Accessible Media Player
2. An accessible 360 tour

Each of these applications required a different solution to the other. These solutions will be outlined below.

Accessible Media Player

The Nomensa accessible media player relies heavily on flash (although we are currently adding support for HTML5 video and audio). We couldn’t conceivably claim to have an accessible media player if we did not resolve the keyboard issues presented in Firefox 4. With this in mind we set out to find a solution. The Nomensa accessible media player uses HTML and JavaScript to interact with third party flash players. Because all of the controls for the player are provided as HTML elements we came to the conclusion that there should be no need for a keyboard user to require access to the flash movie itself. With this in mind we were able to devise a solution fairly quickly. Please note that at the time of writing, redevelopment of the Nomensa accessible media player is still in progress.  As such, the media player in use on our website still suffers from the firefox 4 keyboard trap.  We will do our best to ensure that this is updated as soon as possible.

The solution

Within the Accessible media player plugin we have used an object detection technique (See code example below) to determine whether or not firefox four is being used. It is important to note that object detection is generally prefferred to browser “sniffing”. Although browser “sniffing” is possible (easy if using a JavaScript framework such as jQuery) it should be discouraged. We have decided to use the object detection method because the browser detection methods may be moved into a plugin in future releases of the jQuery library. Since we wanted the media player plugin to be forwards compatible with future versions of jQuery we decided to make use of a more stand alone object detection technique. More information on the pros and cons of browser sniffing can be found on www.quirksmode.org.

Code example – Firefox Four detection

function is_ff4(){
return window.globalStorage && window.getSelection().modify;
}

If firefox four is being used we ensure that the tabindex for the flash movie is set to a negative value (in this instance -1). This will remove the flash element from the tabbing order of the page and will ensure that focus cannot be moved to the flash element by people who use a keyboard for navigation. Since all of the controls for the media player are presented as HTML buttons full control of the media player will be possible using these elements. As a result the keyboard trap will no longer be triggered and full keyboard control will be restored.

360 accessible tour

One of my colleagues has recently completed some work on an accessible 360 tour application. The controls for the 360 tour needed to be embedded within the flash movie itself. As such keyboard control within the flash movie needed to be maintained. Therefore, removing the flash element from the tabbing order was not a viable option. Doing so would constitute a failure under WCAG 2.0 since not all of the content on the page would be operational using a keyboard alone. As such a different approach is needed.

The solution

Thankfully, a number of techniques for making flash accessible have been published by the W3C working group. Technique 17 specifically addresses the issue of moving focus back to an HTML element from a flash movie. This technique requires modification of the Flash component in use on your website. Essentially, another class must be merged into the flash movie. This class deals with the management of the tabbing order within the flash movie. It will insert empty HTML links immediately before and immediately after the flash movie. It will then listen for a “focus wrap” event within the flash movie. A “focus wrap” event is fired when focus moves from the last element within the flash movie to the first and vice versa. When this event is detected a javascript function is called that moves focus to the neighbouring link of the flash movie thus breaking out of the flash and back into the HTML. This makes it possible (and easy) for people who use a keyboard for navigation to tab through the page regardless of whether or not flash is used on the page. However, the technique also has a few issues:

1. Redundant mark up is used for this technique. Notably the links inserted before and after the flash movie have no obvious purpose and are likely to confuse some people;
2. The technique only works with Firefox browsers. Browsers such as Opera, Chrome and Safari are not supported.

Conclusion

This is not a comprehensive tutorial on how to resolve keyboard accessibility issues relating to flash elements in Firefox 4. Rather, this post should have identified a couple of practical solutions that we have used for our own applications and plug-ins. As with anything that relates to accessibility careful consideration is needed when weighing up the best approach for your own application. The techniques that we have used for the applications identified above will not be applicable to every single situation. However, what I hope to have shown is that with a little careful consideration and a few minutes with Google solutions to some of the most annoying issues can often be rectified with relative ease.