Thread Subject: Re: Definition Consensus Decision: Text

Note

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: Peter Korn
Date: Tue, Mar 11 2008 12:25 AM

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

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University