Chapter 5: User Interface Fundamentals
- 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 who are 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
5.1 Support standard system size, color, font, and input settings
5.2 Ensure compatibility with the High Contrast option
5.3 Provide documented keyboard access to all features
5.4 Provide notification of the keyboard focus location
5.5 Do not rely exclusively on sound
5.6 Do not place shortcuts to documents, help, or uninstall in the Start Menu
5.7 Support multiple monitors
References
- Guidelines for accessibile software design, see: https://www.microsoft.com/enable
- "Microsoft Active Accessibility" see the Platform SDK
- Microsoft media player, see: https://www.microsoft.com/windows/mediaplayer
- "Microsoft Windows Guidelines for User Interface Design" is available from MSDN and MS Press
How to Comply with Requirements for UI Fundamentals
5.1 Support standard system size, color, font, & 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:
| SPI_GETHIGHCONTRAST | All GetSysColor settings are required for menus, dialog boxes, and other standard UI elements; see Requirement 5.2 |
| SPI_GETWORKAREA | Primary display monitor work area size |
Customized combo boxes must support:
| SPI_GETCOMBOBOXANIMATION | Slide-open effect for combo boxes must be disabled when this setting is false |
Customized keyboard handlers (low level input) must support:
| SPI_GETKEYBOARDDELAY
SPI_GETKEYBOARDSPEED |
Keyboard repeat-delay setting
Keyboard repeat-speed setting |
| SPI_GETFILTERKEYS | Expanded range for above |
Customized menus must support:
| SM_CYMENUCHECK, CXMENUCHECK | Default menu check-mark dimensions |
| SM_CYMENU | Single-line menu bar height |
| SPI_GETNONCLIENTMETRICS
IfMenuHeight lfMenuFont lfMessageFont |
Menu bar height Menu bar font Message box font |
| SPI_GETSELECTIONFADE | Menu fade must be disabled when this setting is FALSE |
| SPI_GETMENUANIMATION | Menu animation must be disabled when this setting is FALSE |
| SPI_GETMENUFADE | Menu fade animation must be disabled when this setting is FALSE |
Specialized mouse functions must support:
| SM_CYDOUBLECLK,
SM_CXDOUBLECLK |
Maximum vertical and horizontal distances the mouse can move between successive clicks and still be interpreted as a double-click |
| SM_CYDRAG, SM_CXDRAG | Minimum vertical and horizontal distances the mouse must be moved with button down to start a drag operation |
| SPI_GETMOUSEHOVERHEIGHT
SPI_GETMOUSEHOVERWIDTH |
Height and width of the rectangle within which the mouse pointer has to stay to activate hover effects |
| SPI_GETMOUSEHOVERTIME | Mouse hover time |
Customized scroll bars must support:
| SM_CYHSCROLL
SM_CXVSCROLL |
Height of horizontal scroll bar
Width of a vertical scroll bar |
Application sounds must support:
| SPI_GETSHOWSOUNDS | When TRUE, the application must present all information visually rather than by sound alone |
Customized tooltips must support:
| SPI_GETNONCLIENTMETRICS
SPI_lfStatusFont |
Font used in status bars and tooltips |
| SPI_GETTOOLTIPANIMATION | ToolTip animation must be disabled when this setting is FALSE |
Customized window frames must support:
| SM_CYSMCAPTION | Small caption height |
| SPI_GETNONCLIENTMETRICS
IfCaptionFont |
Caption font information |
| SM_CYBORDER, SM_CXBORDER | Minimum thickness of a line, in pixels. Applications should not draw lines thinner than this because on high-resolution monitors a 1-pixel line might be nearly invisible (the display driver sets this number, and it is also increased when the user selects the Custom System Font Size in Control Panel.) |
| SM_CXEDGE
SM_CYEDGE |
Thickness of a 3D edge, in pixels
Each 3D edge is comprised of two adjacent lines, so the thickness is 2 * SM_CxBORDER |
| SM_CXSIZEFRAME
SM_CYSIZEFRAME |
Thickness of the complete resizable window frame, in pixels |
| SM_CYFIXEDFRAME
SM_CXFIXEDFRAME |
Thickness of a non-resizable window frame, in pixels
This is made up of one 3D edge whose thickness is SM_CxEDGE plus one line of space whose thickness is SM_CxBORDER |
5.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 any 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 any 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 any images or patterns drawn behind text, and make sure any 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 GetSysColors 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: 1) 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); 2) animation, video, and graphic images when the information content is available through other means; 3) entire applications are exempted only when it can be shown that the application has no value without the use of color. For example, painting programs may be exempted, but drawing programs where the user manipulates shapes would not be exempted; and 4) reference and educational titles will not be exempted.
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.
5.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 of 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 all 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. For 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" ** available at: https://www.microsoft.com/enable.
Exemptions
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 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.
5.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 98 and 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.5 Do not rely exclusively on sound
Applications should not convey important information exclusively by sound. If sound is the default method for conveying information, the application must provide other options to express this information.
Closed captioning or synchronized highlighting is recommended when conveying information by audio and video content longer than several seconds
Closed captioning is supported by the Windows Media Player since version 5.2. See: https://www.microsoft.com/enable and https://www.microsoft.com/windows/mediaplayer.The application must provide visual equivalents of all information normally provided by sounds alone when the ShowSounds option is selected. If the ShowSounds option is selected when the application starts, the application must either turn on these additional visuals or explicitly ask the user whether they would like them.
The user may select the ShowSounds option in the Control Panel to notify applications that all information should be conveyed visually rather than relying on audible means. This option is set through the Accessibility Options section of the Control Panel. Applications can determine the current value of the ShowSounds option with the SystemParametersInfo function to query SPI_GETSHOWSOUNDS.
Applications are not required to display visual equivalents of music or other sounds that convey no information. However, they are required to display a visual indication that such sounds are playing when the ShowSounds flag is set. When a sound merely emphasizes a visible event, the application does not need to provide an additional visual indication that the sound is present. For example, when a message box appears, it is often accompanied by a warning sound. When a user presses an invalid direction key, the selection fails to move and a warning beep is produced. In these cases the application does not need to display additional visual feedback. However, when user input or an external event can trigger results indicated or distinguished exclusively by sound, additional visual notification is required.
5.6 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
5.7 Support multiple monitors
In a multiple monitor system, the top left pixel on the primary monitor always has coordinates 0,0. Valid screen coordinates can exist anywhere in relation to this location. In particular:
- Pixels in multiple monitor systems can have negative values for one or both coordinates, since users can place secondary monitors to the left and above the primary monitor
- Users may also place several monitors in a horizontal or vertical row; at high screen resolutions, coordinates for the monitor furthest from the primary may be much larger than would be possible on any single monitor system
Your application must support users who have two or more monitors installed. This support is automatically provided by the operating system, unless your application specifies screen coordinates in any of the windows it creates. If your application does specify screen coordinates for any window, then:
- It must handle negative coordinates, as well as large coordinates that are outside the traditional display space
- Dialogs must not open in a location that splits them across two monitors. Applications that specify dialog locations as the center of the desktop should use the center of a physical monitor instead
- If you cache the locations of your application’s windows so they appear at their previous screen locations when the user starts your application, you must accommodate any changes in the user’s monitor arrangement and change the display locations of your windows accordingly (when your application opens windows, it must verify that the locations where it intends to restore its windows correspond to locations on the current multiple monitor configuration)
- Each monitor can have a different resolution and color depth; if your application allows images to span monitors, and your application cannot successfully combine the images from several monitors of different resolutions/color depths, it must degrade gracefully and give the user meaningful options, such as resizing the monitors, limiting the image to a single monitor, or accepting a lower definition image
- Some applications must be especially aware of multiple monitor issues, including the following:
- Applications that capture all or part of the desktop as a graphic
- Applications that float toolbars
- Applications that switch among multiple simulated desktops
- Screen savers
How to Pretest Applications for UI Fundamentals
To Pretest System Metrics Support
Open Control Panel, and then open the Display applet.
Choose the Appearance tab.
Select a scheme with the "(extra large)" designation, such as Windows Standard (sxtra large) scheme. Clink on Apply.
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
Open Control Panel, and then open the Accessibility Options.
Choose the Display tab.
Select the Use High Contrast option.
Choose Settings.
Choose Custom and verify that High Contrast Black is selected. Apply these settings.
Go back into your product and test the major screens, dialog boxes, and controls to ensure that these changes have been properly reflected.
Repeat, selecting the High Contrast White option in step 5 above.
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 anything within the window is not 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
- Open Control Panel, and then open the Accessibility Options.
- Choose the Keyboard tab.
- Select the Show Extra Keyboard Help. Apply these settings.
- Exercise the major functions within your application without using a mouse.
- 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.
- Verify that all menu items and controls have underlined access keys.
To Pretest Exposure of Keyboard Focus
Use the Magnifier accessory. From the Start menu, choose Programs -> Accessories -> Accessibility -> Magnifier.
Magnifier is included with Windows 98 and Windows 2000. For Windows 95, install the Microsoft Active Accessibility SDK to get Magnifier. Magnifier is not available for Windows NT 4.
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
To Pretest Use of Sounds
- Open Control Panel, and then open the Accessibility Options.
- Choose the Sounds tab.
- Select the ShowSounds option. Apply these settings.
- Go back into your product and test the major functions. Notice any sounds that are played that do not have equivalent visual feedback. In particular, look for animations and audio or visual clips.
- If any information is conveyed using sound and the same information is not available through textual means, the application does not meet requirements for supporting the ShowSounds option.
To Pretest Your Application for Multiple Monitor Support
- Move each of your application’s windows to every monitor, including monitors located to the left and above the primary monitor; the windows should move to any monitor without error dialogs, hangs or crashes
- Resize each resizable window across all monitors
- Maximize all windows that can be maximized on each monitor. Windows should maximize to the current monitor, not across monitors to the entire desktop
- For windows that can be minimixed:
- Resize and move each window so it spans all monitors. Minimize each window, then restore it; the window should restore to its original position, spanning several monitors
- Maximize each restored window; each window should maximize to one physical monitor, not to multiple monitors or the virtual desktop
- Test selecting and dragging elements on windows that span several physical monitors
- Test floating toolbars that can move off your application's parent window by maximizing the parent on one monitor and moving the toolbars to a separate monitor
- If your application supports dragging graphics objects, set multiple monitors for different screen resolutions and color depths; then drag the graphics from one monitor to another; the graphics' appearance should adapt to each monitor when dropped
- If your application acts directly on the desktop
- Test all functions with monitors to the left and above the primary monitor
- Set all monitors for the highest possible resolutions and greatest color depths to test your application’s ability to accommodate very large pixel coordinates
- Set each monitor at a different color depth and screen resolution, then exercise your application; your application must successfully accommodate the differences or provide a meaningful message to the user with suggestions on how to change the configuration so the program will work as intended