From the web page
http://microsoft.com/enable/dev/guidelines/logo.htm

Understanding Accessibility Requirements
In the Windows Logo Program


In 1999, Microsoft released the Certified for Windows Logo
Program Application Specification for Windowsr 2000. This
document describes the requirements that applications must meet
to earn the Certified for Windows logo. As in earlier versions
of the logo program, to gain certification applications must
comply with certain guidelines designed to make products more
usable by people with disabilities.

Briefly, the requirements that specifically address
accessibility are:

  * Support standard system size, color, font, and input
    settings. This support provides users with a consistent user
    interface (UI) 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 only required
    when the High Contrast option is on.
  * Ensure compatibility with the High Contrast option. Users
    who select this option indicate that they want a high degree
    of legibility. When this option is selected, the application
    must use only system colors selected through Control Panel
    or other colors that are customizable by the user. 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 and background combinations. Background images or
    patterns that obscure text must be omitted.
  * Provide documented keyboard access to all features. This
    allows the user to operate the product without a mouse or
    other pointing device. Any keyboard UI that doesn't follow
    standard Windows conventions must be documented for the
    product.
  * Provide notification of the keyboard focus location. This
    includes visually indicating the focus location at all times
    when the window has the focus, and exposing this location
    programmatically (this enables the use of accessibility aids
    such as Magnifier and Narrator which are included in
    Microsoft Windowsr 2000).
  * Convey No Information by Sound Alone. 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.

For further information on the accessibility guidelines
summarized here, see the Certified for Windows 2000 Application
Specification and the The Microsoft Windows Guidelines for
Accessible Software Design on the Microsoft Accessibility
Internet site.

Windows Logo Accessibility Requirements Q&A

The following Q&A by Greg Lowney, Microsoft's Accessibility
Architect, provides answers to some questions that have been
raised by product groups working to meet the accessibility
criteria for their products. Questions are arranged under the
following topics:

  * Supporting Standard System Settings
  * Ensuring Compatibility with the High Contrast Option
  * Providing Documented Keyboard Access to All Features
  * Providing Notification of the Keyboard Focus Location
  * Conveying No Information by Sound Alone
  * General Information About the Logo Program

Note: In addition to the requirements discussed below, the
Certified for Windows 2000 Application Specification and earlier
logo handbooks include several recommendations, or "best
practices", that are likely to become logo requirements in
future versions. See the Best Practices section below for
related questions and answers.

Supporting Standard System Settings

Q: Do we always have to follow system metrics? This would
radically change our UI. For non-standard windows and controls,
is allowing the user to zoom in and out an acceptable
alternative to using system metrics?

A: The logo requirements include a number of system metrics that
apply to standard UI elements such as scroll bars, window
frames, and message boxes. Applications that use custom UI
elements that emulate and replace these standard elements are
also required to support these system metrics. However, it is
acceptable for the application to only follow these metrics when
the user requests them. The preferred technique is to provide a
single option that causes the application to use all system
metrics. Or, you could provide a group of options, each of which
turns on a group of related metrics, such as all the system
metrics related to size.

It is also acceptable for the application to allow the user to
select the size and other properties of the UI elements,
independently of the system metrics, as long as the UI element
supports the full range of values that the user can select for
the metric using Control Panel. However, this is much less
convenient for the user, and could lead to situations where the
user can't select the option because they cannot, for example,
read the menu text until the setting is turned on.

The term "zoom" normally refers to scaling the view of the
document content displayed within a window, rather than to the
appearance of window frames and other controls. The logo
requirements do not currently require scaling of document
content.

Q: Do application dialogs have to use system fonts?

A: There is nothing in the Certified for Windows 2000
Application Specification or earlier Windows logo handbooks
about using the system font for dialogs. However, dialog boxes
are covered by the requirement for supporting the High Contrast
option. In addition, hard-coding font sizes smaller than the
system font would clearly be detrimental to the usability and
accessibility of the product. We strongly discourage hard-coding
any font sizes smaller than 10 pt.

Q: What font sizes are we required to use within our application
window?

