***Appendix A***

***Subpart C and D of Section 508***

***Subpart C - Functional Performance Criteria***

The performance requirements of this section are intended for overall
product evaluation and for technologies or components for which there is
no specific requirement under the technical standards in Subpart B.
These requirements are designed to ensure that the individual
accessibility components work together to create an accessible product.
The requirements cover operation - including input and control
functions, operation of mechanical mechanisms, and access to visual and
audible information. Below you will find the 1194.31 Functional
Performance Criteria verbatim as they appear in the law, preceded by
related disabilities.

***Overview***

\(a\) *Vision*: At least one mode of operation and information retrieval
that does not require user vision shall be provided, or support for
assistive technology used by people who are blind or visually impaired
shall be provided.

\(b\) *Visual acuity*: At least one mode of operation and information
retrieval that does not require visual acuity greater than 20/70 shall
be provided in audio and enlarged print output working together or
independently, or support for assistive technology used by people who
are visually impaired shall be provided.

\(c\) *Deaf*: At least one mode of operation and information retrieval
that does not require user hearing shall be provided, or support for
assistive technology used by people who are deaf or hard of hearing
shall be provided.

\(d\) *Hard of hearing*: Where audio information is important for the
use of a product, at least one mode of operation and information
retrieval shall be provided in an enhanced auditory fashion, or support
for assistive hearing devices shall be provided.

\(e\) *Speech impairments*: At least one mode of operation and
information retrieval that does not require user speech shall be
provided, or support for assistive technology used by people with
disabilities shall be provided.

\(f\) *Motor skills, coordination*: At least one mode of operation and
information retrieval that does not require fine motor control or
simultaneous actions and that is operable with limited reach and
strength shall be provided.

***Subpart D - Information, Documentation, and Support***

***Documentation Requirements***

The standards also address access to all information, documentation, and
support provided to end users of EIT. This includes user guides,
installation guides for end-user installable devices, and customer
support and technical support communications. Such information must be
available in alternate formats upon request at no additional charge.
Alternate formats or methods of communication, can include Braille,
large print, electronic text, TTY access, and captioning and audio
description for video materials. However, the easiest solution for this
requirement is to have the vendor provide the USPTO the information in
an electronic format (e.g., CD). It is not acceptable that information
is available on the vendor's web site.

**Overview**

(a) Product support documentation. Make product support documentation
    provided to end-users available in alternate formats upon request
    for no additional charge.

(b) Accessibility and compatibility features. Provide end-users access
    to a description of accessibility and compatibility features of
    products in alternate formats or alternate modes upon request at no
    additional charge.

(c) Support services. Accommodate communication needs of end users with
    disabilities when providing support services for products.

***Appendix B***

***Information and Tips on Creating Accessible Products***

## General Accessibility Improvements 

To increase overall accessibility, developers can:

-   Make documentation available in electronic form and accessible by
    screen reading software, thus making it easier to use for people who
    cannot handle or read printed materials.

-   Make product support staff aware of disability access issues and
    that people with disabilities routinely depend on their software
    products.

-   Establish a protocol to forward accessibility and compatibility
    problems from product support staff to product designers. Keep the
    trigger-level for such referrals low.

All properly trained support staff should be able to handle routine
product use questions from users who have disabilities. Ideally, some
individual should also seek to specialize, to learn how to resolve
specific incompatibility issues between software and technologies
designed to assist those with disabilities.

In this way, developers and support staff can create pools of expertise
to deal with the widest possible range of problems and suggestions
brought forward by users.

## Best Practice Principles for Accessibility in e-Learning 

The following principles are considered best practices for producing
accessible software applications and accessible content for e-Learning.
Developers, content providers, and educators involved in the creation of
learning products should adhere to these guidelines from the outset of
the design process, since retrofitting an inaccessible product is almost
always significantly more difficult, labor-intensive, and expensive.

