Synonyms: keyboard operation, keyboard interface

See also: Use of the pointing device,, fokus indicator, navigation sequence

It must be possible for all functions which can be initialized using a pointing device, motion control or voice input to also be initialized using the keyboard, as disabled users may not be able to use a pointing device and/or may not see the pointer, may not be able to perform the movement or may not be able to speak. It is also possible that disabled users are unable to use a keyboard, but their assistive technology simulates the keyboard and interacts with the keyboard interface of the operating system and/or the Accessibility API.

In this context, the simulation of a pointing device with the keyboard (e.g., keyboard mouse using the numeric keypad) is not considered a permissible alternative form of operation to the use of the pointing device.

No.PropertyDescriptionClassificationReference
125ContrastThe contrast requirements must also be met when using the keyboard, e.g. when receiving the focus (see Colors and contrasts).MustEN 301 549:
9.1.4.3, 11.1.4.3, 9.1.4.11, 11.1.4.11
126Focus visibilityIf a control element receives the keyboard focus, the focus indicator must be visible (see Fokus indicator).MustEN 301 549:
9.2.4.7, 11.2.4.7
127Focus visibilityThe focus indicator must have a contrast ratio of at least 3:1 with respect to the background.MustEN 301 549:
9.1.4.11, 11.1.4.11
128Web: ConsistencyControl elements that have the same functionality must be designed consistently within the application. (see Consistency)MustEN 301 549: 9.3.2.4
129Web: ConsistencyNavigation elements must be displayed in the same relative sequence on each page within the application and receive the keyboard focus.MustEN 301 549: 9.3.2.3
130Desktop: ConsistencyControl elements that have the same functionality should be designed consistently within the application.ShouldWCAG 2.1: 3.2.4 (AA)
131Desktop: ConsistencyNavigation elements that repeat on several screens should always be displayed in the same sequence and receive the focus.ShouldWCAG 2.1: 3.2.3 (AA)
No.PropertyDescriptionClassificationReference
132Use of the keyboardIt must be possible to operate the entire application using the keyboard. This does not apply to necessary path-bound inputs, such as a signature or a freehand screen in an image editing program.

Note 1: An application is operable with the keyboard if all the interactive elements can be accessed and operated with the keyboard.

Note 2: If control elements do not receive the keyboard focus, an alternative use of the keyboard for the corresponding functions must be offered.

MustEN 301 549:
9.2.1.1, 11.2.1.1
133Use of the keyboardPath-bound inputs should also be operable with the keyboard.ShouldWCAG 2.1: 2.1.3 (AAA)
134ConsistencyThe use of the keyboard should be possible according to the known conventions of the platform software. If the use of the keyboard deviates from these conventions, the users should be informed accordingly.

Note: The use of the keyboard for individual elements is described in the “Use of the keyboard” section in this document.

ShouldISO 9241-171:
9.3.15
135Time limitsThe use of the keyboard must be possible without specified time constraints.

Note: For example, it is not permitted

  • that a key has to be pressed for a certain time to trigger an action.
  • that within a certain period of time, two keys must be pressed in succession to trigger an action.

MustEN 301 549:
9.2.1.1, 11.2.1.1
136Keyboard trapThe application may not contain any keyboard traps.

Note: A keyboard trap is an element of the page that can be accessed using the keyboard but cannot be left again using the keyboard.
It must be possible to exit the element using either the standard navigation buttons (such as the tab key, arrow keys, ESC), or users must be informed of the Keyboard shortcuts which allow them to exit.

MustEN 301 549:
9.2.1.2, 11.2.1.2
137Keyboard shortcutsKeyboard shortcuts for printable characters without a modifier key may not be used, unless:
  • the keyboard shortcuts can be disabled,
  • the keyboard shortcuts used can be redefined so that it is not necessary to use any printable characters,
  • the keyboard shortcuts only apply if the keyboard focus is on a specific element.

Note: Modifier keys include the Alt and Ctrl keys. Printable characters include upper and lower case letters, numbers, punctuation marks, and special characters. Among others, the following keys can be used without a modifier key: ESC, delete, function keys, tab key, enter key, space bar, arrow keys.

