Chapter 3. User Interface Fundamentals

Summary of Requirements for UI Fundamentals

Note It is not required that a server application have any graphical UI. However, any graphical UI that is presented must meet these requirements. Regardless of whether graphical UI is presented, all applications must adhere to Requirement 3.5.

Rationale

• Consistency and accessibility among Windows-based applications increases customer confidence in Windows applications and the Windows platform.

• Meeting UI requirements enables the use of sophisticated automation tools, including testing tools, task automation tools such as intelligent agents, and new input methods such as voice input.

• Organizations that use the Windows platforms require software to be usable by a wide range of users in order to comply with employment and equal rights legislation.

• Meeting these requirements helps you ensure that software will be compatible with future enhancements that are planned for the Windows platform, including speech input, speech output, and intelligent task automation.

Customer benefits

• Providing a consistent user interface reduces training, support, and testing costs for customers.

• Meeting UI requirements enables your business customers located in the United States to comply with the Americans with Disabilities Act, which requires that they provide reasonable accommodation for employees with disabilities.

• Meeting UI requirements enables your customers to purchase software that meets standards for usability, such as HFES/ANSI 200 and ISO 9241. Such standards will continue to expand to incorporate high-level requirements for usability and accessibility.

• Meeting UI requirements enables over 49 million people in the United States who have disabilities to use your products. The U.S. Access Board estimates that one in five people, and one in eight Internet users, have some form of functional limitation.

• Meeting UI requirements enables organizations to benefit by keeping valuable employees, even when they receive a permanent or temporary disability, such as repetitive strain injury associated with typing or using a mouse, or experience functional limitations that are a natural part of aging.

Requirements

1. Support standard system size, color, font, and input settings

2. Ensure compatibility with the High-Contrast option

3. Provide documented keyboard access to all features

4. Expose the location of the keyboard focus

5. Do not place shortcuts to documents, help or uninstall in the Start menu

References

Guidelines for accessibile software design
www.microsoft.com/enable/

Microsoft Active Accessibility®,
See the Platform SDK.

Microsoft media player information
www.microsoft.com/windows/mediaplayer/en/

Microsoft Windows Guidelines for User Interface Design,
Available from MSDN and MS Press.

How to Comply with Requirements for UI Fundamentals

1. Support Standard System Size, Color, Font, and Input Settings

Your application must read and use system-wide user interface settings when displaying customized controls or window content. Standard controls provided by USER32.DLL and COMCTL32.DLL automatically support all of the required settings. Applications can add support for these settings to their own windows by calling DefWindowProc in the window procedure. Applications should be careful to handle these settings when:

• Creating custom controls

• Creating owner-drawn controls

• Superclassing or subclassing to alter the normal standard control behavior

• Handling a message and not calling DefWindowProc (especially when drawing any non-client areas)

• Handling low-level input that bypasses normal mouse and keyboard messages (such as double-click and shift-state detection)

These settings are queried using the GetSysColor, GetSystemMetrics, and SystemParametersInfo functions.

 All applications must support:

Customized fields for text selection or editing must support:

Customized combo boxes must support:

Customized keyboard handlers (low-level input) must support:

Customized menus must support:

Specialized mouse functions must support:

Customized scroll bars must support:

Application sounds must support:

Customized tooltips and status bars must support:

Customized window frames must support:

2. Ensure Compatibility with the High-Contrast Option

Your application must be compatible with the High-Contrast option, which indicates that the user requires a high degree of contrast to improve screen legibility. Standard controls provided by USER32.DLL and COMCTL32.DLL automatically support all of the required settings. Applications only need to support it explicitly when creating custom window classes or controls, or altering the normal behavior of standard windows or controls.

Applications can determine the value of the High-Contrast option using the SystemParametersInfo function with the SPI_GETHIGHCONTRAST constant. When this option is set, your application must:

• Display all menus and dialog boxes using the color scheme returned by GetSysColor function. This also applies to other UI elements that are required to adjust colors in the application's UI.

• Allow the user to adjust the colors used to display everything in the application's windows.

  • This must be possible using display options that override the colors normally used by the application or specified in the document, and must not alter the content of the document or affect other users.

  • The preferred method is to use the corresponding colors returned by the GetSysColor function, but the application can provide its own display options.

  • Always draw foreground objects in colors designated as foreground colors, and fill backgrounds with the corresponding background colors. This is required whether colors are selected using the GetSysColor function or through the application's own options. For example, anything drawn using window text color (COLOR_WINDOWTEXT) must be drawn on the window background color (COLOR_WINDOW), and anything drawn using highlight text color (COLOR_HIGHLIGHTTEXT) must be drawn on highlight background (COLOR_HIGHLIGHT).

