RE: Definition of Non-Text Content, Etc.

Harvey,

Thanks for your comments. I have added a few comments below, marked with
"EH1:"

In addition to the comments, this memo a suggests an addition to my earlier
definition of "Text element" and proposes a definition of "Text".

Regards,

Eric

> -----Original Message-----
> From: Harvey Bingham [mailto:hbingham@ACM.org]
> Sent: Thursday, September 21, 2000 11:12 PM
> To: w3c-wai-ua@w3.org
> Subject: Re: Definition of Non-Text Content, Etc.
> 
> 
> At 2000-09-19 06:41-0400, Eric Hansen wrote:
> >To: UA List (w3c-wai-ua@w3.org)
> >From: Eric Hansen
> >Re: Non-Text Content, Text Element, Etc.
> 
> HB: Comments by Harvey Bingham I've snipped parts of the original that
> I agree with. I amplify some of the rest below.
> 
> >Suggestion 1: Provide a definition of "non-text content", etc.
> >
> >In keeping with the working group's resolution in the last 
> teleconference 
> >[1] to "Adopt a definition of non-text content, text 
> element, non-text 
> >element", following is my wording.
> >
> >New:
> >
> >"Non-Text Content, Text Content, Non-Text Element, Text Element"
> >
> >"The term non-text content in this document refers to 
> _content_ that is 
> >composed of one or more "non-text elements". Per checkpoint 
> 1.1 of WCAG 
> >1.0, the content author must ensure that there is a "text 
> equivalent" for 
> >each non-text element in author-supplied content. Similarly, 
> the developer 
> >of a user agent must ensure that a text equivalent is 
> available for any 
> >non-text element produced by the user agent for the user 
> (see checkpoint 
> >1.5). The term "text content" in this document refers to 
> content that is 
> >composed of one or more "text elements.""
> >
> >"A "text element" is an element that, when rendered, is 
> understandable in 
> >_each_ of the three modes: (1) visually-displayed text (for 
> person who is 
> >deaf and adept in reading visually-displayed text); (2) 
> synthesized speech 
> >(for a person who is blind and adept in use of synthesized 
> speech); and 
> >(3) braille (for a person who is deaf-blind and adept at 
> reading braille).
> 
> HB: It is wrong to assert that all braille users are 
> deaf-blind. Many prefer
> that delivery mode with its different navigation choices to 
> the encumbrance
> of linear listening to text-to-speech.
> 

EH1: I don't mean to assert that all braille users are blind. Similarly, I
do not mean to assert that all users of synthesized speech are blind or that
all users of visually-displayed text are deaf. I simply wanted to anchor
each modality in a single group for which that modality is very important.
For the braille category one could say: "(3) braille (for a person who is
deaf-blind or _blind_ and adept at reading braille)"[emphasis added], but I
don't think that it is necessary and begs the question, "Why not add yet
other disability groups for which a particular rendering is likely to be
helpful?". I'd like to keep the definition simple. Braille is particularly
important for people who are deaf-blind because, unlike people who are
blind-only, they cannot hear the audio renderings.

> HB: minor nit: "understandable" implies that the reader 
> "knows that language".
> It is not required that each reader knows all those 
> languages, nor that the
> author must restrict material to that which can only be 
> understood as rendered
> by all of those. For example, some math needs Nemeth braille. 
> Likewise an
> audio renderer may require special adaptive software to read 
> math. For someone
> who doesn't need to read math, such specialization is irrelevant.
> 

Very good point. I think that you have stated well some of the implicit
assumptions. Generally, speaking I like making assumptions explicit.
Possible language to add to the definition of "Text element":

"In this definition, the representatives of the reference disability groups
(deaf, blind, deaf-blind) are assumed to be _similarly well-prepared to
understand_ by factors such as their educational preparation, by the
availability of appropriate commercial input and output technologies
(including assistive technologies, as necessary), and by reasonably
favorable operating conditions (e.g., quiet, well-lighted room, etc.) for
the kind of technology for which conformance claim is made. In this case,
each claim pertains to a user agent (composite or singular) that must adhere
to one or more sets of checkpoints beyond the core level."