A: The application specifications or earlier Windows logo
handbooks include requirements for following system metrics for
font face and font size in specific types of controls such as
menus, ToolTips, and window captions. There is no requirement
affecting fonts used elsewhere in the application's document
area or user interface.

However, small font sizes reduce usability in many
circumstances. They are particularly detrimental for users with
reduced vision or dexterity, but many other users find the
standard font sizes used in applications cause strain on their
eyes or make reading difficult after long periods. Therefore we
strongly encourage you to let the user adjust the sizes of all
fonts displayed in your window. You can usually accommodate
larger fonts by simply making the window larger or adding scroll
bars when needed.

The best practices listed in the application specifications and
logo handbooks include the recommendation that applications do
not hard-code any fonts smaller than 10 pt. This may become a
requirement in future versions of the certification program, so
we strongly encourage you to avoid hard-coding any font sizes
smaller than 10 pt, or that you make such fonts adjustable by
the user as soon as possible.

Q: Do status bars have to follow system metrics?

A: Status bars and ToolTips are both supposed to use the same
font settings, which the user can customize through the Display
properties in Control Panel. Applications can determine the
appropriate value by examining the SPI_lfStatusFont field in the
NONCLIENTMETRICS structure returned by calling
SystemParametersInfo with the SPI_GETNONCLIENTMETRICS constant.

The Server Application Specification for Microsoftr Windowsr
2000 version 1.0 explicitly lists this requirement for all
custom status bars, so this behavior is required for any
application for which you want server certification.

However, the wording in the Desktop Application Specification
for Microsoftr Windowsr 2000 version 1.0 was not clear on this
point. Specifically, this value was described as the "font used
in status bars and ToolTips," but it was listed only under the
heading applying to customized ToolTips. The heading for metrics
applying to customized toolbars was omitted from the document.

Because of this ambiguity, applications being tested only for
desktop certification will not be required to have their status
bars follow this metric at the current time. However, it is
expected that the next update to the Desktop Application
Specification for Microsoft Windows 2000 will require
applications to handle these settings. Therefore, we strongly
recommend that applications implement support for the ToolTip
font metrics as quickly as possible.

Q: The menu of my application is unusable with large font sizes.
I see the same problem in Paintbrush. What, if anything, do I
need to do about it?

A: There is a known problem with applications built using the
Microsoft Foundation Classes (MFC) that can cause menus to
appear partially or entirely off the screen. This only happens
when the user clicks on the menu with the mouse. The user can
easily work around the problem by invoking the menu using the
keyboard. This does not mean that such applications are exempt
from the menu font metrics requirement, but it does mean that
you need to make sure you're testing properly to identify
whether such a workaround exists for your application.

When testing an application for compatibility with large
appearance schemes, you should ignore any problems with menu
truncation, or menus appearing off the screen, that only occur
when the menu is invoked by a mouse click. When you observe this
behavior, try reproducing it by invoking the menu with the
keyboard. Only if truncations still occur should it be counted
as a logo failure. Otherwise, it is a pass.

Ensuring Compatibility with the High Contrast Option

Q: Our application checks the High Contrast option when
starting, but does not respond to changes to this option while
running. If you turn the High Contrast option on or off while
the application is running, the new settings won't take effect
until you restart the application. Is this acceptable?

A: In general, applications are expected to respond to the
WM_SETTINGSCHANGE message by re-querying all system settings and
adjusting their behavior to any settings that have changed. We
strongly recommend that applications use this method to respond
to changes in the High Contrast option while running. This is
because requiring the user to restart one or more applications
can be extremely laborious, difficult, and time-consuming. Some
users may only need to invoke the feature intermittently, such
as when reading documents that use color inappropriately. In
addition, restarting the application may not be an option in
some situations, such as when the application is running on a
shared machine or kiosk.

The current wording of the Designed for Windows logo handbooks
and the Certified for Windows 2000 application specifications do
not specifically require applications to respond to the
WM_SETTINGSCHANGE message. Therefore an application can pass
today even if it must be restarted in order to pick up these
changes.

However, it is expected that the next update to the
certification program will require applications to handle these
settings changes on the fly. Therefore, we strongly recommend
that applications implement support for the WM_SETTINGSCHANGE
message as quickly as possible.

