How to check websites for keyboard accessibility

The most common and most serious accessibility problem that websites have is the lack of keyboard operability – a website must be accessible without a mouse and only with the keyboard. A test by Aktion Mensch shows how widespread this gap is: 71 online stores were examined, but only 15 of them could be operated using a keyboard.

Why is keyboard operability important for accessibility?

Keyboard accessibility is necessary for several reasons:

• People with tremor, muscle weakness, limited fine motor skills or one-handed use cannot operate a mouse or can only do so with pain.
• Blind and severely visually impaired users mainly navigate with screen readers. This assistance software links its shortcuts (tab, arrow navigation, quick jump buttons, etc.) directly to the keyboard. Without a well-defined focus and controllable components, content simply remains inaccessible for them.
• Voice control (Dragon NaturallySpeaking, Windows speech recognition) and mouth/eye controls “pretend” to send keyboard commands. Only when a page is fully operable via buttons does it also work with these technologies.

Keyboard accessibility is closely linked to the “focus indicator” of the selected element. The focus identifies the currently active element on the page, and to make it easy to recognize, it must be clearly highlighted. In the two examples below, it is indicated by a border or a background color:

It is important that the focus is clearly emphasized for the following reasons:

• The visible focus shows where the user is currently located. Without this feedback, when navigating with the tab key (see below), you would not know which element will be activated next – this leads to confusion, incorrect entries or even abortion of the interaction.
• Keyboard events (Enter, spacebar, arrows, ESC …) only ever affect the currently focused element. If there is no focus – or it is “stuck” in the wrong area – interactions simply do not work.
• Screen readers link their output to the focus. If the focus changes, the screen reader reads the new context. A missing or invisible focus makes content practically impossible to find for blind users.

Which WCAG criteria relate to keyboard usability?

Requirements for accessible websites are specified in the internationally recognized standard“Web Content Accessibility Guidelines”. It is available in several versions (currently version 2.2) and several “conformance levels” (from A to AAA). The requirements are described in 86 so-called “Success Criteria”, the following table shows which of these are the relevant criteria for keyboard usability.

Use these steps to test websites for keyboard operability

Carry out an automatic test

Automated testing tools like decareto can identify some problematic aspects that prevent a website from being keyboard inaccessible:

• Missing HTML attribute tabindex="-1" for interactive element (this is required to ensure focus in a normally hidden element, such as a dialog popup).
• Missing or deleted focus, for example if the focus indicator is deliberately suppressed in a website for design reasons.

However, the majority of problems with keyboard operability require manual testing, which is described in the following sections.

Is there a link to the main content?

Open the page and click the Tab button once or twice. Does the focus first jump to a visible “To content” link?(WCAG 2.4.1).

Negative example: The page title gets the focus, but there is no skip link.

Navigate with the Tab key

Click Tab and Shift-Tab to navigate forwards or backwards. Is it clear which element has the focus and does the order follow the natural reading logic? Is nothing essential skipped(WCAG 2.4.3)?

Negative example: The focus jumps from the main navigation directly to the footer.

Check the focus indicator

Observe how the focus is identified. Is it easily recognizable? The indicator should be a line or area at least 2 px wide with 3:1 contrast(WCAG 2.4.7 & WCAG 2.4.11). The two screenshots at the top of the page show this clearly.

Negative example: The indicator is only a wafer-thin, gray outline or invisible on a dark background.

Fold-out menus

If the website has a navigation that can be opened (by clicking or hovering with the mouse), then these menus must be able to be opened with the keyboard.

Identify all navigation elements on the page that open a menu by hovering or clicking. Go to each menu item with Tab and try to open it with Enter or Pfeil-down / Pfeil-hoch. Does the focus remain in the open menu? Can it be closed with Esc?(WCAG 1.4.13, WCAG 2.1.1)

Negative example: The submenu only appears with a mouse hover, you cannot open or close it using the keyboard.

Check forms

Accessible forms can be operated using the keyboard:

• Switch between the form elements with Tab and Shift-Tab
• Selection of radio buttons with Pfeil-down / Pfeil-hoch
• Selection of a checkbox with Space
• Scroll through drop-down options with Pfeil-down / Pfeil-hoch
• Confirm a drop-down selection with Enter
• Close an open dropdown with Esc
• Send the form with Enter

Check whether all forms can be operated in this way(WCAG 2.1.1)

Check dialogs and pop-ups

Identify all dialogs that open as popups and are placed in front of the background. It must be possible to open and close them using the keyboard. Within an open dialog, it must be possible to reach all elements with Tab.

• Can the dialog be opened with Enter?
• Can it be closed with Esc?
• Does the focus jump to the dialog when opening?
• When using Tab multiple times, the focus must be “trapped” in the dialog.
• Does the focus return properly after closing?

Negative example: In a dialog, the focus must not suddenly switch to the side or even to elements behind the dialog when using Tab.

Check drag-and-drop actions

Drag-and-drop is occasionally used to reorder lists, for example. For operation with the keyboard, there must be an alternative to this, with which, for example, an element can be selected and the sorting is carried out using elements for “up” and “down”(WCAG 2.5.7)