- From: <ehansen@ets.org>
- Date: Thu, 18 Nov 1999 16:53:55 -0500 (EST)
- To: w3c-wai-ua@w3.org
Issue #44. Document must give greater emphasis to the differential
applicability of the guidelines to various classes of user agent,
especially assistive technologies.
In addition to providing a new issue, this follows up on Issue #1 (re:
Abstract) and Issue #5 (re: "natively").
Readers of the UAAG document need greater clues as to the scope of the
document -- especially, what kinds of user agents to which the document is
most applicable, especially with regard to assistive technologies.
The following revisions also attempt to clarify the relationship between
user agents and assistive technologies.
Old (5 Nov 1999 - Last Call):
"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."
My suggestion from Issue #1 (17 November 1999):
"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."
My current (17 November 1999, 16:05 hrs) suggestion:
"Abstract:"
"This document provides guidelines to user agent developers for making
their products -- browsers, multimedia players, plug-ins, and other
input/output technologies used to access Web content -- are 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 that provide additional
functionalities that are necessary for full access to 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. Not every
guideline or checkpoint is applicable to every kind of user agent. User
agents that are accessible can be more flexible, powerful, and usable for
all users."
--
I suggest the following additional changes in the Priorities and
Conformance sections.
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}
Really new (18 November 1999):
{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"}.
{Note. The foregoing priority levels are unchanged from yesterday.}
Note. The terms "must", "should", and "may" (and related terms) are used in
this document in accordance with RFC 2119 ([RFC2119]).
1.6 Applicability {This section is mostly new.}
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."} Not every checkpoint or
guideline is applicable to every user agent. Generally, a user agent must
adhere to checkpoints that ensure accessibility of functionalities that it
offers to users, but is generally not required to address checkpoints that
address the accessibility of functionalities that it does not provide. This
means that for user agents such as graphical Web browsers which are
general-purpose user agents for accessing the virtually all Web content, a
greater portion of the checkpoints will be applicable. On the other hand,
applications or utilities with a much narrower range of functionality will
tend to have a smaller set of applicable checkpoints. Many of the user
agents that are also classified as "assistive technologies" (which are
specifically designed for people with disabilities), often have a narrow
range of functionality and hence may a smaller set of applicable
checkpoints. See the definition of "Applicable checkpoint" in the appendix
("Terms and Definitions") for greater detail."
{Note. If necessary, this section could bring in more material from "Terms
and Definitions -- Applicable checkpoint" if necessary.}
1.6 Conformance
Developers of user agents may claim any of three levels of conformance to
this document.
{Note that I have newly inserted the word "applicable" into the definition
of each of the conformance levels.}
Conformance Level "A": all applicable Priority 1 checkpoints are satisfied
Conformance Level "Double-A": all applicable Priority 1 and 2 checkpoints
are satisfied
Conformance Level "Triple-A": all applicable Priority 1, 2, and 3
checkpoints are satisfied
Note. Conformance levels are spelled out in text ("Double-A" instead of
"AA") so they may be understood when rendered as speech.
Claims of conformance to this document must use one of the following two
forms.
[etc., etc.]
{End of New}
Issue #45. Some attention needs to be given to additional situations in
which the UA document is not applicable.
I wonder if there are some unexpected implications of the guidelines. For
example, "Web authoring tools" could be considered "user agents". Do the UA
guidelines place any additional burden upon developers of Web authoring
tools?
I have some small concern here about whether the applicability rules are
robust enough to avoid unnecessary burdens on developers of assistive
technologies. Will the UA guidelines require the developers of pwWebSpeak,
a non-graphical [at least the last time I looked] self-voicing Web browser
be required to provide a lot more capabilities for presenting graphical
material. Probably not, but it might be good to ask people who develop
different kinds of assistive technologies (screen readers, special access
devices, etc.) how well they stack up against the UA document and whether
they see the UA guidelines as an unnecessary burden.
Will developers of utilities for individuals who are deaf-blind be required
to interface to multimedia-capable user agents?
Will manufacturers of new handheld Web appliances, especially some that may
be built for individuals with disabilities, be required to provide
capabilities that are burdensome?
Will wheelchair will classified as a user agent if it allows a person to
sit in front of a computer. Are there any checkpoints applicable to
wheelchairs?
These are concerns that may be unfounded. Once you try to have the document
cover every possible case or exception, you may start down a slippery slope
that you might not climb out of.
Yet if we have concerns, then perhaps would should do as the U.S Congress
does: When it passes a law, it often exempts itself (the House and Senate)
from compliance to the law <grin>.
Seriously, if developers of assistive technologies have serious concerns
about this, then perhaps somewhere there needs to be statement like the
following.
"Note. Certain exceptions to the requirements of this document may be
granted to user agents that are specifically targeted at users with
disabilities, especially very low-incidence disabilities."
Another possible exception might be certain educational applications (which
obscure and hide information for instructional and testing purposes).
Probably not necessary to cite as an exception.
Perhaps these concerns are unfounded. Opinions are welcomed.
----
=============================
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 Thursday, 18 November 1999 16:58:43 UTC