Sun Web Application Guidelines - Version 4.0

Search Guidelines    |    Send Feedback   |    Developers.sun.com

How To Use These Guidelines - An Introduction
 

7 Simple Elements

7.1 Action Buttons

7.1.1 Primary Buttons

7.1.2 Disabled Buttons

7.1.3 Default Buttons

7.1.4 Iconic Buttons

7.1.5 Button Coding

7.1.6 Button Labels

7.2 Elements Used for Choosing Data, Performing Actions, and Navigating

7.2.1 Elements Used for Choosing One Value

7.2.1.1 Checkbox

7.2.1.2 Set of Radio Buttons

7.2.1.3 Standard Drop-Down Menu

7.2.1.3.1 General Drop-Down Menu Behavior

7.2.1.4 Scrolling List

7.2.2 Elements Used for Choosing One or More Values

7.2.2.1 Set of Checkboxes

7.2.2.2 Multiple Selection Scrolling List

7.2.3 Elements Used for Performing Actions and Navigating

7.2.3.1 Jump Menus

7.2.3.2 Jump Menu Behavior

7.2.3.3 Grouping Menu Items

7.3 Text Elements

7.3.1 Labels

7.3.2 Editable Text Fields

7.3.3 Password Fields

7.3.4 Text Areas

7 Simple Elements

This chapter addresses the design of simple user interface elements that are used in similar ways across applications.

When using the user interface elements described in this chapter and elsewhere in these guidelines, remember to use them with cultural considerations in mind. For example, applications must be able to format and display time, date, and calendar data according to local cultural conventions.

To ensure that cultural considerations are addressed when using user interface elements, follow the guidelines in Appendix H, Globalization Requirements.

For most elements, there is an enabled (normal state), a noneditable (read-only) state where the value is applicable but the user cannot change it, and a disabled (not applicable) state for when a value for that field does not apply to the current situation. For fields which do not show a data value, such as buttons and jump menus, the only applicable states are enabled and disabled. The possible appearances are documented for each type of field.

For more information on the placement of read-only fields within a page, see 6.8.1 Noneditable User Interface Elements.

7.1 Action Buttons

Generally, use buttons for actions and use hyperlinks for navigation.

There are three main action button styles:

• Primary
• Secondary
• Iconic buttons

The appearance of each button type will vary depending on the button's state and/or its use. The following table shows state appearance for Primary and Secondary buttons. See 7.1.4 Iconic Buttons for more information about iconic buttons.

7.1.1 Primary Buttons

The primary button's unique appearance indicates that it is the most commonly used button within a page or panel. (A panel is a unit within the page which the user operates within and closes. See 9.5.3 Table Preferences for an example of a table panel). The primary button's uniqueness helps to guide users through a task by helping them find the button most likely to help them accomplish the task.

Only the main button within a page or panel can use the primary button style. The only time a given page might contain more than one primary button is if the main button on the page is a primary button and the page contains a panel that includes a primary button.

If the main button in the page or panel "group" consists of only one button, that button is virtually always a primary button.

All buttons associated with a particular field or section should be secondary buttons.

Use caution when making destructive actions, such as Delete, primary buttons. However, if the user is mostly likely to click this button, and it is the main button on the page or panel, it can be the primary button.

7.1.2 Disabled Buttons

A disabled button is a button that users cannot use in the current context, but the button can be used if the context changes. The implication is that the user can enable the button by taking some action, such as selecting a row or an item in a list.

Do not use a disabled button if it will never become enabled. Instead, just do not display the button.

For example, if security restricts access to a button, hide it instead of displaying it as disabled. This guideline does not apply, however, to a series of pages, as in a wizard, where the button might not apply on the current pane but will apply on other panes. Therefore, the disabled button should be shown for consistent button layout throughout the series.

7.1.3 Default Buttons

Default buttons, buttons that are activated automatically when users press the Enter key, are not provided in the Sun Common UI Component Library (in open source, the Project Woodstock components).

If desired, default button behavior can be developed independent of the Sun Common UI Component Library (in open source, the Project Woodstock components).

If default button behavior is provided, the following guidelines apply:

• There can be default-style behavior for buttons paired with a single text field, such as search. Beyond that situation, default button behavior is typically associated with only the one primary button on the page or pop-up window.
• Do not add any visual treatment to the primary button when default button behavior is associated with it.
• Be consistent in the use of default button behavior throughout the application.

On a Login page, default button behavior should be developed and associated with the primary button.

Other situations where it may be useful to provide default button behavior for a primary button include:

• on a pop-up window with just one or two fields
• when a button appears next to a search field. In this case, only when focus is in the search field would pressing Enter activate the button associated with the field.

