What are keyboard traps?

Introduction

You’re sat at your computer, triumphant in completing that all important piece of code you’ve been working on.  You quickly check your email which consequently causes your computer to stop responding.  We all know the scenario… You haven’t saved your work for a while, cannot remember how to rework what you have lost and have an important deadline looming.  You re-boot your computer and sit rewriting the code that you just lost, cursing yourself for not saving your work more frequently. If this sounds familiar you already know about the inevitable frustration that follows.  The brief interruption to your working day has cost you time, money and compromised what dignity you have left.

So why is this even relevant?

Computers occasionally crash.  This is a common fact of life.  However, if a computer were rendered unusable as a result of someone else’s negligence or lack of foresight, the resulting frustration can be even more intense. Some approaches to front-end web development can cause what is frequently referred to as a “Keyboard trap”.  In extreme cases, a keyboard trap can render a computer as unresponsive and unusable as if it had frozen or crashed.  It is this that I will discuss throughout the remainder of this article.

So what is a keyboard trap?

A “keyboard trap” occurs when a person who uses a keyboard cannot move focus away from an interactive element or control using the keyboard alone.  Since a keyboard trap can be so immobilising the WCAG 2.0 guidelines dedicate an entire success criterion to this issue alone. According to WCAG 2.0 guideline 2.1.2:

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, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. (Level A)

It is worth noting that this is a requirement to meet the most basic level of accessibility defined by the WCAG working group.  As such, any instance of a keyboard trap on a web page will technically render it “inaccessible”.

Enough already, what causes a keyboard trap?

The most common “Keyboard traps” found on the web today are a result of particular implementations of JavaScript functionality.  Specifically, if blur or any keypress events are used to enhance or override an elements behaviour, care need be taken over how this is implemented.  Consider the example below:

Example

HTML

<a class=”trap” href=”some-page.html”>Some page</a>

JavaScript

$(document).ready(function(){
    $(‘a.trap’).keydown(function(event){
        event.preventDefault();
        var href = $(this).attr(‘href’);
        var text = $(this).text();;
        window.open(href, text);
    });
});

In this example, the keydown event has been used to open a new window (this in itself is bad for accessibility but we will ignore this for now).  When a person using a keyboard attempts to move focus away from the link shown in the example, the keydown event will be triggered and the resulting function will be executed.

Seems fairly straight forward at the moment, so what’s the problem?

The problem hinges on the fact that not everyone who uses the internet will use a mouse for navigation. This may be due to personal preference, limitations of their hardware or some form of disability that prevents them from being able to use a mouse effectively. Consider the case of a blind person using a computer. For blind people, it is not very easy to use a mouse as they are unable to see the regions of the page that they would be clicking on. For this reason, people with blindness consistently opt to use a keyboard instead of a mouse for day-to-day use of computers. People with diseases such as Parkinsons also frequently opt to use a keyboard instead of a mouse as many of them do not have sufficient motor neuron control to operate a mouse effectively. The problem with the code above lies in the line:

event.preventDefault();

In this instance, the “event” object refers to the keydown event that triggered our function.  The call to the “preventDefault” method essentially prevents the default action associated with the event from occurring. If the code above were used in practise, when a person using a keyboard attempts to move focus away from the link the keydown event will be fired, the default action prevented and a new window opened.  Since the “Default” event has been prevented, focus will remain with the link and a new window will be opened each time a key is pressed. It is also worth mentioning that the function in the example does not make any attempt to detect which key has been pressed before responding.  As such the function will be executed each time any key is pressed.  This can potentially lock people out of their computers as they will be unable to close the browser using either a conventional method, or by using task managers such as the one that ships with Windows (the ctrl + alt + delete keystroke combination will also cause our function to be executed whilst preventing the default action).  For people who can only use a keyboard for navigation this effectively hijacks their computer.  This person will then be forced to either:

• Ask a friend or colleague to move focus away from the element with a mouse;

• Turn their computer off at the wall and restart, potentially resulting in loss of work and extreme frustration.

So how can I avoid creating a keyboard trap?

So how do you avoid creating a keyboard trap when developing and implementing front-end web solutions?  Ultimately, if you are aware of the practices that can create the conditions for trapping keyboard users within content you are already well on your way.  However, awareness is only half the battle.  The only way to effectively ensure that your content and scripts do not trap users in content is testing.  Fortunately this is not as laborious a task as you would first think and will ensure that your website is fully accessible to people who use a keyboard instead of a mouse. In order to run a quick test on any given web page, click within the address bar or your browser.  From here, press and hold down the tab key on your keyboard.  If focus can be moved through each element on the page and back to the address bar using only the keyboard (the tab key specifically) your page should be free of keyboard traps and you can breathe easy. If however you discover a keyboard trap on any of your pages, you have a few options:

1. Find another solution and use that instead;
2. Dive into the code, find the source of the issue and fix it;
3. Remove the code that is causing the issue and find an alternative

Conclusion

Generally speaking, keyboard traps are not as common a problem on the internet as many other issues such as poor alt text.  However, the effects of the average keyboard trap can be so fiercely negative that care should be taken not to introduce any whatsoever.  Mindfulness of the issues and techniques that may cause a keyboard trap will certainly help you to spot potential issues during development phases.  However, this is no substitute for proper testing of new applications and scripts before deployment on your website or intranet. And remember… make sure to always save your work regularly.

Start building accessibility into your projects at the beginning to save time and money, don’t just leave it hanging on the backlog letting it gather up dust. Drill it in.

If you would like Nomensa to help you with your accessibility challenges or to provide you with an accessibility evaluation of your website/mobile app, please don’t hesitate to get in touch.

You can give us a call on +44 (0) 117 929 7333 or submit this short form. In the meantime, take a full look at the digital accessibility services that we offer.