Suggestions for Inclusion

1. Scope and Limitations {EH: This belongs somewhere early in the document}

Adherence to the guidelines cannot guarantee accessibility for every
individual. Given the nearly infinite variety and degree of disability, the
guideline developers focused on steps that would be feasible for Web content
developers given technologies and methods available now or in the near future.
Furthermore, in order to rate the importance of these steps (checkpoints), the
developers of the document focused evaluating the _impact_ of these steps on a
small group of disability groups: blind, low vision [not including color
deficit], color deficit, deaf-blind, deaf, hard of hearing, cognitive
disability, learning disability, physical disability, seizure disorder [except
photosensitive epilepsy], and photosensitive epilepsy. This means that
priority ratings do not necessarily reflect the importance of a checkpoint for
other disability groups (e.g., emotional disability) or upon sub-groups,
except as they contribute to the rating for a group as a whole (e.g., dyslexia
within the learning disability group) {EH: 23Mar99-1312. I strongly suggest
making the set of reference groups explicit. For one thing, we will get better
review of the document because they will know better how to interpret the
ratings.}{EH, 22Mar99-1533. Important issue}
===
2. Impact {EH: Definition for the glossary}

"Impact" is the adverse effect upon Web page accessibility caused by violation
of a checkpoint. For each checkpoint, the priority was assigned based on
impact on a reference set of disability groups (blind, low vision [not
including color deficit], color deficit, deaf-blind {EH: 23Mar99-1503.}, deaf,
hard of hearing, cognitive disability, learning disability, physical
disability, seizure disorder [except photosensitive epilepsy], and
photosensitive epilepsy).  Specifically, if violation of a checkpoint would
make it "impossible" for one or more groups to access information in a
document, then the checkpoint was assigned a Priority 1 importance level. If
violation of a checkpoint would make it "difficult" for one or more groups to
access information in a document, then the checkpoint was assigned a Priority
2 level. If violation of a checkpoint would make it "somewhat difficult" for
one or more groups to access information in a document, then the checkpoint
was assigned a Priority 3 level. {EH: 23Mar99-1503.}

The estimate of impact assumes that the disability group is accessing typical
content under conditions typical for that group. "Typical content" means a
typical mix of different types of Web information purposes (educational,
informational, entertainment, commerce) and the different media (text,
graphics, video, audio) used by the general population of Web users. "Typical
conditions" means technological and environmental conditions typically
encountered by the group when using the Web. A typical diversity of
technologies that is typically used by members of the group (screen reader,
old browser, new browser, personal computer, other Web-capable hardware and
software) under a mix of environmental conditions (background noise,
illumination, etc.). 

The conditions and content are those which exist or are expected to exist
during the period 1999 through 2010.

===
3. Text Equivalents For Non-Text Objects {EH: Is "objects" OK?}
{EH:23Mar99-1254. This may be helpful somewhere.}

The key practice that enables accessibility is that of ensuring that there is
a appropriate underlying text representation for all {EH:23Mar99-1023. Added
"all"}Web content. This text can be rendered in synthesized speech, braille,
or visually-displayed text, as need by the user. The document does not
discourage the use of other media (graphics, sound, video, etc.), but it is
essential that there be text-based alternatives to these non-text media..
===
4. Basic Requirements for Web Accessibility {EH:23Mar99-1254. This may be
helpful somewhere.}

How does one begin to think about making Web content accessible to people in
these disability groups? 

A good place to start is to think about what it would take to make a Web site
accessible to individuals who are both deaf and blind. An individual who is
deaf-blind cannot hear or see and therefore are unable to access Web content,
which usually assumes both visual and auditory senses. But most deaf-blind
individuals have a sense of touch -- a tactile sense -- and therefore could
receive information via braille. Braille displays allow Web users who are
deaf-blind to receive braille information from computers. Special software can
take text from the Web site and output it, line by line to a braille display
that raises or lowers dot patterns representing the braille characters.

How does one take a Web site with text, graphics, audio, and video and make it
accessible to a person who is deaf-blind and using a braille display? The
braille display can use text directly, but what about the other media? A "text
equivalent" must be created for each non-text object or element. For each
image, there must be text that, when rendered by a user agent (e.g., browser)
will allow the user to know the purpose and function of the graphic. For
example, considering a video with accompanying audio. One must generate a text
transcript that describes the sounds, visual actions, and spoken dialogue.
When text equivalents for the various non-text components have been generateed
and organized for Web delivery, the person can access the content via the
braille display.

How does the situation differ for other disability groups? Fortunately, when
one has brought down the access barriers for individuals who are deaf-blind,
one has gone most of the distance for people in other disability groups. 

Individuals whose only disability is blindness can also benefit from braille,
however, many prefer using the same text source used by the braille display
and having it read aloud using speech synthesis technology. Individuals who
are blind can also benefit directly from prerecorded audio if their computer
is capable of it.

Individuals who have only deafness as a disability can benefit directly from
the visual information -- be it text or non-text -- but require the text
equivalent for the prerecorded audio.

Individuals with physical disabilities, such as inability to move limbs,
hands, or head do not ordinarily need any additional provision from the Web
content developer. 

Other disabilities groups need only relatively small provisions from Web
content developers. For example, certain ways of handling colors will ensure
that individuals with color deficits can see the content on the screen {EH: or
"display"). Avoiding flicker will help individuals with photosensitive
epilepsy avoid seizures when accessing Web content.

Generally speaking, if one ensures that Web content is accessible to
individuals who are deaf-blind, relatively little additional effort is
required. One the necessary text equivalents have been generated, most of the
other accommodation needed by other this and other groups disability groups is
provided by the user agent (e.g., browser) and, if necessary, by additional
assistive technology (braille or speech technology, special input devices,
etc.).

Readability of Language. One additional and very important accessibility
issues is the readability of the language. Because of the central importance
of text for people with diabilities, it is essential that the language be
clear and simple, yet appropriate for the site's content. This is especially
critical for people with language-related disabilities, such as cognitive
disabilities, learning disabilities, and deafness.

Received on Tuesday, 23 March 1999 15:52:30 UTC