Q: Does the High Contrast requirement apply to drawing
applications such as Adobe Photoshop, Adobe Illustrator, and
Microsoft Visio?

A: The application specifications say: "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."

Adobe Photoshop and Windows Paintbrush are primarily used to
adjust pixels making up a large image. Once the user lays down a
shape of some color, that shape cannot be distinguished from any
other region of the image-there is nothing distinguishing the
foreground from the background, and one shape from another. The
application has no information to convey except the color of
each pixel, so we cannot expect the application to convey the
content through any other means. Therefore, Paintbrush and Adobe
Photoshop would be exempted from this requirement.

By contrast, Microsoft Office, Microsoft Visio, and Adobe
Illustrator are programs in which the user inserts drawing
objects on a background, and later can select and manipulate
those shapes. The program understands that there is a rectangle
in one location, an oval in another, and a bitmap image in a
third. It is reasonable to expect the application to convey this
information through means other than the use of color.
Therefore, Microsoft Office, Microsoft Visio, and Adobe
Illustrator are not exempted.

Q: How can we make our drawings useful without color?

A: When the High Contrast option is True, applications should
comply with the High Contrast requirements by selecting a
viewing option in which users can see drawing objects rendered
in colors they choose, on solid backgrounds of other colors they
choose.

Ideally, these would be the window text and window background
colors the user has selected through Control Panel. However, you
can allow the user to choose these colors separately. For
example, you could allow the user to choose separate colors for
displaying different types of objects, as long as those colors
are under the user's control.

It is generally most useful when drawing objects are displayed
as an outline rather than a solid block of the foreground color,
especially when drawing objects may overlap other drawing
objects or text.

Remember that this display option must override the color
assigned by the document author, but only for the purposes of
displaying the document on the screen while the High Contrast
option is True. It should not affect how the document is stored,
printed, or seen by other users.

Q: Our application works fine using the high-contrast white
option, but has some major problems in the high-contrast black
mode. Is it required to support both high-contrast modes?

A: The High Contrast requirement is not specific to any
particular color scheme. Rather, as the guidelines say, "When
this option is set, the application must use only system colors
selected through Control Panel, or other colors that the user
can customize." Clearly, being compatible with any particular
color scheme can be a matter of coincidence, and does not, by
itself, make the colors adjustable to meet the user's needs.
Therefore, it is not sufficient to meet this requirement.

Q: Do we have to display black-and-white icons when High
Contrast mode is selected?

A: It is recommended, but not required, that applications
display monochrome icons and bitmaps when the High Contrast flag
is set.

However, the application would fail the logo requirements if UI
elements (such as graphical images on toolbar buttons) become
unusable, or otherwise indistinguishable, because they fail to
contrast with their background (such as the button face color
selected through Control Panel).

The easiest way to ensure that your images contrast with any
background the user selects through Control Panel, is to convert
images to monochrome (meaning a single set of foreground and
background colors, not necessarily black and white). Then, map
those foreground and background colors to the corresponding
Control Panel colors. For example, icons displayed on toolbar
buttons can be converted to monochrome by using
LoadImage("icon.ico", IMAGE_ICON, 0, 0, LR_MONOCHROME). The
application can then display the icon using the appropriate
combination of foreground and background colors taken from
GetSysColors, such as the button text and button face colors.

Q: How can I support the High Contrast option when it does not
seem to be present on Windows NT version 4.0?

A: The High Contrast option is supported on Windows 95, Windows
98, and Windows 2000. It is not supported on earlier versions of
Microsoft Windows NTr. The application does not need to take
special action on that platform, and compatibility with the High
Contrast option will only be verified on Windows 98 and Windows
2000.

Providing Documented Keyboard Access to All Features

Q: Does my application have to support underlined access keys?

A: There is no requirement to support access keys-but it is
highly recommended. In general, any menu item or control that
lacks an access key should be considered a bug. However, it is
not cause for failing certification as long as there is a
reasonable way of carrying out the action using documented
keyboard techniques, including using the TAB or arrow keys to
navigate between controls or menu items.

