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: Sean Hayes
Date: Sat, Mar 15 2008 6:15 PM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Gregg Vanderheiden: "Re: Definition Consensus Decision: Text"
- Previous message in thread: Gregg Vanderheiden: "Re: Definition Consensus Decision: Text"
- Messages sorted by: Author | Thread | Date
GV: On the text question - I do believe we can agree that text as we use it in the standard, must be programmatically determinable. AT must be able to get at it.
I don't think we will, nor indeed have to, agree that for the definition of text. For example in 1-C while routers must provide transmission of text, there is no need for routers to allow AT to get at the text during transmission. I don't believe it applies in 1-G, which I believe is also for printed text on the case, and letters on a screen (characters on an lcd screen are in fact images of text). The use of text in some of the notes is also talking about internal representations which may not necessarily be accessible directly (although it would be if it were represented in the UI).
We also have the kludge of "text" in captions. 4-A actually has a problem if we don't use "text" as we mean it in the definition of captions.
3-U is there to ensure that a text representation is in fact programmatically determinable when appropriate (i.e. its presented to a user).
I suggest we make the definition of text:
Sequence of encoded characters, where the sequence is expressing something in human language. An encoded character means a character from a given character set associated with another representation, such as a natural number, in order to facilitate storage and transmission by computers and telecommunication networks
And modify 3-U (point f) as follows:
text content encoding, text attributes, and the boundary of text presented to the user in written form.
For 1-G we need to say "written form" rather than "text":
"There must be at least one mode where all information that is required for product use and is provided in written form is readable by people with 20/20..."
And for 4-A:
"Functional equivalence requires a synchronized written form displayed on-screen..."
We could also then use "written form" for the very klunky "text or images of text"
Sean Hayes
Media Acessibility Strategist
Accessibility Business Unit
Microsoft
Office: +44 118 909 5867,
Mobile: +44 7875 091385
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg Vanderheiden
Sent: 15 March 2008 21:51
To: 'TEITAC Committee'
Subject: Re: [teitac-committee] Definition Consensus Decision: Text
I think we should separate the "does accessible via AT mean real AT" issue completely out of this and all our other discussions. There is clearly a difference of opinion on this one point (and I think I've mapped 4 different views).
So lets just talk about those things that we think should be "programmatically determinable" and agree that that doesn't mean that some obscure software can access it but that programmatically determinable means "accessible by AT and access features in software" or some such. Then, in another section we can talk about the 4? views of what "accessible by AT and access features in software" means.
Then we can get back to reaching consensus on those things we all agree on. Like the fact that when we say "non-text" we mean things that are not "text" and that means is not "programmatically determinable". We don't want text that is represented and transmitted as a bitmap to be called text - be cause we want to call it (and do call it) non-text.
So, if we get the "which AT (existing, not yet existing, might exist, did once exist, is in use in gov, etc.)" question off the table and into that special discussion section somewhere I do think we can make progress on this.
On the text question - I do believe we can agree that text as we use it in the standard, must be programmatically determinable. AT must be able to get at it. If we have a couple notes or something that call images of text, "text" then we can easily fix those notes. It will be a lot easier than going back and putting 'programmatically determinable text' in all the places we use text to mean that in the doc. (although that is the other option).
Other people's thoughts?
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
If Attachment is a mail.dat try http://www.kopf.com.br/winmail/
- Next message in Thread: Gregg Vanderheiden: "Re: Definition Consensus Decision: Text"
- Previous message in Thread: Gregg Vanderheiden: "Re: Definition Consensus Decision: Text"