w3c-wai-ua@w3.org
Edits to 21 October 2000 Draft
Ian,
Here are some edits.
The Scope section seems to hit the highlights, but has some deep issues as
noted below.
- Eric
====
1. Fix typo.
Remove comma after "user agent design".
Old:
This introduction (section 1) provides context for understanding the
guidelines listed in section 2. Section 1 explains some benefits of
accessible user agent design, and identifies some of the criteria that were
used to establish the scope of requirements for conforming user agents.
Section 3 explains how to make claims that software conforms to these
guidelines and details about the applicability of the requirements for
different kinds of user agents.
====
2. Correct typo in API definition.
By the way, I think that this consolidation and expansion of API information
is an important contribution.
New:
Application Programming Interface (API), standard input/output/device API
An application programming interface (API) defines how communication may
take place between applications.
As part of encouraging interoperability, this document recommends using
standard APIs where possible, although this document does not define in all
cases how those APIs are standardized (i.e., whether they are defined by
specifications such as W3C Recommendations, defined by an operating system
vendor, de facto<<**Delete: "r"** Also mark as French?**>> standards, etc.).
Implementing APIs that are independent of a particular operating system
(e.g., the W3C DOM Level 2 specifications) may reduce implementation costs
for multi-platform user agents and promote the development of multi-platform
assistive technologies. Implementing standard APIs defined for a particular
operating system may reduce implementation costs for assistive technology
developers who wish to interoperate with more than one piece of software
running on that operating system.
A "device API" defines how communication may take place with an input or
output device such as a keyboard, mouse, video card, etc. A "standard device
API" is one that is considered standard for that particular device on a
given operating or windowing system.
In this document, an "input/output API" defines how applications or devices
communicate with a user agent. As used in this document, input and output
APIs include, but are not limited to, device APIs (and in general, they
define a more abstract communication interface than device APIs). A
"standard input/output API" is one that is expected to be implemented by
software running on a particular operating system. Standard input/output
APIs may vary from system to system. For example, on desktop computers
today, the standard input APIs are for the mouse and keyboard. For touch
screen devices or mobile devices, standard input APIs may include stylus,
buttons, voice, etc. The graphical display and sound card are considered
standard ouput devices for a graphical desktop computer environment, and
each has a standard API.
====
3. Fix definition of Equivalent.
New:
Equivalent (for content)
In the context of this document, an equivalency relationship between two
pieces of content means that one piece -- the "equivalent" -- is able to
serve essentially the same function for a person with a disability (at least
insofar as is feasible, given the nature of the disability and the state of
technology) as the other piece -- the "equivalency target" -- does for a
person without any disability. For example, the text "The Full Moon" might
convey the same information as an image of a full moon when presented to
users. If the image is part of a link and understanding the image is crucial
to guessing the link target, then the equivalent must also give users an
idea of the link target. <<**NEW: "Thus, an equivalent is provided to
fulfill the same function as the equivalency target" , OLD:"Note that
equivalent information focuses on fulfilling the same function. **THIS
APPROACH AVOIDS COINING A NEW TERM "equivalent information">>
Equivalents include text equivalents (e.g., text equivalents for images;
text transcripts for audio tracks; collated text transcripts for multimedia
presentations and animations) and non-text equivalents (e.g., a prerecorded
auditory description of a visual track of a movie, or a sign language video
rendition of a written text, etc.). Please refer to the definitions of text
content and non-text content for more information.
Each markup language defines its own mechanisms for specifying equivalents.
For instance, in HTML 4 [HTML4] or SMIL 1.0 [SMIL], the "alt" attribute
<<OLD: "specifies"; NEW: "can specify"**. Note to editor: Principle is same
as below: may be _parts_ of text equivalents. In the absence of definitive
consensus, I think that we need to allow that possibility..>> a text
equivalent for many elements. In HTML 4, authors may provide equivalents (or
portions of equivalents) in attribute values (e.g., the "summary" attribute
for the TABLE element), in element content (e.g., OBJECT for external
content it specifies, NOFRAMES for frame equivalents, and NOSCRIPT for
script equivalents), and in prose. Please consult the Web Content
Accessibility Guidelines 1.0 [WCAG10] and its associated Techniques document
[WCAG10-TECHS] for more information about equivalents.
====
4. Fix the definition of Text Content, etc.
New:
Text content, non-text content, text element, non-text element, text
equivalent <<**", "non-text equivalent". Note to editor: The term is now
defined (see below) and it finishes the pair.**>>
In this document, the term "text element" means content that, when rendered,
is understandable in each of three modes to three reference groups:
1. visually-displayed text, for users who are deaf and adept in reading
visually-displayed text;
2. synthesized speech, for users who are blind and adept in use of
synthesized speech;
3. braille, for users who are deaf-blind and adept at reading braille.
In these definitions, a text element is said to be "understandable" when it
fulfills its communication function to representatives of the three
reference groups. Furthermore, these definitions make assumptions such as
the availability of appropriate hardware and software, that content
represents a general mix of purposes (information, education, entertainment,
commerce), that the individuals in the groups are able to understand the
natural language of the content, that the individuals in the groups are not
required to have specialized skills (e.g., computer science degree), etc.
A text element may contain markup for style (e.g., font size or color),
structure (e.g., heading levels), and other semantics. However, the
essential function of the text element should be retained even if style
information happens to be lost in rendering. In this document, the term
"text content" refers to content that is composed of one or more text
elements. A "non-text element" is an element that fails to be understandable
when rendered in any of three modes to their respective reference disability
audiences. Thus, text elements have essential accessibility advantages often
associated with text while non-text elements are those that lack one or more
such advantages.
In this document, the term "non-text content" refers to content that is
composed of one or more non-text elements. Per checkpoint 1.1 of "Web
Content Accessibility Guidelines 1.0" [WCAG10], authors must provide a text
equivalent for every author-supplied non-text element. Similarly, user agent
developers must provide a text equivalent for every non-text element offered
by the user agent to the user (refer to checkpoint 1.5).
Note that the terms "text element" and "non-text element" are defined by the
characteristics of their output (<<**NEW: "e.g.,"**>>rendering) rather than
those of their <<**Old: "input (format)"; New: "input (e.g., information
sources) or their internals (e.g., format)". Note to editor: I think that
this is much more accurate and complete. In each case -- input, internals,
and output -- we have an example. I think that "e.g.," is appropriate in the
case of rendering because that is really just one of several facets; for
example, there is the influence of the rendering on the groups and their
person variables, plus delivery system variables. Same for other instances
of "e.g.,". For example, "format" is just one potential facet of internals;
the internals could be dynamic rather than static. We don't care as long as
the output is right. Does that make sense?**>>. For example, in principle, a
text element can be generated or encoded in any fashion as long as it has
the proper output characteristics. In general, text elements are composed of
text (i.e., a sequence of characters). Both text elements and non-text
elements should be understood as "pre-rendering" content in contrast to the
"post-rendering" content that they produce.
A "text equivalent" is a text element that, when rendered, serves
essentially the same function as some other content (i.e., an equivalency
target) does for a person without any disability <<**Delete: "(see
definition of equivalents)."**>> <<**NEW: Similarly, a non-text equivalent
is a non-text element that, when rendered, serves essentially the same
function as the equivalency target does for a person without any disability.
(See definition of equivalents)." ** Note to editor: This rounds out the
set of six definitions.>>
====
5. Fix the Scope section.
This section has what I feel are some contradictions.
The Abstract refers to some essential accessibility features being outside
the scope of this document. It says: "A user agent that conforms to these
guidelines will promote accessibility by implementing features that are
within the scope of this document, and through compatibility with
technologies (such as assistive technologies) that provide other essential
features that are outside the scope of this document."
Unfortunately, the Scope (section 1.2) contradicts the Abstract by not
maintaining the distinction between what is in-scope and what is
out-of-scope. Specifically, it establishes a new set of "requirements" that
include both "'in scope' requirements" and "out of scope' requirements". I
don't think that this makes sense because, to my mind, there is no such
thing as 'out of scope requirements'. It only makes sense to have
requirements that are within scope.
This present arrangement again confounds what is in-scope and what is
out-of-scope. Our document treats braille as out of scope and therefore the
document has no requirements for braille support. Braille should not be
called an 'out of scope requirement.' I can see why we this was written this
way. It is a way of saying that these out-of-scope features are important
even though out-of-scope. But it is a problem nevertheless.
The problem begins in earnest with this sentence:
"As part of authoring this version of "User Agent Accessibility Guidelines
1.0", the User Agent Accessibility Guidelines Working Group (UAWG) chose to
require conforming user agents to meet some of the above requirements, and
assistive technologies to meet others."
I think that the terms "requirement" and "require" in the context of this
document should be reserved for talking about checkpoints. Basically, if it
is not in a checkpoint, then I can't see how it can be a "requirement" of
this document.
Essentially, if some feature is out of scope there must be no requirement to
provide that feature. Conversely, if there is no requirement for a feature,
it is out of scope. If you don't have to do it to conform, then it is out of
scope. If you do have to do it to conform, then it is within scope.
<END OF MEMO>
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.