Thread Subject: Re: Definition Consensus Decision: Text

From: Peter Korn
Date: Tue, Mar 11 2008 7:30 PM

• Return to this mailing list's archives
• View all messages in this thread
• Next message in thread: Gregg Vanderheiden: "Re: Definition Consensus Decision: Text"
• Previous message in thread: Phill Jenkins: "Re: Definition Consensus Decision: Text"
• Messages sorted by: Author | Thread | Date

Hi Gregg,

I took exception in our last call when you suggested that some industry
proposals around the FPC (that we appear to have consensed on [save for
the lack of quorum in today's meeting]) were part of some plot by
industry to shirk responsibilities, etc.. So perhaps what I'm about to
do is an instance of calling the kettle black... But:

We have a bunch of provisions upon which we have consensed or "recommend
consensed by those present" (but for lack of quorum), which include the
word "text". Drawing ONLY from these so marked consensed or recommend
consensed provisions, I find the following uses of the word "text":

- Authoring Tools definition ("Note: Simple *text *editors that..")
- CAPTHA definition ("...asking the user to type in *text *that is
presented in an obscured image...")
- Captions definition ("Captions are synchronized *text *equivalents
for...but also include *text *for non-spoken information...")
- Content definition ("For example: ... *text *files, ...")
- Contrast Ratio definition ("Note 3: *Text *can be evaluated with
anti-aliasing turned off." & "Note 4: ... over which the *text *is to be
rendered ..." & "Note 5: For *text *displayed over gradients and
background images...")
- Label definition ("*Text *or other component with a *text
*alternative that is presented to a user...")
- Large Scale *Text *definition (just in the title of the provision)
- TTY definition ("...equipment that enables interactive *text *based
communications..." & "TTYs are a subset of devices called *text
*telephones")
- 1-C Pass-Through ("...must also pass real-time *text *communication
signals...")
- 3-A Color ("...A conforming example is mandatory form fields are
identified with colored *text *and labeled as...")
- 3-B Contrast ("...Large-scale *text *and images of large-scale *text
*must have a contrast ratio..." & "Incidental: *Text *or images of *text
*that are part of an inactive user interface component, that are pure
decoration, that are incidental *text *in an image...")
- 3-D User Preferences ("...all *text *(and images of *text*) must have
a contrast ratio...except for the following: Large Print: Large-scale
*text *and images of large-scale *text *must ... Incidental: *Text *or
images of *text *that are part of an inactive user interface component
... that are incidental *text *in an image")
- 3-F Non-*text *Objects (This provision has the word "text" riddle
throughout it, nearly a dozen times)
- 3-G Human Language ("Note: In order to achieve this provision, *text
*encoded in data operated on by the software would need to be associated
with sufficient information to identify both the primary language of the
*text*, and the language of any sections or the *text *that are in
another language from the primary language, that the software can obtain
as readily as it can obtain the *text *itself.")
- 3-N Link Purpose ("... purpose of each link from the link *text *or
the link *text *together with..." & "...would need to be associated with
link *text *that the software can obtain...")
- 3-T Focus Indicator ("...presence of a highly visible *text
*insertion point is sufficient for a *text *area...")
- 3-U AT-IT Interoperability [excerpts from the consensed portion] ("
f. *text *contents, *text *attributes, and the boundary of *text
*rendered to the screen" & "...information necessary to track and
modify: focus, *text *insertion point...")
- 4-A Caption Processing ("...or decoding as displayed *text *or decode
a functional equivalent to TV closed captions..." & "...requires
synchronized *text *displayed on-screen..." & "...and *text *size for
captions...")
- 5-B Video Description ("...a separate *text *description of the
video..." [this excerpt appears twice in the provision])
- 6-A Real-Time *Text *Reliability and Interoperability (the term
"text" appears many times in this provision)
- 6-B Voice Terminal Hardware and Software (the term "text" appears many
times in this provision)

That is 21 consensed or recommended for consensus provisions that use
the word "text". There are a number of additional provisions (which I
didn't bother counting) which aren't yet consensed that likewise include
the word "text". Since the dictionary definitions that Randy provided
of "text" are quite different from the definition you propose, and
further, since your proposed definition in turn references another
proposed definition that thereby essentially means text is only text if
actual existing AT has demonstrated that it is capable of obtaining it,
you are changing the meaning of 21 provisions AFTER the committee agreed
to them while likely under the impression that the word "text" means in
these provisions what a dictionary would define it as meaning. Note
that "text" is a new definition being proposed by you; it wasn't in the
October 26th draft.

If I were a suspicious person - and especially given that it took 2
levels of indirection to find this subtle but significant ex-post-facto
changing of 21 consensed provisions - I would be tempted to suggest this
is part of some nefarious plot of yours to insert "determinable by
existing AT" into a ton of places where we agreed on language expecting
it didn't mean that.

I'm sorry Gregg, but I cannot accept that. Furthermore, I think we as a
committee cannot afford to risk re-opening 21 provisions in order to
consider whether they should intentionally mean "text" as in "that the
[text] be determinable by existing assistive technologies". Because
that is what we would have to do if we accept your two proposed
definitions - of "text" as requiring "programmatically determinable",
and "programmatically determinable" as requiring "that the information
be determinable by existing assistive technologies".


Finally, even if we did have all the time in the world to finish this -
and could re-discuss these 21 provisions and work through the new issues
involved in these definitions changes - the way you are making this
change is poor. To take Jessica's "lawyer argument" from earlier today
for referencing AT in every FPC, if we bury "determinable by existing
assistive technologies" into the definition of the term used in the
definition of another term that is used in 21+ places, we essentially
invite industry to put forth products that they honestly believe meet
508 but which in fact do not. We do this because it is orders of
magnitude easier to miss this meaning than it is a reference to AT at
the start and again at the end of a block of 9-10 short provisions. I'm
frankly stunned that you don't recognize that risk. It is almost as if
you are trying to "pull a fast one" with this proposal, and create a
situation in which agencies will be open to complaints and lawsuits (and
in turn, industry potentially liable for false statements to
governments). Surely that can't be your desire...


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> Ah I see what you are getting at.
>
>
>
> But in a standard -- you don't define terms in the abstract. You only
> define them as used in the standard.
>
>
>
>
>
> In this standard -- when we say "text" we mean text that AT can get at.
>
>
>
> If you create something that has "text" that only runs on a platform
> with no AT (e.g. GreggOS) then whatever you created would not pass
> the provisions in the accessibility standard because it can only be
> run on a platform that employees of the government with disability
> cannot use (because there is no AT for it)
>
>
>
>
>
> So as used in this standard -- when we say that something is
> accessible if you have a text equivalent -- we mean that it is
> accessible (or rather conforms to the standard) if you have an
> equivalent that AT can access as text and re-render in forms that fit
> users with disabilities.
>
>
>
>
>
> So the definition of Text in 508 (and in WCAG) is not meant to be a
> definition of the generic word text as used in society -- but rather
> what is meant in this accessibility standard when we say text.
>
>
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>
>
> ------------------------------------------------------------------------
>
> *From:* = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] *On Behalf Of
> *Peter Korn
> *Sent:* Tuesday, March 11, 2008 1:19 AM
> *To:* TEITAC Committee
> *Subject:* Re: [teitac-committee] Definition Consensus Decision: Text
>
> Hi Gregg,
>
> I'm going to try a different approach, rather than going
> point-counterpoint with you below.
>
> I suggest that text is something distinct from the rendering of
> the text. An HTML page is an example of this; a document is
> another. The source format of the text is a direct encoding of
> the characters, not an encoding of an image that happens to be
> text. This HTML/document/what-have-you is then typically rendered
> by some application (e.g. a web browser, a word processor), at
> which point AT enters the picture. Until it is rendered, there is
> no software running for AT to interact with.
>
> Your definition of text requires that it be rendered, and further,
> rendered on a platform for which AT exists, and for which AT is
> actually retrieving the information. By this argument then, HTML
> text is text when rendered on Windows with IE, but not on Windows
> with Opera. Certainly not when rendered on GreggOS that doesn't
> have AT on it.
>
> And this is where I am fundamentally bothered. A thing is a thing
> or isn't a thing depending upon where you happen to be looking at
> it? So my document is or isn't text depending upon several pieces
> of software that may be involved in the process of intermediating
> that text to the user.
>
> As I wrote in response to your Note 2 in your proposed definition
> of "programmatically determined", I think we should avoid
> redefining terms from their commonly understood meanings (cf.
> Randy's quote of several definitions of "text"), and rather if we
> mean something different, use a larger phrase and define that
> phrase. E.g. define the phrase "AT accessible text" and then use
> that phrase everywhere where we mean that throughout the TEITAC
> document.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
>
>
>
> Let me treat the different topics in your memo separately to make
> the reading simpler.
>
>
> *<!--[if !supportLists]-->1)* <!--[endif]-->We use text in
> many places
>
> You wrote
>
> As I think about this proposed definition more, I think it doesn't
> work for us because we use the term "text" an awful lot of places
> in the document. To pick just a few examples, we have "text
> descriptions" for video, we have "has text generation capability"
> from telephony provisions, "Examples of status or text information
> includes caller identification" in 6-D, and of course
> "real-time-text" (which may or may not be considered "text").
> Programmatic determination doesn't enter into most (all?) of these
> uses.
>
>
> You are correct --that we do use the word "text" in many places in
> the standard.
>
> However all of the uses mean text that can be read by AT.
>
> This includes your examples
>
> - "text descriptions" for video (These are text documents that
> are provided alongside video-only media so that blind people can
> read the descriptions. What good are they if a screen reader
> cannot read them?)
>
> - "text generation capability" for phone is also eText and needs
> to be accessible by AT or else TTYs cannot display them. Again
> not very useful if not.
>
> Etc.
>
> I looked and there isn't any use of text in the guidelines that
> doesn't mean text that can be read by AT of one sort or another.
> (although I saw a 2 notes that could be worded better). The
> closest thing to this would be Captions where pictures of text
> embedded in video can be used. The new definition though
> clarifies this and says "visual and text equivalents of auditory
> information" so it is covered there.
>
> In fact an "image of text" is called a "non-text object" in 3-F
> clearly indicating that images of text are not text.
>
> I do see that one guideline (that should apply to text and images
> of text) only mentions text. That is 1-G. We should change that
> to "text and images of text".
>
> If I missed one please do point it out -- but I couldn't find any
> use of text that we did not mean electronic text that is not
> accessible by software including AT.
>
> And if we DON'T define 'text' this way --then all of the
> provisions (and there are many) that make things accessible by
> providing text that AT is supposed to be able to read -- will not
> work.
>
> So I think the definition is good to have , and important to
> proper interpretation of the guidelines - as (I think it was
> Sean) pointed out.
>
>
> */2- programmatically determined /*
>
> You wrote
>
> Separately, I would like to explore my concerns with programmatic
> determinability. If we go with a definition of "programmatically
> determined" that requires the existence of actual AT that is
> actually using some programmatic means to obtain that text, then
> we have problems with the proposed definition of text in places
> like 3-N where we talk about link text. This a problem because we
> talk about text in this context in the source web page, and not in
> what/how the browser uses it, that platform of the browse, and the
> AT that may exist on said platform. The information is text
> irrespective of whether it is rendered in a browser on a platform
> with actual AT that is communicating with that browser and
> exposing the text therein.
>
> I don't follow you here. In 3-N we certainly do mean that the
> link text has to be accessible by AT. If the author includes
> the text in a way that is not known to be accessible by AT
> (Through browsers and OS) then the author has failed to make it
> accessible. I don't follow your argument here at all.
>
>
> */3- AT that exists/*
>
> You wrote
>
> Finally, if we look at this solely in the context of text rendered
> to the screen by an application, let us assume for a moment that I
> have a trivial application that draws text onto the screen that is
> passed to it on the command line (e.g. 'c:drawtext "hello
> world"'), and which exposes that text via some set of
> accessibility services. If no AT in existence is using that
> interface to retrieve that text, then we are to say that it isn't
> programmatically determinable? And separately, if I develop AT
> that uses OCR to read the text (there is a screen reader for the
> Amiga text console that does this), then I have an instance of
> text that an AT is obtaining through some programmatic means, so
> then by this definition should it be considered programmatically
> determinable?
>
> Yes -- we would say that text is not 'programmatically
> determinable' if "there is not AT in existence" that can access
> the text. Accessing it through OS services would count. And
> yes -- if someday we have perfect OCR in AT and it can accurately
> access the text even if it is an image -- then it would count.
> And WCAG is written such that this would be true. Note that the
> definition of TEXT does not require that it be encoded in any
> particular form. Just that it be programmatically
> determinable. Which is defined (in WCAG and hopefully here) as
> meaning determinable by software including AT. (not or AT but
> including AT). As long as AT can access the text and re-present
> it we did not feel that other constraints should be imposed.
>
> Does this help?
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
> ------------------------------------------------------------------------
>
> *From:* = EMAIL ADDRESS REMOVED =
> <mailto: = EMAIL ADDRESS REMOVED = >
> [mailto: = EMAIL ADDRESS REMOVED = ] *On Behalf
> Of *Peter Korn
> *Sent:* Monday, March 10, 2008 8:57 PM
> *To:* TEITAC Committee
> *Subject:* Re: [teitac-committee] Definition Consensus
> Decision: Text
>
> Hi Gregg, Mike,
>
> As I think about this proposed definition more, I think it
> doesn't work for us because we use the term "text" an awful
> lot of places in the document. To pick just a few examples,
> we have "text descriptions" for video, we have "has text
> generation capability" from telephony provisions, "Examples of
> status or text information includes caller identification" in
> 6-D, and of course "real-time-text" (which may or may not be
> considered "text"). Programmatic determination doesn't enter
> into most (all?) of these uses.
>
> Separately, I would like to explore my concerns with
> programmatic determinability. If we go with a definition of
> "programmatically determined" that requires the existence of
> actual AT that is actually using some programmatic means to
> obtain that text, then we have problems with the proposed
> definition of text in places like 3-N where we talk about link
> text. This a problem because we talk about text in this
> context in the source web page, and not in what/how the
> browser uses it, that platform of the browse, and the AT that
> may exist on said platform. The information is text
> irrespective of whether it is rendered in a browser on a
> platform with actual AT that is communicating with that
> browser and exposing the text therein.
>
> Finally, if we look at this solely in the context of text
> rendered to the screen by an application, let us assume for a
> moment that I have a trivial application that draws text onto
> the screen that is passed to it on the command line (e.g.
> 'c:drawtext "hello world"'), and which exposes that text via
> some set of accessibility services. If no AT in existence is
> using that interface to retrieve that text, then we are to say
> that it isn't programmatically determinable? And separately,
> if I develop AT that uses OCR to read the text (there is a
> screen reader for the Amiga text console that does this), then
> I have an instance of text that an AT is obtaining through
> some programmatic means, so then by this definition should it
> be considered programmatically determinable?
>
>
> I believe any definition of programmatically determinable (and
> any other definition which depends upon it, e.g. this proposed
> definition of text) should be dependent solely upon what the
> IT application in question does or does not do. Not on
> whether AT exists, whether AT uses published interfaces to
> obtain information, whether AT reverse engineers what is on
> the screen (or uses OCR techniques).
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
>
>
>
> Perhaps someone could clarify for me:
>
> if programatically determinable is a technical term for
> available to AT, then how does this definition apply to closed
> functionality. It would seem that text expresses human
> language regardless of whether or not it is presented in such
> a way as to be available to AT.
>
> ------------------------------------------------------------------------
>
> *From:* = EMAIL ADDRESS REMOVED =
> <mailto: = EMAIL ADDRESS REMOVED = >
> [mailto: = EMAIL ADDRESS REMOVED = ] *On Behalf
> Of *Mike Paciello
> *Sent:* Sunday, March 09, 2008 3:37 PM
> *To:* 'TEITAC Committee'
> *Subject:* [teitac-committee] Definition Consensus Decision: Text
>
> Following is the definition for **Text**. If you **_do_**
> **_not_** agree that this definition is acceptable, please
> reply and state your reason. Please note that this text is now
> harmonized with WCAG.
>
> **Text**
>
> "Sequence of characters that is programmatically determinable,
> where the sequence is expressing something in human language."
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>

• Next message in Thread: Gregg Vanderheiden: "Re: Definition Consensus Decision: Text"
• Previous message in Thread: Phill Jenkins: "Re: Definition Consensus Decision: Text"