From the web site http://microsoft.com/enable

Accessibility in the Documentation Process

There are six basic ways that Microsoft User Education groups
can address accessibility:
  * Document accessibility features, tips, and warnings for each
    product, in normal documentation and in a separate, more
    detailed document.
  * Follow design guidelines for accessible documentation, which
    address issues such as layout, and the use of color and
    fonts.
  * Follow design guidelines for HTML documents and Web sites.
  * Follow guidelines for bias-free communication and proper
    terminology.
  * Provide documentation in alternative formats for users who
    have difficulty reading or handling conventionally printed
    material or using our standard online documentation.


Document Product Features

You are strongly encouraged to take extra effort to fully
document the accessibility of your product.

Benefits:

  * Let users and people making purchasing decisions determine
    whether the product will be usable by them or meet their
    needs--before they make the purchase
  * Let users determine the best way to access your
    product--even if their needs are uncommon
  * Ensure that your customers know you are addressing
    accessibility issues

You should cover the following topics:

  * Accessibility features designed for users with disabilities
  * Mainstream features that may be of especial benefit to users
    with disabilities
  * Tips about how to work around limitations or get the most
    out of the product when a person has uncommon needs.
  * Keyboard procedures to accomplish tasks that are described
    elsewhere only in terms of the mouse.
  * Warnings when the product is not usable by individuals with
    certain types of disabilities, or using certain types of
    accessibility aids.

Information should be made available in two ways:

  * In your product documentation. For example, almost all
    Microsoft products have a chapter or appendix titled
    "Accessibility for People with Disabilities" that describes
    accessibility features of the product as well as general
    services available from the company and other organizations.
  * In separate documents that should be made available on the
    World Wide Web and, optionally, through your customer
    service organization. These may be in the form of Web pages
    or white papers. They should provide more details than can
    be accommodated in the printed or online documentation with
    the product. It can also include information was not ready
    by the time the product was completed. This should also help
    potential customers determine whether the product is usable
    by themselves or other individuals with disabilities, before
    making a purchasing decision.

For examples of how other groups have handled this, see:
  * The Web site describing accessibility of Microsoft products


Designing Accessible Documentation

The guidelines for designing accessible documentation are much
like those used for an application's user-interface:
  * Use high contrast between foreground text and backgrounds.
    Avoid using screened art behind text.
  * Don't convey information by color alone, because some
    individuals will not be able to perceive the differences.
  * Don't convey information by graphics alone, as it makes it
    difficult for people who have some visual or cognitive
    disabilities. Redundant use of text and graphics is
    preferred by almost everyone.
  * Text should be decently large in print and the size should
    be customizable when read on-line.
  * On-line documentation should be complete so that users with
    print impairments will not need to resort to documents in
    alternative formats.
  * Make sure documents convert to SGML cleanly. Use styles
    correctly and avoid using direct formatting.
  * Bind documentation to lie flat. Spiral binding and similar
    techniques let the user read documents when they cannot use
    a hand to hold them in place.

For more information, see

  * Guidelines for accessible Web page and HTML design
  * Guidelines for accessible application design


Guidelines for Accessible HTML and Web Pages

All HTML documentation should follow published guidelines for
accessible HTML. This applies regardless of whether the
documents are posted on the Web or displayed on the user's
computer.

Similarly, online documents that make use of Java, scripts,
ActiveX controls,or dynamic HTML should also follow the
appropriate guidelines.

For more information:

  * Guidelines for Accessible HTML and Web Page Design.


Communication Guidelines

Take care to avoid using words or phrases which may offend some
readers. The following guidelines can help writers and editors
recognize terms which may inadvertently cause offense or convey
an inappropriate message.

For more information, please see:

  * Microsoft Manual of Style for Technical Publications,
    published by Microsoft Press.


Providing Documentation in Alternative Formats

You should provide documentation in alternate formats for users
who have difficulty reading or handling conventionally printed
materials or online documentation.

Microsoft works with Recording for the Blind & Dyslexic, a
not-for-profit organization that converts documents into
formatted ASCII text files for use by people with disabilities.
Several other organizations provide similar services using a
variety of formats.

To contact Recording for the Blind & Dyslexic, see Microsoft
documentation in Accessible Format.


Accessibility Toolbar:
Introduction | Microsoft Accessibility Efforts | Microsoft
Products | Accessibility Aids | Other Resources | For Developers
and Authors | News and Events | Status and Evaluations | About
This Site | Formatted Version | Accessibility Home Page

Microsoft Toolbar:
Microsoft | Products | Search | Support | Shop | Write Us

(c) 1997-1998 Microsoft Corporation. All rights reserved. Legal
Notices. Last updated on March 13, 1998.

----------
End of Document