- From: <ehansen@ets.org>
- Date: Wed, 17 Nov 1999 17:13:11 -0500 (EST)
- To: w3c-wai-ua@w3.org
Following are issues in the 5 November 1999 (Last Call) version of the UAGL
document, not necessarily in order of criticality.
Some of the changes are marked in ALLCAPS for emphasis.
Issue #1: Fix the Abstract.
The abstract needs to reinforce the idea that "assistive technologies" used
by Web browsers _are_ user agents. The old version (5 November 1999) makes
these assistive technologies sound like they are not user agents. This
confusion also shows up in the glossary. (The definition of "user agent"
treats "assistive technology" as a contrast to user agents _as well as_ a
class of user agent. This also needs to be corrected.)
Old:
"Abstract:"
"This document provides guidelines to user agent developers for making
their products -- browsers, multimedia players, plugins -- accessible to
people with disabilities. An accessible user agent allows users with
disabilities to retrieve and view Web content or to enable access when used
in conjunction with other software or hardware, called assistive
technologies. These guidelines discuss the accessibility of the user agent
as well as how the user agent communicates with assistive technologies such
as screen readers, screen magnifiers, braille displays, and voice input
software."
New:
"Abstract:"
"This document provides guidelines to user agent developers for making
their products -- browsers, multimedia players, and related assistive
technologies -- accessible to people with disabilities. Developers must
ensure: (1) that the functionalities offered by the user agent are
accessible, and (2) that the user agent works well with other user agents
-- especially assistive technologies -- that are necessary to access
diverse Web content. For example, the developer of a graphical desktop Web
browser will ensure that its functionalities are accessible by keyboard,
since many people who are blind or have other disabilities require it. The
developer will also use standard ways of interfacing the browser with other
user agents, such as movie and audio players, and assistive technologies
such as screen readers, screen magnifiers, braille displays, and voice
input software. This document establishes criteria for three levels of user
agent accessibility ("A", "Double-A", or "Triple-A"). User agents that are
accessible can be more flexible, powerful, and usable for all users."
----
Issue #2. Fix the definition of "applicable checkpoint".
The definition of "applicable checkpoint" has at least one significant
problem and a few minor problems. The significant problem is that the
definition does not handle cases in which the user agent does not
"recognize" certain content at all. I have fixed this in the revised
version.
Old:
{beginning of Old:}
Applicable checkpoint
If a user agent offers a functionality, it must ensure that all users have
access to that functionality or an equivalent alternative. Thus, if the
user agent supports keyboard input, it must support accessible keyboard
input. If the user agent supports images, it must ensure access to each
image or an alternative equivalent supplied by the author. If a user agent
supports style sheets, it must implement the accessibility features of the
style sheet language. If the user agent supports frames, it must ensure
access to frame alternatives supplied by the author.
Not all user agents support every content type, markup language feature,
input or output device interface, etc. When a content type, feature, or
device interface is not supported, checkpoints with requirements related to
it do not apply to the user agent. Thus, if a user agent supports style
sheets at all, all checkpoints related to style sheet accessibility apply.
If a user agent does not support style sheets at all, the checkpoints do
not apply.
The applicability of checkpoints related to markup language features is
measured similarly. If a user agent supports tables, it must support the
accessibility features of the language related to tables (or images, or
frames, or video, or links, etc.). The Techniques Document includes
information about the accessibility features of W3C languages such as HTML,
CSS, and SMIL.
The following summarizes criteria for applicability. A checkpoint applies
to a user agent unless:
The checkpoint definition states explicitly that it only applies to a
different class of user agent.
The checkpoint includes requirements about a content type (script, image,
video, sound, applets, etc.) that the user agent does not recognize at all.
The checkpoint includes requirements about a content type that the user
agent recognizes but does not support natively.
The checkpoint refers to the properties of an embedded object (e.g., video
or animation rate) that may not be controlled or accessed by the user
agent.
The checkpoint includes requirements about an unsupported markup language
or other technology (e.g., style sheets, mathematical markup language,
synchronized multimedia, metadata description language, etc.)
The checkpoint refers to an unsupported input or output device interface.
Note that if the interface is supported at all, it must be supported
accessibly." {end of Old}
New:
{beginning of New:}
Applicable checkpoint
If a user agent offers a functionality, it must ensure that PEOPLE WITH
DISABILITIES have access to that functionality or an equivalent
alternative. Thus, if the user agent supports keyboard input, it must
support accessible keyboard input. If the user agent supports images, it
must ensure access to each image or an alternative equivalent supplied by
the author. If a user agent supports style sheets, it must implement the
accessibility features of the style sheet language. If the user agent
supports frames, it must ensure access to frame alternatives supplied by
the author.
Not all user agents support every content type, markup language feature,
input or output device interface, etc. When a content type, feature, or
device interface is not supported, checkpoints with requirements related to
it do not apply to the user agent. Thus, if a user agent supports style
sheets at all, all checkpoints related to style sheet accessibility apply.
If a user agent does not support style sheets at all, the checkpoints do
not apply.
The applicability of checkpoints related to markup language features is
DETERMINED similarly. If a user agent supports tables, it must support the
accessibility features of the language related to tables (or images, or
frames, or video, or links, etc.). The Techniques Document includes
information about the accessibility features of W3C languages such as HTML,
CSS, and SMIL.
The following summarizes criteria for applicability. A checkpoint applies
to a user agent unless: {NOTE NEW ORDER OF THE BULLET ITEMS}
(bullet) The checkpoint refers SOLELY {not sure if this is essential, may
be OK as is} to an unsupported input or output device interface. Note that
if the interface is supported at all, it must be supported accessibly.
(bullet) The checkpoint definition states explicitly that it only applies
to a different class of user agent.
[Old - Deleted: (bullet) "The checkpoint includes requirements about a
content type (script, image, video, sound, applets, etc.) that the user
agent does not recognize at all."]
(bullet) {NEW}: "The checkpoint includes requirements about a content type
(script, image, video, sound, applets, etc.) that the user agent EITHER
DOES NOT RECOGNIZE OR recognizes but does not support natively." {This is a
combination of bullet points.}
(bullet) The checkpoint refers to the properties of an embedded object
(e.g., video or animation rate) that may not be controlled or accessed by
the user agent.
(bullet) The checkpoint includes requirements about an unsupported markup
language or other technology (e.g., style sheets, mathematical markup
language, synchronized multimedia, metadata description language, etc.)
{end of New}
----
Issue #3. Form 2 for conformance claims lacks list.
I am not sure why the "list of checkpoints that have been satisfied and
which are considered not applicable" is required only for Form 1. Shouldn't
it be required for both? Maybe there is a good reason why it is the way it
is and I just don't know it. For some user agents, I think that these lists
are extremely important.
----
Issue #4. Form 2 for conformance requires rewording.
Old:
"Form 2: For product packaging or documentation, provide one of three icons
provided by W3C; for Web documentation, link the icon to the appropriate
W3C explanation of the claim."
New:
"Form 2: Provide Include, on product packaging or documentation, one of
three icons provided by W3C and for Web documentation, link the icon to the
appropriate W3C explanation of the claim."
----
Issue #5. Fix the problems with the terms "native" and "natively".
In the introduction to "Priorities" and "Conformance", the use of the term
"native" (and its variations) is extremely confusing.
Please note that the sentence about satisfying requirements "natively"
("User agents must satisfy natively all the applicable checkpoints for a
chosen conformance level.") is redundant with the provision in the
definition of "applicable checkpoints" ((bullet) {NEW}: "The checkpoint
includes requirements about a content type (script, image, video, sound,
applets, etc.) that the user agent EITHER DOES NOT RECOGNIZE OR recognizes
but does not support natively.").
The redundancy becomes more significant when we find reference to "native
feature" in the definition of the three priorities.
There is only one problem and it needs only one solution -- not two or
three solutions. It is a matter of logical consistency.
I recommend a solution with the following steps.
a. Clarify the fact that all user agents only have one set of criteria: (1)
A user agent must provide its own functionality accessibly and (2) A user
agent must work well with other user agents. (This is handled in an earlier
issue in this document. That is, it is fixed at least in the Abstract. The
rest of the UAAG document should be checked for consistency.)
b. Eliminate the current reference to "native" in the definition of the
priority levels. The word is not necessary and it causes confusion. See
below, this issue.
c. Eliminate the reference to "natively" in the conformance section ("User
agents must satisfy natively all the applicable checkpoints for a chosen
conformance level."). See below, this issue.
d. Refer to "user agent" singular as opposed to "user agents" plural, i.e.,
"be satisfied by a user agent". This is important because any conformance
claim pertains to a single user agent rather to the other user agents with
which it interacts. I think that this is very important for reinforcing the
definition of user agents.
Old:
{beginning of Old:}
1.5 Priorities
Each checkpoint in this document is assigned a priority that indicates its
importance for users.
[Priority 1]
This checkpoint must be satisfied by user agents as a native feature,
otherwise one or more groups of users with disabilities will find it
impossible to access information. Satisfying this checkpoint is a basic
requirement for some individuals to be able to use the Web.
[Priority 2]
This checkpoint should be satisfied by user agents as a native feature,
otherwise one or more groups of users will find it difficult to access
information. Satisfying this checkpoint will remove significant barriers to
accessing Web documents.
[Priority 3]
This checkpoint may be satisfied by user agents as a native feature to make
it easier for one or more groups of users to access information. Satisfying
this checkpoint will improve access to the Web for some individuals.
1.6 Conformance
The terms "must", "should", and "may" (and related terms) are used in this
document in accordance with RFC 2119 ([RFC2119]).
User agents must satisfy natively all the applicable checkpoints for a
chosen conformance level.
{End of Old}
New:
{beginning of New:}
1.5 Priorities
Each checkpoint in this document is assigned a priority that indicates its
importance for users WITH DISABILITIES.
[Priority 1]
This checkpoint must be satisfied by a user agent; otherwise one or more
groups of users with disabilities will find it impossible to access
information. Satisfying this checkpoint is a basic Web access {or
"accessibility"} requirement.
[Priority 2]
This checkpoint should be satisfied by a user agent; otherwise one or more
groups of users with disabilities will find it difficult to access
information. Satisfying this checkpoint will remove significant Web access
{or "accessibility"} barriers.
[Priority 3]
This checkpoint may be satisfied by a user agent; otherwise one or more
groups with disabilities will find it somewhat difficult to access
information. Satisfying this checkpoint will improve Web access {or
"accessibility"}.
1.6 Conformance
The terms "must", "should", and "may" (and related terms) are used in this
document in accordance with RFC 2119 ([RFC2119]).
User agents must satisfy all the _applicable checkpoints_ {extend link to
include "checkpoints"} for a chosen conformance level. {NOTE. I DELETED THE
WORD "NATIVELY". REMEMBER, IT IS NOT NEEDED BECAUSE IT IS ALREADY PART OF
THE DEFINITION OF "APPLICABLE CHECKPOINT."}
{End of New}
Notes on Changes:
The above changes also address problems with punctuation and consistency of
structure in the definitions. The revised version is also more brief and
probably easier to understand.
----
Issue #6: Checkpoints 10.1, 10.2, and 10.3 need restructuring and revision.
I still a bit puzzled over 10.1, 10.2, and 10.3. I probably don't have
enough information. I think that someone who understands what was intended
ought to take a look at this and try to restructure it.
My initial reaction was that the importance of displaying the current user
input configuration should be the same as the importance for allowing it to
be changed. There would seem to be no point in displaying the configuration
unless you can modify it.
Checkpoint 10.3 seems to tack on the idea of a single-stroke activation of
changes in input configuration. I have made it a separate checkpoint. I
feel that the _requirement_ for single-stroke changing of configuration is
too restrictive. I prefer to _require_ "quick and direct user control" and
_suggest_ "single stroke" as a method.
My final reaction is partial puzzlement. I am not sure, for example, why
and how failure to provide information about user-specified input
configuration will make access "impossible" (Priority 1). I am also not
sure why and how providing information about user-specified input
configuration can be more important (Priority 1) than allowing users to
modify it (Priority 2). It doesn't seem logical. I think that this one
needs to be revised and sent back to the list. Please see if any of my new
versions help.
Old:
"10.1 Provide information about the current user-specified input
configuration (e.g., keyboard or voice bindings specified through the user
agent's user interface). [Priority 1]"
"Techniques for checkpoint 10.1"
"10.2 Provide information about the current author-specified input
configuration (e.g., keyboard bindings specified in content such as by
"accesskey" in [HTML40]). [Priority 2]"
"Techniques for checkpoint 10.2"
"10.3 Allow the user to change and control the input configuration. Users
should be able to activate a functionality with a single-stroke (e.g.,
single-key, single voice command, etc.). [Priority 2]"
"Users should not be required to activate functionalities by navigating
through the graphical user interface (e.g., by moving a mouse to activate a
button or by pressing the "down arrow" key repeatedly in order to reach the
desired activation mechanism. Input configurations should allow quick and
direct access that does not rely on graphical output. For self-voicing
browsers, allow the user to modify what voice commands activate
functionalities. Similarly, allow the user to modify the graphical user
interface for quick access to commonly used functionalities (e.g., through
buttons)."
"Techniques for checkpoint 10.3"
New - Alternative 1:
"10.1 Provide information about the current user-specified input
configuration (e.g., keyboard or voice bindings specified through the user
agent's user interface). [Priority 1]"
"Techniques for checkpoint 10.1"
"10.2 Provide information about the current author-specified input
configuration (e.g., keyboard bindings specified in content such as by
"accesskey" in HTML 4.0 [HTML40]). [Priority 2]"
"Techniques for checkpoint 10.2"
"10.3-New. Allow the user to change and control the input configuration.
[Priority 2]"
"Note. This entails providing information about at least three input
configurations (current user-specified, author-specified, and default {is
this reference to "default" correct? At least the first two seem
appropriate})."
"Techniques for checkpoint 10.3"
"10.4-New. Provide quick and direct user control of input configuration,
such as through a single stroke (single key or single voice command)
[Priority 2]"
"Avoid having users make multiple strokes to activate a single
functionality. Users should not be required to activate functionalities by
navigating through the graphical user interface (e.g., by moving a mouse to
activate a button or by pressing the "down arrow" key repeatedly in order
to reach the desired activation mechanism. Input configurations should
allow quick and direct access that does not rely on graphical output. For
self-voicing browsers, allow the user to modify what voice commands
activate functionalities. Similarly, allow the user to modify the graphical
user interface for quick access to commonly used functionalities (e.g.,
through buttons)."
"Techniques for checkpoint 10.4"
New - Alternative 2:
{Delete: "10.1 Provide information about the current user-specified input
configuration (e.g., keyboard or voice bindings specified through the user
agent's user interface). [Priority 1]"
"Techniques for checkpoint 10.1"}
{Delete: "10.2 Provide information about the current author-specified input
configuration (e.g., keyboard bindings specified in content such as by
"accesskey" in HTML 4.0 [HTML40]). [Priority 2]"
"Techniques for checkpoint 10.2"}
"10.1-NewAlt2. Allow the user to change and control the input
configuration. [Priority 2]"
"Note. This entails providing information about at least three input
configurations (current user-specified, author-specified, and default {is
this reference to "default" correct? At least the first two seem
appropriate})."
"Techniques for checkpoint 10.1"
"10.2-NewAlt2. Provide quick and direct user control of input configuration,
such as through a single stroke (single key or single voice command)
[Priority 2]"
"Avoid having users make multiple strokes to activate a single
functionality. Users should not be required to activate functionalities by
navigating through the graphical user interface (e.g., by moving a mouse to
activate a button or by pressing the "down arrow" key repeatedly in order
to reach the desired activation mechanism. Input configurations should
allow quick and direct access that does not rely on graphical output. For
self-voicing browsers, allow the user to modify what voice commands
activate functionalities. Similarly, allow the user to modify the graphical
user interface for quick access to commonly used functionalities (e.g.,
through buttons)."
"Techniques for checkpoint 10.4"
----
Issue #7. Break checkpoint 6.1 into two separate checkpoints - 6.1.A and
6.1.B.
The first would deal with adherence to WAI specs (WCAG and ATAG) and the
second would deal with non-WAI W3C specs. See below for details.
----
Issue #8. Checkpoint 6.1.A. should have "Relative Priority".
I think that to fail to use relative priority would be too much of a
broadbrush approach and places an unnecessary burden upon the developer.
Furthermore, by breaking out the WAI specs into its own checkpoint, the use
of relative priority is much more understandable and limited in scope. _If_
we feel that a WCAG checkpoint priority should be higher or lower when
implemented in UAAG, then we should just add a specific checkpoints to say
so. That would not be an insult to the other guidelines to do so.
It is tempting to modify the phrasing to say "Implement the _applicable_
accessibility featuresþ."but that meaning may be implicit. To add the word
_applicable_ would, I think, require adding the phrase "applicable
accessibility features" to the glossary.
Old: N/A
New: "6.1.A. Implement the accessibility features of the specifications of
Web Accessibility Initiative (WAI) of the W3C (Web Content Accessibility
Guidelines [WCAG], Authoring Tool Accessibility Guidelines [ATAG])"
[Relative Priority]"
"Note 1. "Relative priority" means, for example, that a Priority 1 to a
WCAG accessibility feature is Priority 1 for this document, that a Priority
2 WCAG accessibility feature is Priority 2, and that a Priority 3 WCAG
accessibility feature is Priority 3. Any exception to relative priority
will be specifically noted in this document. " {I don't think that there
are currently any major exceptions.}
----
Issue #9. Checkpoint 6.1.B should be modified to refer to "non-WAI W3C
specifications"
It should keep the same priority level (Priority 1). The words "e.g.,"
shows that this is not a complete list. Retain the Priority 1 rating.
Old: "6.1. Implement the accessibility features of supported specifications
(markup language, style sheet languages, meta data languages, graphics
formats)." [Priority 1]
New: "6.1.B. Implement the accessibility features of supported non-WAI W3C
specifications (e.g., markup language, style sheet languages, meta data
languages, graphics formats)." [Priority 1]
----
Issue #10. Checkpoint 6.2 should refer to refer to "non-WAI W3C"
specifications.
This change is made to account for the fact that WAI specs such as WGAG and
ATAG are already addressed in checkpoint 6.1.A. I suppose that one could
possibly retain the old wording, but then it would seem to contradict
checkpoint 6.1.A. Retain the Priority 2 rating.
Old: "6.2. Conform to W3C specifications when they are appropriate for a
task. [Priority 2]"
New 1: "6.2. Conform to non-WAI W3C specifications when they are
appropriate for a task. [Priority 2]"
New 2 (alternative): "6.2. Conform to W3C specifications when they are
appropriate for a task. [Priority 2]"
"Note. Conformance to all applicable WAI specifications (e.g., WCAG and
ATAG {spell out} is already required per checkpoint 6.1.A."
----
Issue #11. Change "closed captions" to "captions" throughout the document.
This change will bring the document into line with the WCAG and ATAG
documents. The term "closed captions" seems far too narrow and is likely to
confuse many people.
----
Issue #12. Fix the expanded guideline statement for guideline 2.
Guideline 2 has several problems.
a. The term "descriptions of images" may seem to refer to "long
descriptions" instead of alt-text.
b. The term "closed captions for video or audio" is misleading and
erroneous. First, the term "closed" should not be used (see elsewhere in
this document). Second, the terms "video or audio" are extremely confusing
because a caption is a text equivalent of an auditory track that is
synchronized with the visual (and auditory track) of a multimedia
presentation, but reference to "video or audio" jumbles everything up.
I think that the phrase "e.g., text equivalents and prerecorded auditory
descriptions (if applicable)" covers everything that is required by WCAG.
Someone please correct me if I am wrong on this.
Old:
"Ensure that users have access to all content, notably author-supplied
alternative equivalents for content (descriptions of images, closed
captions for video or audio, etc.)"
New:
"Ensure that users have access to all content, notably author-supplied
alternative equivalents for content, e.g., text equivalents and prerecorded
auditory descriptions."
----
Issue #13. Delete reference to "braille" in the definition of natural
language and in the main body.
Is braille accepted as a natural language? If so, then I am surprised. You
could, I think, express many different natural language (English, French,
etc.) in braille. How many "lang" attributes can apply to the same text
(two might be "English" and "braille")? I would recommend checking this
definition with a linguist. Regardless of what linguists say, was this the
intent of the "lang" attribute? I am sorry if I missed this in WCAG 1.0
because the problem is also there.
Old definition of "Natural Language":
"Spoken, written, or signed human languages such as French, Japanese,
American Sign Language, and braille. The natural language of content may be
indicated in markup (e.g., by the "lang" attribute in HTML ([HTML40],
section 8.1) or by HTTP headers."
New definition of "Natural Language":
"Spoken, written, or signed human languages such as French, Japanese, and
American Sign Language. The natural language of content may be indicated in
markup (e.g., by the "lang" attribute in HTML ([HTML40], section 8.1) or by
HTTP headers."
----
Issue #14. Fix definition of "assistive technology".
Following is my attempt to clarify the definition. Note that there are
several wording changes in the text.
Old:
"Assistive Technology"
"Software or hardware that has been specifically designed to assist people
with disabilities in carrying out daily activities. Assistive technology
includes wheelchairs, reading machines, devices for grasping, alternative
computer keyboards or pointing devices, etc. In the area of Web
Accessibility, common software-based assistive technologies include
assistive technologies, which rely on other user agents for input and/or
output. These include: "
"(bullet) screen magnifiers, which are used by people with visual
impairment to enlarge and change colors on the screen to improve
readability of text and images."
"(bullet) screen readers, which are used by people who are blind or with
reading disabilities to read textual information through speech or braille
displays."
"(bullet) alternative keyboards, which are used by people with movement
impairments to simulate the keyboard."
"(bullet) alternative pointing devices, which are used by people with
movement impairments to simulate mouse pointing and button activations."
New:
"Assistive Technology"
"In the context of this document, an assistive technology is a user agent
that relies on one or more other user agents to help people with
disabilities interact with a computer. For example, screen reader software
is an assistive technology because it relies on Web browsers or other
application software to assist people who have disabilities (especially
visual and learning disabilities) in interacting with the computer. (More
generally, an assistive technology consists of software or hardware that
has been specifically designed to assist people with disabilities in
carrying out daily activities, e.g., wheelchairs, reading machines, devices
for grasping, alternative computer keyboards or pointing devices, etc.)
Examples of assistive technologies that are important in the context of
this document include the following."
"(bullet) screen magnifiers, which are used by people with visual
disabilities to enlarge and change colors on the screen to improve the
visual readability of text and images."
"(bullet) screen readers, which are used by people who are blind or have
reading disabilities to read textual information through synthesized speech
or braille displays."
"(bullet) alternative keyboards, which are used by people with certain
physical disabilities to simulate the keyboard."
"(bullet) alternative pointing devices, which are used by people with
certain physical disabilities to simulate mouse pointing and button
activations."
----
Issue #15. Fix 1st paragraph of rationale for guideline 2.
Old:
"Users may not be able to perceive primary content due to a disability or a
technological limitation or configuration (e.g., browser configured not to
display images). Markup languages may provide a number of mechanisms for
specifying alternative representations of content: through attribute values,
element content, or as separate resources. User agents must also take into
account markup related to natural language rendering, using appropriate
fonts, text directionality, and synthesized speech elements."
New:
"User agents must be able to render content in a range of modes {or
modalities} -- auditory (synthesized and prerecorded), tactile (braille),
visual, or in mixed mode -- that are required by individuals with
disabilities. This high level of accessibility also requires that Web
content developers provide alternative equivalents. (Refer to the Web
Content Accessibility Guidelines [WAI-WEBCONTENT] for greater detail.)"
Notes regarding changes:
The meaning of the following sentence in paragraph 1 of guideline 2 is
unclear: "User agents must also take into account markup related to natural
language rendering, using appropriate fonts, text directionality, and
synthesized speech elements." The phrases "take into account markup related
to natural language renderingþ.and synthesized speech elements" are
especially confusing. It is not clear what markup is NOT related to natural
language rendering. Furthermore, virtually all text elements -- whether
"primary" or alternative content -- are related to synthesized speech. It
is not clear what a "synthesized speech element" is.
Note that if this recommended change is accepted, a later instance of
"natural language" in UAAG will be the first occurrence and should have a
hyperlink to the glossary.
----
=============================
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 Wednesday, 17 November 1999 17:37:51 UTC