- From: Hansen, Eric <ehansen@ets.org>
- Date: Thu, 26 Oct 2000 13:46:35 -0400
- To: "'Al Gilman'" <asgilman@iamdigex.net>, w3c-wai-ua@w3.org
- Cc: ehansen7@hotmail.com, "Hansen, Eric" <ehansen@ets.org>
AG:: Al Gilman's comments from his memo
(http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0147.html)
EH:: Eric Hansen's comments from this memo.
AG::
** Summary
1. For purposes of definition, the UAAG meaning of the Terms of Art "text
element" and "non-text element" should be "as used in WCAG 1.0, e.g.
Checkpoint 1.1." Explanatory elaboration on the idea is OK to include so
long as it is
clear that the WCAG is the definitive reference in case of questions as to
interpretation.
EH::
I expect that during this Last Call period, WCAG members will indicate any
modifications that they feel would bring UAAG definitions into line with
their intent.
AG::
2. Still, 'element' is _not_ a Term of Art even 'though the combinations
"text element" and "non-text element" could be considered Terms of Art.
EH::
I prefer to think that there are different usages for a given term and that
each usage may be somewhat different in meaning. I believe that we need to
provide clarifying language if confusion might otherwise result. I think
that conventions in usage of certain terms are important to establish and
follow.
AG::
3. However, it would appear that they are terms of the Web Content art, and
_not_ User Agent art. Help me: is there any requirement on the User Agent
to know what is and is not a "text element" in the checkpoints? I thought
that the User Agent only needs to know what is, per the markup structure, a
presumed equivalent for any element (sibling-sub-element in SWITCH in SMIL,
ALT for IMG in HTML, etc.)
EH::
In general, there is no requirement that a user agent know what is or is not
a text element, other than what can be readily inferred from markup.
AG::
** Discussion
1. Do we have consensus that the purpose of using the terms "text element"
and
"non-text element" is to connect with the concepts of the WCAG, or with
concepts shared with the WCAG?
There is a general rule that should emerge in the WAI coordination-of-usage
practice. This is that different Working Groups may need different special
meanings ("Terms of Art"), but that we will try to avoid a situation where
subgroups within the WAI use the same terms for different things. If
different meanings are needed between different groups, different terms will
be used to denote those meanings.
In this regard, we need to regard the international usage of English as a
virtual Working Group within the WAI for the purpose of applying the above
rule. If there is a plain English word (in international usage) which
captures the meanining needed, that should be used in preference to coining
a Term of Art.
EH::
I think that I agree with those general statements.
AG::
--
Let's back off a bit momentarily to review some generalities. What we need
in the WAI rules, and in particular in the User Agent rules, are things a)
that are effective for the user and b) that are readily doable by the User
Agent. That is the existential stretch the UAAG lives in.
The problem of how to categorize ASCII graphics illustrates this well.
ASCII Graphics is composed of text and a particular layout arrangement of
the text. This could be interpreted as falling within the language "text and
presentation properties of the text" that I penned. So that shows the
language I penned is not clear enough in this case.
The user-centric definition "presentable comprehensibly in all of sight,
sound, and touch" meets requirement a) of "effective for the user" very well
but requirement b) of "readily doable by the User Agent" less well. To be
readily doable by the User Agent, ideally it would be stated in terms that
are machine interpretable on inspection of the data of the "document."
ASCII graphics are not a problem with regard to requirement b), because the
html:pre element that is used to mark them as layout-literal source is a
clear indication that interpreting the content as a _stream_ of characters
will _not_ preserve the comprehensibility of the intended message.
Note how the WAI-PF working group enters into the plot, here. It is the
long-range mission of PF to get the format definitions to capture
distinctions about content which are effective for the user in data
encodings i.e. markup which is readily intelligible to machine processing in
the User Agent. In an ideal world, the format definitions bridge the gap
between a) and b). At present, they only partially fulfil that mission.
Note in particular Len's ideas about the potential effectiveness of a
dictionary of classes suitable
for use as values of the class attribute on elements in HTML; and Jon's
input to the XHTML 2.0 requirements that the markup language needs to
support machine discovery of the semantic structure within a document.
Yes, "text element" and "non-text element" are Terms of Art in the UAAG. On
the other hand, attempting to improve on what the WCAG has done to define
these Terms of Art without coordinating with WCA WG will only introduce
confusion.
The intent is to import or synchronize with the concepts employed in WCAG
Checkpoint 1.1. The highest and best glossary entry therefore should make
this clear; that the definitive source for this usage is as used in the
WCAG, although an informative gloss may be offered in the UAAG to make the
document easier to use.
EH::
I can see that for the sake of simplicity one would like to go back to one
definitive document (e.g., WCAG 1.0) and say that all else is informative
gloss. However, due to issues such as long lag times between different
versions of documents WCAG 1.0, UAAG 1.0, WCAG 2.0, etc., its hard for me to
think that this is necessarily practical. One almost needs yet another
document to indicate which definitions are most considered most definitive
at any given time. (I think that is an idea that we need to keep in mind as
we contemplate a combined glossary of terms for WAI). This problem is not
new in other domains (law, etc.). I do agree that there is a need for
coordination between groups so that usages will not cause confusion.
AG::
Because the role adopted by 'element' in the Terms of Art "text element" and
"non-text element" fits well within a general natural-English sense of the
term, 'element' per se is not rendered a Term of Art just because it appears
in those phrases which are Terms of Art. The meaning is only special in the
specific combinations noted. [See details for expansion on how another HTML
document cited in a html:londesc attribute is, in the appropriate user frame
of observation, "part of the document."]
EH::
I think that "element" has several usages, each of which differs somewhat in
meaning. I agree that we need to avoid confusing the reader.
As an aside, I interpret this comment about longdesc as having reference to
something you have brought up before. As I recall, it was the idea that
peers of certain elements as needing to exist in the same "document".
Perhaps my comments are a bit out of context, but I wonder if the concept of
document is really that easily defined. For example, following your logic,
if document B specified by the longdesc attribute is 'part of the [original]
document' (i.e, document A), then the peer elements could exist in either
document A or document B (if I understand your earlier argument). Now
suppose that document B includes document C via longdesc and then document C
includes document A via longdesc. In essence, we have a loop or "donut" of
longdesc related documents. In that case both peers could exist in A, B, or
C. (I can't help but think that this would confuse a browser.) Frankly, just
focusing on the longdesc attribute I can imagine a whole tangle of
documents, all of them, part of the same "document". You evidently allow
documents linked by longdesc to be considered one document. Why rule out
other ways of linking documents? I am not saying that the concept of
"document" is not useful. I am just wondering out loud whether it can be
defined well enough to bear the burden that you wish to place upon it.
AG::
The term 'element' does not require a definition, although an explanation of
how it has been used may be valuable. It is good to put entries in the
Glossary where people may mis-read the usage in the volume, even when the
entry is not absolutely necessary to _define_ the intended sense of a term,
or even if the intended sense of the term is not a Term of Art.
But this probably means we need some way to write entries in the glossary as
a guide to the literal minded on whether a given entry is intended as a
'normative' definition of a Term of Art in the volume or is an 'informative'
comment elaborating on the natural usage employed.
EH: As I think about it, I am inclined to do the following:
1. Include within each specification document the best glossary that we can
write.
2. Write a separate "Harmonization Note" (official document) that attempts
to harmonize usages of the terms between documents, pointing out which one
is considered most definitive at any given time.
3. Allow users of each specification to conform at a minimal level by
following the definition within that specification.
4. Encourage users of a specification to consider additional information in
the 'harmonization' document.
EH::
-- details follow
At 12:54 AM 2000-10-22 -0400, Eric Hansen wrote:
>Definitions of Element, Text Element, etc.
>
>I appreciate Al Gilman's very thoughtful response to my memo "Revision to
>the definition of 'Element'".
>
>I think that at the outset, I see resolving the glossary entry for
"Element"
>as related to but not on the critical path for a resolving of the
definition
>of "Equivalent". The definition of Equivalent will continue to receive
>attention through the Last Call period.
>
AG::
Consider it this way. A relevant question is "does the use of terminology
in the UAAG connect well with the concepts and terminology expressed in the
WCAG?
Here both 'equivalent' and 'element' are implicated in the WCAG checkpoint
language "text equivalent for non-text element." So I think it best we not
try to close on 'element' entirely until we have checked with GL on how we
align with the ideas there.
EH::
I am very happy to have GL comment on alignment and I agree that we should
strive for alignment. However, as I plan to detail later, I think that there
are other non-WCAG-related issues that would suggest that such issues go
beyond what could be decided by WCA WG alone.
>Ian's draft of today (21 October 2000) does not change the entry for
>"Element" and that is okay with me.
>
>Several of Al's points do resonate with me. Although I may not grasp the
>full significance of all of Al's arguments, I accept at face value his
>statement such as: "There is rampant in the community an ambiguity in the
>use of 'element' between denoting an actual part of an actual document
>[instance] vs. an element type specified (in a DTD or otherwise) for use in
>markup to delimit and classify the previous, more concrete sort of
>'element.' Under the circustances there is no reader-safe usage except to
>say 'element instance' when one means a specific part of a specific
>document, and 'element type' when one specifically means a category of the
>above, such as for example all the element types defined in HTML, the
>dialect of SGML." In other words some of the problems in the usage of the
>term 'element' are ongoing and seemingly pervasive. While I am glad to use
a
>discussion of equivalent to illuminate these important issues, at the same
>time I do not want the full burden for resolving such issues to be placed
>upon the definition of equivalent. The problems that Al cites did not
>originate with 'equivalent' nor should the definition of equivalent be
>obliged to definitively resolve all these issue before moving forward.
>
AG::
I did not characterize this pervasive ambiguity as a problem. Just a
situation. I didn't propose to try to tie 'element' down to either sense,
just use phrases for clarity where one must be sure to indicate one sense or
the other.
EH:
>In trying to at least partially separate the resolution of 'element' issues
>from 'equivalent' issues, I am not saying that his memo unduly entwined
>them. (Indeed, it was I who 'entwined' them in suggesting that the
>definition of 'element' be modified to better reflect usage in terms such
as
>'text element'!) I mainly want to alert readers that in my view, the basic
>adequacy of the definition of 'equivalent' does not hinge upon further
>clarification of issues surrounding the glossary entry for 'element.'
>
>Furthermore, I do not think that this issue should in any way affect plans
>for going to Last Call. I think that we have a very narrow window of
>opportunity to improve the definition of "Element" before going to Last
>Call. I think that it would be nice to clarify things a bit if we can, but
>if we can't, then there is still no reason not to proceed.
>
AG::
OK, we are now in Last Call. No way to separate this glossary entry from
the Last Call process at this point.
>Below I have made some notes. Sections beginning with "AG:" are comments of
>Al Gilman and those beginning with "EH:" are those of Eric Hansen.
>====
>
>From: Al Gilman (asgilman@iamdigex.net)
>Date: Fri, Oct 20 2000
>To: "UA List (E-mail)" <w3c-wai-ua@w3.org>
>Subject: Re: Revision to the definition of 'Element'
>
>AG:
>
>1. Why is this conversation happening now? Are we making changes like
this
>to the PR draft?
>
>2. There is no need for a Term of Art, here, because the sense of
>'element' in the WCAG provisions that are the basis for the UAAG provisions
>in question
>is a natural English sense of "a constituent part" [c.f.
><<<http://www.m-w.com/cgi-bin/dictionary>http://www.m-w.com/cgi-bin/dictio
nary><http://www.m-w.com/cgi-bin/dictionar>http://www.m-w.com/cgi-bin/dictio
nar
>y>, search on 'element,' select sense #2].
>
>EH:
>
>I see that you believe that a special meaning ('Term of Art') is not (or
>should not) be necessary in the glossary entry for 'element' in order to
>cover 'text element' and 'non-text element'.
>
>It seems clear to me that these terms do (and should) have specific
>meanings, which are already reflected in other parts of the UAAG document.
>
AG::
I am confused. The word 'element' by itself is not necessarily subject to
special meaning just because it appears in phrases or compounds which have,
in the compound form, special meaning. Just because "they," the two
compound phrases, have special meanings, does not mean that either word used
in them, taken alone, should be viewed as having a special meaning. No?
EH::
I think that the contrast between 'term of art'/'special meaning' and normal
English meanings do break down a bit here. As we have seen in the definition
of 'equivalent', even normal English admits of fairly diverse meanings. Even
seemingly simple terms, like "text" that seem to have a normal English
meaning is really not that 'normal' once you scratch below the surface. For
example, usually I think of text as something to do with letters, numbers,
and punctuation that I can see on a page or computer screen, but when you
really look at UAAG's definition, you see that is does have a special
meaning -- something about 'sequence of characters from a markup language's
document character set (e.g., Unicode or ISO 10646).' A literal-minded
reader is wondering, what on earth does Unicode or ISO 10646 have to do with
letters, numbers, and punctuation? Furthermore, if the person thinks to look
up the definition of 'character' in the "Character Model for the World Wide
Web" (http://www.w3.org/TR/charmod/), they find that even this document
cannot provide a clear and definitive definition of 'character' ("Used in a
loose sense to denote small units of text, where the exact definition of
these units is still open.).
So I would just rather say that our glossary should document how we use
terms and if it is not clear which meaning of a term we intend, then we
should make it clear.
In UAAG, we have tried to avoid coining new terms. For example, checkpoint
1.5 formerly used the term "text message" But to avoid coining a new
compound term, the checkpoint was entirely rephrased to avoid the term ("1.5
Ensure that every message (e.g., prompt, alert, notification, etc.) that is
a non-text element and is part of the user agent user interface has a text
equivalent. [Priority 1] ", UAAG, 23 October 2000).
By the way, it looks like the rephrasing was not carried through to the
definition of "Alert". This needs to be corrected.
Old (23 October 2000, UAAG):
Alert
In this document, "to alert" means to make the user aware of some event,
without requiring acknowledgement. For example, the user agent may alert the
user that new content is available on the server by displaying a text
message in the user agent's status bar. Refer to checkpoint 1.5 for
requirements about alerts.
New:
Alert
In this document, "to alert" means to make the user aware of some event,
without requiring acknowledgement. For example, the user agent may alert the
user that new content is available on the server by displaying visually a
message in the user agent's status bar. Refer to checkpoint 1.5 for
requirements about alerts.
Perhaps Ian or others could suggest even better language that still avoids
coining a new term ("text message").
==
Thus, a goal that I think that we take quite seriously is that of not
coining new terms when existing ones will do.
EH:
>As an aside, I think it worth noting that even if the usage of text element
>and non-text element _did_ fit neatly within the "natural English sense of
>'a constituent part'", that would not be a sufficient reason to exclude
such
>a meaning (and/or usage) from the glossary. (I am not sure whether you were
>asserting that it would be sufficient reason.) If the term is _only_ used
in
>its 'natural English sense', then there might be grounds for excluding the
>term. However, if the document uses _more than one_ meaning, only one
>meaning of which is the natural English sense, then that is _all the more_
>reason to include the natural English meaning along with the other meaning
>or meanings of the term. Otherwise one would not even know that the term
>_could_ be understand in its natural English usage.
AG::
I agree. I am not exactly sure how to word glossary entries to distinguish
restrictive vs. purely illustrative entries.
>
>AG:
>
>That said, Let me clear up the usage in this area just a bit.
>
>There is rampant in the community an ambiguity in the use of 'element'
>between denoting an actual part of an actual document [instance] vs. an
>element type specified (in a DTD or otherwise) for use in markup to delimit
>and classify the previous, more concrete sort of 'element.' To make the
>distinction clear, one could use 'element' and 'element type' but often
>'element' gets reassigned and we wind up talking about 'element instance'
>and 'element.' Under the circustances there is no reader-safe usage except
>to say 'element instance' when one means a specific part of a specific
>document, and 'element type' when one specifically means a category of the
>above, such as for example all the
>element types defined in HTML, the dialect of SGML.
>
>EH:
>
>I agree that the terms 'element' and 'content' are used in many different
>ways and that there is a lot ambiguity about whether one is talking about
>instances or types.
>
>AG:
>
>However: the sense of 'element' in the WCAG 1.0 discussion of "text
>equivalents for non-text elements" is the natural English sense of "a
>constituent part" and not the syntax-technical sense of "an instance of a
>markup construct defined as an element in the formal specification of the
>markup dialect."
>
>EH:
>
>I agree that the usage of 'element' in the terms 'text element' and
>'non-text element' are _not_ synonymous with "the syntax-technical sense of
>'an instance of a markup construct defined as an element in the formal
>specification of the markup dialect.'" I think that the fact that they are
>not synonymous can be analyzed on several levels, but at one basic level, I
>know of no markup language that intentionally maps to these constructs,
>except at the barest level. That said, I think that we need to realize that
>we are essentially in our infancy in terms of defining markup languages
that
>will support accessibility concepts. The availability of "alt" attributes
in
>HTML and other languages is just a small but important step toward that end
>goal. I would hasten to remind us that I think the WCAG and UAAG has
>properly tried to frame their specifications such that they are not focused
>on just one language (e.g., HTML) but that they are intended, as much as
>possible, for implementation in various language environments. Therefore,
it
>is not surprising that the UAAG usage of terms like text element and
>non-text element do not necessarily map exactly or completely to any
>existing markup language.
>
>As to how well the usage of 'element' in terms 'text element' and 'non-text
>element' is captured by the notion of 'a constituent part', I have some
>concerns that I will explain later in this memo.
>
>AG:
>
>The fact that it is not the technical sense may bear mentioning, but this
is
>a warning, not a 'definition.'
>
>EH:
>
>I think that this is a very good reminder that the glossary can alert the
>reader to different usages without necessarily claiming to provide specific
>_definitions_. I think that this comment may point the way to a
>clarification of the UAAG glossary entry for "element." I use this approach
>at the end of this memo.
>
>AG:
>
>Note: The phrase 'logical construct' is much too broad as it includes
>categories such as 'connective' or 'preposition' or 'reference' which are
>never referred to as 'elements' in the disucssions in the WAI documents.
>The category of 'logical constructs' that we use 'element' for is 'element
>types.'
>There is no need to fall back any further into looser categories.
>
>EH:
>
>Your comment about the phrase 'logical construct' as being 'too broad'
seems
>to make some sense though I don't know what others have intended by the
term
>and therefore I don't know what we would lose by not using the phrase.
>
>AG:
>
>Warning 1: It is important to understand the design elements of a web page
>as including the actual image embedded in the document by an IMG element in
>the markup language, although regarding the document as just the HTML text
>of the source one would find that only a reference to the image is preseant
>in the IMG element in the HTML file.
>
>Warning 2: It is perfectly legitimate, however, for someone to talk about
>header font and type color scheme as elements of a company's branding
>scheme.
>This is a pattern of properties that is not a document part and it is not
>represented by an XML or SGML element type definition in the formal
>organization of the markup language. But it can be said in one of our
>documents without breaking our usage because it is just another example of
>the
>plain English sense of 'element.' The key is that it is made clear in the
>context what this syndrome of presentation properties is an element (i.e.
>part
>of component) _of_.
>
>There was question as to whether 'element' refers to a type of content.
Not
>quite. The point is that all the named elements in HTML and other SGML and
>XML applications _do_ have connotations as to categories that the content
>range so marked falls within. But these categories are often heuristic,
>that is to say not machine-interpretable without the aid of a
>natural-language-capable human.
>So although one of the common senses of 'element' is 'element type,' and
>'element type' does contain information about what kind of stuff is in
>there, an 'element type' is not a kind of stuff, but rather a kind of part
>which has restrictions as to the kind of stuff one will find in it (and its
>role in the context).
>
>EH:
>
>I think that I hear you saying that the element type is what in some
domains
>might be called a "class" or "abstract class" or "abstract entity".
>
AG::
Yes, those terms are used in some domains to denote roughly similar
constructs.
>AG:
>
>Webster lists "a constituent part" as the second sense of 'element' and
that
>is the generic sense used throughout UAAG and the rest of the WAI
>literature. It is inadvisable to try to give a reserved meaning to
>'element' in the UAAG as a whole. If you want to make the usage more
>precise in various places, it could be useful to introduce glossary entries
>for "element instance" and "element type" and place a note in the glossary
>indicating that 'element' has been used for either of these or the Webster
>sense "a constituent part" interchangeable where it is clear from the
>context which of these is intended. We should
>endeavor, and say we have so tried, to use "element instance" or
>respectively" element type" where the distinction is important.
>
>Note: there is no need to be concerned about how 'element' is defined as
>used in the glossary entry for "text element." The introduction of "text
>element" in the glossary is gratuitous. Searching for this phrase
>encounters no hits until it appears in the glossary. It is a
self-requiring
>exercise in unnecessary definition of terms. However, if you wish to
>understand what "text element" and "non-text element" should mean in the
>satisfaction of WCAG, please consider the following nominations:
>
>* A _text element_ is a constituent part of the document (i.e. in the
>general, not syntax-technical sense) whose content is entirely composed of
>text and properties of that text.
>
>* A _non-text element_ is a constituent part of the document (same proviso)
>that is not a text element and cannot be reasonably decomposed into
>constituent parts some of which are text elements and some are not.
>
>EH:
>
>It is obvious that there are differences between the definitions you
propose
>and those that are found in UAAG (29 September 2000).
>
>1. Accessibility Focus: Preeminent versus Implied. A very important
>difference between the UAAG definition of text element and your proposal
for
>the term is that the UAAG definition has its _accessibility capability_ as
>its _preeminent_ characteristic, even its defining characteristic, whereas
>in your definition of the accessibility capability is merely _implied_.
>Specifically, the UAAG definition text element has as its defining
>characteristic its accessibility features, that is, being understandable
>when output as visually displayed text, synthesized speech, and braille to
>particular disability groups who find those information delivery modes
>helpful (deaf, blind, deaf-blind, respectively). On the other hand, your
>definition does not even mention any accessibility feature, though some
>accessibility is implied by its reference to "text", which some readers
>should realize can have good accessibility benefits.
>
>The UAAG definitions of text element and non-text element provide a clear
>minimal standard that is directly tied to the most fundamental barriers to
>Web access of which we are aware and to what we believe it takes to remove
>those barriers. Today almost all Web content relies on senses of sight
>and/or hearing and the UAAG definitions of text element and non-text
element
>are directly tied to modes of display that are helpful to people whose
>disabilities impair their sight, hearing, or both.
>
AG::
Yes. You have outlined the difference clearly. This is a very important
difference, and one that affects the definition of 'equivalent' as well.
The refrain that we hear over and over from the toolsmiths is "Just tell me
what I have to do."
The UAAG guidelines properly tie each 'what' to a clear 'why.' The 'why'
has
to do with criterion a) above that it clearly makes a difference in outcomes
for users with disabilities. But the 'what' language should as much as
possible be clearly "just plain what." Don't invent mumbo jumbo for 'what'
they need to do when the only thing special is in the 'why.' The term
'element' should be _descriptive_ of how a document goes together; not why
you
need to do this or that with this or that element. The _prescriptive_ tone
enters in the statement of the whole checkpoint, where the term 'element'
used
in stating the 'what' of that checkpoint should be purely _descriptive_ in
tone.
To honor the "just tell me what we need to do" request, we should attempt to
describe the 'what' in language that the reader already understands, with
recourse to Terms of Art only when plain English absolutely fails us. So
far,
in the case of 'element' I am not finding there to be a need for a Term of
Art.
EH::
The important thing is clear communication. I am amenable to establishing
reasonable conventions for usage in order to make sure it is sufficiently
clear which meaning of element is intended. I expect that there will be
situations in which one wants to use the word "element" in the sense of the
super class of elements of which "text element" and "non-text" element are
sub-classes. The thing to avoid is ambiguity as to what meaning is intended.
AG::
Maybe a glossary entry to clear away the risk that people among the
readership who have encountered 'element' as a syntax-technical term will
tend to read it that way.
What I have stated here is just the argument from effective communication --
i.e. good writing. There is also the argument from Universal Design that I
have explained earlier to the effect that we should not introduce
access-pecular rules or terms where more general and equally implementable
rules or terms get the job done.
That also suggest that since the general definition of 'element' fits what
we need, we should not put language in the glossary that makes it appear
some special access-peculiar meaning is needed to understand what the User
Agent implementer has to do.
EH::
The foregoing is a worthy goal. But I think it is possible to do both: (a)
preserve special-access meaning as necessary and (b) establish a clear
'minimal standard' or 'acceptable standard' about what the implementer has
to do.
AG::
It's actually simpler than that. We want them to immediately grasp how
simple it is.
>2. Compatibility with Checkpoint 1.1 of WCAG 1.0: High versus Low
>
>The UAAG definitions of text element and non-text element are highly
>compatible with WCAG 1.0 checkpoint 1.1 whereas your definitions have
>critical incompatibilities. WCAG 1.0 checkpoint 1.1 requires authors to
>"Provide a text equivalent for every non-text element" and then provides a
>list of what apparently count as "non-text elements". This checkpoint is
>perfectly understandable in the context of the UAAG definitions of text
>element and non-text element. That is, the reason that we _require_ text
>equivalents -- which _are_ text elements -- for every non-text element is
>because non-text elements _fail_ to be understandable in any of those three
>important modes. The text equivalents directly fill the need because, as
>text elements, they _are_ understandable in those three modes. It fits
>together extremely well.
AG::
Yes, it is self-consistent to the point of circularity. No help to the User
Agent implementer in understanding what _they_ have to do, which is make
available user choice (over inclusion in the presented view) concerning
whatever _the markup indicates_ may be an equivalence group.
EH::
As for whether the definitions provide "no help to the User Agent
implementer in understanding what _they_ have to do", that is role of
checkpoints like checkpoint 2.3 (in whatever form it finally takes). And, as
you indicate elsewhere in this memo, the user agent only needs to recognize
what is indicated by markup.
I am not sure what you mean by "circularity". My hunch is that what you see
as circularity is simply an outcome of the fact that my very brief summary
does not provide important implementation details. Yet I think that we have
tried to provide the implementation details that are essential and which are
within the scope of UAAG. For example, we do note how concepts like
equivalent are implemented in HTML and SMIL.
"Each markup language defines its own mechanisms for specifying equivalents.
For instance, in HTML 4 [HTML4] or SMIL 1.0 [SMIL], authors may use the
"alt" attribute to specify a text equivalent for some 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." (definition of Equivalent)
Furthermore, I think that you have (in this memo) essentially agreed that
UAAG does not need to help implementers of user agents distinguish between
text elements and non-text elements; they should rely on other
specifications for that.
If there are implementation details that are missing and that you think
properly fall within the scope of UAAG, please publish them to the list.
Although I suppose that any single virtue can be carried too far, I think
that it is a worthy objective (among many) for UAAG to specify only the
minimum performance objectives and to leave other implementation details to
the Techniques documents or to implementers' own creativity.
AG::
There is no burden on the UA to know text elements from non-text elements,
actually. Only to know what is viewed by the format spec as "where the
author should put the other equivalent."
EH::
In using the term "equivalence group", you are using a term that is not
defined in UAAG or WCAG. And you are using the term "other equivalent" in a
manner different than it is used in UAAG or WCAG.
These statements hearken back to your earlier comments on checkpoint 2.3, to
which I have already responded in:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0092.html
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0103.html
If you wish to propose revised language for 2.3, then I suggest that that
you propose revised language to the list.
If you wish to coin new terms, especially as they relate to the concept of
equivalency, I suggest that you propose definitions for the terms.
Based on this and other memos, I think that you want to define a peer
relationship between pieces of content. Until better language is found, I
suggest the following definition, which seems to capture some of what you
are referring to.
"Peer (for content)"
"In the context of this memo, a 'peer' is content that, under some
circumstances, can serve essentially the same function, for some other
content. An equivalent and its equivalency target both qualify as peers for
each other."
EH:
>On the other hand, your proposed definition of
>non-text element contradicts important parts the list of non-text elements
>in checkpoint 1.1. Specifically, if I understand your proposals, note that
>some of the "non-text elements" in checkpoint 1.1, notably ascii art and
>scripts, would be counted as "text elements". Good definitions of text
>element and non-text element should _not_ allow an element to be both a
text
>element and non-text element _at the same time_. Based on this issue alone,
>I cannot accept the idea that your proposals are closer than the UAAG
>definitions are to "what 'text element' and 'non-text element' should mean
>in the satisfaction of WCAG."
AG::
Yes, I can see what I said could be misinterpreted as regards ASCII art in
PRE in HTML.
But I would not abandon the bottom-up approach if we needed to define "text
element" and "non-text element." I would head in the direction of "A text
element is one which can be substantially understood from its character
content alone, taken as a stream." The point is to allow expendable fluff
like FONT tags in text elements, but not to include PRE because it requires
a rigid layout constraint to preserve the meaning of those characters.
Something along those lines. But we don't need UAAG definitions for these
phrases. The distinction is not something that the UAAG requires the User
Agent to make automated decisions about.
EH::
It is correct that UAAG has not required user agents to recognize
equivalents in the absence of markup from which their presence is indicated.
AG::
Just let the user get at all the equivalents, and pick what is best for him
or her.
EH::
I would translate your statement above as follows:
"Just let the user get at all the peers, and pick what is best for him or
her."
I would need to look at language for a revised checkpoint 2.3 before knowing
whether I agree or not.
But I would strongly urge either using defined language in its defined ways
or proposing specific definitions for new terms that you wish to use.
On the other hand, if you wish to _change_ the existing meanings of
equivalency-related terms, I think that is a bigger job and would require
quite a bit more coordination between groups.
EH:
>I believe that the UAAG definitions of 'text element' and 'non-text
element'
>are highly compatible with and supportive of the direction set by WCAG 1.0.
>
>In deciding between the UAAG definitions and Al's proposed definitions, I
>think one needs to ask oneself the following two questions: (1) Do I want
my
>core concepts such as 'text element' and 'non-text element' to be directly
>tied to the presence of or absence of critical accessibility features or do
>I want a looser connection to accessibility? and (2) Do I want definitions
>that are compatible with WCAG 1.0 checkpoint 1.1 or do I want definitions
>that contradict some of the provisions of checkpoint 1.1?
AG::
Since they're not UAAG concepts at all, but WCAG concepts, we should leave
the defining to WCAG or ask WCA WG if we wish a clarification relative to
WCAG 1.0.
EH::
I am in favor of having concepts agreed upon by all groups. And I trust that
during the Last Call period the WCA WG will make it known if there are
discrepancies between UAAG 1.0 and WCAG 1.0 or WCAG 2.0.
EH:
>
>====
>
>I would like to highlight a very positive contribution of Al's proposed
>definitions. In his definition of non-text element he refers to or at least
>alludes to the possibility of non-text elements being decomposed into
>smaller elements, some of which may be text elements and others of which
may
>be non-text elements. In addressing such issues, Al is, I believe dealing
>with critical issues such as the levels of granularity at which these
>elements can or must operate and whether elements can include elements.
>These issues are important issues that, if not resolved by specifications
>must be resolved by developers of Web content and by developers of user
>agents themselves. Dealing with such issues is an inherent part of
>implementing any accessibility framework in software. I have previously
>brought up issues and suggestions along these lines but there is little if
>anything in UAAG that directly addresses this issue. Nevertheless, the
>absence of specifications on such issues may not be all that bad because
>exactly how one resolves those issues may depend on the environment in
which
>one is operating. My point here is that issues such as element granularity
>and the extent to which elements may include other elements are important
>issues. They are issues that need to be addressed but I don't think that
>they need to be addressed in UAAG. Indeed, resolving such issues at least
on
>the content creation end of things is something more within the purview of
>WCAG than of UAAG.
>
>AG:
>
>The main reason for putting a glossary entry in the document is that
readers
>of the content may be markup-language-literate and will need to be warned
>that the syntax-technical sense is not what is intended [in the WCAG
>language]. Note that since the issue here is echoing the WCAG requirement,
>the appropriate way to get usage clarification would be to ask the WCA WG
>for an interpretation of the document.
>
>All of this is dependent of understanding that 'part' in the above
indicates
>something which contains a subset of the content of the document, _and_
>would be recognizable by a reasonable user as a thing in its own right.
>
>Al
>
>EH:
>
>I have some concerns what I think Al is suggesting about an element as
being
>'part' of a document. I think that in terms of the accessibility function
of
>an element, it makes no difference whether all its parts are in one
document
>or a hundred documents. It is the output, the interface with the user, that
>matters most of all. Why not view Web content as an "application" as some
>have advocated and allow the fragments of a text element (or any element)
to
>be drawn from anywhere in the application (or even beyond the application)?
>
AG::
That doesn't conflict at all with considering it 'part' of the document. In
the user experience, which is indeed where the WCAG is applying its
terminology
of "non-text element," yes, a LONGDESC in a separate file is "part of the
document."
This is the main point about 'element' that bears cleaning up. That it not
only doesn't mean exactly something marked with a pair of matching tags, it
doesn't have to exactly be in the same file. The LONGDESC and SRC parts of
an IMG element are alike in this.
But cleaning up, if it is to be done, belongs in the WCAG. This is a Web
Content notion, not something that is visible in the User Agent processing
directly.
EH::
Our intention has been to have the definitions that are quite compatible
with WCAG. On the other handle, the implications of the definition of
element go well beyond the scope of WCAG alone and the discussion should
involve all groups.
I interpret many of your comments in this and other memos as pointing out
the need for rules or conventions about how to map equivalency concepts to
specific implementations (languages, formats, etc.). This is a very
important theme and is right at the heart of what it takes to design a new
implementation, such as a new markup language or a revision of a old markup
language. If my interpretation is correct, then I basically agree with that
theme.
In the UAAG I think we have tried to be very careful about not
over-specifying on issues that should be handled elsewhere.
<END OF MEMO>
Received on Thursday, 26 October 2000 13:56:31 UTC