Suggestions

Date: 3 December 1998, 14:02 hrs
To: List of the WAIGL-Page Author Working Group
From: Eric Hansen, Development Scientist, Educational
Testing Service (ETS)
Re: Suggestions

I have several suggestions and thoughts regarding the "WAI
Accessibility Guidelines: Page Authoring" (WAIGL-PA 17
November 1998) document. I hope that these suggestions might
assist in the document's timely completion, flexibility for 
future change, and usefulness to its audiences.

The items are labeled Item-1 through Item-21. Most items
contain at least one suggestion.

Item-1. Advancing the Art and Science of Accessible Web
Design

I think that the typical Web developer who wants to make
accessible Web sites wants a prescription for successful,
accessible Web design. If he can't get it all in one place, 
he has to generate it on his own. The working group is
trying to help him by meeting him partway. The working group
will tell him about accessible design, tell him how it will 
also make his site more usable for everyone, and try to cast
the accessibility guidelines in a framework that he can
understand.

Let us assume that the working group has persuaded the
developer to incorporate accessibility considerations into
the his science and art of Web design.

What are the components of design sciences?

(1) Conditions: alternative goals or requirements; 
(2) Methods: possibilities for action; and 
(3) Outcomes: fixed parameters or constraints.

(See Charles Reigeluth [1983, Theories of Instructional
Design] for information on design science. He cites Herbert 
Simon [1969].)

Casting these in their prescriptive form (as opposed to
descriptive), the Web developer accepts as "conditions" that
there are diverse Web users using diverse technologies in
diverse situations. He seeks the "outcomes" (fixed
parameters) of accessibility, usability, and marketability. 
So the question he asks his own design science is: What is
the best method among various "methods" for achieving these 
outcomes? Our job is to show him that his method should
include the WAIGL-PA document(s). Because we know that he
needs help in understanding the normative [W3C-recommended] 
guidelines and seeing how it relates to other guidelines and
considerations, we provide a variety of documents that we
think will be helpful to him. 

The main point of this discussion is that we need to provide
information that will help Web developers select a method
that will be successful in achieving these outcomes.

Item-2. An Automated Tool

Can the WAI or its associates eventually produce an
automated tool based around the guidelines that can help a
Web developer to focus on the most important accessibility
issues and at the most appropriate times? 

It is obviously not fair to expect the working group to
produce such a system on the timelines on which I believe
that it is operating. Yet I think that it is fair to ask
that products of the working group exhibit a level of
organization and consistency that will allow other
components to be linked to them in order for others (if not 
WAI itself) to create such a system or tool.

Item-3. Represent Material to Support Diverse Queries or
Compilations

I think that it is worthwhile to consider how the products
of the working group could support the automated compilation
of documents for diverse purposes and audiences. The
possibility challenges us to look at the working group's
products as a database rather than just documents.

This compilation process might be like the production of
query results by a database system. I am most familiar with 
the relational database model so I tend to think of the
various pieces of data as tables (=relations) that are
linked in orderly way to support the query process. Within
this framework, the working group would develop a database, 
where specific tables or columns within tables would be
normative (W3C recommended) and the rest non-normative.

Item-4. Only the Guideline Statements Should Be Normative 

I suggest that the working group seek W3C approval only for 
the guideline statements (A.1 through B.3.). Everything else
would be non-normative and therefore changed more readily.
(The W3C might require that the title a very brief statement
of purpose and scope also be among the normative portion.)

Item-5. Eliminate the Distinction Between "A" and "B"
Sections

In keeping with the suggestion, the formal "A" or "B"
section designations would no longer be part of the
normative material. Thus, all the guideline statements (A.1 
through B.3.) would be numbered consecutively, 1 through 17.

One motivation for this suggestion is simply the idea that
the "A" and "B" designations constitute a "view"
(presentation) and should be separated from the normative
"content."

