Skip to main content

https://markwilcock.com/2021/03/developing-testing-keyboard-accessibility/

Basics of Keyboard Accessibility

Posted on:

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

Tab

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)

Enter

Activates the current link or button.

Space

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)

Escape

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  tabindex="1" or tabindex="4" 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.

Sharing and comments

Share this page

Leave a comment

We only ask for your email address so we know you're a real person

By submitting a comment you understand it may be published publicly on this website. Please read our privacy notice to see how we handle your information.