Q: When is MouseKeys an acceptable substitute for providing
keyboard user interface in the application?

A: The general rule is that the MouseKeys feature in Windows is
an acceptable fallback only when UI provided by the application
would not be significantly more usable than MouseKeys.

For example, Paint allows the user to move the drawing cursor by
using the keyboard. However, since you're just targeting
individual pixels, it is not more convenient than MouseKeys. In
fact, MouseKeys is generally better than an application's
equivalent because it has more options for acceleration and so
forth.

On the other hand, this is not the case with most layout
operations involving discrete objects. As an example, consider
the task of dialog box layout in Microsoft Visual Basicr. There
are four options-all suited for different users:

  * Use the mouse to drag-and-drop. This is great for many
    people who can position the mouse easily and hold down mouse
    buttons while doing so.
  * Use MouseKeys. This is reasonably easy for people who can't
    use a mouse but can both use the keyboard well and see the
    screen-including many people who type with a stick held
    between their teeth. It does not work for blind users
    because they cannot target the objects. It is also very
    inconvenient for people who type extremely slowly, because
    positioning the mouse accurately using MouseKeys can require
    a large number of keystrokes or holding the keys down for
    very accurate amounts of time.
  * Use keyboard "nudge." This method provides keyboard commands
    to make small, incremental changes to the location or size
    of the selected object. Typically, this means pressing arrow
    keys to move the object slightly, or using arrow keys in
    combination with another modifier key to stretch or shrink
    the object. Of course, the application still has to make it
    easy for the user to position the focus on the object.
    Visual Basic supports tabbing through the list of objects,
    which usually requires far fewer keystrokes than using
    MouseKeys.
  * Use the object's property sheets to set the location,
    height, and width. This may not be as convenient as using
    the mouse because it may take some trial and error to find
    the optimum values, but, since it is entirely textual, it is
    usable by people who are blind or rely on voice input. Fewer
    keystrokes are required than when using MouseKeys.

Please keep in mind that if MouseKeys were an acceptable
substitute for an application's native keyboard user interface,
then everything would be considered accessible through the
keyboard. However, this would certainly not be sufficient for
blind computer users, and it would not be particularly usable by
most users who rely on, or prefer, the keyboard.

Q: We build a CAD application in which the user can be working
with a complex drawing consisting of hundreds or thousands of
complex edges, surfaces, and so forth, in a 3-D environment. How
could we possibly provide keyboard access to all of those
objects?

A: In most respects, Computer Aided Design (CAD) applications
have the same issues as simpler drawing programs. For example,
objects may be specified in 3-D, but they are ultimately reduced
to a 2-D representation. While CAD applications may be used with
a much larger number of objects than some other types of
programs, they are often used for working on a relatively small
number of objects (either as a relatively simple project or as a
component of a larger project).

There are many ways in which a CAD application could provide
keyboard access to the objects rendered in its window. For
example:

  * Tree View. Some CAD applications provide a tree view showing
    a hierarchy of all of the objects in the drawing. It would
    be easy to allow the user to navigate this tree using the
    keyboard exactly as they do standard tree view controls (for
    example, that which is shown in Windows Explorer). Be sure
    that selecting an object in the tree view or in the drawing
    itself causes both representations to be highlighted in some
    way.
  * Smart-Mouse. You could provide a feature that moves a
    pointer in a given direction until it encounters an edge or
    surface of an object. (Rather than stop at every pixel
    showing an object's surface, you probably want to stop only
    at representative locations, such as when the pointer
    crosses an imaginary line a short distance inward from the
    edge.) The pointer can be the mouse pointer or something
    akin to crosshairs drawn by the application itself. In this
    case the pointer is moving across the 2-D screen, passing
    over projections on the screen of the 3-D objects making up
    the drawing. Every CAD application can already determine
    what object or objects are at a given point on the screen in
    order to perform hit-testing when the user clicks the mouse.
    Consequently, this feature should not be particularly
    difficult to add.
  * TAB with Zoom or Filter. Many drawing applications let the
    user cycle through objects by pressing TAB or an equivalent,
    and to cycle in reverse order by pressing SHIFT+TAB. This
    would not be very usable when cycling through a large number
    of objects. However, different strategies can reduce the
    number of objects that the user must navigate through at any
    one time. For example, you can let the user zoom in to view
    only objects in a given region, or apply a filter so that
    only certain types of objects, or objects in a specified
    grouping, are displayed. You would then provide an option to
    limit navigation to the objects currently visible.
  * Entering Coordinates. You can allow the user to enter
    coordinates and thereby select the object or objects at the
    specified location. These can be 2-D coordinates on the
    screen or 3-D coordinates in the drawing space. This
    technique is not recommended for actually selecting objects
    because it often does not provide a significant savings in
    keystrokes. It can, however, be useful for letting users
    quickly move a zoomed window or otherwise scope their
    selection or navigation (as described in the previous
    paragraph).