• Make sure information normally conveyed by color is available through other means, such as sound or a visual display, because the user may have chosen a monochrome appearance scheme.

• Omit images or patterns drawn behind text, and ensure that important information conveyed with such backgrounds is available through other means.

Note Users can adjust the High-Contrast option from the Accessibility Options section of Control Panel, by selecting the Display tab and then the Use High-Contrast check box.

Users can adjust the values returned by GetSysColor using the Display section of Control Panel, by selecting the Appearance tab.

The High-Contrast option can be used with any appearance scheme, and selecting a scheme through the Display section of Control Panel does not affect the High-Contrast option setting.

Exceptions Certain application features may be exempted from High-Contrast requirements when the use of color is intrinsic and indispensable to the goal of the feature. Examples include:

• Palettes or swatches where the user selects from a range of displayed colors. In this case, the application can display the color but must provide a text description such as a name (light blue) or numeric value (RGB 0, 255, 255).

• Animation, video, and graphic images when the information content is available through other means.

  When the major features in the application support the High-Contrast option, exceptions may also be made for minor features that are not required for the operation of the program.

  Requests for exemptions are judged on a case-by-case basis. You must detail these exceptions in your Vendor Questionnaire.

3. Provide Documented Keyboard Access to All Features

Your application must provide keyboard access to all features, so that a mouse or other pointing device is not required for its use. Standard controls provided by USER32.DLL and COMCTL32.DLL automatically support all the required settings. Applications must explicitly provide this support only when:

• Creating custom window classes or controls

• Altering the normal behavior of standard windows or controls

• Assigning keyboard navigation in dialog boxes.

User interface elements that rely on standard Windows keyboard documentation should support equivalent standard window class keyboard behavior. If a specific user interface element, such as a custom control, requires a mouse or other pointing device, its functionality must also be available through keyboard input.

All keyboard techniques required to operate the application must be documented, except for elements that follow Windows conventions, e.g., standard menus and controls. Applications must document non-intuitive complex procedures, customized window class usage, and controls that do not conform to normal conventions. The product's standard documentation must either include this information or direct the user to the appropriate documents.

Example: Information can be delivered by online help, with text file on the product CD, or through the product's Web site.

Note Keyboard behavior of standard window classes is documented in The Microsoft Windows Keyboard Guide, which is available at www.microsoft.com/enable/.

Exceptions Exemptions may be made in the following cases:

• Applications that rely on specialized input devices, such as graphing tablets.

• Situations where the mouse targets are no larger than a pixel. For example, painting with the mouse. These features may rely on the MouseKeys feature built into the 32-bit Microsoft Windows operating systems to allow users to move the mouse pointer using the keyboard. However, this is not acceptable for drawing when the user can independently manipulate separate text and graphic objects. This exemption applies to individual features within a product, not to the entire application.

  When the major features in the application have keyboard access, exceptions may be made for minor features that are not required for operation of the program.

  Requests for exemptions are judged on a case-by-case basis. You must detail these exceptions in your Vendor Questionnaire.

4. Expose the Location of the Keyboard Focus

Your application must visually indicate the location of the keyboard focus, and notify other software of this location by using Microsoft Active Accessibility or by moving the system caret.

The application must display a visual focus indicator at all times when it is the active window, so users can anticipate the effects of keystrokes they type. Exposing its location to other software enables the use of the panning software supported by many display adapters and accessibility aids such as the Magnifier accessory included with Windows 2000.

When it is not feasible to use Microsoft Active Accessibility, the application may indicate the focus location by moving the system caret. The caret is normally the blinking vertical bar that the user sees when editing text, but it can be placed anywhere on the screen, made any shape or size, and even made invisible. If it is invisible, it can be moved to indicate the focus location to applications without disturbing what the user sees on the screen.

To create an invisible caret, call the CreateCaret function to set the caret's size and shape and the SetCaretPos function to move it to wherever you are drawing the visual focus indicator (the highlighted cell, icon, button, and so on). Note that it is present but remains invisible unless you explicitly make it visible.

Each time the focus moves to a new object with a different size, the application should call DestroyCaret and then use CreateCaret to specify the size of the new object. The system caret must cover the bounding rectangle of the screen element, so that screen magnification tools can allow the user to zoom-in on different portions of the region.

An application should only display focus and selection indicators when they are in the active window. When the window loses activation, the application should remove the visual indicator and call the DestroyCaret function.