The other motivation is simply that all 17 guidelines,
including A.13, A.13, B.1, and B.2, fit reasonably well
under the heading of "transform gracefully across users,
technologies, and situations", which is, arguably, a
reasonable statement of the objective of "universal design."
(In the 17 Nov 1998 WAIGL-PA document, the "transform
gracefully" concept encompasses only A.1 through A.12.)

Item-6. The Characterization of "Transform Gracefully" Is
Incomplete

Some of the material on "transform gracefully" in the
introduction to section "A" is unclear. Specifically,
"Documents that transform gracefully are: (1) Able to be
perceived .. visually.. and entirely through auditory
means..[and] (2) Operable on various types of hardware..."

It is not clear whether these two points are (a) "examples" 
from the universe of things that come under the heading of
"transform gracefully" or (b) they constitute a "definition"
of what it means to "transform gracefully." As I alluded to 
earlier, I think that the two points are valid examples
sampled from the broad universe covered by the concept of
graceful transformation, but, in my opinion, they are an
inadequate definition of the concept.

Item-7. Most Documents Will Mix Normative and Non-normative 
Information

For most users, the most helpful compilation documents would
include both normative (W3C-recommended) material and non-
normative material. 

For the sake of simplicity and stability, the normative
material should be very concise. The non-normative material 
could be vast and may undergo frequent revision. 

Item-8. The WAIGL-PA Represents a Mix of Normative and Non-
normative Components

The current WAIGL-PA document is a mix of both normative and
non-normative components and represents the kind of document
that would be useful to many people. For example, the
guideline statements (i.e., sentences) (A.1 through B.3.)
are at the heart of what is (I believe) normative about this
document. On the other hand, techniques, I believe, have
been considered non-normative. I have seen a suggestion that
the Priority-Levels become non-normative, which makes sense 
since they are derived from information about techniques,
which are non-normative. Thus, the current WAIGL-PA document
might be considered a likeness of a query result or a
compilation of what would be generated by the system that I 
envision.

Item-9. A Quick Analysis Information Attached to the
Guideline Statements of the WAIGL-PA

How hard would it be to automatically compile a document
like the WAIGL-PA document? What are the major pieces of
data that are involved? 

Let us briefly look that the pieces of information that are 
attached to the guideline statements in the current WAIGL-PA
document. Following is a quick, not necessarily exhaustive, 
analysis.

#1. Elaboration. Each guideline statement provides zero or
more statements that elaborate upon (or describe) the
guideline  statement. Examples: Guideline statements A.1 and
A.3 contain such an elaboration and A.2 does not. 

#2. Guideline-scoping. Each guideline statement provides
zero or more guideline-scoping statements. For example,
guideline statement A.10 contains the statement: "This is
particularly important for objects that contain text and
does not apply to instant redirection."

#3. Impact-of-violation. Each guideline statement provides
one or more statements explaining the impact of how failure 
to follow the guideline affects individuals in one or more
groups. This is very important information. (Note. The
taxonomy of affected groups belongs in its own table. The
document should use only groups defined in the taxonomy.
This taxonomy should be non-normative.)

#4. Benefit. Each guideline statement provides zero or more 
benefit statements. (Ideally, these benefit statements might
align perfectly with the impact-of-violation statements,
though they do not in the WAIGL-PA document.)

#5. Techniques-scoping. Each guideline statement provides
zero or more techniques-scoping statements. For example,
under "Techniques" for guideline A.13 we read: "Until most
users are able to secure newer technologies that address
these issues:". A list of techniques is then presented.

#6. Technique. Each guideline statement should, but does not
now, provide one or more numbered techniques. Each technique
might also contain a scoping phrase or statement. (In the
WAIGL-PA document, there is not a techniques label for B.2
and B.3, though I assume that this is an oversight.)
Currently, each technique appears to have at least one
Priority attached. (Some techniques have subparts, each with
a priority.)

#7. "Notes". Zero or more Notes are found among guideline
statements or related parts. The working group should
consider if there should be more consistency regarding where 
notes should be attached as well as their length and
purpose. (Sections designated as "Notes" are scattered
throughout the current WAIGL-PA document. For example, for
statement A.14, I see a couple of levels of Notes but no
techniques. Is this intentional? For guideline A.10, I see
two notes following the techniques.)

#8. "See Also". There is at least one instance of "See also"
(at A.9), which links to a technique of another guideline
statement (A.14.2).

Obviously, explicit labeling of these parts would facilitate
determining their how many of each component is there. 

The more consistent and orderly the structure, the more
readily it can become part of an automated system.

I encourage the working group to examine if the structure of
the document is consistent and orderly enough to be
automatically generated.

Item-10. Inclusion of Exceptions

The working group might want to consider explicit listing of
exceptions to techniques or guidelines. Exceptions sometimes
exist. Example 1: Difficult grammar (not "straightforward"
[B.3.1]) may be an essential part of a Web delivered test of
reading comprehension. Example 2: Sometimes a whole sentence
may need be underlined (for a hyperlink): "Click here for a 
modified text-only version of this page." Ordinarily, only a
key phrase would be underlined, but in this case,
underlining only the key phrase "modified text-only version"
might cause to think that she is on the modified text-only
version rather than on a link to go to the modified text-
only version. This contradicts the general advice against
verbose link descriptions. Example 3: In certain portions of
foreign language instructional materials, one might not want
to follow the guideline to "provide supplemental information
needed to pronounce or interpret ...foreign text" (A.7)
because one wants the student to learn to interpret without 
supplemental information. 

There are three advantages to explicitly noting exceptions.

First, this practice would properly alert the developer for 
the need for wisdom in applying the guidelines. If there are
several exceptions for one technique, for example, then it
might properly alert the developer that the guideline cannot
be followed slavishly.

Second, explicit noting of exceptions might help avoid using
soft or indefinite language in the Technique or guideline
statements themselves. For example, it might help avoid
phrases like "wherever possible" (A.6.4) or "that is
possible" (B.3.1). 

Third, it would help define the scope of the technique or
guideline, thereby reducing the need for indefinite scoping 
language in the technique or guideline itself. By
eliminating wiggle room and uncertainty from the technique
and guideline statement, priority ratings assigned to the
techniques can be more reliable.

Item-11. Advantages of Automatic Compilation of Documents
Representing Diverse Views and Perspectives

There are several advantages of being able to automatically 
generate documents based on different views or perspectives.
These documents would draw upon both normative guideline
statements and other non-normative material.

#1. Quicker, more accurate generation of diverse guideline-
related products.
#2. Better evaluation of different views or models. Since
each view is a different parsing of the accessibility
universe, being able to quickly generate different view will
facilitate comparison and evaluation of different views.
#3. Better modeling of reality. In reality, there are many
ways to look at the same data.

Item-12. Some Different Perspectives and Views

Following are some different perspectives, views, or guiding
principles, along with key accessibility topics that would
be emphasized by them. (Obviously, the language and phrasing
are very rough.)

Cognitive and Sensory Perspectives
#1. Enable all essential information to be output
auditorially (speech), visually (large print), and through
tactile media (braille). Key topic: Alternative
representations, importance of textual representations; any 
of the statements A.1 through A.12. [Note. This is similar
to the statement regarding the "A" heading: "Able to be
perceived entirely visually and entirely through auditory
means", but includes "tactile" means, which are especially
essential for individuals who are both deaf and blind.]
#2. Minimize sensory load. Key topic: Proper color palette. 
Blinking, flashing, avoiding patterned backgrounds, minimize
visual strain, etc.
#3. Minimize memory load. Key topics: Positioning and
sequencing, chunking, minimize visual strain.
#4. Minimize language processing load. Key topics:
vocabulary, sentence complexity, meaningful headings and
labels. 
#5. Enable quick finding. Key topics: Search and navigation,
meaningful labels, headings, link names.
#6. Provide user control. Key topics: Search and navigation,
timing, repeating, freezing motion, feedback from actions
taken, etc.
#7. Minimize distraction. Key topics: Motion, animation,
freezing motion, speech and nonspeech noise, interruptions, 
prompts, avoiding patterned backgrounds.
#8. Make consistent use of interface elements. Key topics:
Consistent use of color, screen layout, labeling, etc.

Technological Perspectives.
#9. Enable use by diverse technologies. Key topics: Old
browsers, handheld devices, slow modems, voice input and
output, diverse platforms and color palettes (Mac vs. PC,
etc.).
#10. Ensure effective use by helper technologies. Key
topics: Tagging for optimal use by automatic translation
devices, indexing robots, search engines, etc.
#11. Ensure compatibility with assistive technologies.

Use Environment Perspectives.
#12. Ensure operability in constrained environments. Key
topics: Provisions for hands-free, noise-free, non-visual
environments.

Social, Emotional, Ethical Perspectives
#13. Demonstrate sensitivity and fairness to cultural
differences. Key topics: Use of language, pictures, sounds, 
community standards, etc.
#14. Avoiding inducing anxiety. Key topics: Blinking,
flashing, lack of control over timing, sensitive and
controversial topic areas.

Cost Perspectives
#15. Plan resource allocation. Key topics: Balancing
redesign of new material versus retrofitting of old
material, obtaining knowledge of the costs associated with
alternative media.

Product Development Process Perspective
#16. Plan implementing guidelines at the optimal points in
the Web development process. Key topic: The most cost-
effective points in the development process at which to
include accessibility related steps.

Information Management Perspective
#17. Organize information for further automation. Key topic:
Preparation for use of databases, XML, etc.

Evaluation of Design Alternatives Perspectives
#18. Evaluate alternative ways of developing and maintaining
accessible Web-based products and services. Key topics:
Evaluation of cost and benefits of various approaches.

Globalization/Localization Perspectives
#19. Develop a balanced strategy for making Web-based
products and services accessible internationally. Key
topics: Legal, language, culture, and sensitivity issues.

Evaluation of Accessibility Perspective
#20. Develop a strategy for monitoring progress in attaining
accessible Web-based products and services. Key topics:
Automatic accessibility verifiers, usability testing, etc.

Marketing Perspective
#21. Demonstrate the improvements in marketability of Web-
based products and services that will come from adhering to 
specific guidelines. Key topic: Return on investment in
accessibility/usability improvements.

To summarize, there are many perspectives from which the
guideline-statements can be viewed and analyzed. As
indicated earlier, these views would be non-normative. 

Item-13. Orientation to "Products and Services"
I suggest considering orienting the guidelines around the
concept of improving the accessibility of "Web-based
products and services" (rather than of "pages" or "sites"). 
Isn't it the services and products that need to be
accessible? Who knows how relevant the term "page" will be
in a few years? The term "Web site" seems all the more
problematic. I have not thoroughly examined the implications
of a wholesale change. Perhaps even a partial shift in that 
direction would be helpful. (See my revised Abstract for the
WAIGL-PA document.)
Item-14. Make Guidelines One Sentence Long

I recommend that all guidelines be one sentence long.
Guideline A.14 is currently two sentences long and reads:
"Wherever possible use a W3C technology in accordance with
guidelines on its proper use. Where this is either not
possible, or results in material that does not transform
gracefully you must provide an alternative version of the
content that is accessible." I suggest reducing it to one
sentence or splitting it into two guidelines. All other
guidelines are one sentence long.

Perhaps they should be split in two.

#1. "Use W3C technology in accordance with guidelines on its
proper use." (Eliminated gratuitous "Wherever possible",
since no guideline should be used where not possible.)

