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:
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.
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.
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:
and so on, to the bottom of the PanedWindow.
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:
If a control uses and
for internal navigation, it must support the
following behavior:
Groups that are fields can also use ,
,
, and
to move the location cursor to appropriate
controls within the group.