W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 1999

Issues: Part 1 - #1 through #15

From: <ehansen@ets.org>
Date: Wed, 17 Nov 1999 17:13:11 -0500 (EST)
To: w3c-wai-ua@w3.org
Message-id: <vines.Bh0E+sVmAsA@cips06.ets.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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:49:34 GMT