#2. "When material that does not transform gracefully, then 
provide an alternative version of the content that is
accessible." (Eliminated the word "must," since that idea
should be conveyed by the non-normative priority level. By
the way, I wonder if this guideline even belong here since
it is so generic. It seems to be an overarching principle
regarding alternative content rather than a specific
guideline. I suggest considering the elimination of this
guideline.)

Item-15. Refine the Abstract

Following is a partial rewrite of the first paragraph of the
Abstract of the WAIGL-PA.

"This document is a list of guidelines that developers of
Web-based products and services should follow in order to
make their pages more accessible to people with disabilities
and more usable by both disabled and nondisabled people
operating in variety situations and using a variety of
technologies. For example, following these guidelines is
expected to improve usability by people (a) who use new page
viewing technologies (mobile and voice), (b) who rely
heavily on search technologies, (c) who use older browser or
modem technologies, (d) who are unfamiliar with the language
of the content, or (e) who are operating in hand-free,
noise-free, or sight-free environments.

"This document focuses primarily on issues that can be
influenced through markup of the Web content. 

"This document does not constitute a complete guide to Web
design. It does not necessarily address all valuable
principle of visual design, although it is expected that
these guidelines are generally compatible with and
supportive of good visual design. Nor does the document
specifically address several other issues, such as economic,
legal, and cultural issues that can also influence the
accessibility and usability of Web pages."