Thus, the issue of "language" would be encompassed by the phrase
"educational preparation".

I am actually a little nervous about linking the definition of text element
so directly directly dependent upon delivery technology. Maybe the
definition should end immediately after "favorable operating conditions
(e.g., quiet, well-lighted room, etc.)".

> 
> >  A text element may contain markup for structure (e.g., 
> heading levels), 
> > and style (e.g., font size or color), and so on. However, 
> the essential 
> > function of the text element should be retained even if 
> style information 
> > happens to be lost in rendering."
> >
> >"A non-text element is an element that _fails_ to be 
> understandable when 
> >rendered in _any_ of three modes to their respective 
> disability audiences."
> 
> HB: I prefer to include the other limited delivery 
> conditions, such as low
> bandwidth, non-screen, phone browsers, in which anyone may be 
> constrained,
> rather than just the above inadequate partitioning into three 
> disability 
> classes.

EH1: See the mention of technologies in the language that I have added.
> 
> >"Note that the terms text element and non-text element are 
> defined by the 
> >characteristics of their output (rendering) rather than 
> those of their 
> >input. For example, in principle, a text equivalent can be 
> generated or 
> >encoded in any fashion as long as it has the proper output 
> >characteristics. [EH Question: Do we need to say: "However, 
> in many cases, 
> >text elements are encoded as text -- with or without markup."?
> 
> HB: Only careless practice will allow tag omission. XML 
> won't. The browsers
> that today guess-ahead what the tag structure might be, will 
> need many less
> inferences when their input documents are properly tagged.
> 
> >Or do we need, for practical or other reasons, to otherwise 
> constrain the 
> >format of the text equivalent?] A text equivalent may be 
> understood as 
> >"pre-rendering" content in contrast to the "post-rendering" 
> content that 
> >it produces (visually-displayed text, synthesized speech, braille).
> 
> HB: I note that the lang="fr" attribute on many text elements may
> significantly change how the element is understood. When 
> limited to ASCII,
> the many character entities needed, say to handle the 
> diacritical marks
> of western european languages may need to be processed.
> 
> 
> >A _text equivalent_ is a text element that, when rendered, serves 
> >essentially the same function as some other content (e.g., "primary" 
> >content) does for a person without any disability (see definition of 
> >_alternative equivalents_).
> >
> >Comment 1:
> >
> >I think that it is imprecise and misleading to define text 
> equivalents as 
> >"unrendered content" and the content that they produce 
> (visually-displayed 
> >text, synthesized speech, and braille) as the "rendered 
> content". While 
> >those terms are often correct in particular instances, they 
> don't rise to 
> >the level of defining characteristics. I think that the terms 
> >"pre-rendering content" and "post-rendering content", while 
> perhaps a bit 
> >unfamiliar, are correct.
> 
> HB: Agree. Nit: above "synthesized speech, and/or braille" 
> Rarely are all three
> required for "rendered content".
> 

