Support for using a keyboard to access information on a website is essential for accessibility. We'll look at the reasons why, what you should look out for when implementing it, and how you can test keyboard navigation yourself easily.
Why is keyboard navigation important?
For many people controlling their computer using a mouse is the most common way of navigation. With the popularity of smartphones and tablets using a finger or a stylus are also very common.
But what if those options aren't available to you? You might have a (temporary) disability or motor functional limitation like tremors or limited fine control. Some people live with RSI (Repeated Stress Injury) which could make prolonged use of a computer mouse very painful. There are vision-impaired users that require a screen reader to operate computer, which are controlled by keyboard commands. The same goes for most other assistive technologies like switch controls or speech recognition software.
In all of these situations, having a keyboard accessible website is essential. Even for those visitors that doesn't actually use a keyboard because assistive technology uses the keyboard interface to process it's input signals.
What to look out for?
Many problems can arise if a website cannot be operated properly via the keyboard. Let's look at some examples:
One of the most common accessibility issues with regards to keyboard navigation are with focus indicators on the active element on the page. Ranging from badly visible ones to a complete lack of any visible indicator.
By default, a browser provides an outline around the active element when using a keyboard. These range from a blue and white to a dotted line in different browsers. There are also options for users to customize these styles as needed.
A common mistake is that such indicators are often disabled via CSS with an
outline: 0; or
outline: none; value. This is usually done from a design perspective, but this makes it impossible to visually recognize where the keyboard focus is located. Instead of turning these indicators off, you can give them their own appropriate styling that is also accessible and matches the design.
It often happens that there is styling proved for when a link gets hovered over with a mouse, but then this same styling isn't also provided on keyboard focus.
Make sure you take both situations into account. This can often be solved by including the CSS selector
:focus in addition to the CSS selector
:hover when you apply your own focus indicators.
Sometimes situations arise on a website where the keyboard focus gets stuck and navigating to other elements is no longer possible. These so-called keyboard traps usually occur when using a modal (pop-up screen) and other more complex elements such as widgets.
They arise, for example, when a modal is opened and the focus is limited to this pop-up. This best practice prevents other confusing situations. However, when the button to close the window can only be operated via the mouse, this modal can no longer be closed by everyone.
A solution is to make the close button available via the keyboard by using an actual
<button> element and, for example, have the window close when the escape key
ESC is pressed.
For building and testing of various patterns, the WAI-ARIA Authoring Practices by the W3C contain a lot of information. There is also information available on expected keyboard behavior.
These days, online applications are all around. From online text editors to full-fledged email clients like Gmail and Outlook. Often times these applications make use of hotkeys to quickly preform certain tasks, and often these hotkeys are single-character based.
For example, the web version of Gmail offers hotkeys for tasks like archiving emails or starting a quick reply. These hotkeys are on by default, but can be turned off in the settings.
When using the embed code from YouTube to share a video with your visitors, they also include hotkeys by default. These need to be deactivated manually by adding the
disablekb=1 attribute to your embed URL. Below is a code sample on how to add this attribute.
These hotkeys can not only cause problems for keyboard users. Users of speech recognition software can also be affected by them. If, for example, a word is spelled out in single characters, this might activate the hotkeys.
It is therefore important that certain conditions are met. The WCAG states that one of the following solutions should by applied:
- There is a way to disable the hotkeys.
- There is a way to adjust or re-map the hotkeys to require a not-printable modifier key like
- The hotkey is only active if the affected element has active focus.
In more complex websites, there is often the need for custom components that fit the information provided. Some examples might be a custom navigational menu or having filters on a results page. For these custom components, it is important to keep keyboard navigation closely in mind when building them.
Make sure that all controls are reachable and usable with a keyboard. Always try to use native HTML elements to build your components. Keep in mind that, if for some special reason, you can't use a native element like a
Check if the
tab order of your website has a logical order. This fits nicely with the first point I made about having clearly visible active focus elements.
This logical order is important for the whole page. Not only for its content and structure to present your information correctly, but also for keyboard navigation. Make sure the focus order matches with the visual order of the page and that it doesn't jump all over the page.
Logical order is also an important part to keep in mind with the previously mentioned custom components. Another place focus order often mismatches the visual order is with forms. All too often, input fields get reordered to achieve a certain layout. Make sure matching fields, like name and surname, get focus in the correct order.
tabindex attribute allows for elements, that normally do not receive keyboard focus, to enter the focus order of the webpage. It also allows you to remove an element from the focus order or completely rearrange it.
tabindex attribute affects the entire page. Its application should always be considered carefully, and use of values higher than
tabindex="0" is strongly discouraged!
tabindex="0" elements, that normally do not receive keyboard focus, can be entered into the natural focus order. This might sometimes be needed to enable keyboard users to access certain content.
For example, the YouTube code sample mentioned above. In this element, code lines can become long enough that vertical scrolling is required. By adding the container to the focus order using
tabindex="0" it allows keyboard users to scroll the container using the arrow keys.
tabindex="-1" value removes the element from the focus order. It will then no longer receive keyboard focus.
Elements with a
tabindex value greater than 0 are placed, in order, at the very front of the focus order. This removes them from the natural order on the page and means these elements always receive focus first. Even if such an element is at the very bottom of the page! Extreme care is therefore required, and its use is strongly discouraged!
Testing keyboard navigation
As we've seen, checking keyboard navigation is one of the most important things you can do for digital accessibility. Moreover, as a developer, you can also do it yourself easily while building, and apply fixes where needed.
Below are the most common keyboard combinations you can use to start testing.
|Navigate between interactive elements|
|Buttons||non-button elements with the aria-role |
|Selectmenu (dropdown)||You can navigate options by typing letters. This is an exception on SC 2.1.4 because these 'hotkeys' only work while the menu is active. Be mindfull of this behaviour when making custom dropdown menus.|
Accessible Online will gladly help you along! Whether it is research, auditing or development training, we'll help you make your website accessible!