7.1.4 Iconic Buttons

Iconic buttons (buttons without any text label) are created based on the context in which they are used. See 2.4 Icons for more information about iconic buttons.

Buttons with icons only for labels must have text associated with them in the HTML attributes Alt and Title.

Use the HTML Alt and Title attributes to assign an alternative text description and tool tip. These attributes help users who are unclear about the meaning of the icon and are critical for users who use screen readers.

7.1.5 Button Coding

The button design supported by these guidelines uses a styled HTML form button.

This implementation allows for localization, unlike using a graphic.

For detailed information on the layout and use of the various button types within a content page, see 6.5.2 Content Page Action Buttons.

For detailed information on the layout and use of buttons in a wizard, see 13.1 Anatomy.

7.1.6 Button Labels

Note: Although this section discusses labels for actions represented as buttons, these guidelines also apply to labels of actions represented via other user interface elements, such as drop-down menu commands or embedded table actions. See 6.5 Content Area Actions for information about representing actions using different user interface elements.

Apply headline capitalization to all button labels (see 2.5 Text Capitalization).

Use button labels according to the guidelines in the following table. 

Never use button labels from the following table.

If a button merely initiates an action that is later completed in a secondary-content page or a pop-up window, notify users by placing ellipsis points (...) after the button text. An example of a button that would always use ellipsis points would be the "Browse Server..." button.

This requirement applies only to text in buttons. Ellipsis points are not used in iconic buttons.

For example, after clicking a "Print..." button, users are presented with a dialog page in which they specify the printer location, how many copies to print, and so forth. In contrast, a "Print" button that prints one copy to the default printer without displaying a dialog page should not have ellipsis points.

Do not use ellipsis points in buttons that fully specify an action, even if that action opens a pop-up window. In this case, opening the pop-up window is the result of the action.

For example, a "View Properties" button should not have ellipsis points if the resulting secondary-content page or pop-up window displays the properties that the user requested. Ellipsis points are inappropriate because the pop-up window is not used for specifying an action, but is instead the result of carrying out the requested action.

7.2 Elements Used for Choosing Data, Performing Actions, and Navigating

This section discusses several elements that allow users to choose one or more data values in fields within a page, elements that allow users to perform actions, and simple elements that allow users to navigate. This section does not cover choosing entire rows of data, which is a topic covered in 9.3 Selection in Tables or more advanced means of navigation, covered in Chapter 5, Top-Level Navigation.

Use a particular element for choosing data only if the requirements listed for that element are satisfied. Note whether ALL or ANY of the listed values must be satisfied.

7.2.1 Elements Used for Choosing One Value

• Checkbox
• Set of radio buttons
• Standard drop-down menu
• Scrolling list

Subsequent sections provide details about appropriate uses for these elements.

7.2.1.1 Checkbox

A checkbox is the simplest user interface element for choosing data.

Use a checkbox only if ALL of the following are true:

• Users can choose between True and False, or between one value and no value.
• Checked means definitely True.
• Unchecked means definitely False, and never means null, undefined, varies, etc.
• The variable being represented is a boolean, with only True or False values possible, never with a third, null, or undefined, or varies, etc, possible value.
• A user clicking the checkbox twice will return the UI to its previous state, as if the user did nothing.

Otherwise, use radio buttons or a drop-down menu to explicitly show all the possible values to the user, and to permit the user to select from amongst all the possible acceptable values.

Place a label to the right of the checkbox.

Display the checkbox label according to the guidelines specified in 7.3.1 Labels.

Apply headline capitalization to all checkbox labels (see 2.5 Text Capitalization).

Allow users to select a checkbox by clicking on either the box itself or its label.