EH1: That's right. I have argued elsewhere that that synthesized speech and
braille should be included _within_ the boundary of the Subject ('subject of
the claim'), however, for a variety of reasons (technical and non-technical)
that view has not held sway. Yet this definition reaches out beyond the
boundary of the subject in a soft (but I think necessary way), making
implicit reference to a channel of communication based on commercial
technologies that would allow, if necessary, output as braille or
synthesized speech.

> 
> >Comment 2:
> >
> >I think that the definition of text element could very appropriately 
> >include the requirements of WCAG 1.0 checkpoint 14.1 ("Use 
> the clearest 
> >and simplest language appropriate for a site's content. 
> [Priority 1]"). 
> >For example, if a text equivalent fails to adhere to 
> checkpoint 14.1, the 
> >whole document fails to conform at the WCAG 1.0. However, I 
> am not sure 
> >that it is essential in this context.
> 
> HB: Nit. Who is to judge if the "clearest and simplest 
> language" is used?
> Few authors would rewrite. Few editors would reject.
> 

EH1: Sometimes I would really like to include the WCAG 1.0 checkpoint 14.1
provision as part of the definition of "text element"; one one sense it is
already an implicit part of the definition since if there is a candidate
text element that does not adhere to checkpoint 14.1, the page (and any site
built upon it) cannot conform at the WCAG single-A level. I think that "text
elements" and "text equivalents" (which are simply text elements that
fulfill the essential function of some other content) should exemplify our
conception of accessibilty. On the other hand, I am concerned that to make
that requirement an explict part of the definition may appear to overburden
the definition. And certainly, as you say, the checkpoint is very difficult
to validate. 

> 
> >Comment 3:
> >
> >Another possibly essential part of the definition could be 
> as follows: 
> >"The 'visually-displayed text' must be composed of one or 
> more characters 
> >from any of the standard [?] character sets. That is, if one 
> disregards 
> >stylistic features of the text, the visually displayed text 
> will look like 
> >standard graphical representations of the characters (or 
> glyphs) in the 
> >character set." One could also affirm similar things for 
> braille output, 
> >thought I don't think that we have to do this for this document. See 
> >suggestion this memo regarding the definition of "text".
> 
> HB: A glyph is a representation of a character, a particular 
> rendering of
> the abstract character represented by its character code in 
> some character
> set. Different fonts have different glyphs for the same 
> character code.
> 

EH1: Thanks for what seems to be a very clear explanation of the terms.
Maybe we need a definitions of "character" and "glyph" within the definition
of "Text" in the document. See definition below in this memo.


> >Comment 5:
> >
> >Under the proposed definitions, user agents must expect that 
> _markup_ may 
> >be found in text equivalents. However, I don't think that we 
> normally 
> >think of values of the "alt" attribute as containing markup. 
> Should we 
> >specify that user agents need to be ready to recognize the 
> contents either 
> >as: plain text, as marked up text, as a URI of a file to 
> open or execute? 
> >How can they be expected to recognize them as such?
> 
> HB: Some attribute values give metadata to aid presentation, possibly 
> triggering
> prefix and/or suffix text generation.
> 

EH1: Do you think that anything in the document needs to change to account
for this? Does anything like that operate on the "alt" attribute?

> 
> >====
> >
> >Suggestion 2: Fix checkpoint 7.5.
> >
> >Change the term "rendered text content" simply to "text 
> rendered from the 
> >DOM". The term "text content" has a special meaning (i.e., 
> content that is 
> >composed of one or more text elements).
> >
> >Old (1 September 2000):
> >
> >"7.5 Allow the user to search for rendered text content, including 
> >rendered text equivalents. Allow the user to start a forward 
> search from a 
> >location in content selected or focused by the user. After a 
> match, allow 
> >searching from location of the match. Provide a 
> case-insensitive search 
> >option when applicable to the natural language of text. [Priority 2]"
> >
> >New:
> >"7.5 Allow the user to search for text rendered from the 
> DOM, including 
> >rendered text equivalents. Allow the user to start a forward 
> search from a 
> >location in content selected or focused by the user. After a 
> match, allow 
> >searching from location of the match. Provide a 
> case-insensitive search 
> >option when applicable to the natural language of text. [Priority 2]"
> 
> HB: Text from the DOM: does it include generated list item 
> enumerations?
> Can I search on the 5th sub-list item enumerated with 
> lower-case letters,
> nested within the 3rd roman-enumerated list?

EH1: Somebody can correct me if I am wrong, but I suspect that the output
from the DOM might have structural markup that would allow some other
process (e.g., a rendering process) to produce the nested lists enumerated
with lower and uppercase letters, numbers, etc. If you feel that
case-sensitive search ought to be added to the checkpoint, perhaps you
should make proposal to that effect. 

