- From: eric hansen <ehansen@ets.org>
- Date: Tue, 12 Jan 1999 12:51:43 -0500 (EST)
- To: w3c-wai-gl@w3.org
PART 2: PROPOSED REVISIONS FOR THE PAGL DOCUMENT
Notes are found between square brackets and headed by the word "NOTE". The
notes are my (Eric Hansen's) side comments and are not for inclusion in the
PAGL document.
One area not addressed by these revisions is many related specifically to
the guidelines, which are superordinate to the checkpoints.
2.A. PROPOSED INTRODUCTORY PORTION OF GUIDELINES DOCUMENT
Purpose
The Page Authoring guidelines document is designed to help Web authors
improve the accessibility of Web sites for people with disabilities. The
document also indicates how following the guidelines can also make Web
sites more accessible and usable to individuals without disabilities.
Relation to Other Documents
Other documents in this series also play a role in improving the Web
accessibility.
* The PAGL Supporting Documents provide detail on how to implement the
accessibility guidelines and background on the procedures used to produce
the document's guidelines, checkpoints, and ratings.
* The WAI Authoring Tool guidelines focus on (a) how Web authoring tool
developers can help Web authors implement the PA guidelines (b) making the
tools usable for people with disabilities.
* The WAI User Agent guidelines focus on ensuring that user agents such as
Web browsers are highly usable by people with disabilities.
Benefits
Adhering to the guidelines in this document:
* Will ensure a basic level of accessibility for people with disabilities.
For many individuals with disabilities, following these guidelines will
have a profound positive influence on their access to Web-based
information.
* Will help increase usability and accessibility by both nondisabled and
disabled individuals who are using a mobile and voice technologies or who
are operating in constrained environments (noise-free, nonvisual).
* Is expected to promote comprehension, appreciation, and hence, overall
effectiveness of Web content.
Priorities
To help Web authors prioritize their efforts, this document provides
priorities for implementation. These priorities were determined by the
level of adverse impact on accessibility for disability groups when there
is failure to implement a checkpoint.
Following are the priorities and the impacts that gave rise to them.
[PRIORITY 1] This checkpoint must be addressed by an author BECAUSE failure
to do so would result in one or more groups of users finding it impossible
to access information in the document. Satisfying this checkpoint is a
basic requirement for some groups to be able to use Web documents.
[PRIORITY 2] This checkpoint should be addressed by an author BECAUSE
failure to do so would result in one or more groups of users finding it
very difficult to access information in the document. Satisfying this
checkpoint will significantly improve access to Web documents.
[PRIORITY 3] This checkpoint may be addressed by an author BECAUSE failure
to do so would result one or more groups of users finding it somewhat
difficult to access information in the document. Satisfying this checkpoint
will improve access to Web documents.
[NOTE. I have modified the language to make it more parallel. Also,
"BECAUSE" is in all caps to emphasize this important change. It need not be
capitalized in the final.]
2.B. SCOPE AND LIMITATIONS
[NOTE. This section might best be located in its own appendix.]
The section describes the scope and limitations of this document.
Focuses on Improving Accessibility for People with Disabilities
This document focuses on improving the level of accessibility to Web-based
information by people with disabilities.
Yet neither this document nor any other practical set of guidelines can
guarantee accessibility by all people with disabilities. The diversity of
user characteristics, technologies, and situations is too great to be full
addressed by a finite set of guidelines. For example, following the
guidelines may be ineffective for certain individuals with severe or even
moderate cognitive disabilities.
Following the guidelines will also improve accessibility and usability for
many nondisabled individuals. This is an important but secondary focus of
the document.
Focuses on Major Disability Groups
This document focuses on issues generally encountered in major disability
groups (blind, low vision, deaf, hard of hearing, deaf-blind, learning
disability, physical disability, cognitive disability, emotional disability,
tactual disability [NOTE. Were individuals with tactual disabilities
considered?]), plus two other specific subgroups (color deficiencies,
photosensitive epilepsy). [NOTE. I think that color deficiencies are often
categorized under low-vision. I don't know about photosensitive epilepsy;
should there be another large category called seizure disorders?). Except
for the category of deaf-blind, the document does not focus on the issues
peculiar to multiply-disabled individuals. For example, this document will
not necessarily ensure accessibility for a triply disabled individual who
is not only deaf and blind but also has tactual disability (perhaps due to
diabetes) that affects their capacity to feel braille characters. Neither
might it adequately address the needs of an individual who is deaf and has
a learning disability.
Ensures Perception
The document focuses on ensuring that the information can be perceived but
cannot guarantee that the information will be understood. For example, text
in Web documents may be inaccessible to individuals with language-related
disabilities (cognitive disabilities, learning disabilities, deafness,
etc.) even though the text can be clearly perceived and even if a diligent
effort has been made to write the content simply and straightforwardly (see
checkpoint B.3.1). The improvements brought about by following the
guidelines are expected to be more adequate for individuals with
non-language-related disabilities (blindness, physical disability, etc.)
than for individuals with language-related disabilities.
Uses Written Language as an Essential Representational System
The document emphasizes written language (i.e., "text") as an essential
representation system, meaning that all essential information should have a
textual representation. This does not mean that non-textual visual material
(e.g., still or motion pictures) or auditory materials should not play a
prominent role in Web sites. The guidelines basically require that such
non-text materials be accompanied by alternative textual representations,
such as alt-text, descriptive text, transcripts, and captions. The major
advantage of having written language as an essential representational
system is that it is readily expressed or rendered in ways that are
perceivable by three major sensory systems -- vision (written text),
hearing (synthesized or prerecorded speech), and touch (braille).
However, one limitation of this approach is that it may not always provide
adequate access for individuals requiring information that is not readily
translated into text. Content such as dance, body language, and manual
signing systems, may lose subtlety and richness of meaning when, and if, it
can be translated into a text-based notational system and then rendered
either as written text, speech, or braille. Consider, for example, a Web
site originally targeted to deaf nonreaders. The site may make extensive
use of videos of people using some form of signed communication. However,
the text-based transcripts of these communications may lose many of the
nuances available in the original. (It should be noted that a deaf
nonreader does not necessarily have two disabilities.)
Assumes That Vision, Hearing, and Touch Are the Relevant Sensory Systems
The document assumes that the senses of vision, hearing, and touch are the
relevant senses for presenting Web-based information. Presenting content to
the senses of smell or taste, though possible for some information, is not
addressed.
Focuses on Issues Having Much Greater Impact on Disabled Individuals In
Contrast to Nondisabled Individuals
The document focuses on issues that have much greater impacts on disabled
individuals than on nondisabled individuals. Some potential checkpoints
have been excluded from this document because the problems they address
fail to meet this criterion. For example, many individuals with
disabilities find a Web site less usable or even "inaccessible" if the
content is entirely in a language that they do not understand (e.g., a
"foreign" language or highly complex language) or uses words or phrases
that they find offensive or insensitive. Another possible example is that
certain educational content may be "inaccessible" to individuals with
disabilities who lack the necessary learning prerequisites. Another
possible example is that many people with disabilities lack the economic
resources to buy the necessary computer technology so that Web information
is "inaccessible" to them. All these problems are largely, if not
completely, excluded from these guidelines, because their impact on
disabled individuals is not "much greater" on the nondisabled individuals.
Indeed, some argue that these are not disability access issues at all.
Admittedly, this criterion is not tightly defined. If research shows that
people with disabilities are much more affected by these issues (for
example, lack the economic resources to buy the necessary computer
technology) then one could not exclude possible checkpoints (e.g., "Ensure
that all people with disabilities have a Web-capable personal computer.")
on this basis. (However, in many of these cases, the checkpoints might
still be excluded because they are beyond what can reasonably be expected
of Web authors. [See below.])
To reiterate, this document focuses on issues that tend to have a
substantially greater impact on people with disabilities than on people
without disabilities.
Focuses On What Could Reasonably Be Addressed By Web Authors
The document only considers issues that could reasonably be addressed by
Web authors. As used in this document, the term "Web author" gives special
emphasis to the individuals who are writing the markup code (HTML) or who
are writing the software that generates the markup. But it also encompasses,
to a lesser degree, others who create, design, or provide content for Web
sites. The intent of this document is to point out things that might
reasonably be expected of virtually all Web authors.
An extreme example of a checkpoint that is excluded from this document is
the following. "If a person with a disability has trouble using a Web site,
one _must_ ensure the problem is overcome, if necessary, by sending a staff
person to the location of the disabled person in order to address the
issue." This kind of checkpoint is excluded because it is considered beyond
what could be expected from almost all Web authors.
Let us take a less extreme example. Consider a potential requirement that
"If _a person with a language-related disability_ such as deafness has a
question about something on a Web site, there must be a TTY (teletype [for
individuals who are deaf]) number that he or she can call to obtain
additional information." The TTY device is known primarily for its use by
individuals who are deaf, many of whom have difficulty accessing written
text. Many individuals who are deaf would likely benefit from being able to
conduct interactive discussion with a knowledgeable staff person via TTY.
While providing such TTY support would be a good thing to do, the working
group believed that this is beyond what should be expected of virtually all
Web authors. [NOTE. AM I CORRECT THAT THIS TTY ISSUE WAS CONSIDERED AND
REJECTED FROM THE GUIDELINES?]
Thus, in order to be included in the PAGL document, the checkpoint be
within the scope of what could reasonably expected of Web authors.
Is Not a Comprehensive Guide to Web Design or Development
This document is not a comprehensive guide to Web site design or
development. For example, this document does not specifically address how
to increase a Web site's appeal, though it is expected that following the
guideline can help Web sites appeal to both new and current audiences. Nor
do the guidelines indicate the sequence in which the various checkpoints
should be addressed during the design and development process or by what
Web development participants (e.g., HTML coders, Web designers, content
providers, etc.).
Assumes a General Mix of Content Purposes
This document does not distinguish between major content purposes
(informational, educational, entertainment, commerce) but rather assumes a
variety of such purposes. This is important because an understanding of the
purpose of the site may sometimes necessarily influence the application of
the checkpoints. For example, consider the checkpoint "Use the simplest and
most straightforward language that is possible for the content of your
site" (B.3.1). One should not apply this guideline unthinkingly to certain
kinds of educational content, such as tests of reading comprehension, which
may deliberately use complex syntax or difficult vocabulary to assess a
person's reading skill.
Attempts to Address the Needs of General Audiences Worldwide Rather Than
Local Cultures
This document is intended to apply to Web sites for a variety of audiences
throughout the world, but is not necessarily sensitive the culture or
sub-culture of specific audiences. Some culture- or nation- specific issues
can have an important influence on the accessibility and usability of Web
sites, but are beyond the scope of this document.
Assumes That Information Being Made Accessible is "Helpful"
This document assumes, unless otherwise stated, that information being made
accessible is "helpful" for an overall understanding of the document. Thus,
priority 1 checkpoints must be followed, even though the information being
made accessible is merely "helpful" rather than "important" or necessary.
As noted "Appendix D - Definitions (for "Important information")
"Information is important if understanding it in detail is necessary for
the overall understanding of a document." [NOTE CHANGE IN WORDING]. In some
cases, the guidelines and checkpoints focus specifically on "important"
information (A.2., A.2.1, and A.10.). In a few other cases, different
priority ratings are provided depending on the importance of the content
(e.g., Checkpoint A.1.6.) "Replace ASCII art with an image and alternative
text. [Priority 1] or [Priority 2] depending on the importance of the
information; see also A.3.3., and A.11.1). [NOTE. As I have indicated
before, I prefer not to have multi-valued or contingent priorities, but
perhaps it is OK if one makes the assumptions explicit. Also, I see the use
of the term "important" as inconsistent in A.10. The word is not used in
the guideline statement but immediately following it ("This is particularly
important for objects that contain text and does not apply to instant
redirection.") In my view, the word "important" is a significant qualifier
and belongs inside any applicable checkpoint statement and appear as though
it were tossed in on the side. If the word "important" is in a checkpoint
statement, it may or may not be found in the relevant guideline statement.]
Attempts to Provide Checkpoints That Are Largely Nonoverlapping
The document provides checkpoints that are intended to be largely
nonoverlapping in their coverage. The major known exception to this point
is checkpoint A.14 ("Wherever possible use a W3C technology in accordance
with guidelines on its proper usež"), which essentially overlaps with the
whole PAGL document, since the PAGL document is (when approved) a W3C
technology. [NOTE. I have previously described my concerns about A.14 as
currently phrased. I suppose that one way to characterize my concern is by
asking the question: "What criteria would one employ to determine if a Web
document is compliant or non-compliant to the checkpoint?" Is it possible
that, since the PAGL document is a "W3C technology," then a single
violation of any of the checkpoints would render the document noncompliant
with checkpoint A.14? Checkpoint A.14 seems too broad and logic-packed to
be validated in the same way as most of the other checkpoints. I think that
it might make a good general statement of policy or philosophy undergirding
the checkpoints, but, as currently phrased, it doesn't seem to fit with the
other checkpoints.]
Does Not Permit Cost to Influence Priority Levels
The document does not allow costs to determine priority levels. That is,
for any given checkpoint, the priority levels (the importance of adhering
to a checkpoint) is unrelated to the cost of implementing the checkpoint.
Priority levels were determined solely by impact levels ("impossible,"
"very difficult," "somewhat difficult") on the disability groups. It is
expected that many of the checkpoints can be implemented at little or no
cost, especially when built in at the early stages of Web design and
development.
However, cost was considered informally in determining which checkpoints to
include in the PAGL document, since cost is a necessary component of
overall feasibility and practicality. The working group attempted to
include only those checkpoints that show a strong possibility [NOTE: Or
"probability" (?)] of being cost-effective to implement.
[BEGINNING OF EXTENDED NOTE.
There has been much discussion in my correspondence about cost
considerations and their influence on checkpoints and their priority
ratings. I now understand that cost considerations do not influence the
imperative (priority) ratings of checkpoints, since imperative ratings are
functionally determined by impact ratings.
You will note that I have said that "However, _cost was considered
informally_ in determining which checkpoints to include in the PAGL
document, since cost is a necessary component of overall feasibility and
practicality." (emphasis added). I assume that cost was considered in
determining which checkpoints to include or exclude. I think that it should
have been the case and should be acknowledged. This is consistent with the
first paragraph of Part 2 of this memo: "This [PAGL] document focuses on
disability access issues that can _reasonably_ be addressed by Web authors,
primarily through document markup" (emphasis added). I think that the PAGL
should only include checkpoints that have passed the test of reasonableness,
feasibility, and practicality. In other words, they must have a strong
potential of showing benefits that justify whatever _costs_ may be
entailed. Phrased differently, I expect that the working group was and
should be "biased" against including checkpoints that are expensive, or
more specifically, that are not cost-effective.
What is the alternative to this approach? To say that costs were NOT
considered in determining which checkpoints to include or exclude? Consider
the implications of that approach. I think that if Web developers believed
that cost (or cost-effectiveness) was not considered in determining which
guidelines to include or exclude, then they might doubt the practicality of
the checkpoints. They might then feel it their duty to bring such
considerations to bear in picking and choosing which ones to follow and
which ones not to follow. Even worse, they might assume that the people
that produced the guidelines don't appreciate the challenges of developing
a Web site under financial constraints and that therefore the guidelines
should be ignored.
END OF EXTENDED NOTE.]
Attempts to Provide a Stable List of Checkpoints and Priorities
The document attempts to provide a list of checkpoints and priorities that
will be stable for many years. However, it is understood that the
guidelines may require modification as technologies evolve and as new
disability access problems and solutions are identified. The working group
is particularly interested in identifying new, potentially cost-effective
methods for improving accessibility and usability of Web content for people
with language-related disabilities (cognitive disability, deafness,
dyslexias, etc.). Suggestions on this or any other topic should be sent to
the working group at [INSERT WORKING GROUP EMAIL ADDRESS].
2.C. HOW THE CHECKPOINTS AND THEIR PRIORITIES WHERE PRODUCED
Upon receiving its charter from the W3C, the page authoring guidelines
working group asked themselves and many others the question, "What
disability access checkpoints are so important that failure to implement
the checkpoint would have a significant adverse affect the accessibility to
Web-based information by disability groups?"
Checkpoints were rated by whether failure to implement the checkpoint would
make it (1) impossible, (2) very difficult, or (2) somewhat difficult, for
disability groups to access the information.
The working group also identified the particular disability groups that
would be most affected. (These disability groups, sometimes with other
affected non-disability-related groups, are mentioned under the guideline
that overarches each set of checkpoints. [NOTE. This assumes that all
checkpoints under a single guideline have a similar, if not identical, list
of most-severely-affected-groups.]) The list of disability groups
considered were as follows:
blind
low vision not including color deficiencies
color deficiencies
deaf
hard of hearing
deaf-blind
learning disability
physical disability
cognitive disability
emotional disability
tactual disability
photosensitive epilepsy
The guideline editors made judgments regarding which checkpoints to include,
how to phrase them, and what their priorities should be. These judgments
were based on discussion with working group listserv participants, most of
whom are not formal members of the working group but who bring to bear a
wide range of expertise in technology and disability issues. Participants
were not asked to identify their disabilities, though some active
participants are known to have disabilities. [NOTE. VERIFY ACCURACY AND
SENSITIVITY.]
Drafts of the page authoring guidelines and accompanying checkpoints
documents were submitted at several stages to full review by the working
group, by the ig [NOTE. WHAT IS THIS? (Cited by Gregg Vanderheiden)], and
then posted for public review. The PAGL group was issued as a W3C
recommendation on [INSERT DATE].
Assumptions Underlying the Judgments
Judgments about impact ("impossible", "very difficult", and "somewhat
difficult") were made under the assumptions that the groups were using
moderately accessible Web content under their own preferred conditions,
except for the violation of the checkpoint being considered.
By the term "moderately accessible content" we mean content that is neither
highly accessible nor completely inaccessible. It is important that this
base level of accessibility not be "completely inaccessible." For if it
were, it would be impossible to judge whether the violation of a single
checkpoint had any additional adverse impact, since it would already be
completely inaccessible. On the other hand if the content were high
accessible, it would currently (1999) be highly atypical and therefore
unrealistic. [NOTE. There are pluses and minuses to assuming highly
accessible content. In previous memos I have advocated an assumption of
highly accessible content. Someone suggested that it was unrealistic to
assume highly accessible content. I am now modifying my position.]
By the term "preferred conditions" we mean using the preferred technologies
and physical setting. For example, for many individuals who are blind, the
preferred conditions might involve a multimedia computer and their own
favorite brands of screen reader, speech, and Web browser technologies
operating in a quiet room. Obviously, if the group being considered is
defined by particular technologies and physical settings (e.g., users of
small handheld devices with monochrome monitors in noisy environments),
then the users' preferences can only modify conditions that are not part of
the group definition. Note that if judgments were made under an assumption
of "least preferred (or worst) conditions," then accessibility might
already be so low that it would be impossible to detect the adverse impact
of the violation of a single checkpoint.
It is important to note that the level of impact of violations is tied not
only to the enduring nature of certain categories of disability (blindness,
deafness, cognitive disabilities, etc.), but also to the more changeable
nature of technologies by which a group's preferred conditions might be
defined. This means that impacts of violations on any given group might
change over time, albeit somewhat slowly.
[NOTE. The foregoing paragraphs attempt to answer the question: "What were
the assumptions underlying the judgments about the impact of violations on
any given group?" I think that it is important to state the assumptions. If
these assumptions are not correct, I would invite correction.]
2.D.MATERIAL FOR POSSIBLE INCLUSION IN THE DEFINITIONS SECTION
I have tried to succinctly define key terms. These definitions might be
included in the definition section. Please excuse the redundancy of some of
this information.
Impact
Impact is the adverse affect of violation of a checkpoint upon a group in
terms of the accessibility of information in a Web document.
Impact Rating
Impacts ratings indicate whether violation of a checkpoint makes accessing
the information in a document "impossible", "very difficult", or "somewhat
difficult" for a given group.
Among the assumptions for assigning these ratings are the following:
Typical Web Document. The group is accessing a "typical" Web document
(page), which may be imagined as a composite of all Web documents from a
variety of purposes (informational, educational, entertainment, commerce).
The document is typical not only in its purpose but also in the relative
frequency of different Web objects [NOTE. IS THIS THE BEST WORD?], such as
graphics, tables, headings, paragraphs, ordered lists, etc., and in the
information content of those objects.
Moderately Accessible Content. The content in the document is "moderately
accessible," meaning that it is neither highly accessible nor completely
inaccessible.
Preferred Conditions. The Web document is accessed under conditions
preferred by that group. Conditions include both technologies and physical
setting. For example, for many individuals who are blind, the preferred
conditions might involve a multimedia computer and their own favorite brand
of screen reader, speech synthesizer, and Web browser operating in a quiet
room. If the group being considered is defined by particular technologies
and physical settings (e.g., users of small handheld devices with
monochrome monitors in noisy environments), then the users' preferences can
only modify conditions that are not part of the group definition.
Violations Are Comprehensive. In rating the impact of a violation of any
given checkpoint, the violation is assumed to occur at all relevant
instances throughout the document.
Information is "Helpful." The ratings assume, unless otherwise stated, that
information being made accessible by adhering to a guideline is "helpful"
for an overall understanding of the document. (This means, for example,
that priority 1 checkpoints must be followed, even though the information
being made accessible is merely "helpful" rather than "important" or
necessary.)
Group
Groups were defined by disability (e.g., blind, deaf) or other attributes
("users of audio-only Web browsers"). The disability groups were as
follows:
blind
low vision not including color deficiencies
color deficiencies
deaf
hard of hearing
deaf-blind
learning disability
physical disability
cognitive disability
emotional disability
tactual disability
photosensitive epilepsy
Other groups not related to disability were also considered, but impact
ratings of these other groups were not considered in generating the
priority ratings.
For the purpose of generating impact ratings, all members of each group
were considered as acting as a single composite entity.
Priority Ratings
Priority ratings (1, 2, and 3) indicate how important it is for Web authors
to adhere to a given checkpoint (e.g., Web authors "must," "should," or
"may" follow the guidelines). Priority ratings are functionally determined
by impact ratings. Only impact ratings for disability groups are considered
in generating the priorities. Specifically, the priority rating for a
checkpoint is determined by the highest (most severe) impact rating for any
of the disability groups. For example, if one or more disability groups
would find it "impossible" to access information in the document given
violation of a certain checkpoint, then the Web author "must" adhere to
that checkpoint. The same logic relates the other two impact ratings ("very
difficult" and "somewhat difficult") and their corresponding priorities
("should" and "may").
Priority ratings 1, 2, and 3 correspond to the "must," "should," and "may"
levels.
=============================
Eric G. Hansen, Ph.D.
Development Scientist
Educational Testing Service
ETS 12-R
Rosedale Road
Princeton, NJ 08541
(W) 609-734-5615
(Fax) 609-734-1090
E-mail: ehansen@ets.org
Received on Tuesday, 12 January 1999 16:33:38 UTC