Thread Subject: Re: Definition Consensus Decision: Text
This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.
From: Andi Snow-Weaver
Date: Tue, Mar 11 2008 1:05 PM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Andi Snow-Weaver: "Re: Definition Consensus Decision:Authoring Tools"
- Previous message in thread: Gregg Vanderheiden: "Re: Definition Consensus Decision:SimpleTactile Form"
- Messages sorted by: Author | Thread | Date
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.
< = EMAIL ADDRESS REMOVED = To
u> "'TEITAC Committee'"
Sent by: < = EMAIL ADDRESS REMOVED = >
= EMAIL ADDRESS REMOVED =
Re: [teitac-committee] Definition
Consensus Decision: Text
Please respond to
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
Hence the definition.
Gregg C Vanderheiden Ph.D.
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Randy
Sent: Monday, March 10, 2008 11:31 PM
To: TEITAC Committee,
Subject: Re: [teitac-committee] Definition Consensus Decision: Text
Text may refer to::
Â§ Plain text
Â§ 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)..
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
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).
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
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.
"Sequence of characters that is programmatically determinable, where the
sequence is expressing something in human language."
teitac-committee mailing list
= EMAIL ADDRESS REMOVED =
- Next message in Thread: Andi Snow-Weaver: "Re: Definition Consensus Decision:Authoring Tools"
- Previous message in Thread: Gregg Vanderheiden: "Re: Definition Consensus Decision:SimpleTactile Form"