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

Definitions of Element, Text Element, etc.

From: Eric Hansen <ehansen7@hotmail.com>
Date: Sun, 22 Oct 2000 00:54:13 EDT
To: w3c-wai-ua@w3.org
Cc: ehansen7@hotmail.com, ehansen@ets.org
Message-ID: <LC2-LFD63BiVVO8wvDF00000134@hotmail.com>
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.

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.

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.

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/dictionar
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.

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:

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:

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.

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. 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."

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?

====

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)?

I submit that at the basic definition of text element and non-text element 
should make no assumptions about implementation details such as how elements 
are produced, where elements and their parts are stored, and the size of 
elements.

I realize that as a practical matter some standards need to be established 
but I believe that we need to very judicious about specifying implementation 
details. We think of the Web one way now and it may be something very 
different in five years. By over-specifying implementation details we risk 
having our specifications become prematurely obsolete.

I think that when implementation details must be specified for practical 
concerns, then, whenever possible, they should be qualified by terms such 
as: "This type of element (or this feature) is _ordinarily_ implemented in 
such as such a way." Or we can specifically state "This is how it is 
implemented in an HTML environment."

This is what the UAAG does for the definition of text element. The basic 
definition of says nothing about a text element's storage location, how it 
was produced, or what it looks like inside. It is judged merely on its 
output characteristics.

Then it goes on to make a few judicious comments about implementation. For 
example, it says, "In general, text elements are composed of text (i.e., a 
sequence of characters)." (definition of "Text content", etc.). In other 
words it says that very little bit about the internals of text elements. 
Personally, I would prefer to say simply, "A text element outputs text 
characters", but I think that this concession to an implementation detail is 
okay.

The definition of Equivalent takes the same approach. It provides the basic 
definition Equivalent and then it goes on to say how it is implement in HTML 
and SMIL without trying to establish how it _should or must_ be implemented 
in general.

Therefore, I do not support saying that the content for an element (either 
text or non-text) must reside in a single "page." I think that is too 
limiting. There may be specific implementations where that approach must be 
taken, but I don't think that such as detail belongs in this version of 
UAAG. I think that such a limiting implementation detail should not be 
established without involving WCAG and even if it became established I would 
advocate limited its scope to certain implementations.

Possible Change

We can either leave the glossary entry alone or we can follow a suggestion 
to which Al may have been alluding. That is, we could modify the definition 
simply to signal that there are other usages of "element" that may not fit 
neatly into the other categories.

New (21 October 2000):

"Element This document uses the term "element" both in the XML sense (an 
element is a syntactic construct as described in the XML 1.0 specification 
[XML], section 3) and more generally to mean a type of content (such as 
video or sound) or a logical construct (such as a header or list). In 
addition, the document uses the term in the context of "text element" and 
"non-text element" (see definition of 'Text content, [etc.]).

Comment 1:

This approach is very conservative. It simply signals the existence of 
another usage but does not attempt to define it. I think that this is the 
most reasonable approach at this point.

Comment 2:

I have not changed the reference to "logical construct" since I do not know 
removing will break anything.

For your information and for comparison, here is my 20 October 2000 memo:

At 05:15 PM 2000-10-20 -0400, Hansen, Eric wrote:
>I wanted to make sure that our definition of "Element" adequately covers 
>our
>usage in definitions such as "Text element". Is our usage as a "logical
>construct" or something else? I think it as a "unit of content" rather than
>necessarily being tied to particular "type of content". For example, a
>"multimedia presentation" might be considered an element, but also might 
>its
>visual track or even a text equivalent of a visual track might be 
>considered
>"elements".
>
>Your comments welcome.
>
>Old (29 September 2000):
>
>"Element This document uses the term "element" both in the XML sense (an
>element is a syntactic construct as described in the XML 1.0 specification
>[XML], section 3) and more generally to mean a type of content (such as
>video or sound) or a logical construct (such as a header or list)."
>
>New:
>
>"Element This document uses the term "element" both in the XML sense (an
>element is a syntactic construct as described in the XML 1.0 specification
>[XML], section 3) and more generally to mean a unit of content (text 
>element
>or non-text element) or a logical construct (such as a header or list)."
>
><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:54:46 GMT

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