W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 1999

Responses and Revisions -- Part 2

From: eric hansen <ehansen@ets.org>
Date: Tue, 12 Jan 1999 12:51:43 -0500 (EST)
To: w3c-wai-gl@w3.org
Message-id: <vines.yRv7+AksaqD@cips06.ets.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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:46:59 GMT