[Contents] [Index] [Next] [Previous]

Keyboard-Based Navigation


The navigation model for keyboard users is more complicated than the pointer navigation model. As described earlier, keyboard navigation is only required when the focus policy is explicit. Since window managers, applications, and components must support the explicit focus policy, they must also support keyboard navigation. The keyboard navigation model is composed of the following:

Location Cursor

The window with the focus is identified by highlighting the window border as described in Window Manager Design Principles. Within the window with the focus, the component with the keyboard focus is identified by the location cursor. The term location cursor refers to any visual element that indicates the location where keyboard events are sent. The location cursor is not strictly a cursor. The name cursor simply refers to its use as indicating the location of input.

The location cursor is shown in a number of ways, depending on the type of component with the keyboard focus. Possible location cursor types and their uses are described in the following text. When designing new components, you should try to use one of the existing styles of location cursor, but you can create your own if it is appropriate.

Box
The box cursor should be the default location cursor. It is shown as a box drawn around the object. The first ToggleButton in a group with a box style location cursor is shown below.

Outline Highlight
This cursor style is similar to the box style cursor. The outline is shown of a component whose outline is not normally shown. This form of location cursor is commonly used within Menu systems to show the Menu item with the location cursor. A Menu with an outline highlight style location cursor is shown below.

Text Cursor
In Text components, the text cursor acts as the location cursor to indicate that the Text component has the keyboard focus. Possible text cursor shapes are shown below.

A text cursor must be shown differently when the Text does and does not have the keyboard focus. This can be done by

If the text cursor is hidden when the Text component does not have the focus and if the component gets the focus, the text cursor must reappear at the same position it had when the component lost focus. A Text component can optionally include an outline highlight style location cursor to reinforce the location of the keyboard focus. A Text component with the keyboard focus is shown below.

Item Cursor
A component that manages groups of elements, like a List, should indicate that it has the keyboard focus with an item cursor style location cursor. An item cursor highlights a single element, or group of elements, that the component acts on. In the case of a List, the item cursor should be a box around an element. In the case of a Drawing area, it could be a box with resize handles around a drawn element. Components that use an item cursor to indicate keyboard focus can optionally include an outline highlight style location cursor to reinforce the location of the keyboard focus. A List component with the keyboard focus is shown below.

Fill
Some very small components, like a Sash for resizing Panes, should indicate the keyboard focus by filling. Where this is the case, there must be no other meaning associated with the filled state. Filling avoids the problem caused by other styles of location cursor that make the small component too large. The first of two Sashes with the keyboard focus is shown below.

Components must be designed and positioned within applications so that adding and removing the component's location cursor does not change the amount of space that the component takes up on the screen; that is, there is always room for the location cursor.

Window Navigation

A typical environment has several applications in operation simultaneously. Each application typically has a main or primary window that displays data and in which the user carries on primary interaction with the application. Applications can have additional windows to communicate context-specific interactions with the user of the application. These additional windows are called secondary windows, or transient windows. DialogBoxes are often used to create secondary windows.

The window navigation model can be divided into two levels:

A window family consists of a single primary window and all of its associated secondary windows. and move the focus among windows in a window family. and move the focus among window families. Window navigation is described in more detail in Window Manager Design Principles.

Component Navigation

Component navigation moves the location cursor, and therefore the keyboard focus, among components in a window. The window is divided into fields, and operations that use the key move the cursor from one field to another. For this reason, fields are also known as tab groups. The directional keys , , , and are used for navigation within a field.

Menu systems, including the MenuBar, follow a different traversal model, described in Menu Traversal.

A field can be an individual control, such as a Text control. In this case, the directional keys are used for internal navigation within the control. Alternately, a field can consist of a group of controls such as a RadioBox, which holds a group of RadioButtons. In this case, the directional keys are used to navigate among the component controls of the group.