MustEN 301 549:
9.2.1.4, 11.2.1.4
138Navigation sequenceBei der Navigation mit der Tastatur muss die Navigationsreihenfolge aufgabenangemessen sein (siehe Navigation sequence).MustEN 301 549:
9.2.4.3, 11.2.4.3
139Navigation sequenceWhen navigating with the keyboard, the focus order of the work task should be appropriate.ShouldEN 301 549:
9.2.4.3, 11.2.4.3
140Motion controlIf it is possible for the application to be controlled by motion, it must be possible to disable the motion control and provide a keyboard alternative to the motion control.

Note 1: Motion control encompasses both the movement of the hardware and the movements of the users, which are registered by the software by camera, for example.

Note 2: This does not include necessary motion controls, such those with a pedometer or a GPS device.

MustEN 301 549:
9.2.5.4, 11.2.5.4
141BiometryIf biometric data is required for operational purposes (e.g. fingerprint, facial recognition), an alternative method of operation must be made available.

Note: The alternative method may also be based on biometric data provided that a different form of biometric data is used for this.

MustEN 301 549: 5.3
142Change of contextWhen navigating with the keyboard, no Change of context may occur.MustEN 301 549:
9.3.2.1, 11.3.2.1
143Change of contextWhen changing the value of form elements with the keyboard, no unexpected change of context may occur.MustEN 301 549:
9.3.2.2, 11.3.2.2
144Shown contentIf additional content is shown when receiving keyboard focus, it must be possible to hide such content again using the keyboard without moving the keyboard focus away, unless

Note 1: This does not apply to unchanged content which is displayed by the platform software by default, such as standard tooltips for the respective programming language.

HNote 2: The automatically-shown content can be hidden with ESC, for example.

MustEN 301 549:
9.1.4.13, 11.1.4.13
145Shown contentIf additional content is shown when receiving keyboard focus, it must be displayed until the keyboard focus is moved away, unless
  • the content was deliberately closed (e.g. with ESC) or
  • the content is no longer valid (e.g. an error message in the input field after inputting a correct value).

Note: This does not apply to unchanged content which is displayed by the platform software by default, such as standard tooltips for the respective programming language.

MustEN 301 549:
9.1.4.13, 11.1.4.13
146Different methods of operationUsers should be able to switch between different methods of operation (e.g. operation using the keyboard or operation using the mouse) at any time.ShouldWCAG 2.1: 2.5.6 (AAA)
147Web: EfficiencyIt must be possible to skip areas of content that occur on several pages using the keyboard (see Practical tip: efficient keyboard navigation).MustEN 301 549: 9.2.4.1
148EfficiencyIt must be possible to initialize frequently used functions efficiently with the keyboard.

Note: To do this, keyboard shortcuts and context menus can be implemented. The keyboard shortcuts should be documented in the application and the Help option.

ShouldDIN EN ISO 9241-171: 9.3.10

Use of the keyboard (general requirements)

Permalink "Use of the keyboard (general requirements)"

Note: The operation of individual elements is described at the respective element.

Note: The use of the keyboard does not generally need to be implemented separately, as it is already made available by the platform software or the framework which is used. Care should be taken to avoid overwriting the keyboard shortcuts for other individual functions, however.

ActionKeyClassification
Navigating to an interactive element, exiting an interactive elementTABRequired
Reversal of the direction of navigationSHIFT + [Navigation key]

z. B. SHIFT+TAB oder SHIFT+F6
Required
Highlight, selectSHIFT + [Navigation key]

z. B. SHIFT+DOWN ARROW oder SHIFT+POS1
Required
Navigate within interactive elements (e.g. table, tree structure, selection list, radio button group, etc.)Arrow keysRequired
Enabling of interactive elements
  • ENTER
  • PSACE
Required
Opening the context menu
  • CONTEXT MENU
  • SHIFT+F10
Required
Desktop: Desktop: System menu of the application windowALT+SAPCERequired
Quick navigation to start and end
  • POS1
  • END
Recommended
Quick navigation (skip multiple elements)
  • PAGE UP
  • PAGE DOWN
Recommended
Desktop: Focusing and exiting the main menu
  • ALT
  • F10
Recommended
Desktop: Navigating between application areas
  • CTRL+TAB
  • F6
