Keyboard functionality for websites – creating order, avoiding traps

In recent years, developers have embraced the idea that there are many different ways for people to navigate around a website. In a traditional office environment, it’s likely that the mouse is the most popular navigation tool, while for people on the go it is increasingly likely that fingers on a touchscreen is the favoured way to interact.  

Yet for people with a vision or mobility impairment there is a third option that is often overlooked: accessing content using only the keyboard. For a person who is blind, the mouse is a difficult tool to use as there’s no easy way to figure out where the mouse pointer is located. For people with a mobility impairment, it may be difficult to move the mouse if their hand is constantly shaking, for instance. In both cases, navigation can be much quicker and easier if keyboard commands and shortcuts are used to get around.

Over the years a lot of work has been done to try and make sure that operating systems are fully accessible by keyboard. Microsoft Windows, Mac OS and most Linux variants, along with all modern web browsers, already offer great keyboard support. More information on this can be found in the Digital Technology section of the MAA website.

The good news for developers is that this means most of the hard work has already been done for you:  people with disabilities should be able to get to your website and start navigating around it. The challenge then is making sure that the final accessibility steps are correctly implemented so that the user can quickly get around the website itself, finding all information and achieving all objectives. 

Why is keyboard functionality so important?

The accessibility of a website by keyboard is one of the most important accessibility issues in WCAG because it has the potential to affect the accessibility of the entire website rather than just an element of it. For example, if a video isn’t captioned, the accessibility issue is limited to that particular element of the website. However, if a person who relies on keyboard functionality is unable to complete a task such as using the checkout function on a grocery website, then the entire purpose of the website is inaccessible, and the website is useless.  

Often good coding practices result in minimal keyboard issues, but checking for them and addressing them can make a significant difference to people with a disability wanting to access your online product, service or content.

What the guidelines say

To provide guidance on how to address keyboard functionality accessibility issues, WCAG 2.0 states that:

Guideline 2.1 Keyboard Accessible: Make all functionality available from a keyboard.

For Level A compliance, there are two success criteria that need to be addressed:

2.1.1 Keyboard: 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.

2.1.2 No Keyboard Trap: 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.

Issues of keyboard focus are further expanded in Guideline 2.4, which states that:

2.4 Navigable: Provide ways to help users navigate, find content, and determine where they are.

Which also has two relevant success criteria for Level A compliance:

2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

2.4.3 Focus Order: If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

What these guidelines mean in practical terms is that all elements need to be accessible with basic keyboard commands such as the tab key and arrow keys unless something has been specifically designed for a particular device like a mouse. A good example would be a puzzle game where pieces of the puzzle have to be dragged and reordered around the screen. 

The guidelines also emphasise that it’s not enough just to make everything keyboard accessible. There’s a need to give some thought as to how the keyboard functionality actually works, such as the order in which the tab key moves through the content, or whether an option is needed to help a keyboard user skip over content that repeats on every page of a website, such as the navigation menu.

Best practice

In many cases, your website may already be keyboard accessible as a result of good coding techniques and the positioning of divs and elements in the style sheet. You can test this by using the tab key to move from link to link within each page.

While going through the test, consider the following questions:  

•  Are all the main functions of the website being detected?
• Are the functions being accessed in the intended order?
• Are there any points where I get stuck, unable to tab or back-tab?
• Do I need to create anything extra, such as a ‘skip navigation’ or additional keyboard shortcuts, to assist a keyboard user?  

If there are elements that are not keyboard accessible, such as a keyboard trap or the tab order being incorrect, have a look in the code and see if the issue can be rectified by moving elements around. Failing that, there are some coding techniques which can be used to force a tab order and provide support to users who wish to skip content that repeats on each web page. 

Code examples

A tab order can be forced through the use of thetabindexattribute.  While every effort should be taken to adjust the tab order before using this, there may be circumstances where forcing the tab order is unavoidable. The coding example below provided by WebAIM demonstrates how this attribute can be used:

<a href="http://www.webaim.org/" tabindex="10">WebAIM.org</a>
<form action="submit.htm" method="post">
<label for="name">Name</label>
<input type="text" id="name" tabindex="20"/>
<input type="submit" id="submitform" tabindex="30"value="Submit" />
</form>

As highlighted in this example, the tabindexattribute provides a sequential numerical value which ensures a correct tab order.

Another coding example is the ability to skip repeating content, such as navigation. This can be done by placing the declaration just after the body of the page starts, and linking it to the section after the navigation. This is the code that is currently embedded into the MAA website:

<a href="#content">Skip to Content</a>
…content…
<a name="content">

The final coding example, also from WebAIM, demonstrates how to create additional keyboard shortcuts using the accesskeyattribute.

<a href="http://www.webaim.org/" accesskey="w">WebAIM.org</a>
<form action="submit.htm" method="post">
<label for="name">Name</label>
<input type="text" id="name" accesskey="n"/>
<input type="submit" id="submitform" accesskey="s"value="Submit" />
</form>

The code has established the ‘W’ key, ‘N’ key and ‘S’ key to be used as new keyboard shortcuts specific to this website. 

Issues and developments

While these techniques can provide great benefit to people who rely on keyboard functionality, the current solutions are not always effective. In addition to the recommendation of using the tabindexattribute only as a last resort, the accesskeyattribute also has limitations. For example, it may be the case that different browsers require an additional key to access it, such as ALT + access key or ALT + SHIFT + access key. Developers who use this technique will also need to include some guidance on the website to help people use the additional functionality, otherwise the user may not even realise that the functionality is available.

Another big issue with keyboard accessibility is the use of third-party technologies such as Flash or Silverlight which can often result in keyboard traps. If you are using a third party software package or plug-in, it is best to research keyboard accessibility first.

Development work on HTML5 and WAI-ARIA draft standards offer great potential for addressing these and other accessibility issues. Some of these features can be used now in recent web browser releases. Additional information on these technologies can be found in previous W3C columns.

Final thoughts

Ensuring that your website works well with a keyboard can make a significant difference to people with a vision or mobility impairment and there’s a good chance that your website is already keyboard accessible. Please take the time to test it out and if there are issues they should be relatively easy to fix.

Further information on keyboard accessibility can be found in the WCAG 2.0 techniques document. 

Additional coding examples can be found on WebAIM.