We offer six principles that address accessibility for people who have
sensory or mobility disabilities. These principles also address
accessibility issues faced by people with cognitive disabilities, though
often to a lesser extent.

-   Allow for customization based on user preference

-   Provide equivalent access to auditory and visual content based on
    user preference

-   Provide compatibility with assistive technologies and include
    complete keyboard access

-   Provide context and system orientation information

-   Follow IMS specifications and other relevant specifications,
    standards, and/or guidelines

-   Consider the use of XML for dynamic content generation

***E-Learning Accessibility Checkpoints***

-   All videos should be captioned for deaf and hard-of-hearing viewers

-   Videos carry an audio component that describes visual images for
    blind and low-vision users

-   Software applications offer key combinations (e.g. CRTL+F) for
    functions, that are appropriate for users with mobility restrictions
    (e.g., no key combination should require the use of more than one
    hand) or vision impairments

-   Images and forms on websites have labels (e.g., alt text) for users
    who access content with the help of screen reading software (e.g.,
    Visually impaired or blind students should be able to access
    mathematical equations presented as graphics)

-   Testing protocols should be flexible enough to accommodate disabled
    users (e.g. time-dependent tests can offer more time for mobility
    impaired students)

-   Administrative matters such as course listings and course
    registration are made accessible

***Tips for designing e-Learning for...***

## People who are Blind 

To support screen-reading software, developers can:

-   Use standard system tools to draw and erase all on-screen text and
    to display all cursors and pointers

-   Use standard system on-screen controls whenever possible (e.g., OK
    buttons, dialog boxes, drop-down menus)

-   Define tools in toolbars, palettes, and menus as separate items. Do
    not create single graphics containing multiple objects. By keeping
    tools and other objects separate, the screen reader is better able
    to identify and name each tool for the user.

-   Embed descriptive text (e.g. alt text, tool tips) in graphic images
    in such a way as to make the text known to screen reading software.
    This addresses the problems that can arise when text is rendered as
    a graphic image and cannot be read by software.

-   Assign logical and consistent names to controls, even if the name is
    not visible on the screen

Screen readers can access this information and use it to describe the
type and function of the control on the screen and track the system
cursor with the mouse, even if the cursor is invisible. This allows the
screen reading software to detect the mouse position when customized
highlighting or focusing techniques are in use.

-   Use consistent and predictable screen and dialog layouts

-   Avoid the use of help balloons that disappear whenever the hot spot
    or focus of the mouse changes. Try instead to lock the help balloon
    in place so that the user can move the cursor and continue to read
    the balloon.

-   Use single column text whenever possible

-   Provide keyboard equivalents for all tools, menus, and dialog boxes

Since screen readers can only read text (or give names to separately
identifiable icons or tools), it is a good idea to:

-   Avoid assigning unlabeled \"hot spots\" to pictures for use as
    controls, unless they are redundant with menu selections

-   Avoid non-text menu items when possible or at least incorporate
    visible or invisible text cues to accompany these items. Screen
    readers can see text even if that text is written to the screen
    invisibly.

-   Avoid non-redundant graphic tool bars. Make any tool bar command
    available in a menu

Finally, documentation and training materials are always more accessible
when:

-   Documentation and online help can be understood independent of
    graphics. Text descriptions should be included in all graphics.

-   Synchronized audio descriptions are available to play alongside
    animated graphics or movies

***People with Low-Vision***

To make on-screen information easier to see, developers can:

-   Increase the contrast between text and the background.

-   Place text over a solid-color background. A patterned background can
    make text harder to discern.

-   Create consistent layouts for all screens and dialogs within the
    program.

-   Provide access to tools via a menu bar.

-   Follow line width guidelines when drawing lines on screen. Use the
    line width information provided by operating system settings. This
    will ensure that the learning application will increase all lines
    proportionally should a user choose to enlarge the view (e.g. use
    \<HR\> HTML tags for horizontal separation instead of graphics)

