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.

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.


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

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


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


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

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


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

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

Regards/Harvey Bingham

Received on Thursday, 21 September 2000 23:12:01 UTC