Text Labels

To a user with normal vision, textual output provides the majority of the information and feedback in most applications. To a visually-impaired user who may not be able to see or understand any additional graphical output, clear textual output is critical. You must therefore choose and position text carefully on the screen, and leave the choice of fonts and sizes to the user, to ensure that all users are able to use your application effectively.

8.3.1. Spacing and Alignment

Use spacing and alignment of text uniformly throughout your application. A basic rule of thumb is to put space between user interface components in increments of 6 pixels, going up as the relationship between related elements becomes more distant.

Table 8-2Alignment and spacing for different Text elements
Element Placement Example
Large Icons (file browser) Horizontally centered with and (6 pixels, if specification necessary)below large icon
Small icons (toolbar) Vertically centered with and (6 pixels, if specification necessary) to the right of small icons
List control label 6 pixels above and horizontally left aligned with list control or 12 pixels to the left of and horizontally top aligned with list control
Radio button and check box labels 6 pixels to the right of and vertically center aligned with radio button
Text field labels 6 pixels to the left of and vertically center aligned with textfield control
Button labels 12 pixels of padding to either side of centered text (and any accompanying graphic). If appearing in a group of buttons, longest button label sets button size, center all other button labels and accompanying graphics in same-sized buttons
Other component labels (e.g., spin boxes, text fields 12 pixels between the longest text label and its associated component, all other text labels in component grouping left aligned with the longest label. All labels vertically center aligned with associated components
  • If the label precedes the control it is labelling, end the label with a colon. For example, Email: to label a text field into which the user should type their email address. This helps identify it as a control's label rather than an independent item of text. Some assistive technology screen review utilities may also use the presence of a colon to identify text as a control label.
  • Ensure that a label with a mnemonic is associated with the control it labels.
  • Left-align components and labels, unless all the labels in a group have very different lengths. If they do, right-align the labels instead, to ensure that no controls end up too far away from their corresponding labels.
  • Choose label names carefully. Label objects with names that make sense when taken out of context. Users relying on screenreaders or similar assistive technologies will not always be able to immediately understand the relationship between a control and those surrounding it.
  • Be consistent with label usage and semantics. For example, if you use the same label in different windows, it will help if it means the same thing in both windows. Equally, don't use labels that are spelled differently but sound the same, e.g., "Read" and "Red", as this could be confusing for users relying on screenreaders.
  • Don't use the same label more than once in the same window. This makes life difficult for users relying on tools like magnifiers or screen readers, which cannot always convey surrounding context to the user.
  • Do not hard-code font styles and sizes. The user should be able to adjust all sizes and typefaces.
  • Do not use more than two or three different fonts and sizes in your application, and choose visually distinct rather than similar-looking fonts in one window. Too many font sizes and styles will make the interface look cluttered and unprofessional, and be harder to read. In general, always use fonts from the current theme, and specify relative rather than absolute sizes.
  • Do not use graphical backdrops or "watermarks" behind text, other than those specified by the user's chosen theme. These interfere with the contrast between the text and its background. This can cause difficulty for users with visual impairments, who will therefore normally choose themes that always use plain backdrops.

8.3.2. Capitalization

Two styles of capitalization are used in GNOME user interface elements:

Header capitalization

Capitalize all words in the element, with the following exceptions:

  • Articles: a, an, the.
  • Conjunctions: and, but, for, not, so, yet ...
  • Prepositions of three or fewer letters: at, for, by, in, to ...

Sentence capitalization

Capitalize the first letter of the first word, and any other words normally capitalized in sentences, such as application names.

The following table indicates the capitalization style to use for each type of user interface element.

Table 8-3Capitalization Style Guidelines for User Interface Elements
Element Style
Check box labels Sentence
Command button labels Header
Column heading labels Header
Desktop background object labels Header
Dialog messages Sentence
Drop-down combination box labels Sentence
Drop-down list box labels Sentence
Field labels Sentence
Filenames Sentence
Graphic equivalent text: for example, Alt text on web pages Sentence
Group box or frame labels Header
Items in drop-down combination boxes, drop-down list boxes, and list boxes Sentence
List box labels Sentence
Menu items Header
Menu items in applications Header
Menu titles in applications Header
Radio button labels Sentence
Slider labels Sentence
Spin box labels Sentence
Tabbed section titles Header
Text box labels Sentence
Titlebar labels Header
Toolbar button labels Header
Tooltips Sentence
Webpage titles and navigational elements Header
Capitalization guidelines for other languages

Languages other than English may have different rules about capitalization. For example, Swedish has no concept of Header capitalization. Contact the GNOME Translation Project if you are in doubt about how to capitalize labels in a particular language.