The fields in a window are ordered. generally moves the location cursor to the next field, and moves the location cursor to the previous field. However, a field can use and for internal navigation. For example, within a multiline Text control, is used to tab within the text. Consequently, must always navigate to the next field, and must always navigate to the previous field.

(if not used for internal navigation) and must move the location cursor forward through fields according to the following rules:

If the next field contains no traversable components, (if not used for internal navigation) and must skip the field. Note that Separators and Labels should not be traversable. The ScrollBars of ScrolledWindows also should not be traversable, particularly if a [ScrollLock] key is available on the keyboard.

(if not used for internal navigation) and must move the location cursor backward through fields in the order opposite to that of (if not used for internal navigation) and .

When a window acquires focus, the location cursor must be placed on the control that last had focus in the window, providing that all the following conditions are met:

If the component that last had focus is no longer traversable, or if the window has not previously had the focus, the location cursor should be placed on the component with which the user is most likely to want to interact. In a DialogBox, this is often a text control or a default button. If no such control exists, the location cursor should be placed in the first field in the window-in a left-to-right language environment, the top-leftmost field.

Developers should follow these general rules for field navigation:

Directional keys are used both for component navigation within a field and for internal purposes, including internal navigation, within a control.

When and are used for component navigation within a field, they must behave in the following way:

When and are used for component navigation within a field, they must behave in the following way:

Controls that use directional keys internally - such as Text, List, Canvas, Sash, ScrollBar, and Scale - should be fields. If a control that uses directional keys internally does not act like a field, the directional keys must be used for both internal purposes and component navigation.

In particular, controls can use directional keys in one dimension for internal purposes and in another dimension for component navigation. For example, a vertically organized group of single-line Text controls can be grouped together as a single field. and navigate among the single-line Text controls in the field. , , , and navigate among characters and words within an individual single-line Text control.

The directional keys modified with can also be used for component navigation, following the same rules specified above. If the directional keys modified with are used for component navigation, the unmodified directional keys can be used for internal purposes.

For example, a table can consist of an array of single-word Text controls, with and used to navigate up and down a column. and can navigate among characters within an individual single-word Text control, while and navigate horizontally among the Text components in a row.

Within a control, the directional keys can be used in a variety of ways. In list-like controls, or in graphics-like controls in which the elements are laid out in a matrix-like arrangement, internal navigation using the directional keys should move the cursor among elements using the same rules followed for component navigation. However, if the control is scrollable, directional navigation should not wrap between the first and last elements of the control; a directional key that would otherwise cause wrapping should have no effect at the first or last element.

Additional internal navigation techniques may be needed in situations not covered by this guide, such as the following:

In such cases, navigation models should not deviate unnecessarily from the standard navigation models.

Rather than move the cursor among elements, a graphics-like control can use a positional cursor. In this case, , , , and must internally navigate by moving the cursor one unit (for example, one pixel) at a time in the direction indicated by the key. In this model, the cursor is sometimes on an element and sometimes in the background of the control.

The use of the directional keys for internal navigation in text-like controls is described in the Text reference page in Controls, Groups, and Models Reference Pages. In a control that displays a value, the directional keys can increment or decrement that value.

When the directional keys cause changes that are based on some unit, the directional keys modified by can cause changes based on a larger unit. For example:

If a control uses and for internal navigation, it must support the following behavior:

In a left-to-right language environment, this action must move the location cursor to the leftmost edge of the data or the leftmost element. In a right-to-left language environment, this action must move the location cursor to the rightmost edge of the data or the rightmost element.
In a left-to-right language environment, this action must move the location cursor to the rightmost edge of the data or the rightmost element. In a right-to-left language environment, this action must move the location cursor to the leftmost edge of the data or the leftmost element.

If a control uses and for internal navigation, it must support the following behavior:

This action must move the location cursor to one of the following:
This action must move the location cursor to one of the following:

Groups that are fields can also use , , , and to move the location cursor to appropriate controls within the group.