Keyboard interaction covers a range of behaviors, from text entry and shortcuts, through to the keyboard being used as the sole input device. The latter is vital for visually-impaired people or those with mobility impairments.

While many aspects of keyboard interaction are relevant to accessibility, some users prefer to use the keyboard and it can be an efficient alternative to pointer-based interaction.

Just as it should be possible to perform every action with a pointing device, so every action should also be possible with the keyboard. Most of the time, this is easy to achieve with the standard keyboard features described below. However, some operations — like drag-and-drop — may require more thought.

Test how accessible your app is by trying to use it with just a keyboard.

Shortcut Keys#

Use the standard GNOME shortcut keys if your app supports those functions. This ensures consistency between GNOME apps and aids discoverability.

Shortcut keys should also be assigned to the most commonly-used actions in your app. However, don’t assign shortcuts for everything.

When assigning non-standard shortcuts in your app:

  • Try to use Ctrl in combination with a letter.

  • Shift+Ctrl and a letter is the recommended pattern for shortcuts that reverse or extend another function. For example, Ctrl+Z is the shortcut for undo, and Shift+Ctrl+Z is the shortcut for redo.

  • Shortcuts should be as mnemonic as possible, as this makes them easier to learn and remember. For example, Ctrl+E would be a good shortcut for an edit action.

  • Do not use Alt for shortcut keys, as this may conflict with access keys.

  • GNOME reserves the use of the Super key for use in system shortcuts. Super should therefore not be used by apps. Additional legacy system shortcuts should also be avoided by apps.

  • Don’t assign awkward reaches. Some people may only be able to use one hand on the keyboard, so shortcuts that can be easily used with one hand are preferable for common operations. (This guideline also applies to access keys below.)

The technical term for shortcut keys is accelerators.

Access Keys#

Access keys allow someone to operate labelled controls by holding Alt in combination with another key. These are indicated by an underlined letter within each control label (this is displayed when Alt is held down). As far as possible, all labelled components should have an access key.

Guidelines for selecting access keys:

  • Choose access keys that are easy to remember. Normally this means using the first letter of the label. If the label has more than one word, the first letter of one of its other words can also be used. Additionally, if another letter provides a better association (for example: “x” in “Extra Large”) , consider using that letter instead.

  • Avoid assigning access keys to “thin” letters (such as lowercase i or l), or letters with descenders (such as lowercase g or y), unless it is unavoidable. The underline is sometimes not as clear with these characters.

  • If it is difficult to assign access keys to all labelled controls, assign access keys to the most frequently-used controls first. If the first letter is not available, choose an easy to remember consonant from the label, for example, “p” in “Replace”. Only assign vowels once no consonants are available.

  • Be aware that access keys have to be translated together with the strings that they are taken from, so even if there are no conflicts in your native language, they may occur in translations.

The technical term for access keys is mnemonics.

Keyboard Navigation#

It should be possible to move around and interact with every part of your user interface using the keyboard. This is primarily done with the tab key, which moves through each UI element in sequence.

The keyboard focus sequence follows the internal widget tree, and is usually logically structured by default. However, you should test to make sure that the focus order is logical and traverses each UI element.

Other guidelines for keyboard navigation:

  • When possible, play the alert sound when tab fails to move keyboard focus. For example, when the focus is on the first character in a text field and the user presses left arrow key, or when the user tries to perform multiple selection in a single selection dialog.

  • Control labels should immediately precede their control in the keyboard focus order. This will ensure that the access key you assign to the label will move focus to or activate the control.

  • Where possible, arrow keys should allow moving around the UI in a directional fashion.

Standard Navigation Keys#

The following keys should automatically work for the majority of GNOME user interface elements. However, it is recommended to test to ensure that they do work correctly. Custom UI should support the standard navigation keys.




Move keyboard focus to the next control


Move keyboard focus to the previous control


Move keyboard focus to the next control, when Tab has another function (this is primarily relevant to text entries)


Move keyboard focus to the previous control, when Tab has another function


Activate the focused control or content item


Toggle the state of a control


Open primary or secondary menu

Menu / Shift+F10

Open context menu for focused location


Close the current container, if it is transient (applies to menus, popovers and dialogs)