Thread Subject: FW: Definition Consensus Decision: Simple TactileForm

Return to this mailing list's archives

From: Gregg Vanderheiden
Date: Mon, Mar 10 2008 11:00 AM
Subject: FW: Definition Consensus Decision: Simple TactileForm

A typo



The words "non-coded" were changed to "simple" in every place but one.



They should be changed there too.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Mike Paciello
Sent: Sunday, March 09, 2008 5:37 PM
To: 'TEITAC Committee'
Subject: [teitac-committee] Definition Consensus Decision: Simple
TactileForm

Following is the definition for Simple Tactile Form. If you do not agree
that this definition is acceptable, please reply and state your reason.



Simple Tactile Form



"Tactile form that does not require the memorization of any spatial or
temporal tactile patterns.

Note 1: Simple vibration or switch up/down positions are examples of simple
[DELETE - non-coded] tactile forms.

Note 2: Braille, tactile Morse code, and vibration patterns are examples of
more complex tactile forms that require memorization of non-trivial spatial
and tactile patterns respectively.

Note 3: Different numbers of tactile buzzes, or different frequency buzzes
would be non-trivial patterns, and would not be simple tactile forms."

From: Mike Paciello
Date: Mon, Mar 10 2008 11:05 AM
Subject: Re: Definition Consensus Decision: Text

Hi Peter -

I took that into consideration. However, my fear is that the discussion
around programmatically determinable is so closely attached to other
provision discussions, I didn't want to hold Text up, if possible.

Let me give this some thought.

Thanks for the heads up.

- Mike

Mike Paciello
Cell: +1.603.566.7713



_____

From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Monday, March 10, 2008 9:53 AM
To: = EMAIL ADDRESS REMOVED = ; TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision: Text


Hi Mike,

This definition is fine, EXCEPT that it uses a phrase that is also defined -
namely "programmatically determinable". Depending upon that definition,
this text definition is or is not fine by Sun. So, can we attempt consensus
on the 'programmatically determinable' definition first?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.



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



_____

From: Michele Budris
Date: Mon, Mar 10 2008 11:20 AM
Subject: Re: Definition Consensus Decision:Authoring Tools

Wiki has been updated.

Michele

On Mar 10, 2008, at 9:23 AM, Mike Paciello wrote:

> Thank you Andi. In fact, I've only directed the EWG to make the
> electronic
> content edit at this time.
>
> - Mike
>
> Mike Paciello
> Cell: +1.603.566.7713
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>> Of Andi Snow-Weaver
>> Sent: Monday, March 10, 2008 7:44 AM
>> To: TEITAC Committee
>> Subject: Re: [teitac-committee] Definition Consensus
>> Decision:Authoring Tools
>>
>> Mike and Robert,
>>
>> I don't think the phrase can be deleted. It's meant to scope
>> the definition to tools that support content formats which
>> enable the creation of accessible content. If you can't
>> create accessible content in the first place with a
>> particular content format, then there's no use requiring the
>> authoring tool to support the authoring tool requirements.
>>
>> Andi
>>
>>
>>
>>
>>
>> "Mike Paciello"
>>
>> <mpaciello@paciel
>>
>> logroup.com>
>> To
>> Sent by: "'Baker, Robert C.'"
>>
>> teitac-committee-
>> < = EMAIL ADDRESS REMOVED = >, "'TEITAC
>> = EMAIL ADDRESS REMOVED = Committee'"
>>
>> ac.org
>> < = EMAIL ADDRESS REMOVED = >
>>
>> cc
>>
>>
>> 03/10/2008 08:48
>> Subject
>> AM Re: [teitac-committee]
>> Definition
>> Consensus Decision:
>> Authoring
>> Tools
>>
>> Please respond to
>>
>> mpaciello@paciell
>>
>> ogroup.com;
>>
>> Please respond to
>>
>> TEITAC Committee
>>
>> <teitac-committee
>>
>> @list.teitac.org>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Thank you Robert. EWG will make the adjustment.
>>
>> -mike
>>
>> Mike Paciello
>> Cell: +1.603.566.7713
>>
>>
>> From: Baker, Robert C. [mailto: = EMAIL ADDRESS REMOVED = ] Sent:,
>> Monday, March 10, 2008 6:45 AM
>> To: = EMAIL ADDRESS REMOVED = ; TEITAC Committee
>> Subject: RE: [teitac-committee] Definition Consensus
>> Decision: Authoring Tools
>>
>> Concur with minor change,
>>
>> "Any software intended to create or modify electronic content
>> for publication in one or more formats that support
>> compliance with the user interface and content provisions.
>>
>> the current statement "that support compliance with the user
>> interface and content provisions" is confusing and perhaps
>> can be deleted.
>>
>> Robert
>>
>>
>>
>>

From: Michele Budris
Date: Mon, Mar 10 2008 11:25 AM
Subject: Re: Definition Consensus Decision: Enhanced Audio

The definition has bee updated to be:

Audio which has been enhanced through amplification and/or through a
variety of audio signal processing to make it easier for people with
hearing loss to understand.

This reflects the changes requested by Karen and Tony. Please
remember that this definition will be removed if the term is not used
in the provisions.

Thanks,
Michele


On Mar 10, 2008, at 9:36 AM, James Elekes wrote:

> Yes, Karen is correct. Base the affirmation per contact with NCD.
>
> -Jim
>
> James J. Elekes, m.Ed, MPA, CPM
> Former Public Member/TEITAC Liaison
> United States Access Board
> (O) 888.564.8430
> (E) = EMAIL ADDRESS REMOVED =
>
> At 11:19 AM 3/10/2008, you wrote:
>> I think the preferred term is "hearing loss" not "hearing
>> impairments."
>>
>> Karen
>> ----- Original Message -----
>> From: <mailto: = EMAIL ADDRESS REMOVED = >Mike Paciello
>> To: <mailto: = EMAIL ADDRESS REMOVED = >'TEITAC Committee'
>> Sent: Sunday, March 09, 2008 6:37 PM
>> Subject: [teitac-committee] Definition Consensus Decision:
>> Enhanced Audio
>>
>> Following is the definition for Enhanced Audio. If you do not agree
>> that this definition is acceptable, please reply and state your
>> reason. Please note that this definition was added to support 1.1-E
>> - With Limited Hearing. If the committee decides to rewrite the
>> 1.1-E provision, the definition is not needed and will be removed.
>> Consensus for this definition includes accepting the definition and
>> agreeing to removing it if no longer needed.
>>
>> Enhanced Audio
>>
>> "Audio which has been enhanced through amplification and/or through
>> a variety of audio filters to make it easier for people with hearing
>> impairments to understand."
>>
>>
>>
>>
>> ----------
>>

From: Michele Budris
Date: Mon, Mar 10 2008 11:35 AM
Subject: Re: FW: Definition Consensus Decision: Simple TactileForm

Done.

Michele

On Mar 10, 2008, at 10:42 AM, Gregg Vanderheiden wrote:

> A typo
>
> The words �non-coded� were changed to �simple� in every place but
> one.
>
> They should be changed there too.
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> From: = EMAIL ADDRESS REMOVED = [mailto:teitac-
> = EMAIL ADDRESS REMOVED = ] On Behalf Of Mike Paciello
> Sent: Sunday, March 09, 2008 5:37 PM
> To: 'TEITAC Committee'
> Subject: [teitac-committee] Definition Consensus Decision: Simple
> TactileForm
>
> Following is the definition for Simple Tactile Form. If you do not
> agree that this definition is acceptable, please reply and state
> your reason.
>
> Simple Tactile Form
>
> "Tactile form that does not require the memorization of any spatial
> or temporal tactile patterns.
>
> Note 1: Simple vibration or switch up/down positions are examples
> of simple [DELETE - non-coded] tactile forms.
>
> Note 2: Braille, tactile Morse code, and vibration patterns are
> examples of more complex tactile forms that require memorization of
> non-trivial spatial and tactile patterns respectively.
>
> Note 3: Different numbers of tactile buzzes, or different frequency
> buzzes would be non-trivial patterns, and would not be simple
> tactile forms."
>
>

From: DEBORAH E. COOK
Date: Mon, Mar 10 2008 5:45 PM
Subject: Re: Definition Consensus Decision: Simple Tactile Form

I'm OK with this except as noted by someone regarding the switch up/down mode. I've seen too many variants on how this gets interpreted to the point I have to trial and error to see what the intent would be.

From: DEBORAH E. COOK
Date: Mon, Mar 10 2008 5:50 PM
Subject: Re: Definition Consensus Decision: Text

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: Gregg Vanderheiden
Date: Mon, Mar 10 2008 6:00 PM
Subject: Re: Definition Consensus Decision: Text

Hi Debbie,



This does not apply to closed products. The term is used in places where
we need to have text available to AT. For example, if you had a text
equivalent for a picture which was a picture of text (rather than text that
AT could access) then it would do little good.



So when we say that the information needs to be in text - we mean text that
can be programmatically determined.



The human language part has to do with ASCII art or charts made out of
underlines and pipe characters. They are made of characters - but since
screen reader can't render them they would not useful. Hence - it must be
text in a human language. Math does count by the way.



Does that help?




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of DEBORAH E.
COOK
Sent: Monday, March 10, 2008 6:46 PM
To: = EMAIL ADDRESS REMOVED = ; TEITACCommittee
Subject: Re: [teitac-committee] Definition Consensus Decision: Text

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

From: DEBORAH E. COOK
Date: Mon, Mar 10 2008 6:30 PM
Subject: Re: Definition Consensus Decision: Text

Yes that's fine.

From: Peter Korn
Date: Mon, Mar 10 2008 8:00 PM
Subject: Re: 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 = ] *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."
>
> ------------------------------------------------------------------------
>
>

From: Randy Marsden
Date: Mon, Mar 10 2008 10:10 PM
Subject: Re: Definition Consensus Decision: Simple Tactile Form

The notes here are confusing to me. For example, Note 1 refers to
examples of non-coded tactile forms, yet the definition doesn't
specifically talk about "non-coded tactile forms". So is Note 1
saying using vibration or switch up/down is a good thing, or a bad
thing? Similarly for Note 2: are these examples of what NOT to do?
It doesn't explicitly say that, and I had to read them a few times to
figure it out.

Hmmm (gregg-ism)

How about:

Simple Tactile Form

"Tactile form that does not require the memorization of any spatial or
temporal tactile patterns"

Note 1: A simple vibration or a switch with up/down positions do not
involve complex tactile coding, and are good examples of Simple
Tactile Forms.

Note 2: Braille, tactile Morse code, and vibration patterns are
samples of more complex tactile forms that require memorization of non-
trivial spatial and tactile patterns respectively, and therefore are
not Simple Tactile Forms.

Note 3: (as is)

-Randy

>
> .
>
> From: = 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: Simple
> Tactile Form
>
> Following is the definition for Simple Tactile Form. If you do not
> agree that this definition is acceptable, please reply and state
> your reason.
>
> Simple Tactile Form
>
> "Tactile form that does not require the memorization of any spatial
> or temporal tactile patterns.
> Note 1: Simple vibration or switch up/down positions are examples of
> non-coded tactile forms.
>
> Note 2: Braille, tactile Morse code, and vibration patterns are
> examples of more complex tactile forms that require memorization of
> non-trivial spatial and tactile patterns respectively.
>
> Note 3: Different numbers of tactile buzzes, or different frequency
> buzzes would be non-trivial patterns, and would not be simple
> tactile forms."
>
>

From: Randy Marsden
Date: Mon, Mar 10 2008 10:35 PM
Subject: Re: Definition Consensus Decision: Text

Wikipedia says:

Text may refer to:
Plain text
Book
TEXT, a Swedish band formed by 3/4 ex-Refused Members.
Text file, a computer file consisting solely of characters from a
recognized character set

I'm thinking we go with number 3 - the Swedish band definition ;-)

Seriously, don't we just mean text that is electronically stored (as
opposed to pixels in a picture that happen to form letters)? Is it
getting too technical if we just say:

"Text: A sequence of characters representing human language that is
encoded electronically in a standard form such as ASCII or Unicode".

If it's ASCII or Unicode, then AT should be able to do something with
it, provided it is sufficiently exposed (via API's or other ways).

-Randy
ATIA



On Mar 10, 2008, at 7:56 PM, Peter Korn wrote:

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

From: Gregg Vanderheiden
Date: Mon, Mar 10 2008 10:40 PM
Subject: Re: Definition Consensus Decision: SimpleTactile Form

Note 1 had a typo/edito in it



You will see it is repaired in the WIKI.



So those are examples of things that pass.

Note 2 are failures.



Your edit to note 1 is no longer necessary (see WiKI which is shorter and
doesn't use (any longer) the discarded term "non-coded" which Sean pointed
out was flawed.)

But your edit to note 2 I think is very good. Recommend acceptance.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Randy Marsden
Sent: Monday, March 10, 2008 11:07 PM
To: TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision: SimpleTactile
Form

The notes here are confusing to me. For example, Note 1 refers to examples
of non-coded tactile forms, yet the definition doesn't specifically talk
about "non-coded tactile forms". So is Note 1 saying using vibration or
switch up/down is a good thing, or a bad thing? Similarly for Note 2: are
these examples of what NOT to do? It doesn't explicitly say that, and I had
to read them a few times to figure it out.



Hmmm (gregg-ism)



How about:



Simple Tactile Form



"Tactile form that does not require the memorization of any spatial or
temporal tactile patterns"



Note 1: A simple vibration or a switch with up/down positions do not
involve complex tactile coding, and are good examples of Simple Tactile
Forms.



Note 2: Braille, tactile Morse code, and vibration patterns are samples of
more complex tactile forms that require memorization of non-trivial spatial
and tactile patterns respectively, and therefore are not Simple Tactile
Forms.



Note 3: (as is)



-Randy





.




_____


From: = 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: Simple Tactile
Form

Following is the definition for Simple Tactile Form. If you do not agree
that this definition is acceptable, please reply and state your reason.



Simple Tactile Form



"Tactile form that does not require the memorization of any spatial or
temporal tactile patterns.

Note 1: Simple vibration or switch up/down positions are examples of
non-coded tactile forms.

Note 2: Braille, tactile Morse code, and vibration patterns are examples of
more complex tactile forms that require memorization of non-trivial spatial
and tactile patterns respectively.

Note 3: Different numbers of tactile buzzes, or different frequency buzzes
would be non-trivial patterns, and would not be simple tactile forms."

From: Gregg Vanderheiden
Date: Mon, Mar 10 2008 11:30 PM
Subject: Re: Definition Consensus Decision: Text

Hi Randy,



That would be a good dictionary definition (and we had one like that in the
beginning) but it was pointed out that there were problems with is. I don't
remember them all but you can't have "such as" in a definition in a
standard. And people also pointed that without specifying ASCII or some
encoding, the information encoded in EBCDIC (hello IBMers) would pass - but
would not help any screen readers. Also other codes. In the end we came
back to - 'it doesn't matter what code is used as long as AT can handle it -
and if AT can't then it is of no use as a way of conveying information
accessibly).



Hence the definition.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Randy Marsden
Sent: Monday, March 10, 2008 11:31 PM
To: TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision: Text

Wikipedia says:



Text may refer to:

* <http://en.wikipedia.org/wiki/Plain_text> Plain text

* <http://en.wikipedia.org/wiki/Book> Book

* <http://en.wikipedia.org/wiki/TEXT> TEXT, a Swedish band
formed by 3/4 ex- <http://en.wikipedia.org/wiki/Refused> Refused Members.

* <http://en.wikipedia.org/wiki/Text_file> Text file, a
computer file consisting solely of characters from a recognized character
set



I'm thinking we go with number 3 - the Swedish band definition ;-)



Seriously, don't we just mean text that is electronically stored (as opposed
to pixels in a picture that happen to form letters)? Is it getting too
technical if we just say:



"Text: A sequence of characters representing human language that is encoded
electronically in a standard form such as ASCII or Unicode".



If it's ASCII or Unicode, then AT should be able to do something with it,
provided it is sufficiently exposed (via API's or other ways).



-Randy

ATIA







On Mar 10, 2008, at 7:56 PM, Peter Korn wrote:



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








_____

From: Gregg Vanderheiden
Date: Mon, Mar 10 2008 11:45 PM
Subject: Re: Definition Consensus Decision: Text

Hi Peter,



Thanks for your email



Let me treat the different topics in your memo separately to make the
reading simpler.




1) 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 = ] 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 = ] 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."






_____

From: Peter Korn
Date: Tue, Mar 11 2008 12:25 AM
Subject: Re: 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.
>
>
>
>
> *1) *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 = ] *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."
>
>
>
> ------------------------------------------------------------------------
>
>
>
>
>

From: Gregg Vanderheiden
Date: Tue, Mar 11 2008 12:45 AM
Subject: Re: Definition Consensus Decision: Text

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








_____

From: Hoffman, Allen
Date: Tue, Mar 11 2008 7:40 AM
Subject: Re: Definition Consensus Decision: SimpleTactile Form

I can live with the definitions, but would like to see a note that
basically says:
If Braille is used, it is considered sufficient to meet this
requirement.

For labeling hardware, Braille, when it fits in the available space, is
an alternate to print for people with visual disabilities. Indicating
this is not sufficient to meet this requirement doesn't make sense to
me. While there are blind people who don't read Braille, generally this
is not due to their disability, but to their education.




Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303