For more examples of ways to provide good keyboard access see
The Microsoft Windows Guidelines for Accessible Software Design
on the Microsoft Accessibility Internet site.

Q: Are CAD applications exempt from keyboard requirements? Can
my application get an exemption from keyboard requirements
because it is similar to a CAD application?

A: Computer Aided Design (CAD) applications are not exempt from
keyboard access requirements under any version of the Certified
for Windows or Designed for Windows logo programs.

The Designed for Windows 95 and the Designed for Windows NT and
Windows 98 logo handbooks included a specific exemption for "CAD
and similar applications that are dependent upon graphing
tablets and other input devices." The critical aspect is the
dependence upon specialized input devices, not other features
associated with CAD applications. For example, Visual Basic and
the Office 2000 drawing layer both allow the user to manipulate
objects on the screen in CAD-like fashion, but both provide full
keyboard access.

In the Certified for Windows 2000 Application Specification this
wording has been clarified to read "Applications that rely on
specialized input devices, such as graphing tablets." There is
no longer any specific reference to, or exemption for, CAD
applications.

Q: Are games exempted from keyboard requirements?

A: Games were specifically exempted from some requirements in
the Designed for Windows 95 and the Designed for Windows NT and
Windows 98 logos. However, these exemptions no longer exist in
the Certified for Windows 2000 Professional or Certified for
Windows 2000 Server programs. All application must meet the same
set of requirements in order to become certified professional or
server.

Q: Ours is a very sophisticated application that includes
literally hundreds of features and functions. It would be
virtually impossible for us to provide keyboard access to all of
them. Is this an absolute requirement?

A: Windows generally supports and recommends that functionality
be provided through the keyboard as well as the mouse. Most
sophisticated and full-featured applications provide keyboard
access to all their features. Keep in mind that this does not
mean that every UI element needs to be keyboard accessible.
However, the end result should be that the user is able to
author documents and otherwise effectively use the product
without resorting to a pointing device.

For example, direct manipulation need not be supported through
the keyboard if an equivalent is provided, such as a property
sheet that allows the user to see and adjust properties for
objects. As another example, the application does not need to
provide keyboard access to buttons on a toolbar as long as the
functionality provided by those buttons is also available
through menus or documented shortcut keys.

Providing Notification of the Keyboard Focus Location

Q: When exposing keyboard focus, what happens when the selected
object is scrolled off the screen?

A: If you are exposing the keyboard focus location using
Microsoft Active Accessibilityr, when the object with the
keyboard focus is not visible on the screen it would still have
the focus attribute. You simply set its state flag to indicate
that it is currently off-screen.

If you are using the system caret to indicate the focus region,
simply move the caret to the location that the focus would
occupy if the window were large enough to encompass it, and the
screen were large enough to encompass that part of the
application window. If you are not set up to calculate the
correct location for things that aren't visible, simply move the
caret to coordinates outside the visible region of the window
and in the correct direction. This tells other software that the
focus is still on something within the window, but is currently
not visible. If you were instead to destroy the caret, other
software would assume that the focus was on the entire window
rather than an object within that window.

Similarly, applications are not required to show a visual
indication of the keyboard focus location when the focus has
been scrolled outside the visible portion of the window.
However, you may consider providing a visual cue indicating
which direction the user would have to scroll to find the focus
location. It is also recommended that the application scroll the
focus location into view when it has "jumped" from a visible
location to one that is not visible, such as after a Find
operation.

