UI/Shell

Required:
The application must be compatible with the following system color, size, font, sound, and input settings. This provides the user with a consistent user interface and allows them to customize the system to meet their needs and preferences. These settings are queried using the GetSystemMetrics, SystemParametersInfo, or GetSysColors functions. Color settings are required only when the High Contrast option is on. For more information refer to the accessibility guidelines for application developers on http://microsoft.com/enable/.

Tip: Standard window classes and controls automatically support all of these settings. Applications only need to be aware of these when creating custom window classes or controls.

Required:
Applications must be compatible with the High Contrast option, which indicates that the user wants a high degree of legibility. When this option is set the application must use only system colors selected through Control Panel or other colors that the user can customize. Because documents are typically shared, a user must not be required to alter a document in order to adjust the colors drawn on the screen. System colors must be used in their proper foreground/background combinations. For more information refer to the accessibility guidelines for application developers on http://microsoft.com/enable/.

Tip: To get the space left over after the tray takes up the screen, use either GetSystemMetrics to query SM_CXFULLSCREEN and SM_CYFULLSCREEN or use SystemParamtersInfo to query SPI_GETWORKAREA.

Exception:
Palettes where the user selects a color may continue to display their full range of fixed colors. Games and certain multimedia applications may have aesthetic and design considerations, such as custom dialog boxes and user interface elements, where system settings are inappropriate. Games, certain multimedia applications, and inherently graphical applications such as image editing tools may also be excepted from color requirements. These will be judged on a case-by-case basis. You must detail these exceptions in your Vendor Questionnaire.

Recommended:
In addition to the required system settings listed above, applications should be compatible with the following recommended system settings.

Required:
The application must provide keyboard access to all features. For more information refer to the accessibility guidelines for application developers on http://microsoft.com/enable/.

Exception:
Exceptions may be made in the following cases:

• Games that are dependent upon the use of a mouse or joystick. It is recommended, but not required, that games provide keyboard support where feasible. They should not require a pointing device except where it is unavoidable due to the nature of the game.
  
  
• CAD and similar applications that are dependent upon graphing tablets and other input devices.
  
  
• Applications that are entirely graphical, such as image editors, may rely on the MouseKeys feature built into the 32-bit Windows operating systems to allow users to move the mouse pointer. However, this is not acceptable for drawing applications that allow the user to independently manipulate separate text and graphic objects.

Exceptions may be made for minor features that are not required for operation of the program, when the major features in the application have keyboard access. All major features or functional areas without keyboard access should be explained in the Vendor Questionnaire.

Required:
The keyboard user interface must be documented.

Exception:
It is not necessary to document elements that simply follow the Windows conventions for elements such as standard menus and controls.

Tip: This information may be provided in your standard documentation that is included with the product, or it may be orderable separately. In the latter case, it is strongly recommended that the standard documentation inform the user that this additional documentation is available.

Required:
The application must notify other software of the locations of the keyboard focus, either by moving the system caret or using Active Accessibility. This requirement enables the use of accessibility aids such as the screen magnification accessory included with the Active Accessibility SDK. Note that this accessory will be included in future versions of the Windows operating systems. Be sure to check the Pretesting & Verification section to help test your product. For more information refer to the accessibility guidelines for application developers on http://microsoft.com/enable/.

Recommended:
In addition to the above requirements, the following behaviors are recommended for the User Interface. For more information refer to the accessibility guidelines for application developers on http://microsoft.com/enable/.

• The application should allow other software to identify and manipulate all screen elements that the user interacts with. This should be accomplished by supporting Microsoft Active Accessibility. Standard window classes and controls automatically support this mechanism. Applications only need to add additional support when creating custom window classes or controls, or drawing content in their window client area. NOTE: this recommendation will become a requirement in the future and may require significant work to accomplish. It is strongly recommended that vendors begin planning for this as soon as possible. For more information refer to the accessibility guidelines for application developers on http://microsoft.com/enable/.
  
  
• The application should not convey any important information by sound alone. If sound alone is the default method for conveying the information, the application should provide an option to convey this information by other means. For more information refer to the accessibility guidelines for application developers on http://microsoft.com/enable/.
  
  
• The application should not convey important information by color alone. If color alone is the default method for conveying the information, the application should provide an option to convey this information by other means.
  
  
• We strongly recommend that the product avoid hard coding any font sizes smaller than 10 points. Small fonts can cause eyestrain and are difficult for many people to read.
  
  
• Allow the user to customize all user interface timings that are not based on standard system settings. For more information refer to the accessibility guidelines for application developers on http://microsoft.com/enable/.
  
  
• The application should be compatible with changes to the system font size and changes to the number of pixels per logical inch. For more information refer to the accessibility guidelines for application developers on http://microsoft.com/enable/.
  
  
• Allow the user to choose font names and font sizes in order to make the document or window contents more legible.
  
  
• The application should not trigger unexpected side effects based on changes in pointer or keyboard focus locations. For more information refer to the accessibility guidelines for application developers on http://microsoft.com/enable/.