> ...
> >New:
> >
> >"Content"
> >"In this specification, the term "content" is used in three ways:"
> >"1. Content refers to the DOM document object as a whole or 
> in parts. 
> >Phrases such as "content type" and "language of content" 
> refer to this 
> >usage. When used in this sense, the term content encompasses 
> equivalent 
> >alternatives. Refer also to the definition of rendered content <NOTE 
> >PERIOD DELETED> and other accessibility information."
> >"2. Content refers to the content of an HTML or XML element, 
> in the sense 
> >employed by the XML 1.0 specification ([XML], section 3.1): 
> "The text 
> >between the start-tag and end-tag is called the element's content." 
> >Context should indicate that the term content is being used 
> in this sense."
> 
> HB: Note that content can include embedded tags, either inline, or
> hierarchically subordinate. There is no requirement that 
> subordinate tags
> are rendered within that subordination, say a figure floating 
> to the top
> of a "page".

EH1: Doesn't the current definition of content allow that? I suppose that
the definition was thought to _not_ require comment on rendering. 

> 
> >"3. Content is used in the context of the phrase "non-text 
> content" and 
> >"text content". See definition of _non-text content_."
> >
> >New:
> >
> >Document Object, Document Object Model
> >
> >In general usage, the term "document object" refers to the 
> user agent's 
> >representation of data (e.g., a document). This data 
> generally comes from 
> >the document source, but may also be generated (from style sheets, 
> >scripts, transformations, etc.) or produced as a result of 
> preferences set 
> >within the user agent. Some data that is part of the 
> document object is 
> >routinely rendered (e.g., in HTML, what appears between the 
> start and end 
> >tags of elements and the values of attributes such as "alt", 
> "title", and 
> >"summary").
> 
> Only the non-hierarchic tags need rendering. Tags like div 
> and span often
> are ignored.
> 
> >  ... Other parts of the document object are generally 
> processed invisibly 
> > by the ...
> >
> >
> >Suggestion 7: Add a definition of "text".
> >
> >Per our earlier discussion [1], there should be a definition 
> of "text".
> >
> >I think that we need to be very thoughtful and deliberate 
> about adding 
> >such a definition. If we specify some set of character sets, 
> then what do 
> >we mean -- (a) that those sets must _all_ be supported or 
> (b) that user 
> >agents are _not required_ to support anything outside of 
> them or (c) that 
> >they _cannot_ support anything outside them?
> >
> >If we name a specific set of character sets as what we mean, 
> then we need 
> >to carefully examine the contexts of its use. I am not sure 
> how fully 
> >various character sets are supported in braille and 
> synthesized speech. 
> >Perhaps we need not have the definition specifically refer 
> to braille and 
> >synthesized speech renderings.
> >
> >Without necessary naming a particular set of character sets, 
> it might be 
> >valuable to simply make clear that when we refer to text we 
> are referring 
> >to the stuff of _character sets_ rather than to things like 
> sign language 
> >videos. (The term 'text' is sometimes used outside the document to 
> >encompass such divergent things.)
> 
> HB: Good points. The Unicode base of ISO 10646 is a broad 
> character set that
> should be our basis, I believe. I realize that broad support 
> for all of it
> is problematic. Most documents will use a minuscule portion of it.
> 

EH1: Following is a possible definition for "Text".

Proposed definition of "Text"

"Text"

"In a narrow, technical sense, 'text' refers to the abstract character
represented by its character code in some character set. This document uses
the term more broadly to include an additional meaning as _rendered
characters_ (which, particularly in visual renderings, are sometimes called
"glyphs" [EH comment: I presume that the term glyph was intended for visual
renderings and adaptable to some tactile renderings (e.g., sculpted relief
carvings of letters) but does it even apply in the area of synthetic speech
or braille?]). Different fonts have different glyphs for the same character
code. Although this document does not require support for any particular
character set, it is expected that user agent developers will implement
character sets like those found in the Unicode base of ISO 10646 [NEED
REFERENCE]. It should be noted that certain terms using the word "text" have
highly specialized meanings. (See the definitions of _non-text element,
non-text content, text element, text content, text equivalent, non-text
equivalent_.)"

> rendering of
> the abstract character represented by its character code in 
> some character
> set. 

END OF MEMO

Received on Friday, 22 September 2000 11:48:07 UTC