Item-16. Why Refer to Issues Not Addressed?

Why refer to issues that are not addressed (economic, legal,
cultural, etc.)? It seems only fair to warn people that this
is not a complete guide to Web design.
Furthermore, other accessibility guidelines wisely
acknowledge these other factors.
The "Center for Universal Design" at North Carolina State
University states the following: 
"Please note that the Principles of Universal Design address
only universally usable design, while the practice of design
involves more than consideration for usability. Designers
must also incorporate other considerations such as economic,
engineering, cultural, gender, and environmental concerns in
their design processes. These Principles offer designers
guidance to better integrate features that meet the needs of
as many users as possible." (Authors in alphabetical order: 
Bettye Rose Connell, Mike Jones, Ron Mace, Jim Mueller, Abir
Mullick, Elaine Ostroff, Jon Sanford, Ed Steinfeld, Molly
Story, and Gregg Vanderheiden)
(http://www.design.ncsu.edu/cud/pubs/udprinciples.html)

Crystal Waters in her book "Universal Web Design" says,
"This book aims to show you how to find a balance among
elements that takes advantage of the technology, serves your
viewers, and doesn't sacrifice design quality" (p. 8). 

Item-17. Priority-Levels

The priority levels are important. The current levels
generally seem reasonable. I agree that Web developers need 
models for how to adjust project-specific priorities based
on the developer's circumstances. I think that priorities
should remain non-normative.

Item-18. Some Thoughts on the Name of the WAIGL-PA Document

I think that the current name is OK, though as noted
elsewhere in this document the use of the term "page" seems 
a bit archaic.

I am against using the term "universal design" in the title.
"Universal design" -- i.e., usability by everyone everywhere
-- is a great design objective, but it suggests a note of
impracticality and also, in the minds of some, the phrase
may carry other meanings that we might not want associated
with the guidelines. Besides, the document does not deserve 
the title because no where does it acknowledge the wide
range of considerations that should go into the design of
accessible and cost-effective Web-based products and
services.
Item-19. Should B.3 and A.7 Be Combined in Some Way?

I wonder if B.3 and A.7, both of which related to language, 
be combined in some way?

Item-20. "[P]ronounce or interpret ... foreign text"

Should A.7 be revised to change the word "foreign" to
"unfamiliar"?

Item-21. Absence of Tactile Communication

The introductory material for section "A" seems to neglect
tactile communication. Web material should be "Able to be
perceived entirely visually and entirely through auditory
means", but does not refer to "tactile" means, which are
especially essential for individuals who are both deaf and
blind.

Received on Thursday, 3 December 1998 14:05:54 UTC