Many users are physically unable to use a pointer interface (such as a mouse), and therefore may rely on navigating through digital products including websites using a keyboard alone. In this article we will mainly focus on web applications, however, much of the same information can be applied to other application mediums. The Importance of Keyboard Accessibility has been outlined in one of my previous articles.
Before being able to resolve any issues with keyboard access, it's important to understand, how a keyboard is used to interact with a web application. A number of the common keyboard keystrokes for navigation and interaction are listed within the following table.
|Key(s)||Usage of Key|
|Moves to the next focusable element (such as a link, form control or button)|
Shift and Tab
|Moves to the previous focusable element (such as a link, form control or button)|
|Activates the current link or button.|
|Check or uncheck a checkbox form element. Additionally will activate a button.|
Up Arrow or Down Arrow
|Moves between radio buttons or in some instances menu links.|
Left Arrow or Right Arrow
|In some instances, move between menu links or adjusts sliders (for example an audio or progress bar)|
|Closes the current modal dialog or dropdown menu and return focus to the previous element.|
By default, users will only be able to access a number of elements such as links, buttons and field controls using the keyboard natively. It's always best to use native Hyper Text Mark-up Language (HTML) elements as these are natively accessible. If it is not possible to use these elements, a
tabindex="0" will need to be assigned against the element to enable it to be keyboard focusable. Defining a specific
tabindex such as
should be avoided in all instances, the necessity to use a fixed tabindex value often means that the content has been illogical positioned within the Document Object Model (DOM) of the page, therefore it's better to restructure the order of content rather than applying a fixed tabindex. Read more about the Importance of not using a Tabindex Greater than 0 in Adrian Roselli article.
It's important to note simply applying a
tabindex does not mean the control is entirely keyboard accessible, and supports all the keyboard access expected by a user, such as navigating radio lists using the arrow keys. A detailed breakdown of expected keyboard interactions on a per element basis can be found within the WAI-ARIA Authoring Practices documentation.
You can try keyboard accessible by using the TAB button, to navigate between the links, buttons, form fields, and other features on this blog. The current focus should be easy to distinguish by the yellow highlight. The navigational order of the content should follow that of the visual layout of the page, commonly in the Western world, left to right, top to bottom. Do note, however, depending on the geography of the website this may differ but still be logical for their local reading order.
When navigating yours or this blog consider:
- Can you access all the features using the keyboard alone?
- Can you operate all controls using the keyboard alone?
- Is it relatively easy to distinguish where you are currently on the page?
This article was last updated on March 3rd 2021.