Do not use Checkboxes to trigger immediate actions (i.e. submitting the page, hyperlinking, or opening a window) unless the action is solely for purposes of redrawing the same page to facilitate interactivity (i.e. showing additional information) on the same apparent page whose edits remain uncommitted and in-progress (from the user's perspective).

Instead, use Buttons to trigger immediate actions.

Note that many checkboxes do not trigger actions but set boolean flag variables for an action to be performed later (see 2nd example). These are not triggers of immediate actions at all. This guideline does not apply to such situations.

When checkboxes are used in an aligned, labeled set of fields (i.e. on a Property Page), each checkbox must have BOTH a normal label on the left and a description of the checked state on the right. Exception: if the checkbox is in a set of related options, use a single normal label on the left to label the whole set (top-align the label to the set).

When checkboxes are used in an aligned, labeled set of fields (i.e. on a Property Page), and when checkboxes are used to indicate enabled, on, active, or similar concepts describing system or object state, then these rules apply:

• The text on the left of the checkbox (the field label) should be the name of the affected object or subsystem [or a general term such as "mode"]. This is generally a noun [phrase] or infinitive verb in English.
  
  
   
  
• The text on the right of the checkbox should be the description of the checked state. This is generally an adverb (for infinitive verbs on the left), adjective (for noun phrases on the left), or affirmative statement. Avoid Yes and True.
  
  
   
  
• Do not repeat the same words on both sides of the checkbox.
  
  
   
  
• Be consistent within an application with regard to the terminology used (i.e. don't mix "enabled" and "active") and the format of labeling checkboxes.
  
  
   
  
• Do not artificially split a multiword concept term into two parts just to comply with the rules above.
  
  

7.2.1.2 Set of Radio Buttons

Use a set of radio buttons if ALL of the following are true:

• Users can choose from among a maximum of ten options, or if there are icons associated with the different options, twenty options. Icons can be used to help users more easily identify individual options or groups of options from which a selection can be made. (Icons cannot be placed next to items in drop-down menus. Thus, when icons need to be associated with the different options, radio buttons are used.)
• Users can select only one option at a time.
• The page has sufficient space to display all the options (without causing unnecessary page scrolling).
• One option must always be selected. See the following guideline if you need to represent that none of the options are selected.

When these conditions are met, radio buttons are preferable to drop-down menus because all the possible options are always visible.

If you need to represent <none selected>, add an additional radio button for this purpose. For example, a radio button labeled "Unknown" or "None" could be added.

Place each radio button label to the right of the radio button.

Display the radio button labels according to the guidelines specified in 7.3.1 Labels.

Apply headline capitalization to all radio button labels (see 2.5 Text Capitalization).

Allow users to select a radio button by clicking on either the button itself or its label.

Follow the guidelines in 6.7 Secondary-Content Page Layout and Use to determine how to position a set of radio buttons on a page with other user interface elements (for example, on a page that allows users to view, edit, and save changes to an object's properties).

When you can clarify the meaning of the radio button set, label the set on the left and align the label with the topmost radio button. However, never provide a label only to the left of a radio button or to the left of each radio button in a set. See the example at the beginning of this section.

Display the radio buttons using a vertical layout if space is available.

A vertical layout is most commonly used when icons are associated with the radio buttons to help users more easily identify the desired selection. For example:

When vertical space is limited, use a horizontal layout for the radio buttons.

A horizontal layout is usually less visually clear than a vertical layout, so users have more difficulty scanning the options. If you use a horizontal layout, include sufficient space between the options to avoid confusion about which radio button is associated with which text label. However, keep the options close enough to visually indicate that they form a distinct set of radio buttons.

For example:

Also consider laying out radio buttons in columns (with the order of the options running down the first column, then down the second column, and so on).

7.2.1.3 Standard Drop-Down Menu

Drop-down menus are also known as:

• Drop-down lists
• Noneditable combo boxes (in Swing Components and thus also in the Java Look and Feel Design Guidelines)
• Pop-up lists
• Pull-down menus (even though they are not similar to pull-down menus, such as File and Edit at the top of Java™ technology-based application windows)

There are two types of drop-down menus specified in these guidelines: standard menus and jump menus. These menu types exhibit different behavior and have a different appearance. The standard menu is described in this section.

Standard menus are the type of menu used to simply choose a data value. Standard menus are not used to perform actions or allow simple navigation. For this, use a jump menu (see 7.2.3.1 Jump Menus). The selections in standard drop-down menus should usually be nouns, not verbs.

A standard drop-down menu looks like this:

Standard menus exhibit typical menu behavior in that when a user selects an item, the menu closes and the selected item is shown. Note that sometimes when a value is selected, additional information or UI elements may be displayed, or existing elements may be enabled or disabled. This does not mean that a jump menu should be used. A change such as this is considered more of a side-result of choosing a particular value. Only when the selection explicitly performs an action or explicitly navigates to another page or view would a jump menu be used.

Use a standard drop-down menu if ALL of the following are true:

• Users are attempting to choose a single data value from among a number of possible values.
• Users can choose among more than two values, or the page has insufficient space for a set of radio buttons.
• No more than approximately 75 values are available.
• There is no need to associate icons with the options. (If you wish to associate icons, consider using radio buttons. See 7.2.1.2 Set of Radio Buttons.)
• The data does not have more than 3 values which begin with the same letter or number, as otherwise the field becomes unwieldy to set without using a mouse.  For example, date fields are poor choices for drop-down lists as the user would have to type 1 ten times to finally get the drop-down list to the date value 19 (or press the down arrow up to 18 times instead).
  

Place a label to the left of all standard drop-down menus, as is done with other entry fields, according to the guidelines specified in 7.3.1 Labels. Do not include the label within the drop-down menu itself.

This placement differs from the jump menus as described in 7.2.3.1 Jump Menus.

Apply headline capitalization to the labels of standard menus (see 2.5 Text Capitalization).

If the user is not required to make a selection from a standard menu, include a blank option and select it by default if that most accurately reflects the system's current state. The user may choose something else or may keep the blank option (assuming it is selected). (If you need to be more specific than using blank, insert some text within parentheses for this option. For example, make "(No Color)" a selectable item in a list of color choices.) Below is an example of of a standard menu with a blank option selected:

If the user must make a selection from a standard menu, choose an appropriate default value from the list of options. If there is no appropriate default value, include (and select by default, if appropriate) a blank option, but make sure there is an asterisk image associated with this field indicating that it is a required field (see 7.3.2 Editable Text Fields). (Do not display text in parentheses instead of a blank option as this misleadingly suggests a valid value has been chosen.) If the user does not choose a value from the list and then submits the page, provide an error message indicating that a selection is required (see Chapter 14 Alerts and Messages).

For information about grouping the menu items within a standard menu, see 7.2.3.3 Grouping Menu Items.

7.2.1.3.1 General Drop-Down Menu Behavior

The information in this section applies to both standard menus (described in the previous section) and jump menus (see 7.2.3.1 Jump Menus).

Provide users with several ways to select an item in the drop-down menu. Allow them to:

• Click the drop-down menu to open the menu, position the pointer over the desired item to highlight it, and then click.
• Press the mouse button in the drop-down menu to open the menu, drag through the menu to the desired item, and then release the mouse button.
• Use the arrow key to move up and down through the items in the menu.
• Type a letter to jump to the first item that begins with that letter (and possibly arrow or click from there). (In the Macintosh version of Internet Explorer, multiple letters can be specified if they are typed quickly enough.)
• On Windows platforms, use Alt-Down to open the menu, use arrow keys or hovering mouse to move the highlight, then use Enter to complete the selection.

If all of the items in a menu are temporarily disabled due to system state, allow the menu to open and display all of the disabled menu items rather than disabling the entire menu. If all of the menu items are permanently unavailable, the menu should not be displayed.

For items in the drop-down menu (most applicable to standard menus), you can combine two data elements, usually shown as concatenated together with a hyphen.

This strategy is most often used when an option has both a code and a description. For example, a severity drop-down menu might contain these items:

1 - Corrupts Data
2 - Crashes Program
3 - User Interface Issue

7.2.1.4 Scrolling List

Display the scrolling list label according to the guidelines specified in 7.3.1 Labels.

Align the scrolling list label to the left of the list's top item.

If the user is not required to make a selection from the scrolling list, include a blank option and select it by default if that most accurately reflects the system's current state. The user may choose something else or may keep the blank option (assuming it is selected). (If you need to be more specific than using blank, insert some text within parentheses for this option. For example, make "(No Color)" a selectable item in a list of color choices.) This guideline does not apply to editable scrolling lists, the add-and-remove idiom, and orderable lists. See Chapter 8, Complex Elements for information on these elements. Below is an example of of a scrolling list with a blank option selected:

If the user must make a selection from the scrolling list, choose an appropriate default value from the list of options. If there is no appropriate default value, start with no selection for the list, but make sure there is an asterisk image associated with this field indicating that it is a required field (see 7.3.2 Editable Text Fields). If the user does not choose one or more of the values from the list and then submits the page, provide an error message indicating that a selection is required (see Chapter 14 Alerts and Messages).

If you are grouping items in the scrolling list, follow the guidelines specified in 7.2.3.3 Grouping Menu Items.

Though scrolling lists are not often used for choosing a single value, use a scrolling list if ALL of the following are true:

• Users can choose among approximately 10 or more values.
• The page has sufficient space to show at least 5 list items, and preferably, at least 10 percent of the number of expected list items. (Otherwise, scrolling is just as clumsy as using a drop-down menu.)
• There is no need to associate icons with the options.
• Users do not want to type the first letter of the desired option to jump to it. (This feature does not work in scrolling lists.)

7.2.2 Elements Used for Choosing One or More Values

• Set of checkboxes
• Multiple selection scrolling list
• Editable scrolling list
• Add-and-remove idiom

Subsequent sections in this chapter provide details about appropriate uses for sets of checkboxes and multiple selection scrolling lists. See 8.1 Editable Scrolling List and 8.2 Add-and-Remove Idiom for details about these, more complex, elements.

7.2.2.1 Set of Checkboxes

Use a set of checkboxes if ALL of the following are true:

• Users can select or deselect up to ten checkboxes, or if there are icons associated with them, up to twenty checkboxes. Icons can sometimes be used to help users more easily understand the choices being offered. For example, if choosing colors, seeing a swatch of color in an icon could help users understand the textual descriptions of the color choices given by the checkbox labels.
• Users can select any combination of the values.
• There is no need for users to specify an order for the selected values.
• The page has sufficient space for a set of checkboxes.
• It is not required that the user select any of the options offered by the checkboxes.

Display checkbox labels according to the guidelines specified in 7.2.1.1 Checkbox.

When you can clarify the meaning of the set of checkboxes, label the set on the left and align the label with the topmost checkbox. However, never provide a label only to the left of a checkbox or to the left of each checkbox in a set.

Where appropriate, this label can be plural (such as "Installed Browsers" rather than "Installed Browser").

Display the checkbox set label according to the guidelines specified in 7.3.1 Labels.

Apply headline capitalization to both the checkbox set label and each individual checkbox label (see 2.5 Text Capitalization).

Consider associating icons with the checkboxes to help users more easily identify the desired options, similar to the strategy of associating icons with radio buttons. 

7.2.2.2 Multiple Selection Scrolling List

Use a multiple selection scrolling list if ALL of the following are true:

• Users can choose multiple values, and it is inappropriate to use a set of checkboxes. See 7.2.2.1 Set of Checkboxes for guidelines regarding when to use checkboxes.
• It is not important for users to view all their selected values at once (as some values will likely be scrolled out of view).

Multiple selection scrolling lists are also used in the following more complex user interface elements: 8.1 Editable Scrolling List, 8.2 Add-and-Remove Idiom and 8.3 Orderable List.

Display the label for the multiple selection scrolling list according to the guidelines specified in 7.3.1 Labels.

Apply headline capitalization to the label (see 2.5 Text Capitalization).

Include text just below the multiple selection scrolling list that tells users they can select multiple values. Make this text platform-specific so that users know which keys to press.

This text serves to differentiate the multiple selection scrolling list from a single selection scrolling list, to which it would otherwise appear identical.

Make this text smaller than normal. (See information about Field Inline Help in 11.1 Inline Help.) While considering operating system differences, a technical writer can choose the text's final wording.

Align the multiple selection scrolling list label to the left of the list's top item. Make the label plural.

If the user is not required to make a selection from the multiple select scrolling list, include a blank option and select it by default if that most accurately reflects the system's current state. The user may choose one or more other options or may keep the blank option (assuming it is selected). (If you need to be more specific than using blank, insert some text within parentheses for this option. For example, make "(No Color)" a selectable item in a list of color choices.) If the user selects this option along with other options and submits the page, display an error message indicating that the blank option in their selection is in conflict with the other selections (see Chapter 14 Alerts and Messages). The user must choose either the blank option or one or more of the other options. This guideline does not apply to editable scrolling lists, the add-and-remove idiom, and orderable lists. See Chapter 8, Complex Elements for information on these elements. Below is an example of of a multiple selection scrolling list with a blank option selected:

If the user must make a selection from the multiple select scrolling list, choose an appropriate default value from the list of options. If there is no appropriate default value, start with no selection for the list. In either case, make sure there is an asterisk image associated with this field indicating that it is a required field (see 7.3.2 Editable Text Fields). This is important because users can deselect all items using this user interface element. If the user does not choose one or more of the values from the list and then submits the page, provide an error message indicating that a selection is required (see Chapter 14 Alerts and Messages).

If the user needs to be able to order the items in the scrolling list, see section 8.3 Orderable List.

7.2.3 Elements Used for Performing Actions and Navigating

A number of elements can be used to allow users to perform actions within an application. Actions are commonly available via buttons which are described above in 7.1 Action Buttons. In tables they can be provided via buttons or via links (see 9.4.3.3 Using Embedded Table Actions). In addition, actions can be provided in a type of drop-down menu called a jump menu (see the following section).

Navigation is typically provided by more complex elements such as trees and tabs (see Chapter 5, Top-Level Navigation). In tables they can be provided via links (see 9.2 Embedded Table Navigation). In addition, the jump menu can also be used to allow users to navigate among different views of a given page.

Jump menus, as used to perform actions as well as to navigate among views, are described in the following section.

7.2.3.1 Jump Menus

Drop-down menus are also known as:

• Drop-down lists
• Noneditable combo boxes (in Swing Components, and thus also in the Java Look and Feel Design Guidelines)
• Pop-up lists
• Pull-down menus (even though they are not similar to pull-down menus, such as File and Edit at the top of Java™ technology-based application windows)

There are two types of drop-down menus specified in these guidelines: standard menus and jump menus. These menu types exhibit different behavior and have a different appearance. The jump menu is described in this section.

Jump menus perform some action, such as opening a window, or allow simple navigation to another page or view when the user selects an item in the menu. Jump menus are not used for choosing a data value. For this, use a standard drop-down menu (see 7.2.1.3 Standard Drop-Down Menu).

The distinguishing traits of a jump menu are:

• The items listed in a jump menu are displayed as links (use the default link text color as described in 2.1 Color Palette)
• An action or navigation results immediately upon selection of an item in a jump menu

A jump menu used to allow users to perform an action looks like this:

When used for providing actions, a jump menu does not display a label to the left of it. Instead, it has a title with em-dashes (—) around it (for example, — Actions — ) displayed inside the drop-down menu itself. This label is displayed to let users know what kind of items are contained within the drop-down menu, and this label is re-displayed after a valid selection is made, and its associated action is performed. See 7.2.3.2 Jump Menu Behavior for more information on jump menu behavior. Usually, the entries in an action Jump Menu are verbs, not nouns.

See 6.5.3 Content Page Actions Drop-Down Menu and 9.4.3.2 Using a Single Drop-Down Menu for Table Actions for example uses of jump menus for performing actions.

A jump menu used to allow users to navigate looks like this:

When used for navigation, a jump menu does display a label to the left of it, similar to the way a standard menu is displayed (see 7.2.1.3 Standard Drop-Down Menu). Common labels for a jump menu used for navigation are "View:" and "Filter:." Note that filtering (for example, in a table) is considered to be a form of navigation as the user explicitly requests to see a different (filtered) view of the data. The user isn't choosing the action to "Filter" from the jump menu, but choosing which filtered view (for example, which alarm severity) to display. Alarm severities are not actions.

When used for navigation, the selected value is displayed in the menu so that the currently selected view (or filter) is always visible to the user.

See 6.4.1 Using a Drop-Down Menu for Content Area Navigation and 9.5.1.1 Basic Table Filtering for examples of uses of jump menus for navigation.

Give each jump menu a label, inside of it when used for performing actions, or to the left of it when used for navigation.

Use a jump menu if ALL of the following are true:

• Users are attempting to perform an action or perform simple navigation (for example, navigating among page views)
• Users can choose among more than two values, or the page has insufficient space for a set of action buttons or navigation links.
• No more than approximately 75 values are available.

Display jump menu labels, when they appear to the left of the menu (when used for navigation), according to the guidelines specified in 7.3.1 Labels.

Apply headline capitalization to the labels of jump menus, whether they appear within the menu or to the left of the menu (see 2.5 Text Capitalization).

7.2.3.2 Jump Menu Behavior

Behavior specific to jump menus is described in this section. However, for general drop-down menu behavior, applicable to both jump menus and standard menus, refer to 7.2.1.3.1 General Drop-Down Menu Behavior.

To reduce the number of user steps and to reduce clutter, jump menus do not use a Go (submit) button to initiate actions. Instead, these menus exhibit behavior in which the action associated with the menu item is performed as soon as the user selects a menu item.

In Netscape 7, users can keyboard navigate within jump menus using the arrow keys. In Internet Explorer, users can keyboard navigate by using the Alt key + down arrow to view the menu contents and the arrow keys to navigate through the menu content. In both cases, pressing the Enter key activates the selected menu item.

Require confirmation from the user through means of an alert message (see Chapter 14 Alerts and Messages) before a destructive or long action is actually performed.

Confirmation is especially important when a Go button is unavailable because users can inadvertently select an unintended item.

For jump menus allowing users to perform actions (as opposed to navigation), design the drop-down menu such that after a menu item is selected, the menu snaps back to the first item in the menu (that is, the label) before the action is performed.

This way, if the user clicks the Back button on the browser, the page loads with the menu label selected in the menu.

An exception to this snap-back behavior is when a separator is selected from a jump menu used to perform actions. In that case, the separator should remain selected and the page should remain unchanged. Note that because Netscape 7 supports having disabled menu items in which items such as separators are not actually selectable, this situation would never occur. However, older browsers may not support disabled menu items. So, users could inadvertently select this invalid item.

For jump menus used to allow users to navigate, the menu remains on the value the user last selected, and does not snap back. This way, users can see the location to which they have chosen to navigate.

It would be rare to have a separator in a navigation jump menu, but if a separator is selected in a navigation jump menu, display the separator, and leave the page unchanged. Users are more likely to realize that they have inadvertently selected an invalid item if the page does not change, and the separator is displayed as the selected item. Note that this is applicable only on older browsers that don't support disabled, and therefore unselectable, menu items.

The following diagram shows jump menu behavior for a menu used for performing actions:

7.2.3.3 Grouping Menu Items

To help users quickly locate and understand items contained in drop-down menus, consider grouping logically-related items. This is typically used in jump menus. The two methods for accomplishing this goal are standard grouping and optgroup grouping.

In standard grouping, use separator lines to group items. Indicate each separator line by a disabled and unselectable menu item containing a series of em-dashes ("—" or "&#8212;" as in "—————"). This method is similar to the menu grouping method commonly used for pull-down menus in nonbrowser-based applications. The series of em-dashes should be as long as the longest item in the menu. Note that some older browsers may not support disabling menu items. In this case, follow the guidelines in 7.2.3.2 Jump Menu Behavior for guidelines about what to do if a user selects a separator line.

In contrast, optgroup grouping relies on an HTML tag called optgroup, which gives grouped items an unselectable label. This label appears above the grouped items, and all of the items contained in the group appear indented below. Note that the optgroup tag is not supported on older browsers such as Internet Explorer 5.5. These browsers degrade gracefully by simply not showing the optgroup label and not indenting any of the menu items.

Place separators before optgroups so that older browsers, which do not show the optgroup labels, still appear to group items using the standard grouping. The exception: when the optgroup appears at the beginning of the menu, omit the separator.

Group items that are logically related. Do not group items based solely on frequency of use.

If the relationships among items in the menu groups are relatively clear, then use standard grouping. If the relationships among items are not clear, then consider using optgroup grouping.

For example, say a menu contains a list of storage devices and the items in the menu are the names of the devices. In this case, grouping the storage devices by model might be useful. It's unlikely that the names of the devices themselves convey the device model. Therefore, it is unlikely that, if standard grouping were used, users would realize how the items are grouped. However, optgroup grouping could be used to clarify the grouping scheme so that users can more easily understand the contents of the menu and more easily locate items.

On the other hand, if a menu contained a list of actions to be performed on storage devices and the actions were grouped into administrative actions and configuration actions, optgroup labels would be superfluous, merely adding visual clutter to the menu.

When using the optgroup method, use a concise, descriptive noun for the grouping label. Also, create parallel, consistent labels.

When using the optgroup method, avoid creating single-item optgroups.

Likewise, a menu should not contain only a single optgroup. In this case, the label for the group should be reflected in the menu's label.

Strive to use the standard and optgroup grouping methods consistently within your application. Do not arbitrarily use both types across menus.

7.3 Text Elements

Text elements allow users to view and edit text in applications. The several types of text elements include:

• Labels
• Editable text fields (which may be disabled or displayed as noneditable/read-only)
• Password fields (a special version of the editable text field)
• Text areas

The following example shows a page with an example of each type of text element:

7.3.1 Labels

Use text labels to identify controls and data values. Labels should be left-aligned and appear to be associated with the item being labeled.

 Use headline capitalization on all labels (see 2.5 Text Capitalization).

If a field requires that units-of-measure be specified, place this information to the right of the field itself (not as part of the field's label). Do not place this information within parentheses. Use headline capitalization (see 2.5 Text Capitalization) for units-of-measure information.

For accessibility reasons, enclose the field and units-of-measure information in a span or div tag to tie them together.

Form elements are often organized hierarchically into groups and subgroups. The labels on the individual elements as well as on the groups are designed to visually support this hierarchy. In this scheme, groups have bolder, heavier labels whereas individual elements within the groups have lighter labels. In the following example, Level 1 labels have a heavier appearance than Level 2 labels, which, in turn have a heavier appearance than Level 3 labels.



Level 1 labels are visually much heavier than the text appearance for field labels as specified in these guidelines. Therefore, use them sparingly. In these guidelines, use of Level 1 labels is reserved for elements such as section headings.

Level 2 labels are the labels to use by default. They are used for most field labels. These labels appear left-aligned with each other and to the left of the element or elements they are labeling.

Use Level 3 labels for items appearing within a group that is labeled with a Level 2 label. These labels should be left-aligned with each other and generally, though not always, appear to the right of the element that they are labeling (for example, checkbox and radio button labels). If an item with a Level 3 label contains a group of items (as in the preceding example), then the items within the group should also have a Level 3 label.

When a mix of checkboxes, radio buttons and other form elements appear in a group, as shown in the following example, each item at the top level (that is, not items that are in subgroups) should have a Level 2 label to its left. In the Incorrect example on the right, the checkbox labeled "Automatically Mount Home Directory" is logically at the same level as the other items (Path, Server and Permissions). Therefore, the checkbox arguably could appear left-aligned with the labels for these items with the Level 2 label. However, this arrangement diminishes readability and makes it more difficult for the user to understand the relationships among the items.

The method for handling these mixed-element situations, shown in the Correct example on the left, is to give each item a Level 2 label on the left and to align the radio button or checkbox (and its right-hand label) with the other form elements in the group. It can be awkward to have an item with two labels if the labels are essentially identical. So, one approach to writing the labels is to use a short descriptive noun as the Level 2 label on the left and a more descriptive phrase for the Level 3 label on the right.

When displaying a set of checkboxes in its noneditable (read-only) appearance (see 7.2.2.1 Set of Checkboxes), use a level 2 label for the label of the set, as is done when labeling a set of enabled or disabled form elements. Use label level 2 to identify each individual checkbox in its noneditable (read-only) appearance as well, but indent these labels by 10 pixels with respect to the label for the entire set.

For example, in the following image showing different appearances for a set of checkboxes, the noneditable (read-only) appearance for the set of checkboxes shows the label for the whole set, "Options:" using label level 2. The labels "Connect on Carrier:" and "Bidirectional:" also use label level 2, but are indented 10 pixels to the right.

Labels for individual elements should use the HTML <label> tag to associate the labels with form elements. Aside from being an accessibility requirement, use of this tag also enables users to click on the label text in order to activate or put focus on the form element. Without the HTML <label> tag, users have to click on the element itself. See Appendix D, Accessibility Requirements for more information on the HTML <label> tag.

Labels for groups of elements should use the HTML <fieldset> and HTML <legend> tags to identify the elements as a group to assistive technologies. See Appendix D, Accessibility Requirements for more information on use of the HTML <fieldset> tag. Note that, by default, the HTML <fieldset> tag places a rectangle around the group of items. This rectangle can and should be suppressed using CSS styles.

7.3.2 Editable Text Fields

Text fields display a single line of editable text.

Use fixed fonts for text field contents only in rare situations when it is necessary to render a text field where the length of the data can be no longer than what is allowed by the size of the field.

For example, this might be necessary if the user needs to see the exact length of the value relative to other text field values on the page (where all the text fields would be lined up). Another situation might be when users must see all of the characters in the text field even if they type a lot of wide characters such as capital Ws. These situations tend to be rare, however.

Appropriately size the visible width of a text field to accommodate the length of the intended text strings. This is particularly important for fields intended to hold potentially lengthy data such as file paths.

If the text field can accept long entries (for example, 60 characters or more), but making the text field's visible width accommodate the whole entry creates page layout and alignment concerns, consider using a text area (see 7.3.4 Text Areas) with a height large enough to accommodate a horizontal scrollbar. The width can be sized for visual design aesthetics within the page, but should generally be made as large as possible.

Avoid setting the text field to a shorter visible width and letting the leftmost characters then scroll out of the text box, as needed, when new characters are typed. When doing so there is no indication that any text is out of view, and when manually scrolling, there are no scrollbars to provide information about how much data there is and which part of it is currently in view.

To denote required fields, place the graphic named Required Field, , to the right of the field's label and set its tool tip to "Required Field". Then, include the legend: " Indicates required field" at the top right of the content area, as shown in the previous example at the beginning of 7.3 Text Elements. Do this for all required fields, even if all fields on the page are required.

If an extremely large number of possible values exist for a given field (for example, thousands of possible values), the best option might simply be to provide an editable text field for users to type in a value. Other user interface elements (for example, drop-down menus, scrolling lists, sets of checkboxes or radio buttons, add-and-remove idioms) are not designed to handle extremely large numbers of possible values.

However, if appropriate, the text field can be linked to a pop-up window of values where users can search for a value that they do not remember (not shown in preceding picture). The details of this pop-up search window entry field have not yet been determined.

7.3.3 Password Fields

Password fields are editable text fields that display an asterisk ("*") in place of every character typed by the user. The password field serves to mask what the user types.

7.3.4 Text Areas

A text area is a rectangular space where users can type multiple lines of text.

Display the text in the text area in a single font size and font type. Read only text areas appear just as editable text areas do. The text is just not editable.

Wrap the text, when advisable to do so. For example, wrap text when descriptive information is held in a text area. This activates the text area's vertical scrollbar if the text exceeds the height of the text area.

When text wrapping is not advisable, such as when the user types code or a path name that must appear on one line, turn off wrapping.