E. Hansen Edits to 21 October 2000 Draft

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.

Received on Sunday, 22 October 2000 00:45:50 UTC