Q: How can I satisfy the requirement to expose the keyboard
focus location when Active Accessibility does not run on Windows
NT 4.0?

A: As explained in the Designed for Windows NT and Windows 98
Logo Handbook, there are two methods for exposing the location
of the keyboard focus. You can use Active Accessibility or, you
can achieve similar results by moving the system caret. Both are
described in more detail in the The Microsoft Windows Guidelines
for Accessible Software Design, which is available on the
Microsoft Accessibility Web site. Moving the system caret is
fully supported on all versions of the Windows platform. Active
Accessibility is only supported on recent operating system
releases; applications using it can run on any platform, but the
focus location would not be exposed on older versions of the
operating system.

If you are submitting an application for the Certified for
Windows 2000 logo, behavior will be verified under Windows 2000.
If you are applying for the Designed for Windows logo, behavior
should be verified under Windows NT 4.0 with Service Pack (SP)
6. Both of these platforms fully support Active Accessibility
and moving the system caret.

In some cases you may want to do informal testing on older
platforms. Active Accessibility was partially supported with
Service Pack (SP) 3, specifically where support is explicitly
implemented by the application. This means that Microsoft
Magnifier can track focus changes within an application's client
area. However, versions before SP 6 will not provide Active
Accessibility support for standard Windows controls, so
utilities such as Magnifier will not track focus within a list
view control displayed by the application. Problems found while
testing on these older platforms would not constitute a failure
unless the problem also occurs on Windows 2000, Windows 98, or
Windows NT 4.0 SP 6.

In addition, Windows 95 and versions of Windows NT prior to
Windows 2000 do not include the Magnifier accessory used to
verify proper behavior. This can be installed as part of the
Active Accessibility SDK, available on the Microsoft
Accessibility Internet site. If an application is exposing the
focus by moving the system caret, and needs to be evaluated on
platforms that do not support Active Accessibility, you can
verify the behavior using a separate testing tool that displays
the location of the system caret.

Q: Do remote-control utilities such as pcAnywhere and Carbon
Copy have to comply with the requirement to expose the keyboard
focus location?

A: Remote-control utilities are required to expose the focus
location in all of their own UI, including their menus and
dialog boxes. However, at this time such utilities are not
required to expose the location of the keyboard focus on the
host machine to software running on the client machine. This
exemption will probably be removed in the future when various
technical difficulties are resolved.

Explanation:

Accessibility of any communication requires three components to
cooperate and follow accessible design guidelines:

  * The source of information needs to provide data needed by
    people with disabilities.
  * The pipeline that transmits information must preserve the
    accessibility data and provide it to the client software.
  * The client software needs to take the accessibility data and
    make it available to the user or to accessibility aids
    running on the user's behalf. (It may also need to
    explicitly request that the source provide this data.)

Remote-control applications consist of two components running on
separate systems and communicating over a network or similar
infrastructure. Typically, the user is sitting at one
workstation where the client component of the utility allows
them to see an image of what is appearing on a separate host
computer. The user's input is gathered on the client machine and
transmitted to the host where it is simulated as if the user
were working on the host machine. Then, any output is gathered
on the host machine and transmitted to, and displayed on, the
client machine.

In this case one might initially argue that a remote-control
utility is a client utility that is not getting accessibility
information (such as the location of the keyboard focus on the
host machine), so it cannot present this information to the
user. However, the remote-control utility consists, not only of
a client portion, but also the pipeline that gathers information
on the host machine and transmits it over the network to its
client component. Today, it gathers and transmits information
about what drawing objects appear on the screen. It is clear
that it could, if necessary, also gather and transmit
information about the keyboard focus location.

Unfortunately, while it is easy to remote the focus once you
know it, at this time it is very difficult for applications to
track the focus properly in order to know what to remote.
Therefore, this would represent an undue burden on software
applications. So, at this time, remote-control applications are
exempted from this portion of the requirement.

