From the web page http://microsoft.com/msdn/news/devnews/mayjun98/earning.htm MSDN News: Earning the Logo | May 1, 1998 Earning the Logo by Greg Lowney The "Designed for Windows" Logo is a powerful tool that is helping improve computer software in many ways, all geared toward providing an easier-to-use environment for the customer. The logo represents a consensus by Microsoft and other companies about what makes a truly well designed application for the Microsoft Windows(R) platform. "Easier to use" is an important goal, and one that touches areas that many people seldom think about. For the past six years, Microsoft has been actively working on ways to make computers more usable by a wide range of people, particularly users who have a hard time using the mouse, or typing quickly, or reading the screen. In short, the 53 million people in the United States who have disabilities. And the tens of millions more throughout the rest of the world. And the tens of millions of additional users who are aging, or who have a temporary injury such as repetitive strain that may be aggravated by too much typing or using the mouse. The core belief is that software should avoid putting up barriers that make use by some customers needlessly difficult or impossible. That is, software should be made to accommodate the user, rather than the other way around. That principle is never more important to remember than when software design inadvertently shuts out an entire class of customers who are otherwise competent and productive computer users. Empowering the User The Microsoft Windows Guidelines for Accessible Software Design (available for download) contains a large amount of background information on what it means to make software usable by everyone. These guidelines are broken down into a number of specific areas and they're explained in some detail. In reality, though, they all boil down to a very simple rule: let users do things their way. Make your product flexible enough to accommodate a wide range of user preferences. Don't assume everyone likes to work the way you do. Don't put up artificial constraints that force everyone into the same box. In short, give power to the user. In practice, that means working towards a handful of common-sense goals: * Let the user choose to work with the keyboard or the mouse. * Let the user adjust fonts, sizes, colors, and other display options. * Let the user look at the screen instead of listening to the speakers. * Let the user work at his or her own pace. * Let the user take advantage of automation tools that help with his or her work. This concept of empowering the user is reinforced through the "Designed for Windows" Logo program. There are separate requirements for hardware and software, but the goal for both is to promote accessible design. In this article we'll take a closer look at how this is addressed in the logo requirements for software applications. Whether yours is one of the thousand-plus applications that currently earn the logo, whether you're considering applying for it in the future, or whether it's not yet on your radar screen, keep in mind that meeting these requirements is part of being a well behaved Windows-based application. Your customers will encounter these issues and it's up to you whether their experience is positive or negative. Five Guidelines and More to Come In addition to the requirements listed in the Designed for Microsoft Windows Logo Handbook for Software Applications, there are recommendations, which are scheduled to turn into requirements in future editions of the program. These criteria were selected based upon their impact on the customer, how easily they can be implemented in your application, and how easily they can be verified by you and by the testing laboratory that oversees the logo program. Remember, if it wasn't easy to do and important, it wouldn't be included. Today, the following five guidelines are requirements for earning the "Designed for Windows" logo: * The application must be compatible with specific system color, size, font, sound, and input settings. * Applications must be compatible with the High Contrast option. * The application must provide keyboard access to all features. * The keyboard user interface must be documented. * The application must notify other software of the locations of the keyboard focus. The rest of this article provides an introduction to each of these five requirements. Listening to the User The application must be compatible with specific system color, size, font, sound, and input settings. This requirement dates back to the very first version of the logo program. System metrics are values that the user can choose through Control Panel. It's important that applications pay attention to these values in order to provide the user with some degree of consistency in the interface. But more importantly, if users go out of their way to tell you they want a certain setting, ignoring their requests never makes you look good. The logo doesn't require you to support all of the settings, just a subset of them. Examples of important metrics include things like the size of menu items and title bars and the amount of time the user can take to double-click. The exact list is spelled out in the logo handbook, but chances are good that you're already compatible with all of these requirements. However, in some cases you may want to be intentionally different, perhaps in order to fit particular graphic design goals. With a little work, the logo can still accommodate you. The key is that you don't have to follow the rules all the time, you just have to support them when the user asks. Go ahead and make your default settings anything you like. All you have to do is provide the user with an option wherein your user interface can be made compatible with the standards. Make It Legible Applications must be compatible with the High Contrast option. Many, many users complain of the difficulty in reading particular screens, or simply have eyestrain or headaches at the end of the day. In some cases it's worse, preventing the customer from using a particular application entirely. In both cases, the application is probably making text hard to read--either it's too small or there's too little contrast between the text and the background. The latter can be addressed easily by letting users choose the colors they want. Luckily, the user can check the High Contrast option in the Accessibility section of Control Panel. This option allows the user to indicate that he or she wants the screen optimized for legibility. When this option is selected, an application should use the colors chosen through Control Panel or other colors that the user can customize. When the High Contrast mode is on, the application should ideally use the appropriate colors selected through Control Panel. Most things can be drawn using a combination of Window Text on Window Background colors, or Button Text on Button Background. When elements on the screen don't really correspond with anything chosen through Control Panel, the application can provide its own option to let the user adjust that color. For example, in Windows 95 there was no option in the Control Panel to adjust the colors for visited or unvisited links on Web pages, so Microsoft Internet Explorer provided the ability to change these colors through its own dialog boxes. This is a display option, not a change to the document. You can't actually force the user to change a document in order to adjust the colors, because that could adversely affect other users. Instead, the application should override normal display colors for the document and use the basic window and text colors the user has selected through the Control Panel. There are exceptions, of course. You can still draw samples of different colors to let the user choose one, and icons and other images don't need to be changed. You can also continue to draw color samples in the colors they represent rather than drawing them all in standardized colors. (However, it is recommended that you also draw the name of the color in a way that the text will be legible.) Similarly, most icons and other images can be drawn in their normal colors. But again, if you have monochrome versions of these images, you should use them when the High Contrast mode is on. Many applications let the user select independent colors for a number of different purposes. In most cases it's fine to display these colors instead of those specified through the Control Panel. However, keep in mind that Windows also provides a keyboard shortcut to turn on High Contrast mode. When the user presses this key combination, it is usually because they need the high contrast option in order to work with the Windows user interface (UI). Because of this, standard UI elements such as menus and dialog boxes should be drawn using the appropriate Control Panel colors whenever the High Contrast flag is set. For more information on Control Panel colors, see the description of the GetSysColors function in the Microsoft Win32(R) Platform Documentation. Keyboard Support The application must provide documented keyboard access to all features. This one is pretty straightforward: not everyone can use a mouse and many people who type quickly just find they're more productive when they can keep their hands on the home row. The upshot is that the user should be able to use the product effectively without having to rely on a mouse. That doesn't mean that you have to add code to provide keyboard access to every UI element, every drag-handle, and every pixel on the screen. It's important to provide the ability to get the right results, but the software developer has great flexibility in how that is provided. For example, the Microsoft Visual Basic design environment allows the user to drag and drop controls onto a form and move or resize them with simple mouse operations. It might seem that providing keyboard access to all that would involve a huge amount of additional UI, but that wasn't the case. The developers simply included numeric values for the height, width, and location of the control in the object's property sheet, which the user can easily view or edit using reasonably standard menu and dialog box operations. Similarly, Microsoft Word does not provide direct keyboard access to the ruler (which shows and changes tabs and margins for the current paragraph), but the user can easily use menu items and dialog boxes to accomplish all the same tasks. Exposing the Keyboard Focus Location The application must notify other software of the locations of the keyboard focus. Of all of the logo requirements for accessibility, this one is probably the least intuitive, but it is easy to implement once it is understood. Various types of automation tools need to know where the user is working. For example, Microsoft Windows 98 includes a new standard accessory called Magnifier, which shows an enlarged version of a portion of the screen Windows notifies Magnifier and other clients whenever a window gains the keyboard focus. It also tells them when it detects the focus moving within a window, based on the location of the system caret (the blinking vertical bar you see when editing text). The tricky part is when an application represents the keyboard focus somewhere within its window, but in ways that Windows doesn't understand. For example, a window might contain images that look like push buttons, but in reality they're only pictures. It may even let the user navigate to them with the keyboard, but they're still just pictures. In that case, Magnifier and other tools won't properly display where the user is working unless the application takes a few simple, additional steps. These involve explicitly informing other applications of the keyboard focus location. The application developer can choose between several different means of doing this. They include: * Leaving the system caret invisible, but moving it to cover the object that has the keyboard focus. * Providing a separate window handle for each object that can take the keyboard focus. * Using standard controls, such as tree view and list view, that automatically expose this information for you. * Implementing Microsoft Active AccessibilityTM programming tools, a Component Object Model-based (COM-based) mechanism for exposing general user interface objects. There are advantages to each approach, but you can almost always find one that works for you. In particular, the system caret method is probably the most general means available--and the least amount of work. And if you want to tell whether you're doing it right, it's easy to see: just install Windows 98 and try Magnifier. Use your application with the keyboard and see how Magnifier behaves. The Future As we mentioned, there are a lot of resources that can help you understand how to make your application more accessible, and how to qualify for the "Designed for Windows" logo. In particular, take a look at the following: * The Designed for Windows Logo program, on the Microsoft Windows Family Web site at http://www.microsoft.com/windows/thirdparty/winlogo/. * The Microsoft Accessibility and Disabilities Web site at http://www.microsoft.com/enable/, which includes the Microsoft Windows Guidelines for Accessible Software Design. * The articles for developers and authors at http://www.microsoft.com/enable/dev/default.htm. The most important thing to remember is that these aren't that hard, especially if they're designed in early. And they're important, not just for earning the logo, but for pleasing the customer--and in the end, that's the bottom line. (c) 1998 Microsoft Corporation. All rights reserved. ---------- End of Document