Use of the keyboard

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.

Colors and contrasts). | Must | EN 301 549:
9.1.4.3, 11.1.4.3, 9.1.4.11, 11.1.4.11 | | @!126 | Focus visibility | If a control element receives the keyboard focus, the focus indicator must be visible (see

Fokus indicator). | Must | EN 301 549:
9.2.4.7, 11.2.4.7 | | @!127 | Focus visibility | The focus indicator must have a contrast ratio of at least 3:1 with respect to the background. | Must | EN 301 549:
9.1.4.11, 11.1.4.11 | | @!128 | Web: Consistency | Control elements that have the same functionality must be designed consistently within the application. (see

Consistency) | Must | EN 301 549: 9.3.2.4 | | @!129 | Web: Consistency | Navigation elements must be displayed in the same relative sequence on each page within the application and receive the keyboard focus. | Must | EN 301 549: 9.3.2.3 | | @!130 | Desktop: Consistency | Control elements that have the same functionality should be designed consistently within the application. | Should | WCAG 2.1: 3.2.4 (AA) | | @!131 | Desktop: Consistency | Navigation elements that repeat on several screens should always be displayed in the same sequence and receive the focus. | Should | WCAG 2.1: 3.2.3 (AA) |

Keyboard shortcuts which allow them to exit.

• 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.

Navigation sequence). | Must | EN 301 549:
9.2.4.3, 11.2.4.3 | | @!139 | Navigation sequence | When navigating with the keyboard, the focus order of the work task should be appropriate. | Should | EN 301 549:
9.2.4.3, 11.2.4.3 | | @!140 | Motion control | If 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.

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

Change of context may occur. | Must | EN 301 549:
9.3.2.1, 11.3.2.1 | | @!143 | Change of context | When changing the value of form elements with the keyboard, no unexpected change of context may occur. | Must | EN 301 549:
9.3.2.2, 11.3.2.2 | | @!144 | Shown content |If 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

• the content consists of an error message, or
• the content only hides white space or

  decorative non-text content.

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.

• 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.

Practical tip: efficient keyboard navigation). | Must | EN 301 549: 9.2.4.1 | | @!148 | Efficiency | It 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.

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.

Accessibility API). | Must | EN 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 | | @!151 | Keyboard shortcut, shortcut key | Keyboard shortcuts and shortcut keys that are visually perceptible in the application must also be communicated to the Accessibility API. | Must | EN 301 549: 9.1.3.1, 11.1.3.1 | | @!152 | Position | The focused element and the selected entry within an element must be communicated to the Accessibility API. | Must | EN 301 549: 9.4.1.2, 11.4.1.2, 11.5.2.13 | | @!153 | Desktop: Position | The position of the text cursor must be communicated to the Accessibility API. | Must | EN 301 549: 11.5.2.13 | | @!154 | Desktop: Position | The spatial size and position of the elements must be communicated to the Accessibility API (see

Focus indicator). | Must | EN 301 549:
11.5.2.5, 11.5.2.10 |

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 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

Date:

15.01.2024

License:

CC-BY-SA 4.0

Version:

1.0

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