From: Gregg Vanderheiden
Date: Tue, Mar 11 2008 9:50 AM
Subject: Re: Definition Consensus Decision:SimpleTactile Form

Hi Allen,



Although Braille is very powerful for those who know it - and it should be
highly encouraged, only a minority of people who lose their vision know
braille. Those who are older when they lose their vision do no know
Braille. Soldiers who are blinded do not know braille and often may not
have fingers that can read braille (calloused, burns, etc). And those who
lose vision to diabetes also often have no sensation in their fingertips.



So the note says that Braille is good but does not meet the requirement.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Hoffman,
Allen
Sent: Tuesday, March 11, 2008 8:38 AM
To: TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision:SimpleTactile
Form

I can live with the definitions, but would like to see a note that basically
says:

If Braille is used, it is considered sufficient to meet this requirement.



For labeling hardware, Braille, when it fits in the available space, is an
alternate to print for people with visual disabilities. Indicating this is
not sufficient to meet this requirement doesn't make sense to me. While
there are blind people who don't read Braille, generally this is not due to
their disability, but to their education.







Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Randy Marsden
Sent: Tuesday, March 11, 2008 12:07 AM
To: TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision: SimpleTactile
Form

The notes here are confusing to me. For example, Note 1 refers to examples
of non-coded tactile forms, yet the definition doesn't specifically talk
about "non-coded tactile forms". So is Note 1 saying using vibration or
switch up/down is a good thing, or a bad thing? Similarly for Note 2: are
these examples of what NOT to do? It doesn't explicitly say that, and I had
to read them a few times to figure it out.



Hmmm (gregg-ism)



How about:



Simple Tactile Form



"Tactile form that does not require the memorization of any spatial or
temporal tactile patterns"



Note 1: A simple vibration or a switch with up/down positions do not
involve complex tactile coding, and are good examples of Simple Tactile
Forms.



Note 2: Braille, tactile Morse code, and vibration patterns are samples of
more complex tactile forms that require memorization of non-trivial spatial
and tactile patterns respectively, and therefore are not Simple Tactile
Forms.



Note 3: (as is)



-Randy





.




_____


From: = 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: Simple Tactile
Form

Following is the definition for Simple Tactile Form. If you do not agree
that this definition is acceptable, please reply and state your reason.



Simple Tactile Form



"Tactile form that does not require the memorization of any spatial or
temporal tactile patterns.

Note 1: Simple vibration or switch up/down positions are examples of
non-coded tactile forms.

Note 2: Braille, tactile Morse code, and vibration patterns are examples of
more complex tactile forms that require memorization of non-trivial spatial
and tactile patterns respectively.

Note 3: Different numbers of tactile buzzes, or different frequency buzzes
would be non-trivial patterns, and would not be simple tactile forms."

From: Andi Snow-Weaver
Date: Tue, Mar 11 2008 1:05 PM
Subject: Re: Definition Consensus Decision: Text

Weighing in here in response to Gregg's "hello IBMers".....

Text encoded in EBCDC (as I recall, there is no "I") would fail to work
with a lot more than just AT so I don't think you have to worry about it.

Andi




Gregg
Vanderheiden
< = EMAIL ADDRESS REMOVED = To
u> "'TEITAC Committee'"
Sent by: < = EMAIL ADDRESS REMOVED = >
teitac-committee- cc
= EMAIL ADDRESS REMOVED =
ac.org Subject
Re: [teitac-committee] Definition
Consensus Decision: Text
03/11/2008 12:25
AM


Please respond to
TEITAC Committee
<teitac-committee
@list.teitac.org>






Hi Randy,

That would be a good dictionary definition (and we had one like that in the
beginning) but it was pointed out that there were problems with is. I
don't remember them all but you can't have �such as� in a definition in a
standard. And people also pointed that without specifying ASCII or some
encoding, the information encoded in EBCDIC (hello IBMers) would pass �
but would not help any screen readers. Also other codes. In the end we
came back to � �it doesn�t matter what code is used as long as AT can
handle it � and if AT can't then it is of no use as a way of conveying
information accessibly).

Hence the definition.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Randy
Marsden
Sent: Monday, March 10, 2008 11:31 PM
To: TEITAC Committee,
Subject: Re: [teitac-committee] Definition Consensus Decision: Text
Wikipedia says:

Text may refer to::
§ Plain text
§ Book
§ TEXT, a Swedish band formed by 3/4 ex-Refused Members.
§ Text file, a computer file consisting solely of
characters from a recognized character set

I'm thinking we go with number 3 - the Swedish band definition ;-)

Seriously, don't we just mean text that is electronically stored (as
opposed to pixels in a picture that happen to form letters)? Is it
getting too technical if we just say:

"Text: A sequence of characters representing human language that is
encoded electronically in a standard form such as ASCII or Unicode".

