Keyboard inputs and alternatives: accessibility for developers

  • Author: Access iQ ®
  • Date: 1 Feb 2013
  • Access: Premium

Quick facts

For people with disabilities, it is important to have full functionality of a website through the keyboard. Assistive technologies like screen readers and alternative pointing devices such as haptic feedback and head pointers also benefit from full keyboard accessibility.

  • Ensure no keyboard traps
  • Make web content keyboard accessible
  • Tab order
  • WAI-ARIA landmark roles

Many people are accustomed to using pointing devices to navigate websites, but all modern browsers also allow content to be navigated and controls to be activated through the keyboard; mainly with control keys like Tab, Return and the arrow keys.

For people with disabilities, it is important to have full functionality of a website through the keyboard. Assistive technologies like screen readers and alternative pointing devices such as haptic feedback and head pointers also benefit from full keyboard accessibility. All alternative forms of input and control depend on keyboard input as the prime interface between user and computer. In addition, tablets and smartphones utilise some "keyboard" functions even through their keyboards are not physical devices. It is not uncommon for people with disabilities to connect keyboards or items that function like keyboards to these devices.

No other form of computer input is as flexible or widely supported as the keyboard input. This makes the keyboard a practical base for accessible input and interactions.

For these reasons, Success Criterion 2.1.1 Keyboard states:

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)

There are several key points to understand this success criterion, which we will explore in turn.

  • The point about specific timings is to ensure that people with cognitive disabilities, or people with slower or less accurate motor control are not placed at a disadvantage if they cannot complete a sequence of keystrokes in rapid succession.
  • The exception that that depends on the path of the user's movement and not just the endpoints is to ensure that if the task is to, for example, draw a freeform line, that condition is exempt from requiring full keyboard operability.

Keyboard functionality relates to a website being operable, one of the four POUR principles that form the foundation of WCAG 2.0:

  • Perceivable
  • Operable
  • Understandable
  • Robust

This does not mean that other forms of user control have to be ignored, such as mouse input or speech input, as long as full keyboard functionality is also available and accessible. This may cause some problem for functionality that depends on drag-and-drop events. The solution is to allow navigability by keyboard to the elements that can be moved by mouse, and allow them to copied, in order to be moved to their location (Copy > Paste).

Nor does it exclude computing devices that don't have physical keyboards, such as some smartphones or tablets. Those devices will have some way of accepting user input through keystrokes, through virtual keyboards, a number pad, or voice commands. This criterion applies to any hardware or software that generates keyboard or text input.

The keyboard trap

On occasion, some webpages suffer from what is commonly referred to as the keyboard trap.  As a user navigates a webpage using a keyboard, perhaps by pressing the Tab key to navigate through the links. For example, they may navigate into a section or function on the page that they cannot then navigate out of. This is called a keyboard trap because the user can move into the area but not move out of it. There is one concession to this condition. If the user is notified, in an accessible way, of an easy keyboard method for moving out of that component, the page will still comply with this criterion.

Success Criterion 2.1.2 No keyboard trap states:

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)

For example, a user tabs to a link titled "Help", and presses the return key to follow that link. This opens a dialog box that has not received focus, asking for a response. Further presses of the tab key do not navigate through the controls in the newly opened dialog box, and the user cannot answer the request nor dismiss the dialog box to return to the page. This is a keyboard trap as it fails to allow the user to continue.

The impact of a keyboard trap for most people will be minor. For a user restricted to a keyboard for navigation, however, this can be frustrating and for some, it can end their ability to continue with the website. With the screen reader unable to communicate the condition to the user, and no way to exit or move beyond the trap, for some it means exiting the browser completely and starting again, probably elsewhere, on a competitor’s site or straight to the complaints section of the same website.

Making web content keyboard accessible

As noted above, both Success Criterion 2.1.1 Keyboard and Success Criterion 2.1.2 No keyboard trap are Level A conformance, meaning they are a basic, some say core, accessibility requirement. These are two criteria that clearly demonstrate how accessibility testing cannot be fully automated, since the only valid way to test is to disconnect your mouse and to use a keyboard to navigate the site with a keyboard.

Common controls are:

  • Tab, to move between form fields links and buttons (adding shift moves backwards)
  • Return, to action the link or button with current focus
  • Space key to move between options (radio and checkboxes) in a form
  • Esc key to close modal boxes, slideshows, etc.

When testing the navigability of a site by keyboard, it is important to follow every actionable item (links, form elements, including all inputs, selections and buttons) and ensure they are all accessed and controlled via the keyboard. You should be able to move through all actionable elements of the site, including video, pop-ups, forms, lightbox overlays, carousels etc.

Tab order

As a standard navigation method, the Tab key has significant value to keyboard accessibility, hampered by being able to navigate only links and form elements. It is possible to create more elements to focus on within a document using the tabindex attribute, which will add the ability to focus on elements (by tabbing) that would not normally attract focus.

Example 1:

By adding tabindex=”0” to the collection of content below it allows an element to follow the flow of tab-navigation simply.


      <p tabindex="0">Join our mailing list</p>

      <label for="email-address">Email address

      <span class="required">(required)</span></label><br />

      <input type="text" name="email-address" id="email-address" /><br />

      <input type="submit" value="Submit" />


WAI-ARIA landmark roles

Another valuable method for supporting keyboard operability is the use of WAI-ARIA landmark roles. ARIA extends the qualities of good HTML markup by adding extra features that don’t alter the experience of people without disabilities but are embraced by assistive technologies, helping to increase accessibility in documents. Screen reader users are accustomed to being notified when a site has WAI-ARIA landmark roles specified and appreciate developers including them.

There is more information on applying ARIA in other topics but the key thing to consider here is to add a short WAI-ARIA attribute to some elements in order to improve keyboard navigability.

For example, it is relatively trivial to add a role=”main” to the div element that contains the main content or a role=”navigation” to the div or HTML5 element that contains navigation. It also helps the accessibility of HTML5 elements that are not covered by the advantages found in landmark roles of banner, contentinfo or search.

Example 2:

The snippet below adds very little to the code but a great deal for people with disabilities:

<div id=”topsection” role=”banner”>...</div>

<form role=”search”>

<input type=”text” name=”search” id=”search” />

<input type=”submit” value=”Search” />


<div id=”nav” role=”navigation”>...</div>

<div id=”content” role=”main”>...</div>

<div id=”sidebar” role=”complementary”>...</div>

<div id=”footer” role=”contentinfo”>...</div>