Recommended
Closing of shown content (such as tooltips, pop-ups, sub-menus)ESCRecommended
Select allCTRL+ARecommended
Copy selection to clipboardCTRL+CRecommended
Cut selection to clipboardSTRG+XRecommended
Paste from clipboardCTRL+VRecommended
Undo the last actionCTRL+ZRecommended
Repeat the last action and/or restore the undoCTRL+YRecommended
Delete elementsDELRecommended
Desktop: Initialize HelpF1Recommended
Desktop: Initialize context-sensitive HelpSHIFT+F1Recommended
Desktop: Closing the applicationALT+F4Recommended
No.PropertyDescriptionClassificationReference
149Desktop: OperationAll the control options of the element must be communicated to the Accessibility API.MustEN 301 549:
11.5.2.11
150OperationIt must be possible to run all the control options of the element with the assistive technology (see Accessibility API).MustEN 301 549: 9.4.1.2, 11.4.1.2, 11.5.2.12, 11.5.2.14, 11.5.2.16, 11.5.2.17
151Keyboard shortcut, shortcut keyKeyboard shortcuts and shortcut keys that are visually perceptible in the application must also be communicated to the Accessibility API.MustEN 301 549: 9.1.3.1, 11.1.3.1
152PositionThe focused element and the selected entry within an element must be communicated to the Accessibility API.MustEN 301 549: 9.4.1.2, 11.4.1.2, 11.5.2.13
153Desktop: PositionThe position of the text cursor must be communicated to the Accessibility API.MustEN 301 549: 11.5.2.13
154Desktop: PositionThe spatial size and position of the elements must be communicated to the Accessibility API (see Focus indicator).MustEN 301 549:
11.5.2.5, 11.5.2.10

Practical tip: use of the keyboard in Web and desktop applications

Permalink "Practical tip: use of the keyboard in Web and desktop applications"

The standard elements of the marking and/or programming language or of the framework used are generally fully keyboard-operable. They should therefore be used with preference.

If custom elements are used, in terms of the keyboard operability, it is necessary to pay attention to the following in particular:

  • Accessibility with the keyboard (e.g. using the tabindex),
  • Operability with the keyboard (event handler for the keyboard and/or device-independent event handler),
  • Operability conforms to the expectations or has been documented (conforms to expectations regarding the visual presentation and the role, that is communicated to the Accessibility API.
  • Focus indicator,
  • Focus handling (e.g. no loss of focus during operation; Navigation sequence),
  • possibly defined keyboard shortcuts are consistent with those of the platform software and/or do not override those of the platform software.

If a custom element is implemented, it is often recommended that a related default element is used and customized accordingly, as it is then possible to use the basic functionality of the default element.

Dragging and dropping elements (drag and drop) can only be done with a pointing device. Designing the alternative form of operation with the keyboard so that it can be used efficiently and in accordance with expectations is recommended. Possible variants include

  • Kontextmenü (e.g. for moving elements to other areas),
  • several buttons, grouped in one toolbar (e.g. for changing the sequence of elements within an area),
  • a button (e.g. for uploading files),
  • individual keyboard shortcuts (e.g. adjustment of the size of elements),
  • keyboard shortcuts of the platform (e.g. cutting and pasting elements using CTRL+X and CTRL+V),
  • use of the arrow keys (e.g. slider),
  • Start and finish with the ENTER key, move with the arrow keys (e.g. drawing a freehand screen).

A combination of the variants is often a good idea (e.g. buttons and keyboard shortcuts).

As the alternative form of operation with the keyboard is not usually visible, it should be described in the application and the Help option.

Control elements that are not permanently visible

Permalink "Control elements that are not permanently visible"

Control elements that are shown and hidden when using the application, e.g.

  • because they are in tooltips, or
  • because they only appear when the keyboard focus is in a particular position,

are not usually operable with the keyboard.

Displaying control elements all the time and avoiding control elements in tooltips, for example, is recommended.

Alternatively, an alternative form of operation must be implemented using the keyboard and described in the Help option and the application. In addition to this, the application must be designed so that it is perceptible with the assistive technology when elements that are not always visible are shown. Blind users, for example, must be able to perceive that a tooltip contains control elements with the screen reader, so that they can use the documented alternative form of operation with the keyboard.

Information about this article

You are welcome to send feedback by email about our handout!