If it's ASCII or Unicode, then AT should be able to do something with it,
provided it is sufficiently exposed (via API's or other ways)..

-Randy
ATIA



On Mar 10, 2008, at 7:56 PM, Peter Korn wrote:

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











_______________________________________________
teitac-committee mailing list
= EMAIL ADDRESS REMOVED =
http://list.teitac.org/mailman/listinfo/teitac-committee

From: Andi Snow-Weaver
Date: Tue, Mar 11 2008 1:10 PM
Subject: Re: Definition Consensus Decision:Authoring Tools

Allen,

> Just because that format is inaccessible does not, in my
view, mean that the tool shouldn't produce accessible content. It can't
because the format chosen won't allow it to work. How do we address
this?

I'm not quite following what your're getting at. It seems like these
statements are contradictory: the tool should produce accessible content
but it can't because the format doesn't support it.

Andi




"Hoffman, Allen"
<Allen.Hoffman@dh
s.gov> To
Sent by: "TEITAC Committee"
teitac-committee- < = EMAIL ADDRESS REMOVED = >
= EMAIL ADDRESS REMOVED = cc
ac.org
Subject
Re: [teitac-committee] Definition
03/10/2008 10:05 Consensus Decision:Authoring
AM Tools


Please respond to
TEITAC Committee
<teitac-committee
@list.teitac.org>






Andi is correct.

The idea was, that for a tool like NotePad, which edits files in ASCII,
such things as alternate text are not feasible, or sensible, so the
authoring tool requirements would not be applicable. My only question,
Andi, is, how should such tools be considered? If we can identify that
maybe an additional note for such tools would be helpful?

So, for example, an org-chart program uses a proprietary format to
present the organizations, it has graphics, relationships, text, and
pictures. Just because that format is inaccessible does not, in my
view, mean that the tool shouldn't produce accessible content. It can't
because the format chosen won't allow it to work. How do we address
this?




Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi
Snow-Weaver
Sent: Monday, March 10, 2008 10:44 AM
To: TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision:Authoring
Tools

Mike and Robert,

I don't think the phrase can be deleted. It's meant to scope the
definition to tools that support content formats which enable the
creation of accessible content. If you can't create accessible content
in the first place with a particular content format, then there's no use
requiring the authoring tool to support the authoring tool requirements.

Andi





"Mike Paciello"

<mpaciello@paciel

logroup.com>
To
Sent by: "'Baker, Robert C.'"

teitac-committee- < = EMAIL ADDRESS REMOVED = >,
"'TEITAC
= EMAIL ADDRESS REMOVED = Committee'"

ac.org
< = EMAIL ADDRESS REMOVED = >

cc


03/10/2008 08:48
Subject
AM Re: [teitac-committee] Definition

Consensus Decision: Authoring

Tools

Please respond to

mpaciello@paciell

ogroup.com;

Please respond to

TEITAC Committee

<teitac-committee

@list.teitac.org>









Thank you Robert. EWG will make the adjustment.

-mike

Mike Paciello
Cell: +1.603.566.7713


From: Baker, Robert C. [mailto: = EMAIL ADDRESS REMOVED = ] Sent:, Monday,
March 10, 2008 6:45 AM
To: = EMAIL ADDRESS REMOVED = ; TEITAC Committee
Subject: RE: [teitac-committee] Definition Consensus Decision: Authoring
Tools

Concur with minor change,

"Any software intended to create or modify electronic content for
publication in one or more formats that support compliance with the user
interface and content provisions.

the current statement "that support compliance with the user interface
and content provisions" is confusing and perhaps can be deleted.

Robert

From: Judy Brewer
Date: Tue, Mar 11 2008 1:55 PM
Subject: Re: Definition Consensus Decision:Authoring Tools

I concur with Andi and Allen that the scoping phrase
"that support compliance with the user interface and content
provisions"
is necessary.

Allen, I'm unclear about your question below, though. Are you
suggesting that there are other requirements that should fall on
these otherwise out-of-scope tools? The example of an inaccessible
org chart unfortunately doesn't help me understand your comment,
since if it were built with Scalable Vector Graphics (SVG), the
relationships among the graphics should be accessible; therefore, I
think that an SVG authoring tool would fall within the scope of this
definition of authoring tool; therefore, for at least some org chart
authoring tools, it is possible for them to support accessibility.

- Judy

At 11:05 AM 3/10/2008 -0400, Hoffman, Allen wrote:
>Andi is correct.
>
>The idea was, that for a tool like NotePad, which edits files in ASCII,
>such things as alternate text are not feasible, or sensible, so the
>authoring tool requirements would not be applicable. My only question,
>Andi, is, how should such tools be considered? If we can identify that
>maybe an additional note for such tools would be helpful?
>
>So, for example, an org-chart program uses a proprietary format to
>present the organizations, it has graphics, relationships, text, and
>pictures. Just because that format is inaccessible does not, in my
>view, mean that the tool shouldn't produce accessible content. It can't
>because the format chosen won't allow it to work. How do we address
>this?
>
>
>Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
>-----Original Message-----
>From: = EMAIL ADDRESS REMOVED =
>[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi
>Snow-Weaver
>Sent: Monday, March 10, 2008 10:44 AM
>To: TEITAC Committee
>Subject: Re: [teitac-committee] Definition Consensus Decision:Authoring
>Tools
>
>Mike and Robert,
>
>I don't think the phrase can be deleted. It's meant to scope the
>definition to tools that support content formats which enable the
>creation of accessible content. If you can't create accessible content
>in the first place with a particular content format, then there's no use
>requiring the authoring tool to support the authoring tool requirements.
>
>Andi
>
>
> "Mike Paciello"
>
> <mpaciello@paciel
>
> logroup.com>
>To
> Sent by: "'Baker, Robert C.'"
>
> teitac-committee- < = EMAIL ADDRESS REMOVED = >,
>"'TEITAC
> = EMAIL ADDRESS REMOVED = Committee'"
>
> ac.org
>< = EMAIL ADDRESS REMOVED = >
>
>cc
>
>
> 03/10/2008 08:48
>Subject
> AM Re: [teitac-committee] Definition
>
> Consensus Decision: Authoring
>
> Tools
>
> Please respond to
>
> mpaciello@paciell
>
> ogroup.com;
>
> Please respond to
>
> TEITAC Committee
>
> <teitac-committee
>
> @list.teitac.org>
>
>
>
>
>
>
>
>
>
>Thank you Robert. EWG will make the adjustment.
>
>-mike
>
>Mike Paciello
>Cell: +1.603.566.7713
>
>
>From: Baker, Robert C. [mailto: = EMAIL ADDRESS REMOVED = ] Sent:, Monday,
>March 10, 2008 6:45 AM
>To: = EMAIL ADDRESS REMOVED = ; TEITAC Committee
>Subject: RE: [teitac-committee] Definition Consensus Decision: Authoring
>Tools
>
>Concur with minor change,
>
>"Any software intended to create or modify electronic content for
>publication in one or more formats that support compliance with the user
>interface and content provisions.
>
>the current statement "that support compliance with the user interface
>and content provisions" is confusing and perhaps can be deleted.
>
>Robert
>
>
>
>

From: Hoffman, Allen
Date: Tue, Mar 11 2008 2:10 PM
Subject: Re: Definition Consensus Decision:Authoring Tools

I think I'm just linking format encoding capacity with the tool, which
is true, e.g. format that can't encode the accessibility information but
the tool won't be able to either. I think what we have is sufficient.



Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Judy
Brewer
Sent: Tuesday, March 11, 2008 12:27 PM
To: TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision:Authoring
Tools

I concur with Andi and Allen that the scoping phrase
"that support compliance with the user interface and content
provisions"
is necessary.

Allen, I'm unclear about your question below, though. Are you suggesting
that there are other requirements that should fall on these otherwise
out-of-scope tools? The example of an inaccessible org chart
unfortunately doesn't help me understand your comment, since if it were
built with Scalable Vector Graphics (SVG), the relationships among the
graphics should be accessible; therefore, I think that an SVG authoring
tool would fall within the scope of this definition of authoring tool;
therefore, for at least some org chart authoring tools, it is possible
for them to support accessibility.

- Judy

At 11:05 AM 3/10/2008 -0400, Hoffman, Allen wrote:
>Andi is correct.
>
>The idea was, that for a tool like NotePad, which edits files in ASCII,

>such things as alternate text are not feasible, or sensible, so the
>authoring tool requirements would not be applicable. My only question,

>Andi, is, how should such tools be considered? If we can identify that

>maybe an additional note for such tools would be helpful?
>
>So, for example, an org-chart program uses a proprietary format to
>present the organizations, it has graphics, relationships, text, and
>pictures. Just because that format is inaccessible does not, in my
>view, mean that the tool shouldn't produce accessible content. It
>can't because the format chosen won't allow it to work. How do we
>address this?
>
>
>Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
>-----Original Message-----
>From: = EMAIL ADDRESS REMOVED =
>[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi
>Snow-Weaver
>Sent: Monday, March 10, 2008 10:44 AM
>To: TEITAC Committee
>Subject: Re: [teitac-committee] Definition Consensus Decision:Authoring

>Tools
>
>Mike and Robert,
>
>I don't think the phrase can be deleted. It's meant to scope the
>definition to tools that support content formats which enable the
>creation of accessible content. If you can't create accessible content
>in the first place with a particular content format, then there's no
>use requiring the authoring tool to support the authoring tool
requirements.
>
>Andi
>
>
> "Mike Paciello"
>
> <mpaciello@paciel
>
> logroup.com>
>To
> Sent by: "'Baker, Robert C.'"
>
> teitac-committee- < = EMAIL ADDRESS REMOVED = >,
>"'TEITAC
> = EMAIL ADDRESS REMOVED = Committee'"
>
> ac.org
>< = EMAIL ADDRESS REMOVED = >
>
>cc
>
>
> 03/10/2008 08:48
>Subject
> AM Re: [teitac-committee]
Definition
>
> Consensus Decision: Authoring
>
> Tools
>
> Please respond to
>
> mpaciello@paciell
>
> ogroup.com;
>
> Please respond to
>
> TEITAC Committee
>
> <teitac-committee
>
> @list.teitac.org>
>
>
>
>
>
>
>
>
>
>Thank you Robert. EWG will make the adjustment.
>
>-mike
>
>Mike Paciello
>Cell: +1.603.566.7713
>
>
>From: Baker, Robert C. [mailto: = EMAIL ADDRESS REMOVED = ] Sent:, Monday,
>March 10, 2008 6:45 AM
>To: = EMAIL ADDRESS REMOVED = ; TEITAC Committee
>Subject: RE: [teitac-committee] Definition Consensus Decision:
>Authoring Tools
>
>Concur with minor change,
>
>"Any software intended to create or modify electronic content for
>publication in one or more formats that support compliance with the
>user interface and content provisions.
>
>the current statement "that support compliance with the user interface
>and content provisions" is confusing and perhaps can be deleted.
>
>Robert
>
>
>
>

From: Hoffman, Allen
Date: Tue, Mar 11 2008 2:35 PM
Subject: Re: Definition Consensus Decision:Authoring Tools

circular thinking on my part, please delete thinking here....



Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi
Snow-Weaver
Sent: Tuesday, March 11, 2008 11:00 AM
To: TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision:Authoring
Tools

Allen,

> Just because that format is inaccessible does not, in my
view, mean that the tool shouldn't produce accessible content. It can't
because the format chosen won't allow it to work. How do we address
this?

I'm not quite following what your're getting at. It seems like these
statements are contradictory: the tool should produce accessible content
but it can't because the format doesn't support it.

Andi





"Hoffman, Allen"

<Allen.Hoffman@dh

s.gov>
To
Sent by: "TEITAC Committee"

teitac-committee-
< = EMAIL ADDRESS REMOVED = >
= EMAIL ADDRESS REMOVED =
cc
ac.org


Subject
Re: [teitac-committee] Definition

03/10/2008 10:05 Consensus Decision:Authoring

AM Tools





Please respond to

TEITAC Committee

<teitac-committee

@list.teitac.org>









Andi is correct.

The idea was, that for a tool like NotePad, which edits files in ASCII,
such things as alternate text are not feasible, or sensible, so the
authoring tool requirements would not be applicable. My only question,
Andi, is, how should such tools be considered? If we can identify that
maybe an additional note for such tools would be helpful?

So, for example, an org-chart program uses a proprietary format to
present the organizations, it has graphics, relationships, text, and
pictures. Just because that format is inaccessible does not, in my
view, mean that the tool shouldn't produce accessible content. It can't
because the format chosen won't allow it to work. How do we address
this?




Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi
Snow-Weaver
Sent: Monday, March 10, 2008 10:44 AM
To: TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision:Authoring
Tools

Mike and Robert,

I don't think the phrase can be deleted. It's meant to scope the
definition to tools that support content formats which enable the
creation of accessible content. If you can't create accessible content
in the first place with a particular content format, then there's no use
requiring the authoring tool to support the authoring tool requirements.

Andi





"Mike Paciello"

<mpaciello@paciel

logroup.com>
To
Sent by: "'Baker, Robert C.'"

teitac-committee- < = EMAIL ADDRESS REMOVED = >,
"'TEITAC
= EMAIL ADDRESS REMOVED = Committee'"

ac.org
< = EMAIL ADDRESS REMOVED = >

cc


03/10/2008 08:48
Subject
AM Re: [teitac-committee] Definition

Consensus Decision: Authoring

Tools

Please respond to

mpaciello@paciell

ogroup.com;

Please respond to

TEITAC Committee

<teitac-committee

@list.teitac.org>









Thank you Robert. EWG will make the adjustment.

-mike

Mike Paciello
Cell: +1.603.566.7713


From: Baker, Robert C. [mailto: = EMAIL ADDRESS REMOVED = ] Sent:, Monday,
March 10, 2008 6:45 AM
To: = EMAIL ADDRESS REMOVED = ; TEITAC Committee
Subject: RE: [teitac-committee] Definition Consensus Decision: Authoring
Tools

Concur with minor change,

"Any software intended to create or modify electronic content for
publication in one or more formats that support compliance with the user
interface and content provisions.

the current statement "that support compliance with the user interface
and content provisions" is confusing and perhaps can be deleted.

Robert

From: Phill Jenkins
Date: Tue, Mar 11 2008 3:30 PM
Subject: Re: Definition Consensus Decision: Text

I doubt there are any more working "Talking 3270" terminals - but they
worked fine as early screen readers for blind data operators - so there is
nothing inherently wrong with EBCDIC [see note]. After the "talking 3270"
came Screen Reader/DOS and Screen Reader OS/2 in the 1980's. And the 3270
terminals were replaced with 3270 emulators that run on DOS, OS/2 and now
Windows still today. The ASCII characters in the emulators are perfectly
accessible to today's screen readers but need a lot of custom scripting
since it is plain text, but the scripting is so old or common that
everyone takes for granted that it is accessible. These "green screens of
text" are fairly compliant to the rest of the provisions too. I'm
actually giving a talk at CSUN 2008 about the newer (more accessible) ways
of accessing the mainframe data and applications using JAVA and/or HTML
browser clients in addition to 3270 emulators.

See http://en.wikipedia.org/wiki/EBCDIC

Text is text, independent of the encoding which is easily transformed. It
really doesn't matter if its ASCII, EBCDIC, UNICODE, etc. The problem
with text is when it is used as "art" as commonly called "ASCII ART", when
tab stops or spaces are used to create multi-column layouts, and when
nonreaders of English need the text translated into other forms such as
pictures or sign language.

Regards,
Phill Jenkins
IBM Research - Human Ability & Accessibility Center
http://www.ibm.com/able

From: Peter Korn
Date: Tue, Mar 11 2008 7:30 PM
Subject: Re: Definition Consensus Decision: Text

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

From: Gregg Vanderheiden
Date: Tue, Mar 11 2008 11:25 PM
Subject: Re: Definition Consensus Decision: Text

Hi Peter,





I don't know what to do with this memo.





First - It was industry not me that suggested we bring the definition of
Text over from WCAG. So you are pointing your paintbrush in the wrong
direction.



Second - no one is suggesting opening op those 21 provisions and
definitions. The definition of text proposed is consistent with all of
them (except captions (which is a known error and you'll find that the
definition of caption has been under revision for some time because it was
inaccurate in a number of ways including this - all or most all of which
were raised by industry.) and 2 informative notes (which are also being
fixed).



In fact many of the provisions make no sense unless text is programmatically
determinable. (e.g. what good is a text alternative, or a text file, or a
text label etc if text is not programmatically determinable. And if
programmatically determinable doesn't mean that it can be determined by AT.
Why have a text alternative that can't be determined by AT?)



Are you suggesting that the committee actually did not mean that AT should
be able to work with text in these other provisions using 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 8:23 PM
To: TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision: Text

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












_____

From: Peter Korn
Date: Wed, Mar 12 2008 12:20 AM
Subject: Re: Definition Consensus Decision: Text

Hi Gregg,

Speaking only for myself now (though I expect many colleagues will agree
with me), *I* did not and do not intend to have either a definition or
use of "text", or a definition or use of "programmatically
determinable", to mean that actual existing AT must have demonstrated
that it is using programmatically exposed interfaces in order for the
thing in question to either qualify as "text" or as "programmatically
determinable".

I think I have been pretty consistent in this from the start. I think
many industry colleagues have been likewise pretty consistent on this
from the start. I don't know how to make it more plain. If you insist
on introducing a definition that changes the meaning of 21 consensed
provisions to make their references to "text" utterly dependent on
whether an AT has been made commercially available that is actually
accessing that text before it can be called "text", then we may as well
shoot ourselves now. We will not finish this process before April 2009.


Just to illustrate why I think this is absurd...

Take an app - GreggWriter on GreggOS - that is used for editing written
documents, reading and saving them from/to a file. GreggOS defines
standard APIs for painting text onto the GUI display, and a set of
accessibility services (and perhaps other services) for retrieving that
text - exposing it to other software programs on the system. Now let us
assume that no AT is yet commercially available for GreggOS (though
perhaps some are working nicely in the engineering department of an AT
company, just not yet available to the public). That file containing
writing does not contain "text" by your proposed TEITAC definition;
likewise the words on the screen aren't "text". But suddenly, perhaps
only a mere 12 days later, the AT company makes their AT product
commercially available that uses the GreggOS accessibility service to
obtain the text displayed on the screen. Now suddenly, the file becomes
a text file - WITH NO ACTION BY THE IT VENDOR. It doesn't matter that
this AT is a trivial product, perhaps designed as a simple aid for folks
with not-so-severe reading impairments that simply draws a circle around
all of the words in the window of GreggWriter, in turn, from start to
finish. It is "AT", and it is "using the accessibility services to
access the text", therefore this trivial "AT" app - which does nothing
for the blind or for significantly low vision or... - completely changes
whether and how GreggWriter and GreggOS are able to meet a host of
provisions in 508. Suddenly the hundreds (or thousands or millions) of
GreggWriter files contain text where 12 days ago they did not.

Now, let's go the other way. Instead of saying "there must be 'some'
AT", let's say "ALL AT". Well, this means that Microsoft Word isn't
accessible and the .doc file doesn't contain text. That is because
Microsoft Office runs on Mac as well as Windows, and VoiceOver on
Macintosh is an AT that isn't able to read the text from Microsoft
Word. Likewise, nobody can deploy a Web app using EVEN ONLY HTML
because there are some AT apps on Windows that don't work with some web
browsers on Windows (let alone the same on Macintosh, UNIX, etc.).


These are all (additional) reasons why I think we cannot change the
commonly understood meanings of terms like text and (to me and many of
my engineering colleagues) programmatically determinable. Especially we
cannot change them to be dependent upon whether some 3rd party
application does or does not behave in some way with respect to some set
of APIs.


To answer the two questions you asked:

> In fact many of the provisions make no sense unless text is
> programmatically determinable. (e.g. what good is a text
> alternative, or a text file, or a text label etc if text is not
> programmatically determinable. And if programmatically determinable
> doesn't mean that it can be determined by AT. Why have a text
> alternative that can't be determined by AT?)
>
>
>
> Are you suggesting that the committee actually did not mean that AT
> should be able to work with text in these other provisions using text?

I believe I have stated this before - I am quite comfortable with a
definition of "programmatically determinable" to be about exposing
information for AT to use. AT should be able to work with
programmatically determinable information. AT should be able to work
with most text in most situations (and 3-U points the way for how AT can
do this, and things like the already-discussed caption text are examples
of the exceptions to this rule). But "AT should be able to work with"
is *dramatically* different from "existing AT is actually using these
techniques". This gets us right back to our old arguments around
"support for AT" vs. "with existing AT" from the FPCs. Arguments I had
thought we might be past given the semi-consensus we reached earlier
today based on your proposal for FPC language.

If you will accept a definition of "Programmatically determinable" as
meaning that the information is available to AT, then I think we can
find a way forward. If you insist that both that term/phrase, and the
term "text", require the existence of commercially available AT that is
actively utilizing those interfaces, then we have our old problem
again. And as my somewhat absurd first example above shows, such a test
further provides rather little guarantee of much significant access
through the use of AT in order to be claimed by industry. Or as my
other somewhat absurd example shows, the other end of the spectrum is
likewise untenable.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

P.S. Anticipating a potential objection: I recognize a concern that in
the 12+ days prior to any AT being published for GreggOS that does
something with the text exposed by the accessibility services of
GreggWriter, an agency shouldn't procure GreggWriter and GreggOS under
the mistaken assumption that this procurement will be accessible in the
instance where GreggOS and GreggWriter pass the technical provisions.
To this concern, I point out two things. First, the semi-consensed FPC
make it clear that GreggOS and GreggWriter must be accessible to people
without vision, with limited vision, etc. Unless GreggOS and
GreggWriter are self-voicing, self-magnifying, etc., they will not meet
the FPCs without the use of AT, and if there is no AT, then they will
not meet the FPCs and a procuring agency should either acquire something
else or make a Business Needs-style justification for why they are
acquiring an inaccessible app. The semi-consensed "second role" of the
FPC intro language - "If the technical provisions are met, the
Functional Performance Criteria must/can be used to see if the technical
provisions cover all aspects needed to provide access to the product.
(i.e overall evaluation)" helps make this clear. The parenthetical
remarks and the concluding FPC paragraph make this clear. The existence
or lack of existence of the trivial AT app I cited above that simple
draws circles successively around each word doesn't change this fact -
it doesn't make GreggWriter & GreggOS accessible to the blind or to
those with low vision or... And frankly, for most of the cognitive
impairments we are at least somewhat familiar with, it doesn't do a
whole lot for most of 'em. So I believe we already have protections in
place for the inaccessible GreggWriter scenario (through lack of AT),
and redefining "text" and "programmatically determinable" as you are
advocating doesn't fundamentally improve things. It does however make
them significant worse in many ways I've already more than belabored...

> Hi Peter,
>
>
>
>
>
> I don't know what to do with this memo.
>
>
>
>
>
> First -- It was industry not me that suggested we bring the definition
> of Text over from WCAG. So you are pointing your paintbrush in the
> wrong direction.
>
>
>
> Second -- no one is suggesting opening op those 21 provisions and
> definitions. The definition of text proposed is consistent with all
> of them (except captions (which is a known error and you'll find that
> the definition of caption has been under revision for some time
> because it was inaccurate in a number of ways including this -- all or
> most all of which were raised by industry.) and 2 informative notes
> (which are also being fixed).
>
>
>
> In fact many of the provisions make no sense unless text is
> programmatically determinable. (e.g. what good is a text
> alternative, or a text file, or a text label etc if text is not
> programmatically determinable. And if programmatically determinable
> doesn't mean that it can be determined by AT. Why have a text
> alternative that can't be determined by AT?)
>
>
>
> Are you suggesting that the committee actually did not mean that AT
> should be able to work with text in these other provisions using 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 8:23 PM
> *To:* TEITAC Committee
> *Subject:* Re: [teitac-committee] Definition Consensus Decision: Text
>
> 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 = >
> [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."
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

From: Gregg Vanderheiden
Date: Wed, Mar 12 2008 8:20 AM
Subject: Re: Definition Consensus Decision: Text

Peter,



The discussion on this thread is about having a definition of Text.
The definition of programmatically determined is a separate thread. My
comments were on adding the definition of text - to mean programmatically
determined.



The definition of programmatically determined definition seems to be where
you are having a problem. And that is tied to the "AT" question.



I would like to keep this thread on track. This thread is not about
whether we determine that thing should pass 508 if AT exists or not. That
is a separate discussion.





This is only about whether the use of TEXT in this document - means TEXT
that AT can get. ( We don't say anything about which AT here).



The definition of TEXT merely says that this is what we mean by text - and
that a bitmap image of text does not qualify as a TEXT alternative for
example.





If we can agree on this - then we can proceed with the definition of TEXT.






I understand well your other concern - but lets keep that one off as a
separate discussion. The way we have structured this document - we can
isolate that discussion to just a couple places. 3-U and the definition of
programmatically determined. Lets get the rest of this done and then
have our discussion there.



In this case I believe that you do (and I know your colleagues do) agree
that text alternatives and text files etc should be "programmatically
determined". You just differ on the definition of "programmatically
determinable". In fact I think there are multiple views on what
"programmatically determinable" and "compatible with AT' in general mean.
But lets put those discussions in a separate positions paper or section or
whatever and get the rest of this covered.



I have been trying very hard to find language that we could all agree on -
that would put that question into a contained space where we can work on it
separately.





RE the discussion of programmatically determined - lets move that over to
the Programmatically determined thread and talk about it there. There is
no language about AT or existing AT in this item (TEXT) or any of its notes.




It is important/essential that what we refer to as TEXT in this document
however be programmatically determinable - whatever the definition you want
to attach to that term.



Thanks




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: Wednesday, March 12, 2008 1:15 AM
To: TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision: Text

Hi Gregg,

Speaking only for myself now (though I expect many colleagues will agree
with me), *I* did not and do not intend to have either a definition or use
of "text", or a definition or use of "programmatically determinable", to
mean that actual existing AT must have demonstrated that it is using
programmatically exposed interfaces in order for the thing in question to
either qualify as "text" or as "programmatically determinable".

I think I have been pretty consistent in this from the start. I think many
industry colleagues have been likewise pretty consistent on this from the
start. I don't know how to make it more plain. If you insist on
introducing a definition that changes the meaning of 21 consensed provisions
to make their references to "text" utterly dependent on whether an AT has
been made commercially available that is actually accessing that text before
it can be called "text", then we may as well shoot ourselves now. We will
not finish this process before April 2009.


Just to illustrate why I think this is absurd...

Take an app - GreggWriter on GreggOS - that is used for editing written
documents, reading and saving them from/to a file. GreggOS defines standard
APIs for painting text onto the GUI display, and a set of accessibility
services (and perhaps other services) for retrieving that text - exposing it
to other software programs on the system. Now let us assume that no AT is
yet commercially available for GreggOS (though perhaps some are working
nicely in the engineering department of an AT company, just not yet
available to the public). That file containing writing does not contain
"text" by your proposed TEITAC definition; likewise the words on the screen
aren't "text". But suddenly, perhaps only a mere 12 days later, the AT
company makes their AT product commercially available that uses the GreggOS
accessibility service to obtain the text displayed on the screen. Now
suddenly, the file becomes a text file - WITH NO ACTION BY THE IT VENDOR.
It doesn't matter that this AT is a trivial product, perhaps designed as a
simple aid for folks with not-so-severe reading impairments that simply
draws a circle around all of the words in the window of GreggWriter, in
turn, from start to finish. It is "AT", and it is "using the accessibility
services to access the text", therefore this trivial "AT" app - which does
nothing for the blind or for significantly low vision or... - completely
changes whether and how GreggWriter and GreggOS are able to meet a host of
provisions in 508. Suddenly the hundreds (or thousands or millions) of
GreggWriter files contain text where 12 days ago they did not.

Now, let's go the other way. Instead of saying "there must be 'some' AT",
let's say "ALL AT". Well, this means that Microsoft Word isn't accessible
and the .doc file doesn't contain text. That is because Microsoft Office
runs on Mac as well as Windows, and VoiceOver on Macintosh is an AT that
isn't able to read the text from Microsoft Word. Likewise, nobody can
deploy a Web app using EVEN ONLY HTML because there are some AT apps on
Windows that don't work with some web browsers on Windows (let alone the
same on Macintosh, UNIX, etc.).


These are all (additional) reasons why I think we cannot change the commonly
understood meanings of terms like text and (to me and many of my engineering
colleagues) programmatically determinable. Especially we cannot change them
to be dependent upon whether some 3rd party application does or does not
behave in some way with respect to some set of APIs.


To answer the two questions you asked:




In fact many of the provisions make no sense unless text is programmatically
determinable. (e.g. what good is a text alternative, or a text file, or a
text label etc if text is not programmatically determinable. And if
programmatically determinable doesn't mean that it can be determined by AT.
Why have a text alternative that can't be determined by AT?)

Are you suggesting that the committee actually did not mean that AT should
be able to work with text in these other provisions using text?


I believe I have stated this before - I am quite comfortable with a
definition of "programmatically determinable" to be about exposing
information for AT to use. AT should be able to work with programmatically
determinable information. AT should be able to work with most text in most
situations (and 3-U points the way for how AT can do this, and things like
the already-discussed caption text are examples of the exceptions to this
rule). But "AT should be able to work with" is *dramatically* different
from "existing AT is actually using these techniques". This gets us right
back to our old arguments around "support for AT" vs. "with existing AT"
from the FPCs. Arguments I had thought we might be past given the
semi-consensus we reached earlier today based on your proposal for FPC
language.

If you will accept a definition of "Programmatically determinable" as
meaning that the information is available to AT, then I think we can find a
way forward. If you insist that both that term/phrase, and the term "text",
require the existence of commercially available AT that is actively
utilizing those interfaces, then we have our old problem again. And as my
somewhat absurd first example above shows, such a test further provides
rather little guarantee of much significant access through the use of AT in
order to be claimed by industry. Or as my other somewhat absurd example
shows, the other end of the spectrum is likewise untenable.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

P.S. Anticipating a potential objection: I recognize a concern that in the
12+ days prior to any AT being published for GreggOS that does something
with the text exposed by the accessibility services of GreggWriter, an
agency shouldn't procure GreggWriter and GreggOS under the mistaken
assumption that this procurement will be accessible in the instance where
GreggOS and GreggWriter pass the technical provisions. To this concern, I
point out two things. First, the semi-consensed FPC make it clear that
GreggOS and GreggWriter must be accessible to people without vision, with
limited vision, etc. Unless GreggOS and GreggWriter are self-voicing,
self-magnifying, etc., they will not meet the FPCs without the use of AT,
and if there is no AT, then they will not meet the FPCs and a procuring
agency should either acquire something else or make a Business Needs-style
justification for why they are acquiring an inaccessible app. The
semi-consensed "second role" of the FPC intro language - "If the technical
provisions are met, the Functional Performance Criteria must/can be used to
see if the technical provisions cover all aspects needed to provide access
to the product. (i.e overall evaluation)" helps make this clear. The
parenthetical remarks and the concluding FPC paragraph make this clear. The
existence or lack of existence of the trivial AT app I cited above that
simple draws circles successively around each word doesn't change this fact
- it doesn't make GreggWriter & GreggOS accessible to the blind or to those
with low vision or... And frankly, for most of the cognitive impairments we
are at least somewhat familiar with, it doesn't do a whole lot for most of
'em. So I believe we already have protections in place for the inaccessible
GreggWriter scenario (through lack of AT), and redefining "text" and
"programmatically determinable" as you are advocating doesn't fundamentally
improve things. It does however make them significant worse in many ways
I've already more than belabored...




Hi Peter,

I don't know what to do with this memo.

First - It was industry not me that suggested we bring the definition of
Text over from WCAG. So you are pointing your paintbrush in the wrong
direction.

Second - no one is suggesting opening op those 21 provisions and
definitions. The definition of text proposed is consistent with all of
them (except captions (which is a known error and you'll find that the
definition of caption has been under revision for some time because it was
inaccurate in a number of ways including this - all or most all of which
were raised by industry.) and 2 informative notes (which are also being
fixed).

In fact many of the provisions make no sense unless text is programmatically
determinable. (e.g. what good is a text alternative, or a text file, or a
text label etc if text is not programmatically determinable. And if
programmatically determinable doesn't mean that it can be determined by AT.
Why have a text alternative that can't be determined by AT?)

Are you suggesting that the committee actually did not mean that AT should
be able to work with text in these other provisions using 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 8:23 PM
To: TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision: Text

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.




_____

size=2 width="100%" align=center tabIndex=-1>

From: = 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 = ] 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."














_____

From: Hoffman, Allen
Date: Wed, Mar 12 2008 8:45 AM
Subject: Re: Definition Consensus Decision: Text

Gregg:
Is the wiki up to date with this definition?

I concur that we can keep the programmatically determinable discussion
on another thread and deal with this definition.
I also concur that "text" for our usage, must be programmatically
determinable, or another better descriptive phrase that does or does not
include the whole existing-AT concept.

Do we have a thread on programmatically determinable now?





Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303

From: Michaelis, Paul R. (Paul)
Date: Wed, Mar 12 2008 9:00 AM
Subject: Re: Definition Consensus Decision: Text

Gregg,

Without commenting one way or the other on the definition of Text, I
need to ask a favor of you.

You tend to describe proposals from a specific person, representing a
specific company or organization, as being from "industry" or being
"what industry wants." This is misleading and counterproductive.
Regulatory requirements that make sense for one company can be
completely unacceptable to others. (I learned this recently during the
discussions of wide-band audio.) It muddies the waters when you
characterize one company's position as being "a request from industry"
because, even though the statement may be true, it implies that there is
a consensus within industry when one might not exist. If an idea
originated with one member of private industry, I think it would be
helpful if you described it as such. Thanks,

-- Paul Michaelis

From: Randy Marsden
Date: Wed, Mar 12 2008 9:45 AM
Subject: Re: Definition Consensus Decision: Text

Peter:

You have a talent for twisting people's words. My previous post
showing the Wikipedia definition for "text" was provided for comic
relief and reference only - not as a suggestion that we use that
definition as it obviously doesn't pertain to 508. You misrepresented
my position in your text below as being opposed to Gregg's definition
of TEXT, which I am not.

I support Gregg's proposal that we simply say text must be
"programmatically determinable", and let that stand as the
definition. Then, we can deal with what "programmatically
determinable" means in another section.

-Randy

On Mar 11, 2008, at 7:23 PM, Peter Korn wrote:

> 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 thetext, 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 =
>> ] 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 =
>> ] 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."
>>
>>
>>
>>
>>
>>
>>
>>

From: Peter Korn
Date: Wed, Mar 12 2008 10:00 AM
Subject: Re: Definition Consensus Decision: Text

Gregg,

I'm sorry, but I think we will need to first agree on a definition of
programmatically determinable before we can agree on a definition of
something else - e.g. text - that uses that definition. I suggested
this a few days ago when Mike first asked for consensus around the text
definition.

Also, you wrote below: "The definition of TEXT merely says that this is
what we mean by text -- and that a bitmap image of text does not qualify
as a TEXT alternative for example." But earlier in this thread I raised
the idea of some future OCR package being good enough to read text in
bitmap images, and in response you said that if that were to occur,
bitmap images would now become text by this definition. This, too,
bothers me. Changes in technology and the existence or lack thereof of
other applications shouldn't change what definitions mean.

I am willing to keep these threads separate, but to do that, we should
first agree on programmatically determinable. Then we can work on the
definition of text that references another defined term. But if we
insist on using one not-yet-agreed-upon defined term in the definition a
second one, then I don't see how we can agree on the second one first.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> Peter,
>
>
>
> The discussion on this thread is about having a definition of
> Text. The definition of programmatically determined is a separate
> thread. My comments were on adding the definition of text -- to
> mean programmatically determined.
>
>
>
> The definition of programmatically determined definition seems to be
> where you are having a problem. And that is tied to the "AT" question.
>
>
>
> I would like to keep this thread on track. This thread is not
> about whether we determine that thing should pass 508 if AT exists or
> not. That is a separate discussion.
>
>
>
>
>
> This is only about whether the use of TEXT in this document -- means
> TEXT that AT can get. ( We don't say anything about which AT here).
>
>
>
> The definition of TEXT merely says that this is what we mean by text
> -- and that a bitmap image of text does not qualify as a TEXT
> alternative for example.
>
>
>
>
>
> If we can agree on this -- then we can proceed with the definition of
> TEXT.
>
>
>
>
>
> I understand well your other concern -- but lets keep that one off as
> a separate discussion. The way we have structured this document --
> we can isolate that discussion to just a couple places. 3-U and the
> definition of programmatically determined. Lets get the rest of
> this done and then have our discussion there.
>
>
>
> In this case I believe that you do (and I know your colleagues do)
> agree that text alternatives and text files etc should be
> "programmatically determined". You just differ on the definition of
> "programmatically determinable". In fact I think there are
> multiple views on what "programmatically determinable" and
> "compatible with AT' in general mean. But lets put those discussions
> in a separate positions paper or section or whatever and get the rest
> of this covered.
>
>
>
> I have been trying very hard to find language that we could all agree
> on -- that would put that question into a contained space where we can
> work on it separately.
>
>
>
>
>
> RE the discussion of programmatically determined -- lets move that
> over to the Programmatically determined thread and talk about it
> there. There is no language about AT or existing AT in this item
> (TEXT) or any of its notes.
>
>
>
> It is important/essential that what we refer to as TEXT in this
> document however be programmatically determinable -- whatever the
> definition you want to attach to that term.
>
>
>
> Thanks
>
>
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>
>
> ------------------------------------------------------------------------
>
> *From:* = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] *On Behalf Of
> *Peter Korn
> *Sent:* Wednesday, March 12, 2008 1:15 AM
> *To:* TEITAC Committee
> *Subject:* Re: [teitac-committee] Definition Consensus Decision: Text
>
> Hi Gregg,
>
> Speaking only for myself now (though I expect many colleagues will
> agree with me), *I* did not and do not intend to have either a
> definition or use of "text", or a definition or use of
> "programmatically determinable", to mean that actual existing AT
> must have demonstrated that it is using programmatically exposed
> interfaces in order for the thing in question to either qualify as
> "text" or as "programmatically determinable".
>
> I think I have been pretty consistent in this from the start. I
> think many industry colleagues have been likewise pretty
> consistent on this from the start. I don't know how to make it
> more plain. If you insist on introducing a definition that
> changes the meaning of 21 consensed provisions to make their
> references to "text" utterly dependent on whether an AT has been
> made commercially available that is actually accessing that text
> before it can be called "text", then we may as well shoot
> ourselves now. We will not finish this process before April 2009.
>
>
> Just to illustrate why I think this is absurd...
>
> Take an app - GreggWriter on GreggOS - that is used for editing
> written documents, reading and saving them from/to a file.
> GreggOS defines standard APIs for painting text onto the GUI
> display, and a set of accessibility services (and perhaps other
> services) for retrieving that text - exposing it to other software
> programs on the system. Now let us assume that no AT is yet
> commercially available for GreggOS (though perhaps some are
> working nicely in the engineering department of an AT company,
> just not yet available to the public). That file containing
> writing does not contain "text" by your proposed TEITAC
> definition; likewise the words on the screen aren't "text". But
> suddenly, perhaps only a mere 12 days later, the AT company makes
> their AT product commercially available that uses the GreggOS
> accessibility service to obtain the text displayed on the screen.
> Now suddenly, the file becomes a text file - WITH NO ACTION BY THE
> IT VENDOR. It doesn't matter that this AT is a trivial product,
> perhaps designed as a simple aid for folks with not-so-severe
> reading impairments that simply draws a circle around all of the
> words in the window of GreggWriter, in turn, from start to
> finish. It is "AT", and it is "using the accessibility services
> to access the text", therefore this trivial "AT" app - which does
> nothing for the blind or for significantly low vision or... -
> completely changes whether and how GreggWriter and GreggOS are
> able to meet a host of provisions in 508. Suddenly the hundreds
> (or thousands or millions) of GreggWriter files contain text where
> 12 days ago they did not.
>
> Now, let's go the other way. Instead of saying "there must be
> 'some' AT", let's say "ALL AT". Well, this means that Microsoft
> Word isn't accessible and the .doc file doesn't contain text.
> That is because Microsoft Office runs on Mac as well as Windows,
> and VoiceOver on Macintosh is an AT that isn't able to read the
> text from Microsoft Word. Likewise, nobody can deploy a Web app
> using EVEN ONLY HTML because there are some AT apps on Windows
> that don't work with some web browsers on Windows (let alone the
> same on Macintosh, UNIX, etc.).
>
>
> These are all (additional) reasons why I think we cannot change
> the commonly understood meanings of terms like text and (to me and
> many of my engineering colleagues) programmatically determinable.
> Especially we cannot change them to be dependent upon whether some
> 3rd party application does or does not behave in some way with
> respect to some set of APIs.
>
>
> To answer the two questions you asked:
>
>
> In fact many of the provisions make no sense unless text is
> programmatically determinable. (e.g. what good is a text
> alternative, or a text file, or a text label etc if text is not
> programmatically determinable. And if programmatically
> determinable doesn't mean that it can be determined by AT. Why
> have a text alternative that can't be determined by AT?)
>
> Are you suggesting that the committee actually did not mean that
> AT should be able to work with text in these other provisions
> using text?
>
>
> I believe I have stated this before - I am quite comfortable with
> a definition of "programmatically determinable" to be about
> exposing information for AT to use. AT should be able to work
> with programmatically determinable information. AT should be able
> to work with most text in most situations (and 3-U points the way
> for how AT can do this, and things like the already-discussed
> caption text are examples of the exceptions to this rule). But
> "AT should be able to work with" is *dramatically* different from
> "existing AT is actually using these techniques". This gets us
> right back to our old arguments around "support for AT" vs. "with
> existing AT" from the FPCs. Arguments I had thought we might be
> past given the semi-consensus we reached earlier today based on
> your proposal for FPC language.
>
> If you will accept a definition of "Programmatically determinable"
> as meaning that the information is available to AT, then I think
> we can find a way forward. If you insist that both that
> term/phrase, and the term "text", require the existence of
> commercially available AT that is actively utilizing those
> interfaces, then we have our old problem again. And as my
> somewhat absurd first example above shows, such a test further
> provides rather little guarantee of much significant access
> through the use of AT in order to be claimed by industry. Or as
> my other somewhat absurd example shows, the other end of the
> spectrum is likewise untenable.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> P.S. Anticipating a potential objection: I recognize a concern
> that in the 12+ days prior to any AT being published for GreggOS
> that does something with the text exposed by the accessibility
> services of GreggWriter, an agency shouldn't procure GreggWriter
> and GreggOS under the mistaken assumption that this procurement
> will be accessible in the instance where GreggOS and GreggWriter
> pass the technical provisions. To this concern, I point out two
> things. First, the semi-consensed FPC make it clear that GreggOS
> and GreggWriter must be accessible to people without vision, with
> limited vision, etc. Unless GreggOS and GreggWriter are
> self-voicing, self-magnifying, etc., they will not meet the FPCs
> without the use of AT, and if there is no AT, then they will not
> meet the FPCs and a procuring agency should either acquire
> something else or make a Business Needs-style justification for
> why they are acquiring an inaccessible app. The semi-consensed
> "second role" of the FPC intro language - "If the technical
> provisions are met, the Functional Performance Criteria must/can
> be used to see if the technical provisions cover all aspects
> needed to provide access to the product. (i.e overall evaluation)"
> helps make this clear. The parenthetical remarks and the
> concluding FPC paragraph make this clear. The existence or lack
> of existence of the trivial AT app I cited above that simple draws
> circles successively around each word doesn't change this fact -
> it doesn't make GreggWriter & GreggOS accessible to the blind or
> to those with low vision or... And frankly, for most of the
> cognitive impairments we are at least somewhat familiar with, it
> doesn't do a whole lot for most of 'em. So I believe we already
> have protections in place for the inaccessible GreggWriter
> scenario (through lack of AT), and redefining "text" and
> "programmatically determinable" as you are advocating doesn't
> fundamentally improve things. It does however make them
> significant worse in many ways I've already more than belabored...
>
>
> Hi Peter,
>
> I don't know what to do with this memo.
>
> First -- It was industry not me that suggested we bring the
> definition of Text over from WCAG. So you are pointing your
> paintbrush in the wrong direction.
>
> Second -- no one is suggesting opening op those 21 provisions and
> definitions. The definition of text proposed is consistent with
> all of them (except captions (which is a known error and you'll
> find that the definition of caption has been under revision for
> some time because it was inaccurate in a number of ways including
> this -- all or most all of which were raised by industry.) and 2
> informative notes (which are also being fixed).
>
> In fact many of the provisions make no sense unless text is
> programmatically determinable. (e.g. what good is a text
> alternative, or a text file, or a text label etc if text is not
> programmatically determinable. And if programmatically
> determinable doesn't mean that it can be determined by AT. Why
> have a text alternative that can't be determined by AT?)
>
> Are you suggesting that the committee actually did not mean that
> AT should be able to work with text in these other provisions
> using text?
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
> ------------------------------------------------------------------------
>
> *From:* = EMAIL ADDRESS REMOVED =
> <mailto: = EMAIL ADDRESS REMOVED = >
> [mailto: = EMAIL ADDRESS REMOVED = ] *On Behalf
> Of *Peter Korn
> *Sent:* Tuesday, March 11, 2008 8:23 PM
> *To:* TEITAC Committee
> *Subject:* Re: [teitac-committee] Definition Consensus
> Decision: Text
>
> 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 = >
> [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.
>
> ------------------------------------------------------------------------
> size=2 width="100%" align=center tabIndex=-1>
>
> *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."
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

From: Gregg Vanderheiden
Date: Wed, Mar 12 2008 10:10 AM
Subject: Re: Definition Consensus Decision: Text

Thanks Paul,



Good comment. I tried to say "industry representative" but I see that
would be incorrect too.



I will try to say something like "from a company" or such. But better yet
- maybe we should just try to get off of the he-said she-said mentality and
focus back on the issues. I guess I got a little sensitive about how
things were being presented. I should know better. I should be better.



Thanks


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Michaelis,
Paul R. (Paul)
Sent: Wednesday, March 12, 2008 9:57 AM
To: TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision: Text

Gregg,



Without commenting one way or the other on the definition of Text, I need to
ask a favor of you.



You tend to describe proposals from a specific person, representing a
specific company or organization, as being from "industry" or being "what
industry wants." This is misleading and counterproductive. Regulatory
requirements that make sense for one company can be completely unacceptable
to others. (I learned this recently during the discussions of wide-band
audio.) It muddies the waters when you characterize one company's position
as being "a request from industry" because, even though the statement may be
true, it implies that there is a consensus within industry when one might
not exist. If an idea originated with one member of private industry, I
think it would be helpful if you described it as such. Thanks,



-- Paul Michaelis







_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Tuesday, March 11, 2008 11:17 PM
To: 'TEITAC Committee'
Subject: Re: [teitac-committee] Definition Consensus Decision: Text

Hi Peter,





I don't know what to do with this memo.





First - It was industry not me that suggested we bring the definition of
Text over from WCAG. So you are pointing your paintbrush in the wrong
direction.



Second - no one is suggesting opening op those 21 provisions and
definitions. The definition of text proposed is consistent with all of
them (except captions (which is a known error and you'll find that the
definition of caption has been under revision for some time because it was
inaccurate in a number of ways including this - all or most all of which
were raised by industry.) and 2 informative notes (which are also being
fixed).



In fact many of the provisions make no sense unless text is programmatically
determinable. (e.g. what good is a text alternative, or a text file, or a
text label etc if text is not programmatically determinable. And if
programmatically determinable doesn't mean that it can be determined by AT.
Why have a text alternative that can't be determined by AT?)



Are you suggesting that the committee actually did not mean that AT should
be able to work with text in these other provisions using 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 8:23 PM
To: TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision: Text

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














_____

From: Gregg Vanderheiden
Date: Wed, Mar 12 2008 10:15 AM
Subject: Re: Definition Consensus Decision: Text

Hi Allen,



Yes I believe the WIKI is up to date. (they have been doing a
remarkably good job on this) It includes the text under discussion and
marks it clearly as such "Proposed to ensure harmonization" but NOT a
consensed item.



RE programmatically determined thread

- there is a programmatically determined definition - and I think it is
part of the AT block. So it will be up for discussion soon as a thread.
We could start one now if desired but I think we will see it from the Chairs
in the next block of definitions or in an AT block.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Hoffman,
Allen
Sent: Wednesday, March 12, 2008 9:38 AM
To: TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision: Text

Gregg:

Is the wiki up to date with this definition?



I concur that we can keep the programmatically determinable discussion on
another thread and deal with this definition.

I also concur that "text" for our usage, must be programmatically
determinable, or another better descriptive phrase that does or does not
include the whole existing-AT concept.



Do we have a thread on programmatically determinable now?









Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Wednesday, March 12, 2008 10:09 AM
To: 'TEITAC Committee'
Subject: Re: [teitac-committee] Definition Consensus Decision: Text

Peter,



The discussion on this thread is about having a definition of Text.
The definition of programmatically determined is a separate thread. My
comments were on adding the definition of text - to mean programmatically
determined.



The definition of programmatically determined definition seems to be where
you are having a problem. And that is tied to the "AT" question.



I would like to keep this thread on track. This thread is not about
whether we determine that thing should pass 508 if AT exists or not. That
is a separate discussion.





This is only about whether the use of TEXT in this document - means TEXT
that AT can get. ( We don't say anything about which AT here).



The definition of TEXT merely says that this is what we mean by text - and
that a bitmap image of text does not qualify as a TEXT alternative for
example.





If we can agree on this - then we can proceed with the definition of TEXT.






I understand well your other concern - but lets keep that one off as a
separate discussion. The way we have structured this document - we can
isolate that discussion to just a couple places. 3-U and the definition of
programmatically determined. Lets get the rest of this done and then
have our discussion there.



In this case I believe that you do (and I know your colleagues do) agree
that text alternatives and text files etc should be "programmatically
determined". You just differ on the definition of "programmatically
determinable". In fact I think there are multiple views on what
"programmatically determinable" and "compatible with AT' in general mean.
But lets put those discussions in a separate positions paper or section or
whatever and get the rest of this covered.



I have been trying very hard to find language that we could all agree on -
that would put that question into a contained space where we can work on it
separately.





RE the discussion of programmatically determined - lets move that over to
the Programmatically determined thread and talk about it there. There is
no language about AT or existing AT in this item (TEXT) or any of its notes.




It is important/essential that what we refer to as TEXT in this document
however be programmatically determinable - whatever the definition you want
to attach to that term.



Thanks




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: Wednesday, March 12, 2008 1:15 AM
To: TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision: Text

Hi Gregg,

Speaking only for myself now (though I expect many colleagues will agree
with me), *I* did not and do not intend to have either a definition or use
of "text", or a definition or use of "programmatically determinable", to
mean that actual existing AT must have demonstrated that it is using
programmatically exposed interfaces in order for the thing in question to
either qualify as "text" or as "programmatically determinable".

I think I have been pretty consistent in this from the start. I think many
industry colleagues have been likewise pretty consistent on this from the
start. I don't know how to make it more plain. If you insist on
introducing a definition that changes the meaning of 21 consensed provisions
to make their references to "text" utterly dependent on whether an AT has
been made commercially available that is actually accessing that text before
it can be called "text", then we may as well shoot ourselves now. We will
not finish this process before April 2009.


Just to illustrate why I think this is absurd...

Take an app - GreggWriter on GreggOS - that is used for editing written
documents, reading and saving them from/to a file. GreggOS defines standard
APIs for painting text onto the GUI display, and a set of accessibility
services (and perhaps other services) for retrieving that text - exposing it
to other software programs on the system. Now let us assume that no AT is
yet commercially available for GreggOS (though perhaps some are working
nicely in the engineering department of an AT company, just not yet
available to the public). That file containing writing does not contain
"text" by your proposed TEITAC definition; likewise the words on the screen
aren't "text". But suddenly, perhaps only a mere 12 days later, the AT
company makes their AT product commercially available that uses the GreggOS
accessibility service to obtain the text displayed on the screen. Now
suddenly, the file becomes a text file - WITH NO ACTION BY THE IT VENDOR.
It doesn't matter that this AT is a trivial product, perhaps designed as a
simple aid for folks with not-so-severe reading impairments that simply
draws a circle around all of the words in the window of GreggWriter, in
turn, from start to finish. It is "AT", and it is "using the accessibility
services to access the text", therefore this trivial "AT" app - which does
nothing for the blind or for significantly low vision or... - completely
changes whether and how GreggWriter and GreggOS are able to meet a host of
provisions in 508. Suddenly the hundreds (or thousands or millions) of
GreggWriter files contain text where 12 days ago they did not.

Now, let's go the other way. Instead of saying "there must be 'some' AT",
let's say "ALL AT". Well, this means that Microsoft Word isn't accessible
and the .doc file doesn't contain text. That is because Microsoft Office
runs on Mac as well as Windows, and VoiceOver on Macintosh is an AT that
isn't able to read the text from Microsoft Word. Likewise, nobody can
deploy a Web app using EVEN ONLY HTML because there are some AT apps on
Windows that don't work with some web browsers on Windows (let alone the
same on Macintosh, UNIX, etc.).


These are all (additional) reasons why I think we cannot change the commonly
understood meanings of terms like text and (to me and many of my engineering
colleagues) programmatically determinable. Especially we cannot change them
to be dependent upon whether some 3rd party application does or does not
behave in some way with respect to some set of APIs.


To answer the two questions you asked:



In fact many of the provisions make no sense unless text is programmatically
determinable. (e.g. what good is a text alternative, or a text file, or a
text label etc if text is not programmatically determinable. And if
programmatically determinable doesn't mean that it can be determined by AT.
Why have a text alternative that can't be determined by AT?)

Are you suggesting that the committee actually did not mean that AT should
be able to work with text in these other provisions using text?


I believe I have stated this before - I am quite comfortable with a
definition of "programmatically determinable" to be about exposing
information for AT to use. AT should be able to work with programmatically
determinable information. AT should be able to work with most text in most
situations (and 3-U points the way for how AT can do this, and things like
the already-discussed caption text are examples of the exceptions to this
rule). But "AT should be able to work with" is *dramatically* different
from "existing AT is actually using these techniques". This gets us right
back to our old arguments around "support for AT" vs. "with existing AT"
from the FPCs. Arguments I had thought we might be past given the
semi-consensus we reached earlier today based on your proposal for FPC
language.

If you will accept a definition of "Programmatically determinable" as
meaning that the information is available to AT, then I think we can find a
way forward. If you insist that both that term/phrase, and the term "text",
require the existence of commercially available AT that is actively
utilizing those interfaces, then we have our old problem again. And as my
somewhat absurd first example above shows, such a test further provides
rather little guarantee of much significant access through the use of AT in
order to be claimed by industry. Or as my other somewhat absurd example
shows, the other end of the spectrum is likewise untenable.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

P.S. Anticipating a potential objection: I recognize a concern that in the
12+ days prior to any AT being published for GreggOS that does something
with the text exposed by the accessibility services of GreggWriter, an
agency shouldn't procure GreggWriter and GreggOS under the mistaken
assumption that this procurement will be accessible in the instance where
GreggOS and GreggWriter pass the technical provisions. To this concern, I
point out two things. First, the semi-consensed FPC make it clear that
GreggOS and GreggWriter must be accessible to people without vision, with
limited vision, etc. Unless GreggOS and GreggWriter are self-voicing,
self-magnifying, etc., they will not meet the FPCs without the use of AT,
and if there is no AT, then they will not meet the FPCs and a procuring
agency should either acquire something else or make a Business Needs-style
justification for why they are acquiring an inaccessible app. The
semi-consensed "second role" of the FPC intro language - "If the technical
provisions are met, the Functional Performance Criteria must/can be used to
see if the technical provisions cover all aspects needed to provide access
to the product. (i.e overall evaluation)" helps make this clear. The
parenthetical remarks and the concluding FPC paragraph make this clear. The
existence or lack of existence of the trivial AT app I cited above that
simple draws circles successively around each word doesn't change this fact
- it doesn't make GreggWriter & GreggOS accessible to the blind or to those
with low vision or... And frankly, for most of the cognitive impairments we
are at least somewhat familiar with, it doesn't do a whole lot for most of
'em. So I believe we already have protections in place for the inaccessible
GreggWriter scenario (through lack of AT), and redefining "text" and
"programmatically determinable" as you are advocating doesn't fundamentally
improve things. It does however make them significant worse in many ways
I've already more than belabored...



Hi Peter,

I don't know what to do with this memo.

First - It was industry not me that suggested we bring the definition of
Text over from WCAG. So you are pointing your paintbrush in the wrong
direction.

Second - no one is suggesting opening op those 21 provisions and
definitions. The definition of text proposed is consistent with all of
them (except captions (which is a known error and you'll find that the
definition of caption has been under revision for some time because it was
inaccurate in a number of ways including this - all or most all of which
were raised by industry.) and 2 informative notes (which are also being
fixed).

In fact many of the provisions make no sense unless text is programmatically
determinable. (e.g. what good is a text alternative, or a text file, or a
text label etc if text is not programmatically determinable. And if
programmatically determinable doesn't mean that it can be determined by AT.
Why have a text alternative that can't be determined by AT?)

Are you suggesting that the committee actually did not mean that AT should
be able to work with text in these other provisions using 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 8:23 PM
To: TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision: Text

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.



<HRsize=2 width="100%" align=center tabIndex=-1>

From: = 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 = ] 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."
















_____

From: Gregg Vanderheiden
Date: Wed, Mar 12 2008 10:35 AM
Subject: Re: Definition Consensus Decision: Text

Hi Peter,



I think that we are all close on what programmatically determined
means. The only difference I believe is the question about whether AT (in
this definition and throughout the standard) means 'possible AT' or
"current AT" or "AT available to consumers" or something like that (as well
as what those phrases might mean). I believe that we all think that
there will not be an agreement on that question - and that it will be
written up with two or more (hopefully only a few) positions on it.



I don't think we can or should stop the whole process to until we resolve
that single question. I think it is fairly well contained now. We are
going to use the word AT and we are going to have to highlight for the
Access Board what the issues and points of view are - and where it would
impact the provisions as we turned them in. But I think the chairs are
working on a way to do this if I have been understanding the herding words
they have been using on these topics and on how they are handling things.
Not sure if they have figured it out exactly yet but I think they are right
if I understand it - and will try to adapt my concerns and input to the
format they come up with.



Til then I think we should agree that 1) this is a very tricky question
("which AT") with very high stakes on both sides (all 4 sides?) if it isn't
done right and 2) that there are different views on how to define "which
AT".



. and then we should try to get on with the completing the rest of standard.










Oh - and yes - I should have said ". and TODAY a bitmap image of text does
not qualify as a TEXT alternative". This will likely be true for the life
of this revision of the standard - but I do expect that someday a clear
image of text would qualify as 'programmatically determinable' but a highly
stylized bitmap image of text would not (think CAPTCHA or the Illustrated
first letter of a chapter in a formal religious book or manuscript"). The
trick at that point will be having a bright line between what AT can handle
or not. Til then - 'programmatically determinable text' is likely to not
be satisfied by 'images of text'.






Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: Wednesday, March 12, 2008 10:51 AM
To: TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision: Text

Gregg,

I'm sorry, but I think we will need to first agree on a definition of
programmatically determinable before we can agree on a definition of
something else - e.g. text - that uses that definition. I suggested this a
few days ago when Mike first asked for consensus around the text definition.


Also, you wrote below: "The definition of TEXT merely says that this is what
we mean by text - and that a bitmap image of text does not qualify as a TEXT
alternative for example." But earlier in this thread I raised the idea of
some future OCR package being good enough to read text in bitmap images, and
in response you said that if that were to occur, bitmap images would now
become text by this definition. This, too, bothers me. Changes in
technology and the existence or lack thereof of other applications shouldn't
change what definitions mean.

I am willing to keep these threads separate, but to do that, we should first
agree on programmatically determinable. Then we can work on the definition
of text that references another defined term. But if we insist on using one
not-yet-agreed-upon defined term in the definition a second one, then I
don't see how we can agree on the second one first.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.





Peter,

The discussion on this thread is about having a definition of Text.
The definition of programmatically determined is a separate thread. My
comments were on adding the definition of text - to mean programmatically
determined.

The definition of programmatically determined definition seems to be where
you are having a problem. And that is tied to the "AT" question.

I would like to keep this thread on track. This thread is not about
whether we determine that thing should pass 508 if AT exists or not. That
is a separate discussion.

This is only about whether the use of TEXT in this document - means TEXT
that AT can get. ( We don't say anything about which AT here).

The definition of TEXT merely says that this is what we mean by text - and
that a bitmap image of text does not qualify as a TEXT alternative for
example.

If we can agree on this - then we can proceed with the definition of TEXT.


I understand well your other concern - but lets keep that one off as a
separate discussion. The way we have structured this document - we can
isolate that discussion to just a couple places. 3-U and the definition of
programmatically determined. Lets get the rest of this done and then
have our discussion there.

In this case I believe that you do (and I know your colleagues do) agree
that text alternatives and text files etc should be "programmatically
determined". You just differ on the definition of "programmatically
determinable". In fact I think there are multiple views on what
"programmatically determinable" and "compatible with AT' in general mean.
But lets put those discussions in a separate positions paper or section or
whatever and get the rest of this covered.

I have been trying very hard to find language that we could all agree on -
that would put that question into a contained space where we can work on it
separately.

RE the discussion of programmatically determined - lets move that over to
the Programmatically determined thread and talk about it there. There is
no language about AT or existing AT in this item (TEXT) or any of its notes.


It is important/essential that what we refer to as TEXT in this document
however be programmatically determinable - whatever the definition you want
to attach to that term.

Thanks


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.




_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: Wednesday, March 12, 2008 1:15 AM
To: TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision: Text

Hi Gregg,

Speaking only for myself now (though I expect many colleagues will agree
with me), *I* did not and do not intend to have either a definition or use
of "text", or a definition or use of "programmatically determinable", to
mean that actual existing AT must have demonstrated that it is using
programmatically exposed interfaces in order for the thing in question to
either qualify as "text" or as "programmatically determinable".

I think I have been pretty consistent in this from the start. I think many
industry colleagues have been likewise pretty consistent on this from the
start. I don't know how to make it more plain. If you insist on
introducing a definition that changes the meaning of 21 consensed provisions
to make their references to "text" utterly dependent on whether an AT has
been made commercially available that is actually accessing that text before
it can be called "text", then we may as well shoot ourselves now. We will
not finish this process before April 2009.


Just to illustrate why I think this is absurd...

Take an app - GreggWriter on GreggOS - that is used for editing written
documents, reading and saving them from/to a file. GreggOS defines standard
APIs for painting text onto the GUI display, and a set of accessibility
services (and perhaps other services) for retrieving that text - exposing it
to other software programs on the system. Now let us assume that no AT is
yet commercially available for GreggOS (though perhaps some are working
nicely in the engineering department of an AT company, just not yet
available to the public). That file containing writing does not contain
"text" by your proposed TEITAC definition; likewise the words on the screen
aren't "text". But suddenly, perhaps only a mere 12 days later, the AT
company makes their AT product commercially available that uses the GreggOS
accessibility service to obtain the text displayed on the screen. Now
suddenly, the file becomes a text file - WITH NO ACTION BY THE IT VENDOR.
It doesn't matter that this AT is a trivial product, perhaps designed as a
simple aid for folks with not-so-severe reading impairments that simply
draws a circle around all of the words in the window of GreggWriter, in
turn, from start to finish. It is "AT", and it is "using the accessibility
services to access the text", therefore this trivial "AT" app - which does
nothing for the blind or for significantly low vision or... - completely
changes whether and how GreggWriter and GreggOS are able to meet a host of
provisions in 508. Suddenly the hundreds (or thousands or millions) of
GreggWriter files contain text where 12 days ago they did not.

Now, let's go the other way. Instead of saying "there must be 'some' AT",
let's say "ALL AT". Well, this means that Microsoft Word isn't accessible
and the .doc file doesn't contain text. That is because Microsoft Office
runs on Mac as well as Windows, and VoiceOver on Macintosh is an AT that
isn't able to read the text from Microsoft Word. Likewise, nobody can
deploy a Web app using EVEN ONLY HTML because there are some AT apps on
Windows that don't work with some web browsers on Windows (let alone the
same on Macintosh, UNIX, etc.).


These are all (additional) reasons why I think we cannot change the commonly
understood meanings of terms like text and (to me and many of my engineering
colleagues) programmatically determinable. Especially we cannot change them
to be dependent upon whether some 3rd party application does or does not
behave in some way with respect to some set of APIs.


To answer the two questions you asked:





In fact many of the provisions make no sense unless text is programmatically
determinable. (e.g. what good is a text alternative, or a text file, or a
text label etc if text is not programmatically determinable. And if
programmatically determinable doesn't mean that it can be determined by AT.
Why have a text alternative that can't be determined by AT?)

Are you suggesting that the committee actually did not mean that AT should
be able to work with text in these other provisions using text?


I believe I have stated this before - I am quite comfortable with a
definition of "programmatically determinable" to be about exposing
information for AT to use. AT should be able to work with programmatically
determinable information. AT should be able to work with most text in most
situations (and 3-U points the way for how AT can do this, and things like
the already-discussed caption text are examples of the exceptions to this
rule). But "AT should be able to work with" is *dramatically* different
from "existing AT is actually using these techniques". This gets us right
back to our old arguments around "support for AT" vs. "with existing AT"
from the FPCs. Arguments I had thought we might be past given the
semi-consensus we reached earlier today based on your proposal for FPC
language.

If you will accept a definition of "Programmatically determinable" as
meaning that the information is available to AT, then I think we can find a
way forward. If you insist that both that term/phrase, and the term "text",
require the existence of commercially available AT that is actively
utilizing those interfaces, then we have our old problem again. And as my
somewhat absurd first example above shows, such a test further provides
rather little guarantee of much significant access through the use of AT in
order to be claimed by industry. Or as my other somewhat absurd example
shows, the other end of the spectrum is likewise untenable.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

P.S. Anticipating a potential objection: I recognize a concern that in the
12+ days prior to any AT being published for GreggOS that does something
with the text exposed by the accessibility services of GreggWriter, an
agency shouldn't procure GreggWriter and GreggOS under the mistaken
assumption that this procurement will be accessible in the instance where
GreggOS and GreggWriter pass the technical provisions. To this concern, I
point out two things. First, the semi-consensed FPC make it clear that
GreggOS and GreggWriter must be accessible to people without vision, with
limited vision, etc. Unless GreggOS and GreggWriter are self-voicing,
self-magnifying, etc., they will not meet the FPCs without the use of AT,
and if there is no AT, then they will not meet the FPCs and a procuring
agency should either acquire something else or make a Business Needs-style
justification for why they are acquiring an inaccessible app. The
semi-consensed "second role" of the FPC intro language - "If the technical
provisions are met, the Functional Performance Criteria must/can be used to
see if the technical provisions cover all aspects needed to provide access
to the product. (i.e overall evaluation)" helps make this clear. The
parenthetical remarks and the concluding FPC paragraph make this clear. The
existence or lack of existence of the trivial AT app I cited above that
simple draws circles successively around each word doesn't change this fact
- it doesn't make GreggWriter & GreggOS accessible to the blind or to those
with low vision or... And frankly, for most of the cognitive impairments we
are at least somewhat familiar with, it doesn't do a whole lot for most of
'em. So I believe we already have protections in place for the inaccessible
GreggWriter scenario (through lack of AT), and redefining "text" and
"programmatically determinable" as you are advocating doesn't fundamentally
improve things. It does however make them significant worse in many ways
I've already more than belabored...





Hi Peter,

I don't know what to do with this memo.

First - It was industry not me that suggested we bring the definition of
Text over from WCAG. So you are pointing your paintbrush in the wrong
direction.

Second - no one is suggesting opening op those 21 provisions and
definitions. The definition of text proposed is consistent with all of
them (except captions (which is a known error and you'll find that the
definition of caption has been under revision for some time because it was
inaccurate in a number of ways including this - all or most all of which
were raised by industry.) and 2 informative notes (which are also being
fixed).

In fact many of the provisions make no sense unless text is programmatically
determinable. (e.g. what good is a text alternative, or a text file, or a
text label etc if text is not programmatically determinable. And if
programmatically determinable doesn't mean that it can be determined by AT.
Why have a text alternative that can't be determined by AT?)

Are you suggesting that the committee actually did not mean that AT should
be able to work with text in these other provisions using 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 8:23 PM
To: TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision: Text

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.




_____


size=2 width="100%" align=center tabIndex=-1>

From: = 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 = ] 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."
















_____

From: Peter Korn
Date: Wed, Mar 12 2008 11:15 AM
Subject: Re: Definition Consensus Decision: Text

Hi Gregg,

Yes, we need to find a way to move forward.

Since as you suggest we may well have two (or more) definitions of
programmatically determinable, perhaps we need to likewise have two (or
more) definitions of text. I am comfortable with the "Version 2
(Trace)" definition of Programmatically determinable at
http://teitac.org/wiki/EWG:Draft_Jan_7#Programmatically_Determinable
with the EXCEPTION of Note 2. Perhaps we can consense on all of the
text save Note 2, and then call Note 2 out as something some folks want
and some don't. This might also be referenced from a section of the
Narrative that highlights these concerns. Of course we need to hear
from others on TEITAC to see if that is the only distinction.

Then in the definition of text, we might likewise have two versions, or
expository text which clearly calls out the dependency on the
"programmatically determinable" definition, notes the issues that arise
from that (and the objections to these issues) if Note 2 of the "Version
2 (Trace)" definition holds, and further notes the dependency on what
"text" means if "programmatically determinable" changes in the future.


Does that seem like a reasonable way forward?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.



> Hi Peter,
>
>
>
> I think that we are all close on what programmatically determined
> means. The only difference I believe is the question about whether
> AT (in this definition and throughout the standard) means 'possible
> AT' or "current AT" or "AT available to consumers" or something like
> that (as well as what those phrases might mean). I believe that
> we all think that there will not be an agreement on that question --
> and that it will be written up with two or more (hopefully only a few)
> positions on it.
>
>
>
> I don't think we can or should stop the whole process to until we
> resolve that single question. I think it is fairly well contained
> now. We are going to use the word AT and we are going to have to
> highlight for the Access Board what the issues and points of view are
> -- and where it would impact the provisions as we turned them in.
> But I think the chairs are working on a way to do this if I have been
> understanding the herding words they have been using on these topics
> and on how they are handling things. Not sure if they have figured it
> out exactly yet but I think they are right if I understand it -- and
> will try to adapt my concerns and input to the format they come up
> with.
>
>
>
> Til then I think we should agree that 1) this is a very tricky
> question ("which AT") with very high stakes on both sides (all 4
> sides?) if it isn't done right and 2) that there are different
> views on how to define "which AT".
>
>
>
> ... and then we should try to get on with the completing the rest of
> standard.
>
>
>
>
>
>
>
>
>
> Oh -- and yes - I should have said "... and TODAY a bitmap image of
> text does not qualify as a TEXT alternative". This will likely be
> true for the life of this revision of the standard -- but I do expect
> that someday a clear image of text would qualify as 'programmatically
> determinable' but a highly stylized bitmap image of text would not
> (think CAPTCHA or the Illustrated first letter of a chapter in a
> formal religious book or manuscript"). The trick at that point will
> be having a bright line between what AT can handle or not. Til then
> -- 'programmatically determinable text' is likely to not be satisfied
> by 'images of text'.
>
>
>
>
>

From: Brooner Mary-AMB004
Date: Wed, Mar 12 2008 11:20 AM
Subject: Re: Definition Consensus Decision: Text

I would like to remind everyone there is NOTHING wrong and it is NOT a
failure if we narrow the options and are clear about reasons. We don't
have to reach consensus for the AB to report our work to the AB. This
may be such a circumstance and it's OK.

Mary Brooner
Senior Director
Global Government Affairs, Motorola
1455 Pennsylvania Avenue NW, Suite 900
Washington, DC 20004
202.371.6899

From: Gregg Vanderheiden
Date: Wed, Mar 12 2008 11:45 AM
Subject: Re: Definition Consensus Decision: Text

Hi Peter,



I was in fact just writing up the same proposal ( I think). Let me see if
I got it straight.







1) we go with the Version 2 of Programmatically Determined - but call out
note 2 - like this:




Programmatically Determinable


Determinable by user agents, including assistive technologies, from the

data provided.



Note 1: Purpose is to allow user agents including assistive technologies to

extract and present this information to users in different modalities.



NOTE TO ACCESS BOARD: See separate discussion presenting different
viewpoints and issues regarding what the words "assistive technologies"
should mean in this standard and its provisions (e.g. how many, which,
legacy, existing at time or not, etc.).









And for text




Text


Sequence of characters that is programmatically determinable, where the
sequence is expressing something in human language.



NOTE TO ACCESS BOARD: There was a concern by some that the use of
'programmatically determinable' in this sentence might .







Hmmm



I'm with you on the programmatically determined part. But I'm not sure
what you are proposing to say for the Text Part. Can you propose
something?



It seems to me that no matter what we decide to do with programmatically
determinable, we still want to say that when we say "text alternative" and
"text label" and "text equivalent" etc we want to be determinable by AT.
It was just the "what AT" issue that we have problems with right?





Does the Programmatically determined fix alone get us there?






Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: Wednesday, March 12, 2008 12:09 PM
To: TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision: Text

Hi Gregg,

Yes, we need to find a way to move forward.

Since as you suggest we may well have two (or more) definitions of
programmatically determinable, perhaps we need to likewise have two (or
more) definitions of text. I am comfortable with the "Version 2 (Trace)"
definition of Programmatically determinable at
http://teitac.org/wiki/EWG:Draft_Jan_7#Programmatically_Determinable with
the EXCEPTION of Note 2. Perhaps we can consense on all of the text save
Note 2, and then call Note 2 out as something some folks want and some
don't. This might also be referenced from a section of the Narrative that
highlights these concerns. Of course we need to hear from others on TEITAC
to see if that is the only distinction.

Then in the definition of text, we might likewise have two versions, or
expository text which clearly calls out the dependency on the
"programmatically determinable" definition, notes the issues that arise from
that (and the objections to these issues) if Note 2 of the "Version 2
(Trace)" definition holds, and further notes the dependency on what "text"
means if "programmatically determinable" changes in the future.


Does that seem like a reasonable way forward?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.





Hi Peter,

I think that we are all close on what programmatically determined
means. The only difference I believe is the question about whether AT (in
this definition and throughout the standard) means 'possible AT' or
"current AT" or "AT available to consumers" or something like that (as well
as what those phrases might mean). I believe that we all think that
there will not be an agreement on that question - and that it will be
written up with two or more (hopefully only a few) positions on it.

I don't think we can or should stop the whole process to until we resolve
that single question. I think it is fairly well contained now. We are
going to use the word AT and we are going to have to highlight for the
Access Board what the issues and points of view are - and where it would
impact the provisions as we turned them in. But I think the chairs are
working on a way to do this if I have been understanding the herding words
they have been using on these topics and on how they are handling things.
Not sure if they have figured it out exactly yet but I think they are right
if I understand it - and will try to adapt my concerns and input to the
format they come up with.

Til then I think we should agree that 1) this is a very tricky question
("which AT") with very high stakes on both sides (all 4 sides?) if it isn't
done right and 2) that there are different views on how to define "which
AT".

. and then we should try to get on with the completing the rest of standard.


Oh - and yes - I should have said ". and TODAY a bitmap image of text does
not qualify as a TEXT alternative". This will likely be true for the life
of this revision of the standard - but I do expect that someday a clear
image of text would qualify as 'programmatically determinable' but a highly
stylized bitmap image of text would not (think CAPTCHA or the Illustrated
first letter of a chapter in a formal religious book or manuscript"). The
trick at that point will be having a bright line between what AT can handle
or not. Til then - 'programmatically determinable text' is likely to not
be satisfied by 'images of text'.

From: Andi Snow-Weaver
Date: Wed, Mar 12 2008 9:30 PM
Subject: Re: Definition Consensus Decision: Text

Gregg,

Sorry that I have not weighed in on this. I don't have an Internet
connection during the day here at CSUN.

With regard to this comment:

"... TODAY a bitmap image of text does not qualify as a TEXT alternative�.
This will likely be true for the life of this revision of the standard �
but I do expect that someday a clear image of text would qualify as
�programmatically determinable� but a highly stylized bitmap image of text
would not (think CAPTCHA or the Illustrated first letter of a chapter in a
formal religious book or manuscript�). The trick at that point will be
having a bright line between what AT can handle or not. Til then �
�programmatically determinable text� is likely to not be satisfied by
�images of text�."

I don't think a bitmap of text will ever be a "text alternative". When OCR
advances to the state that "text alternatives" are no longer needed for
clear images of text, then we will change the provisions in the standard
that require text alternatives but we don't change the meaning of what text
is.

Text is a binary encoded representation of a human readable sequence of
characters and the words they form. It can be determined exactly from the
pattern of 1s and 0s in the electronic storage media, assuming you know the
encoding format, and does not depend on any recognition algortithms to
extract it.

Most IT developers would interpret that as being "programmatically
determinable" but I share Peter's concern about trying to consense on a
definition of text that uses "programmatically determinable" is impossible
when we have such fundamental issues with the definition of
"programmatically determinable".

I do want to find a way to move forward on this and agree with what you and
Peter have come to regarding having two versions of both "text" and
"programmatically determinable" as long as we are clear that a particular
version of each is tied to a particular version of the other. We don't want
the AB picking one version of "text" and the wrong version of
"programmatically determinable".

Andi
_______________________________________________
teitac-committee mailing list
= EMAIL ADDRESS REMOVED =
http://list.teitac.org/mailman/listinfo/teitac-committee

From: Peter Korn
Date: Wed, Mar 12 2008 10:05 PM
Subject: Re: Definition Consensus Decision: Text

Andi,

I like your definition of text. Since we speak about text both as the
contents of a file, and as rendered to the screen, I'd like to build on
your definition (and also tweak it slightly):

"Text is a binary encoded representation of a human readable sequence of
characters/ideographs and the words they form. It can be determined
exactly from the pattern of 1s and 0s in the electronic storage media,
assuming the encoding format is known, and does not depend on any
pattern recognition algortithms to extract it. When text is imaged on
the screen in a graphical/visual environment, the translation of that
text into pixels happens by software at the time the text is imaged (vs.
a priori storage in a bitmap or other picture, which is then imaged in
toto to the display).

For purposes of accessibility, text must further be programmatically
determinable by a user agent and/or Assistive Technology. For text
encoded in a file, this means that the encoding format must be known.
For text imaged onto the screen, this means that there must be a set of
accessibility services that provide an interface to obtaining the text
contents, boundary of the text, etc. (see 3-U AT-IT Interoperability)."


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> Gregg,
>
> Sorry that I have not weighed in on this. I don't have an Internet
> connection during the day here at CSUN.
>
> With regard to this comment:
>
> "... TODAY a bitmap image of text does not qualify as a TEXT alternative�.
> This will likely be true for the life of this revision of the standard �
> but I do expect that someday a clear image of text would qualify as
> �programmatically determinable� but a highly stylized bitmap image of text
> would not (think CAPTCHA or the Illustrated first letter of a chapter in a
> formal religious book or manuscript�). The trick at that point will be
> having a bright line between what AT can handle or not. Til then �
> �programmatically determinable text� is likely to not be satisfied by
> �images of text�."
>
> I don't think a bitmap of text will ever be a "text alternative". When OCR
> advances to the state that "text alternatives" are no longer needed for
> clear images of text, then we will change the provisions in the standard
> that require text alternatives but we don't change the meaning of what text
> is.
>
> Text is a binary encoded representation of a human readable sequence of
> characters and the words they form. It can be determined exactly from the
> pattern of 1s and 0s in the electronic storage media, assuming you know the
> encoding format, and does not depend on any recognition algortithms to
> extract it.
>
> Most IT developers would interpret that as being "programmatically
> determinable" but I share Peter's concern about trying to consense on a
> definition of text that uses "programmatically determinable" is impossible
> when we have such fundamental issues with the definition of
> "programmatically determinable".
>
> I do want to find a way to move forward on this and agree with what you and
> Peter have come to regarding having two versions of both "text" and
> "programmatically determinable" as long as we are clear that a particular
> version of each is tied to a particular version of the other. We don't want
> the AB picking one version of "text" and the wrong version of
> "programmatically determinable".
>
> Andi
> _______________________________________________
> teitac-committee mailing list
> = EMAIL ADDRESS REMOVED =
> http://list.teitac.org/mailman/listinfo/teitac-committee
>

_______________________________________________
teitac-committee mailing list
= EMAIL ADDRESS REMOVED =
http://list.teitac.org/mailman/listinfo/teitac-committee

From: Gregg Vanderheiden
Date: Wed, Mar 12 2008 11:00 PM
Subject: Re: Definition Consensus Decision: Text

Hi Andi,



No problem with the assessment. It wasn't a good idea to get into talking
about things beyond the life of the standards anyway.



RE programmatically determined - and text.



What about the suggestion to avoid multiple versions of the definitions by
(as Peter suggested) using version 2 removing the note 2 and replacing it
with a note referring readers to a section where the issues and points of
view can be presented without decision.



Here it is (With 'user agent' replaced by 'software' to better match




Programmatically Determinable


determinable by software, including assistive technologies, from the data
provided.



Note 1: Purpose is to allow user agents including assistive technologies to
extract and present this information to users in different modalities.



NOTE TO ACCESS BOARD: See separate discussion presenting different
viewpoints and issues regarding what the words "assistive technologies"
should mean in this standard and its provisions (e.g. how many, which,
legacy AT, existing at time or not, etc.).









Gregg

-- ------------------------------

Gregg C Vanderheiden Ph.D.







> -----Original Message-----

> From: = EMAIL ADDRESS REMOVED =

> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf

> Of Andi Snow-Weaver

> Sent: Wednesday, March 12, 2008 10:27 PM

> To: TEITAC Committee

> Subject: Re: [teitac-committee] Definition Consensus Decision: Text

>

> Gregg,

>

> Sorry that I have not weighed in on this. I don't have an

> Internet connection during the day here at CSUN.

>

> With regard to this comment:

>

> "... TODAY a bitmap image of text does not qualify as a TEXT

> alternative".

> This will likely be true for the life of this revision of the

> standard - but I do expect that someday a clear image of text

> would qualify as 'programmatically determinable' but a

> highly stylized bitmap image of text would not (think CAPTCHA

> or the Illustrated first letter of a chapter in a

> formal religious book or manuscript"). The trick at that

> point will be

> having a bright line between what AT can handle or not. Til then -

> 'programmatically determinable text' is likely to not be

> satisfied by 'images of text'."

>

> I don't think a bitmap of text will ever be a "text

> alternative". When OCR advances to the state that "text

> alternatives" are no longer needed for clear images of text,

> then we will change the provisions in the standard that

> require text alternatives but we don't change the meaning of

> what text is.

>

> Text is a binary encoded representation of a human readable

> sequence of characters and the words they form. It can be

> determined exactly from the pattern of 1s and 0s in the

> electronic storage media, assuming you know the encoding

> format, and does not depend on any recognition algortithms to

> extract it.

>

> Most IT developers would interpret that as being

> "programmatically determinable" but I share Peter's concern

> about trying to consense on a definition of text that uses

> "programmatically determinable" is impossible when we have

> such fundamental issues with the definition of

> "programmatically determinable".

>

> I do want to find a way to move forward on this and agree

> with what you and Peter have come to regarding having two

> versions of both "text" and "programmatically determinable"

> as long as we are clear that a particular version of each is

> tied to a particular version of the other. We don't want the

> AB picking one version of "text" and the wrong version of

> "programmatically determinable".

>

> Andi

>

From: Gregg Vanderheiden
Date: Wed, Mar 12 2008 11:05 PM
Subject: Re: Definition Consensus Decision: Text

Ok

Lets see if we can work with this. it is a bit long for a definition and
contains "must" which is not usually allowed in definitions.

Text
a programmatically determinable binary encoded representation of a human
readable sequence of characters/ideographs that can be decoded without
pattern recognition

Note: When text is imaged on the screen in a graphical/visual environment,
the translation of that text into pixels happens by software at the time the
text is imaged (vs. a priori storage in a bitmap or other picture, which is
then imaged in toto to the display).

Note: For text encoded in a file, this means that the encoding format that
is known. For text imaged onto the screen, this means that there must be a
set of accessibility services that provide an interface to obtaining the
text contents, boundary of the text, etc. (see 3-U AT-IT Interoperability).




I wonder though - if we need the notes. For the text file we would need to
specify what "known" means. Known to who. And I think note one follows
from the definition. Since we have programmatically determined - and since
that means determinable by software including AT - I think all the rest is
not necessary.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: Wednesday, March 12, 2008 11:04 PM
> To: TEITAC Committee
> Subject: Re: [teitac-committee] Definition Consensus Decision: Text
>
> Andi,
>
> I like your definition of text. Since we speak about text
> both as the contents of a file, and as rendered to the
> screen, I'd like to build on your definition (and also tweak
> it slightly):
>
> "Text is a binary encoded representation of a human readable
> sequence of characters/ideographs and the words they form. It
> can be determined exactly from the pattern of 1s and 0s in
> the electronic storage media, assuming the encoding format is
> known, and does not depend on any pattern recognition
> algortithms to extract it. When text is imaged on the screen
> in a graphical/visual environment, the translation of that
> text into pixels happens by software at the time the text is
> imaged (vs.
> a priori storage in a bitmap or other picture, which is then
> imaged in toto to the display).
>
> For purposes of accessibility, text must further be
> programmatically determinable by a user agent and/or
> Assistive Technology. For text encoded in a file, this means
> that the encoding format must be known.
> For text imaged onto the screen, this means that there must
> be a set of accessibility services that provide an interface
> to obtaining the text contents, boundary of the text, etc.
> (see 3-U AT-IT Interoperability)."
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> > Gregg,
> >
> > Sorry that I have not weighed in on this. I don't have an Internet
> > connection during the day here at CSUN.
> >
> > With regard to this comment:
> >
> > "... TODAY a bitmap image of text does not qualify as a
> TEXT alternative".
> > This will likely be true for the life of this revision of
> the standard
> > - but I do expect that someday a clear image of text would
> qualify as
> > 'programmatically determinable' but a highly stylized
> bitmap image of
> > text would not (think CAPTCHA or the Illustrated first
> letter of a chapter in a
> > formal religious book or manuscript"). The trick at that
> point will be
> > having a bright line between what AT can handle or not.
> Til then -
> > 'programmatically determinable text' is likely to not be
> satisfied by
> > 'images of text'."
> >
> > I don't think a bitmap of text will ever be a "text
> alternative". When
> > OCR advances to the state that "text alternatives" are no longer
> > needed for clear images of text, then we will change the
> provisions in
> > the standard that require text alternatives but we don't change the
> > meaning of what text is.
> >
> > Text is a binary encoded representation of a human readable
> sequence
> > of characters and the words they form. It can be determined exactly
> > from the pattern of 1s and 0s in the electronic storage media,
> > assuming you know the encoding format, and does not depend on any
> > recognition algortithms to extract it.
> >
> > Most IT developers would interpret that as being "programmatically
> > determinable" but I share Peter's concern about trying to
> consense on
> > a definition of text that uses "programmatically determinable" is
> > impossible when we have such fundamental issues with the
> definition of
> > "programmatically determinable".
> >
> > I do want to find a way to move forward on this and agree with what
> > you and Peter have come to regarding having two versions of both
> > "text" and "programmatically determinable" as long as we are clear
> > that a particular version of each is tied to a particular
> version of
> > the other. We don't want the AB picking one version of
> "text" and the
> > wrong version of "programmatically determinable".
> >
> > Andi
> >

From: Randy Marsden
Date: Wed, Mar 12 2008 11:15 PM
Subject: Re: Definition Consensus Decision: Text

This wouldn't be the first time I didn't understand some of Peter's
vast vocabulary, but is "toto" a word? (I mean other than Dorothy's
dog). It's in the last sentence in the first note. Should that read
"total"?

I like the direction of this definition.

-Randy

On Mar 12, 2008, at 10:54 PM, Gregg Vanderheiden wrote:

> Ok
>
> Lets see if we can work with this. it is a bit long for a
> definition and
> contains "must" which is not usually allowed in definitions.
>
> Text
> a programmatically determinable binary encoded representation of a
> human
> readable sequence of characters/ideographs that can be decoded without
> pattern recognition
>
> Note: When text is imaged on the screen in a graphical/visual
> environment,
> the translation of that text into pixels happens by software at the
> time the
> text is imaged (vs. a priori storage in a bitmap or other picture,
> which is
> then imaged in toto to the display).
>
> Note: For text encoded in a file, this means that the encoding
> format that
> is known. For text imaged onto the screen, this means that there
> must be a
> set of accessibility services that provide an interface to obtaining
> the
> text contents, boundary of the text, etc. (see 3-U AT-IT
> Interoperability).
>
>
>
>
> I wonder though - if we need the notes. For the text file we would
> need to
> specify what "known" means. Known to who. And I think note one
> follows
> from the definition. Since we have programmatically determined -
> and since
> that means determinable by software including AT - I think all the
> rest is
> not necessary.
>
>
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>> Of Peter Korn
>> Sent: Wednesday, March 12, 2008 11:04 PM
>> To: TEITAC Committee
>> Subject: Re: [teitac-committee] Definition Consensus Decision: Text
>>
>> Andi,
>>
>> I like your definition of text. Since we speak about text
>> both as the contents of a file, and as rendered to the
>> screen, I'd like to build on your definition (and also tweak
>> it slightly):
>>
>> "Text is a binary encoded representation of a human readable
>> sequence of characters/ideographs and the words they form. It
>> can be determined exactly from the pattern of 1s and 0s in
>> the electronic storage media, assuming the encoding format is
>> known, and does not depend on any pattern recognition
>> algortithms to extract it. When text is imaged on the screen
>> in a graphical/visual environment, the translation of that
>> text into pixels happens by software at the time the text is
>> imaged (vs.
>> a priori storage in a bitmap or other picture, which is then
>> imaged in toto to the display).
>>
>> For purposes of accessibility, text must further be
>> programmatically determinable by a user agent and/or
>> Assistive Technology. For text encoded in a file, this means
>> that the encoding format must be known.
>> For text imaged onto the screen, this means that there must
>> be a set of accessibility services that provide an interface
>> to obtaining the text contents, boundary of the text, etc.
>> (see 3-U AT-IT Interoperability)."
>>
>>
>> Regards,
>>
>> Peter Korn
>> Accessibility Architect,
>> Sun Microsystems, Inc.
>>
>>> Gregg,
>>>
>>> Sorry that I have not weighed in on this. I don't have an Internet
>>> connection during the day here at CSUN.
>>>
>>> With regard to this comment:
>>>
>>> "... TODAY a bitmap image of text does not qualify as a
>> TEXT alternative".
>>> This will likely be true for the life of this revision of
>> the standard
>>> - but I do expect that someday a clear image of text would
>> qualify as
>>> 'programmatically determinable' but a highly stylized
>> bitmap image of
>>> text would not (think CAPTCHA or the Illustrated first
>> letter of a chapter in a
>>> formal religious book or manuscript"). The trick at that
>> point will be
>>> having a bright line between what AT can handle or not.
>> Til then -
>>> 'programmatically determinable text' is likely to not be
>> satisfied by
>>> 'images of text'."
>>>
>>> I don't think a bitmap of text will ever be a "text
>> alternative". When
>>> OCR advances to the state that "text alternatives" are no longer
>>> needed for clear images of text, then we will change the
>> provisions in
>>> the standard that require text alternatives but we don't change the
>>> meaning of what text is.
>>>
>>> Text is a binary encoded representation of a human readable
>> sequence
>>> of characters and the words they form. It can be determined exactly
>>> from the pattern of 1s and 0s in the electronic storage media,
>>> assuming you know the encoding format, and does not depend on any
>>> recognition algortithms to extract it.
>>>
>>> Most IT developers would interpret that as being "programmatically
>>> determinable" but I share Peter's concern about trying to
>> consense on
>>> a definition of text that uses "programmatically determinable" is
>>> impossible when we have such fundamental issues with the
>> definition of
>>> "programmatically determinable".
>>>
>>> I do want to find a way to move forward on this and agree with what
>>> you and Peter have come to regarding having two versions of both
>>> "text" and "programmatically determinable" as long as we are clear
>>> that a particular version of each is tied to a particular
>> version of
>>> the other. We don't want the AB picking one version of
>> "text" and the
>>> wrong version of "programmatically determinable".
>>>
>>> Andi
>>>

From: Hoffman, Allen
Date: Thu, Mar 13 2008 6:05 AM
Subject: Re: Definition Consensus Decision: Text

Andi wrote:
Text is a binary encoded representation of a human readable sequence of
characters and the words they form. It can be determined exactly from
the pattern of 1s and 0s in the electronic storage media, assuming you
know the encoding format, and does not depend on any recognition
algortithms to extract it.

This isn't "text", it is electronic text, or electronically encoded
text. Should "electronically encoded or stored text" be the actual
definition then? Or, do we just state for purposes of these
recommendations "text" is...?





Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi
Snow-Weaver
Sent: Wednesday, March 12, 2008 11:27 PM
To: TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision: Text

Gregg,

Sorry that I have not weighed in on this. I don't have an Internet
connection during the day here at CSUN.

With regard to this comment:

"... TODAY a bitmap image of text does not qualify as a TEXT
alternative".
This will likely be true for the life of this revision of the standard -
but I do expect that someday a clear image of text would qualify as
'programmatically determinable' but a highly stylized bitmap image of
text would not (think CAPTCHA or the Illustrated first letter of a
chapter in a
formal religious book or manuscript"). The trick at that point will
be
having a bright line between what AT can handle or not. Til then -
'programmatically determinable text' is likely to not be satisfied by
'images of text'."

I don't think a bitmap of text will ever be a "text alternative". When
OCR advances to the state that "text alternatives" are no longer needed
for clear images of text, then we will change the provisions in the
standard that require text alternatives but we don't change the meaning
of what text is.

Text is a binary encoded representation of a human readable sequence of
characters and the words they form. It can be determined exactly from
the pattern of 1s and 0s in the electronic storage media, assuming you
know the encoding format, and does not depend on any recognition
algortithms to extract it.

Most IT developers would interpret that as being "programmatically
determinable" but I share Peter's concern about trying to consense on a
definition of text that uses "programmatically determinable" is
impossible when we have such fundamental issues with the definition of
"programmatically determinable".

I do want to find a way to move forward on this and agree with what you
and Peter have come to regarding having two versions of both "text" and
"programmatically determinable" as long as we are clear that a
particular version of each is tied to a particular version of the other.
We don't want the AB picking one version of "text" and the wrong version
of "programmatically determinable".

Andi

From: Andi Snow-Weaver
Date: Thu, Mar 13 2008 7:15 AM
Subject: Re: Definition Consensus Decision: Text

Allen,

I was trying to say that for the context of "electronic" IT standards, this
is what text is.

Andi




"Hoffman, Allen"
<Allen.Hoffman@dh
s.gov> To
Sent by: "TEITAC Committee"
teitac-committee- < = EMAIL ADDRESS REMOVED = >
= EMAIL ADDRESS REMOVED = cc
ac.org
Subject
Re: [teitac-committee] Definition
03/13/2008 05:01 Consensus Decision: Text
AM


Please respond to
TEITAC Committee
<teitac-committee
@list.teitac.org>






Andi wrote:
Text is a binary encoded representation of a human readable sequence of
characters and the words they form. It can be determined exactly from
the pattern of 1s and 0s in the electronic storage media, assuming you
know the encoding format, and does not depend on any recognition
algortithms to extract it.

This isn't "text", it is electronic text, or electronically encoded
text. Should "electronically encoded or stored text" be the actual
definition then? Or, do we just state for purposes of these
recommendations "text" is...?





Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi
Snow-Weaver
Sent: Wednesday, March 12, 2008 11:27 PM
To: TEITAC Committee
Subject: Re: [teitac-committee] Definition Consensus Decision: Text

Gregg,

Sorry that I have not weighed in on this. I don't have an Internet
connection during the day here at CSUN.

With regard to this comment:

"... TODAY a bitmap image of text does not qualify as a TEXT
alternative".
This will likely be true for the life of this revision of the standard -
but I do expect that someday a clear image of text would qualify as
'programmatically determinable' but a highly stylized bitmap image of
text would not (think CAPTCHA or the Illustrated first letter of a
chapter in a
formal religious book or manuscript"). The trick at that point will
be
having a bright line between what AT can handle or not. Til then -
'programmatically determinable text' is likely to not be satisfied by
'images of text'."

I don't think a bitmap of text will ever be a "text alternative". When
OCR advances to the state that "text alternatives" are no longer needed
for clear images of text, then we will change the provisions in the
standard that require text alternatives but we don't change the meaning
of what text is.

Text is a binary encoded representation of a human readable sequence of
characters and the words they form. It can be determined exactly from
the pattern of 1s and 0s in the electronic storage media, assuming you
know the encoding format, and does not depend on any recognition
algortithms to extract it.

Most IT developers would interpret that as being "programmatically
determinable" but I share Peter's concern about trying to consense on a
definition of text that uses "programmatically determinable" is
impossible when we have such fundamental issues with the definition of
"programmatically determinable".

I do want to find a way to move forward on this and agree with what you
and Peter have come to regarding having two versions of both "text" and
"programmatically determinable" as long as we are clear that a
particular version of each is tied to a particular version of the other.
We don't want the AB picking one version of "text" and the wrong version
of "programmatically determinable".

Andi

From: Gregg Vanderheiden
Date: Thu, Mar 13 2008 11:40 AM
Subject: Re: Definition Consensus Decision: Text

Hi Allen,

I made the same observation a long time ago in WCAG - that when we say that
all information should be in text we really mean etext or some other word.
But it gets very complicated and awkward to say etext file, non-etext
content etc. You can substitute anything you want for etext and you get
the same problem (or worse if it is two words long). So we went with text
and images of text in WCAG.


In a standard many of the words used are narrower than public use. So you
define them in the standard so people know what they mean if you don't mean
the general meaning. But this one is hard to do right - and needs to be
because having text be readable by AT is central to so many of the
provisions in TEITAC. If the text can't be seen or read by the AT then all
the provisions requiring that information be in text have no meaning. So I
think following WCAG lead as was suggested is the way to do this.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Hoffman, Allen
> Sent: Thursday, March 13, 2008 7:02 AM
> To: TEITAC Committee
> Subject: Re: [teitac-committee] Definition Consensus Decision: Text
>
> Andi wrote:
> Text is a binary encoded representation of a human readable
> sequence of characters and the words they form. It can be
> determined exactly from the pattern of 1s and 0s in the
> electronic storage media, assuming you know the encoding
> format, and does not depend on any recognition algortithms to
> extract it.
>
> This isn't "text", it is electronic text, or electronically
> encoded text. Should "electronically encoded or stored text"
> be the actual definition then? Or, do we just state for
> purposes of these recommendations "text" is...?
>
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Andi Snow-Weaver
> Sent: Wednesday, March 12, 2008 11:27 PM
> To: TEITAC Committee
> Subject: Re: [teitac-committee] Definition Consensus Decision: Text
>
> Gregg,
>
> Sorry that I have not weighed in on this. I don't have an
> Internet connection during the day here at CSUN.
>
> With regard to this comment:
>
> "... TODAY a bitmap image of text does not qualify as a TEXT
> alternative".
> This will likely be true for the life of this revision of the
> standard - but I do expect that someday a clear image of text
> would qualify as 'programmatically determinable' but a
> highly stylized bitmap image of text would not (think CAPTCHA
> or the Illustrated first letter of a chapter in a
> formal religious book or manuscript"). The trick at that point will
> be
> having a bright line between what AT can handle or not. Til then -
> 'programmatically determinable text' is likely to not be
> satisfied by 'images of text'."
>
> I don't think a bitmap of text will ever be a "text
> alternative". When OCR advances to the state that "text
> alternatives" are no longer needed for clear images of text,
> then we will change the provisions in the standard that
> require text alternatives but we don't change the meaning of
> what text is.
>
> Text is a binary encoded representation of a human readable
> sequence of characters and the words they form. It can be
> determined exactly from the pattern of 1s and 0s in the
> electronic storage media, assuming you know the encoding
> format, and does not depend on any recognition algortithms to
> extract it.
>
> Most IT developers would interpret that as being
> "programmatically determinable" but I share Peter's concern
> about trying to consense on a definition of text that uses
> "programmatically determinable" is impossible when we have
> such fundamental issues with the definition of
> "programmatically determinable".
>
> I do want to find a way to move forward on this and agree
> with what you and Peter have come to regarding having two
> versions of both "text" and "programmatically determinable"
> as long as we are clear that a particular version of each is
> tied to a particular version of the other.
> We don't want the AB picking one version of "text" and the
> wrong version of "programmatically determinable".
>
> Andi
>

From: Hoffman, Allen
Date: Thu, Mar 13 2008 12:55 PM
Subject: Re: Definition Consensus Decision: Text

I'm fine with this.



Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Thursday, March 13, 2008 1:35 PM
To: 'TEITAC Committee'
Subject: Re: [teitac-committee] Definition Consensus Decision: Text

Hi Allen,

I made the same observation a long time ago in WCAG - that when we say
that all information should be in text we really mean etext or some
other word.
But it gets very complicated and awkward to say etext file, non-etext
content etc. You can substitute anything you want for etext and you
get
the same problem (or worse if it is two words long). So we went with
text and images of text in WCAG.


In a standard many of the words used are narrower than public use. So
you define them in the standard so people know what they mean if you
don't mean
the general meaning. But this one is hard to do right - and needs to
be
because having text be readable by AT is central to so many of the
provisions in TEITAC. If the text can't be seen or read by the AT then
all the provisions requiring that information be in text have no
meaning. So I think following WCAG lead as was suggested is the way to
do this.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Hoffman, Allen
> Sent: Thursday, March 13, 2008 7:02 AM
> To: TEITAC Committee
> Subject: Re: [teitac-committee] Definition Consensus Decision: Text
>
> Andi wrote:
> Text is a binary encoded representation of a human readable sequence
> of characters and the words they form. It can be determined exactly
> from the pattern of 1s and 0s in the electronic storage media,
> assuming you know the encoding format, and does not depend on any
> recognition algortithms to extract it.
>
> This isn't "text", it is electronic text, or electronically encoded
> text. Should "electronically encoded or stored text"
> be the actual definition then? Or, do we just state for purposes of
> these recommendations "text" is...?
>
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi
> Snow-Weaver
> Sent: Wednesday, March 12, 2008 11:27 PM
> To: TEITAC Committee
> Subject: Re: [teitac-committee] Definition Consensus Decision: Text
>
> Gregg,
>
> Sorry that I have not weighed in on this. I don't have an Internet
> connection during the day here at CSUN.
>
> With regard to this comment:
>
> "... TODAY a bitmap image of text does not qualify as a TEXT
> alternative".
> This will likely be true for the life of this revision of the standard

> - but I do expect that someday a clear image of text would qualify as
> 'programmatically determinable' but a highly stylized bitmap image of

> text would not (think CAPTCHA or the Illustrated first letter of a
> chapter in a
> formal religious book or manuscript"). The trick at that point will
> be
> having a bright line between what AT can handle or not. Til then -
> 'programmatically determinable text' is likely to not be satisfied by
> 'images of text'."
>
> I don't think a bitmap of text will ever be a "text alternative". When

> OCR advances to the state that "text alternatives" are no longer
> needed for clear images of text, then we will change the provisions in

> the standard that require text alternatives but we don't change the
> meaning of what text is.
>
> Text is a binary encoded representation of a human readable sequence
> of characters and the words they form. It can be determined exactly
> from the pattern of 1s and 0s in the electronic storage media,
> assuming you know the encoding format, and does not depend on any
> recognition algortithms to extract it.
>
> Most IT developers would interpret that as being "programmatically
> determinable" but I share Peter's concern about trying to consense on
> a definition of text that uses "programmatically determinable" is
> impossible when we have such fundamental issues with the definition of

> "programmatically determinable".
>
> I do want to find a way to move forward on this and agree with what
> you and Peter have come to regarding having two versions of both
> "text" and "programmatically determinable"
> as long as we are clear that a particular version of each is tied to a

> particular version of the other.
> We don't want the AB picking one version of "text" and the wrong
> version of "programmatically determinable".
>
> Andi
>

From: Peter Korn
Date: Thu, Mar 13 2008 10:30 PM
Subject: Re: Definition Consensus Decision: Text

Hi Randy,

Please see http://www.merriam-webster.com/dictionary/in%20toto

It may be that the Merriam-Webster folks are based in Kansas. Could be
wrong about that though...


Peter "loquacious" Korn
Accessibility Architect
Sun Microsystems, Inc.

> This wouldn't be the first time I didn't understand some of Peter's
> vast vocabulary, but is "toto" a word? (I mean other than Dorothy's
> dog). It's in the last sentence in the first note. Should that read
> "total"?
>
> I like the direction of this definition.
>
> -Randy
>
> On Mar 12, 2008, at 10:54 PM, Gregg Vanderheiden wrote:
>
>> Ok
>>
>> Lets see if we can work with this. it is a bit long for a definition and
>> contains "must" which is not usually allowed in definitions.
>>
>> Text
>> a programmatically determinable binary encoded representation of a human
>> readable sequence of characters/ideographs that can be decoded without
>> pattern recognition
>>
>> Note: When text is imaged on the screen in a graphical/visual
>> environment,
>> the translation of that text into pixels happens by software at the
>> time the
>> text is imaged (vs. a priori storage in a bitmap or other picture,
>> which is
>> then imaged in toto to the display).
>>
>> Note: For text encoded in a file, this means that the encoding
>> format that
>> is known. For text imaged onto the screen, this means that there
>> must be a
>> set of accessibility services that provide an interface to obtaining the
>> text contents, boundary of the text, etc. (see 3-U AT-IT
>> Interoperability).
>>
>>
>>
>>
>> I wonder though - if we need the notes. For the text file we would
>> need to
>> specify what "known" means. Known to who. And I think note one follows
>> from the definition. Since we have programmatically determined - and
>> since
>> that means determinable by software including AT - I think all the
>> rest is
>> not necessary.
>>
>>
>>
>>
>> Gregg
>> -- ------------------------------
>> Gregg C Vanderheiden Ph.D.
>>
>>
>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>>> <mailto: = EMAIL ADDRESS REMOVED = >
>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>>> Of Peter Korn
>>> Sent: Wednesday, March 12, 2008 11:04 PM
>>> To: TEITAC Committee
>>> Subject: Re: [teitac-committee] Definition Consensus Decision: Text
>>>
>>> Andi,
>>>
>>> I like your definition of text. Since we speak about text
>>> both as the contents of a file, and as rendered to the
>>> screen, I'd like to build on your definition (and also tweak
>>> it slightly):
>>>
>>> "Text is a binary encoded representation of a human readable
>>> sequence of characters/ideographs and the words they form. It
>>> can be determined exactly from the pattern of 1s and 0s in
>>> the electronic storage media, assuming the encoding format is
>>> known, and does not depend on any pattern recognition
>>> algortithms to extract it. When text is imaged on the screen
>>> in a graphical/visual environment, the translation of that
>>> text into pixels happens by software at the time the text is
>>> imaged (vs.
>>> a priori storage in a bitmap or other picture, which is then
>>> imaged in toto to the display).
>>>
>>> For purposes of accessibility, text must further be
>>> programmatically determinable by a user agent and/or
>>> Assistive Technology. For text encoded in a file, this means
>>> that the encoding format must be known.
>>> For text imaged onto the screen, this means that there must
>>> be a set of accessibility services that provide an interface
>>> to obtaining the text contents, boundary of the text, etc.
>>> (see 3-U AT-IT Interoperability)."
>>>
>>>
>>> Regards,
>>>
>>> Peter Korn
>>> Accessibility Architect,
>>> Sun Microsystems, Inc.
>>>
>>>> Gregg,
>>>>
>>>> Sorry that I have not weighed in on this. I don't have an Internet
>>>> connection during the day here at CSUN.
>>>>
>>>> With regard to this comment:
>>>>
>>>> "... TODAY a bitmap image of text does not qualify as a
>>> TEXT alternative".
>>>> This will likely be true for the life of this revision of
>>> the standard
>>>> - but I do expect that someday a clear image of text would
>>> qualify as
>>>> 'programmatically determinable' but a highly stylized
>>> bitmap image of
>>>> text would not (think CAPTCHA or the Illustrated first
>>> letter of a chapter in a
>>>> formal religious book or manuscript"). The trick at that
>>> point will be
>>>> having a bright line between what AT can handle or not.
>>> Til then -
>>>> 'programmatically determinable text' is likely to not be
>>> satisfied by
>>>> 'images of text'."
>>>>
>>>> I don't think a bitmap of text will ever be a "text
>>> alternative". When
>>>> OCR advances to the state that "text alternatives" are no longer
>>>> needed for clear images of text, then we will change the
>>> provisions in
>>>> the standard that require text alternatives but we don't change the
>>>> meaning of what text is.
>>>>
>>>> Text is a binary encoded representation of a human readable
>>> sequence
>>>> of characters and the words they form. It can be determined exactly
>>>> from the pattern of 1s and 0s in the electronic storage media,
>>>> assuming you know the encoding format, and does not depend on any
>>>> recognition algortithms to extract it.
>>>>
>>>> Most IT developers would interpret that as being "programmatically
>>>> determinable" but I share Peter's concern about trying to
>>> consense on
>>>> a definition of text that uses "programmatically determinable" is
>>>> impossible when we have such fundamental issues with the
>>> definition of
>>>> "programmatically determinable".
>>>>
>>>> I do want to find a way to move forward on this and agree with what
>>>> you and Peter have come to regarding having two versions of both
>>>> "text" and "programmatically determinable" as long as we are clear
>>>> that a particular version of each is tied to a particular
>>> version of
>>>> the other. We don't want the AB picking one version of
>>> "text" and the
>>>> wrong version of "programmatically determinable".
>>>>
>>>> Andi
>>>>

From: Peter Korn
Date: Thu, Mar 13 2008 10:40 PM
Subject: Re: Definition Consensus Decision: Text

Hi Gregg,

I appreciate your working to use the definition proposal I put forth
(based on Andi's good work). But I feel you aren't quite hearing what
I'm saying; that you are missing the point(s) I am making.

I believe that text is text, whether or not there is a formal interface
to expose it to other software. I believe that accessible rendered text
is text with such an interface, and accessible text in a file is text
with a published encoding scheme that is published for others to use.
Text on a printed page is text in my view; but it isn't accessible in
that form.

If you like the definition as you have modified it below, I warmly
invite you to put it forth as your proposal. If you prefer your first
version, then I warmly invite you to stick with that. Perhaps others
will agree with your choice. For me, I don't believe programmatically
determinable belongs in the definition of all text. I believe it
belongs in the definition of accessible text. If that doesn't work for
you, then I suggest we agree at this point to put forth two variant
proposals, see if they gain adherents - such that we coalesce around
only two versions - and move on to other topics. With the little time
we have left, I don't think it is worth expending any more energy trying
to find consensus here. We have bigger fish to fry...


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> Ok
>
> Lets see if we can work with this. it is a bit long for a definition and
> contains "must" which is not usually allowed in definitions.
>
> Text
> a programmatically determinable binary encoded representation of a human
> readable sequence of characters/ideographs that can be decoded without
> pattern recognition
>
> Note: When text is imaged on the screen in a graphical/visual environment,
> the translation of that text into pixels happens by software at the time the
> text is imaged (vs. a priori storage in a bitmap or other picture, which is
> then imaged in toto to the display).
>
> Note: For text encoded in a file, this means that the encoding format that
> is known. For text imaged onto the screen, this means that there must be a
> set of accessibility services that provide an interface to obtaining the
> text contents, boundary of the text, etc. (see 3-U AT-IT Interoperability).
>
>
>
>
> I wonder though - if we need the notes. For the text file we would need to
> specify what "known" means. Known to who. And I think note one follows
> from the definition. Since we have programmatically determined - and since
> that means determinable by software including AT - I think all the rest is
> not necessary.
>
>
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>> Of Peter Korn
>> Sent: Wednesday, March 12, 2008 11:04 PM
>> To: TEITAC Committee
>> Subject: Re: [teitac-committee] Definition Consensus Decision: Text
>>
>> Andi,
>>
>> I like your definition of text. Since we speak about text
>> both as the contents of a file, and as rendered to the
>> screen, I'd like to build on your definition (and also tweak
>> it slightly):
>>
>> "Text is a binary encoded representation of a human readable
>> sequence of characters/ideographs and the words they form. It
>> can be determined exactly from the pattern of 1s and 0s in
>> the electronic storage media, assuming the encoding format is
>> known, and does not depend on any pattern recognition
>> algortithms to extract it. When text is imaged on the screen
>> in a graphical/visual environment, the translation of that
>> text into pixels happens by software at the time the text is
>> imaged (vs.
>> a priori storage in a bitmap or other picture, which is then
>> imaged in toto to the display).
>>
>> For purposes of accessibility, text must further be
>> programmatically determinable by a user agent and/or
>> Assistive Technology. For text encoded in a file, this means
>> that the encoding format must be known.
>> For text imaged onto the screen, this means that there must
>> be a set of accessibility services that provide an interface
>> to obtaining the text contents, boundary of the text, etc.
>> (see 3-U AT-IT Interoperability)."
>>
>>
>> Regards,
>>
>> Peter Korn
>> Accessibility Architect,
>> Sun Microsystems, Inc.
>>
>>
>>> Gregg,
>>>
>>> Sorry that I have not weighed in on this. I don't have an Internet
>>> connection during the day here at CSUN.
>>>
>>> With regard to this comment:
>>>
>>> "... TODAY a bitmap image of text does not qualify as a
>>>
>> TEXT alternative".
>>
>>> This will likely be true for the life of this revision of
>>>
>> the standard
>>
>>> - but I do expect that someday a clear image of text would
>>>
>> qualify as
>>
>>> 'programmatically determinable' but a highly stylized
>>>
>> bitmap image of
>>
>>> text would not (think CAPTCHA or the Illustrated first
>>>
>> letter of a chapter in a
>>
>>> formal religious book or manuscript"). The trick at that
>>>
>> point will be
>>
>>> having a bright line between what AT can handle or not.
>>>
>> Til then -
>>
>>> 'programmatically determinable text' is likely to not be
>>>
>> satisfied by
>>
>>> 'images of text'."
>>>
>>> I don't think a bitmap of text will ever be a "text
>>>
>> alternative". When
>>
>>> OCR advances to the state that "text alternatives" are no longer
>>> needed for clear images of text, then we will change the
>>>
>> provisions in
>>
>>> the standard that require text alternatives but we don't change the
>>> meaning of what text is.
>>>
>>> Text is a binary encoded representation of a human readable
>>>
>> sequence
>>
>>> of characters and the words they form. It can be determined exactly
>>> from the pattern of 1s and 0s in the electronic storage media,
>>> assuming you know the encoding format, and does not depend on any
>>> recognition algortithms to extract it.
>>>
>>> Most IT developers would interpret that as being "programmatically
>>> determinable" but I share Peter's concern about trying to
>>>
>> consense on
>>
>>> a definition of text that uses "programmatically determinable" is
>>> impossible when we have such fundamental issues with the
>>>
>> definition of
>>
>>> "programmatically determinable".
>>>
>>> I do want to find a way to move forward on this and agree with what
>>> you and Peter have come to regarding having two versions of both
>>> "text" and "programmatically determinable" as long as we are clear
>>> that a particular version of each is tied to a particular
>>>
>> version of
>>
>>> the other. We don't want the AB picking one version of
>>>
>> "text" and the
>>
>>> wrong version of "programmatically determinable".
>>>
>>> Andi
>>>