In the future, we expect to provide helper libraries that make
it easier to track the focus. When those become available it is
likely that remote control applications will be required to
gather and transmit this data.

This exemption applies only to remote-control applications. It
does not represent a general exemption for all components that
sit between some source of information and the user's operating
environment. For example, the exemption would not permit
applications that host COM objects to interfere with those
objects' ability to comply with accessibility or logo
guidelines.

Conveying No Information By Sound Alone

Q: What is the difference between ShowSounds and SoundSentry?

A: ShowSounds and SoundSentry are two entirely separate features
that users can select on the Sound tab of Accessibility Options
in Control Panel. ShowSounds instructs programs that usually
convey information only by sound to also provide all information
visually, such as by displaying text captions or informative
icons. Applications that normally convey information by sound
should get the state of the ShowSounds flag by calling the
SystemParametersInfo function with the SPI_GETSHOWSOUNDS value
and displaying information visually when the state is True. If
the application never conveys information by sound without
displaying textual equivalents, you do not need to pay attention
to the ShowSounds setting.

SoundSentry instructs the computer to flash part of your screen
every time the system's built-in speaker plays a sound.
Applications do not need to do anything special for this option,
as it is taken care of by the system. However, since this does
not convey the information content of the sound, SoundSentry is
not sufficient for complying with the certification requirement
that applications avoid conveying information by sound alone.

General Information About the Logo Program

Q: In looking at other applications that currently carry the
logo, I see that almost all of them have problems with some of
these requirements. Are these really firm requirements?

A: All applications tested are expected to comply with the
requirements of the edition of the logo handbook or application
specification that is current at the time they are tested. Many
applications earned the logo under previous versions of the
program when some accessibility criteria were only
recommendations and "future requirements." Such applications may
not comply with more recent requirements, but customers can tell
which program an application was certified under by the version
of the logo it displays.

In addition, verification procedures have continued to improve,
so applications may have earned the logo because problems were
not found, but which would be found today and prevent them from
earning certification. If problems are identified after a
product is certified for Windows 2000, the problem will be
documented in the testing report posted on the VeriTest Web
site, and the developer would need to correct the problem in any
future versions of the product they submit for certification.

Q: We have done significant work to make our application more
accessible to people with disabilities. Can these features
substitute for the accessibility requirements in the logo
program?

A: While we appreciate the work many companies have done to
address the needs of people with disabilities, we cannot make
exceptions to the logo requirements based on good intentions or
unrelated work, no matter how valuable that work might be.

Q: How long have accessibility requirements been part of the
logo program?

A: All current accessibility requirements have been included in
the Designed for Windows and Certified for Windows logo programs
since July 1996. They were initially listed as recommendations
and future requirements, but began to be promoted to full
requirements in May 1997. Following is a more detailed timeline
of the inclusion of accessibility requirements in the logo
programs:

July 31, 1996 Microsoft released the Designed for Microsoftr
Windows NTr and Windowsr 95 Logo Handbook for Software
Applications, which included:

  * A requirement to support system metrics for sizing.
  * Accessibility guidelines as future requirements. All
    requirements added since then were included as "future
    requirements" in this edition.

May 7, 1997 Microsoft released the Designed for Microsoftr
Windows NTr and Windowsr 95 Logo Handbook for Software
Applications, which:

  * Enhanced one existing requirement:
  * Support a greatly expanded set of system metrics for size,
    input, and sounds.
  * Promoted four "future requirements" to full requirements:
  * Support the High Contrast viewing option.
  * Provide keyboard access to all features.
  * Ensure that the keyboard user interface is documented.
  * Expose keyboard focus to enable accessibility aids such as
    screen magnifier accessories.

June 15, 1999 Microsoft released of the Desktop Application
Specification for Microsoftr Windowsr 2000, which:

  * Included all requirements from the earlier logo program.
    (Requirements for providing complete keyboard access and
    documenting keyboard access were combined into a single
    requirement.)
  * Promoted one additional accessibility guideline to a full
    requirement:
  * Applications must now avoid conveying important information
    by sound alone.
  * Required applications to run on Windows 2000 Professional,
    but allowed applications to be additionally certified for
    older Windows platforms, including Windows NT Workstation
    4.0, Windows 98, and Windows 95.