-   Allow the user to zoom in to or magnify images

-   Provide volume controls for audio tracks

To make their software more compatible with other applications that
offer low-vision access features, developers can:

-   Use the system pointers whenever possible, as well as the system
    caret or insertion bar, if available

-   Include a highlight or focus indicator when dragging the system
    cursor, even at those times when the cursor is invisible. This
    adjustment will help screen enlargement software using \"pan and
    zoom\" features to track the user\'s movements more accurately.

-   Add support for a \"high contrast\" setting.

-   Protect users from the need to simultaneously monitor two or more
    events occurring far apart from each other on the screen.

-   Avoid using key combinations for functions that require more than
    one hand

***People with Color Blindness***

To make it easier for color-blind users to access their software,
developers can:

-   Make color-coding a redundant or secondary means of conveying
    information

-   Ensure that applications they develop are usable on monochrome
    screens

-   Use variations in contrast and brightness in addition to color
    variations

***People Who Are Hard-of-Hearing or Deaf***

To increase the accessibility of software to users with hearing
impairments, developers can:

-   Provide all auditory information visually.

-   Ensure that all visual cues are noticeable even if the user is not
    looking straight at the screen. Important information should catch
    the user\'s attention, even through peripheral vision.

-   Support the Microsoft Windows *ShowSounds* feature that allows a
    user to assign a visual and caption for each audio event.

-   Telephone support staff should also have text telephone (TTY)
    available in order to be able to assist deaf or hard-of-hearing
    customers.

##  People with Mobility Impairment 

To increase the accessibility of software to people with physical
disabilities and ensure compatibility with assistive technologies,
developers can:

-   Avoid timed responses

-   Provide keyboard access to all toolbars, menus, and dialog boxes

-   Allow the user to access helpful features already built into the
    operating system, such as Microsoft Windows *StickyKeys*,
    *SlowKeys*, and *Key Repeating*

# *IBM Accessibility Checklists*

These checklists can be used for all general software products and
applications. The checklists also apply to applications written in Java
1.1.x using standard AWT components that are designed to run on
Windows-only platforms. If you are developing web applications, you can
follow the **IBM Web Accessibility Checklist** found at

> http://www-306.ibm.com/able/guidelines/web/accessweb.html.

If you are developing Java2 applications, you can use the **IBM Java
Accessibility Checklist** found at

> http://www-306.ibm.com/able/guidelines/java/accessjava.html.

Each checkpoint includes detailed rationale, techniques and test
strategies to help you develop and test accessible software. To review
the detailed information, select the text link on each checkpoint.

***Appendix C***

Section 508 Evaluation of a USPTO Software System

In 2001, the USPTO had a task order for a contractor to revise a major
proprietary software system. The task order required the contractor to
evaluate the Section 508 status of the revised system and to ensure that
the final product was compliant.

For the price of a good SUV, the contractor did an extensive evaluation
of the system and provided the following report. Out of the 11 software
standards, only eight were applicable to the system. The report does an
excellent job of identifying and illustrating the problems.

There was a second proprietary system under development. When the
contractor estimated that their Section 508 evaluation would cost the
price of a very nice luxury car, the USPTO sought other sources for the
evaluations.

We discovered that there are several reputable companies that will do a
quasi evaluation of a product for \$2500 or less. And, for that amount,
the company will train a flock of your staff on an assistive technology
tool so that they learn how to find and correct compliant issues.

Everyone wins with the \$2500 evaluations. They are affordable. They can
be purchased via a credit card. You have your staff trained. And,
management is more receptive and supportive.

Key lessons learned:

-   Always include a statement in the contract that requires the
    contractor to build or provide Section 508 products.

-   No matter what a contractor tells you, your agency is the only one
    legally responsible for Section 508 compliant products.

-   If a final product is not compliant, make the contractor correct the
    problem at their expense

-   Have a means to evaluate a product for compliance *before* the
    product is about to go into production.