Exception Applications and features that are exempt from the keyboard access requirement as described earlier in this section are also exempt from the requirement to expose keyboard focus location. However, it is strongly recommended that applications expose the keyboard focus location for any feature that provides keyboard access.

5. Do Not Place Shortcuts to Documents, Help, or Uninstall in the Start Menu

The Start menu is designed to give users easy access to launch applications. Usability studies show that when the Start menu becomes too cluttered, users can no longer do this.

• Do not place shortcuts to documents, such as readme files, in the Start menu. If you have important information that the user should see, consider displaying that information during the install process.

• Do not put shortcuts to help files in the Start menu. Users can access help once they launch the application.

• Do not place shortcuts to uninstall in the Start menu. The Add/Remove Program control panel applet provides this functionality.

The following behaviors, though not required, are recommended:

• Place your icon to launch your application directly under Start -> Programs. Avoid placing it in a folder under programs. In particular, do not create a folder in the Start menu in which you only put one item. Often, applications will create a folder, based on Company name, and then put a single shortcut to launch the application inside that folder. Instead, consider renaming the shortcut to include the company name and dropping the use of the folder.

  Programs    My Company    My App    (Avoid this)

  Programs    My Company My App          (Recommended)

• Do not put anything in the top of the Start menu, as users consider this their own personal space.

• If you have support applications, tools, or utilities associated with your application, and you wish to publish these in the Start menu, create a single folder in the Start menu as a peer of the icon to launch your application and place them there.

How to Pretest Applications for UI Fundamentals

To Pretest System Metrics Support

1. Open Control Panel, and then open the Display applet.

2. Choose the Appearance tab.

3. Select a scheme with the "(extra large)" designation, such as Windows Standard (extra large) scheme. Click on Apply.

4. Test the application's main screens, dialog boxes, and controls to ensure that these changes have been instated and the application is still usable.

   Screen elements should be displayed correctly and compatible with the appearance scheme, i.e., menu items, title bars, icons and icon titles, window borders and scroll bars are displayed with appropriate sizes and fonts. Text and controls should never overlap and text should not be truncated inappropriately. Examples of appropriate truncation are:

   • Text strings too large to be displayed in a column in a list view control. The beginning of the text is displayed, followed by "…" to indicate the truncation.

   • Text that runs beyond the frame of a window, but can be viewed using the horizontal or vertical scroll bar.

To Pretest High-Contrast Support

1. Open Control Panel, and then open the Accessibility Options.

2. Choose the Display tab.

3. Select the Use High-Contrast option.

4. Choose Settings.

5. Choose Custom, and verify that High-Contrast Black is selected. Apply these settings.

6. Go back into your product and test the major screens, dialog boxes, and controls to ensure that these changes have been properly reflected.

7. Repeat, selecting the High-Contrast White option in Step 5.

   The application should still be usable. Screen elements should be displayed correctly and be compatible with the appearance scheme. For example, make sure that text contrasts with its background, that graphics on toolbar buttons are distinguishable, that lines are still visible, and that no images or complex backgrounds appear behind text.

   If nothing within the window is displayed using the selected color scheme, verify that the user can adjust the display colors without having to alter the document.

To Pretest Documented Keyboard Access

1. Open Control Panel, and then open the Accessibility Options.

2. Choose the Keyboard tab.

3. Select the Show Extra Keyboard Help. Apply these settings.

4. Exercise the major functions within your application without using a mouse.

5. Verify that a mouse is not required for any activity.

   For example, if a command on a toolbar can only be used with a mouse, make sure that the equivalent command is also available through a menu or through a documented keyboard shortcut.

   The product documentation and user interface must make clear how to carry out a task using the keyboard or it must be readily inferred using knowledge of standard Windows keyboard conventions. If the documentation is not clear, the product fails the requirement to use adequately documented keyboard UI.

6. Verify that all menu items and controls have underlined access keys.

To Pretest Exposure of Keyboard Focus

1. Use the Magnifier accessory that is included with Windows 2000. From the Start menu, choose Programs -> Accessories -> Accessibility -> Magnifier.

2. Navigate through your application using the keyboard, making sure that Magnifier accurately tracks and displays the area with the keyboard focus. In particular, verify that Magnifier:

   • Shows the correct focus location when you navigate or type within a document, text field, or table.

   • Shows the correct focus location when you navigate in menus, dialog boxes, toolbars, list boxes, or other controls.

   • Shows the correct focus location when you extend a selection in text or in a multiple-selection list box, list view, or tree view.

   • Shows the correct focus location when you return to your application from a dialog box, menu, or another application.