August 30, 1999: Microsoft and VeriTest released the Certified
for Microsoftr Windowsr Test Plan for Desktop Applications
installed on Windows 2000 Professional, which:

  * Included instructions for verifying that applications met
    accessibility requirements in the Desktop Application
    Specification.

December 9, 1999 Microsoft released the Server Application
Specification for Microsoftr Windowsr 2000, which:

  * Included all requirements from the Desktop Application
    Specification.
  * Clarified that status bars are required to support font
    settings for ToolTips and status bars that the user selected
    through Control Panel.

January 31, 2000 Microsoft and VeriTest released an update to
the Certified for Microsoftr Windowsr Test Plan for Desktop
Applications Installed on Windows 2000 Professional, which:

  * Improved and clarified the testing procedures for
    accessibility requirements.

Best Practices

In addition to the requirements discussed above, the
applications specifications and logo handbooks include several
recommendations, or "best practices", that are likely to become
logo requirements in future versions. This section answers
questions about some of those best practices.

Q: What is meant by Exposing Screen Elements?

A: Some utilities need to interact with elements that
applications draw on the screen. These "screen elements" are all
the things that the user can manipulate, or that convey
information to the user. These include user interface elements
such as windows, controls, and menus; as well as document
elements such as words, paragraphs, images, worksheets, and
tables.

Accessibility aids and other types of automation tools
frequently need to interact with screen elements in a number of
ways. For example, to:

  * Identify properties of screen elements including their
    names, locations, types, and values.
  * Identify relationships between screen elements such as which
    are parents of other elements and the logical order in which
    they should be read or navigated.
  * Receive notification about events such as when screen
    elements are created or destroyed, and when their properties
    change.
  * Manipulate screen elements such as activating a menu or
    toggling the state of a check box.

Many utilities rely on these capabilities. Screen review
utilities, for example, let blind users run applications by
describing controls in words, and reporting the name, type, and
state of each control. When a user tabs to a check box, a screen
review utility might announce "Quick Printing check box,
checked."

On-screen keyboards and voice recognition utilities need to
identify and name specific controls so they can provide the user
with a list of available commands or recognize and activate a
control when they hear its name spoken. For example, the user
may say "Page Setup" to choose the corresponding menu command,
then say "Landscape" to check the corresponding check box.

Testing tools such as Rational Software's Visual Test use these
techniques to recognize controls that are named in a script,
manipulate controls in response to the script's commands, and
log information about the state of the controls. They may also
carry out actions when specific screen elements appear or change
state. For example, a routine in a script may be triggered when
a specific message box appears or a specific value appears in a
particular text field.

The standard way to expose this information is through Microsoft
Active Accessibility. Standard window frames and controls
provided by USER32.DLL and COMCTL32.DLL automatically support
this method as long as they are used correctly. Applications
only need to provide additional support when creating custom
window classes or controls, or drawing content in the window
client area.

For more information, see the Microsoft Active Accessibility
SDK.

Q: Selecting the Large Fonts option in Display Options of
Control Panel will make 8-point fonts appear as 10 point. Will
this allow our application to meet the future requirement to
avoid hard-coding fonts smaller than 10-point?

A: It is not acceptable to rely on the Large Fonts mode to
enlarge small fonts. Almost anything can be made infinitely
larger through the Custom Font Size feature in the Display
section of Control Panel, but it is not acceptable to make the
user enlarge everything-including that which is already large
enough-just to enlarge those elements that are too small.
Instead, applications should avoid displaying any elements that
are small enough to reduce usability, or should provide the
option to enlarge those specific elements.


Last updated on May 24, 2000
c 1996-2000 Microsoft Corporation. All rights reserved.


VICUG-L is the Visually Impaired Computer User Group List.
To join or leave the list, send a message to
[log in to unmask]  In the body of the message, simply type
"subscribe vicug-l" or "unsubscribe vicug-l" without the quotations.
 VICUG-L is archived on the World Wide Web at
http://maelstrom.stjohns.edu/archives/vicug-l.html