Thread Subject: Re: real-time 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: jagbell
Date: Sat, Jun 23 2007 4:00 PM

I agree with you. This has been an on-going issue with the goal of
this committee. :)

Janice



On Jun 22, 2007, at 11:22 AM, Owen Rachal wrote:

> I realize the ideal situation is one where industry in general
> steps up and offers these kinds of things, but what about the AT
> industry? Should we limit our requirements to what Telecom vendors
> and the like find agreeable, when 3rd parties offer products that
> bridge these gaps? It seems like we should concentrate less on what
> industry likes and more on what users can benefit from... I doubt
> many deaf users would prefer to not even have the option of
> character-by-character conversation when they IM on their mobile
> devices (which is the current situation)... As a hearing user, I
> don't like not even having the option... The fact that no one has
> stepped up and made their IM client with any flexibility does not
> mean we wouldn't benefit from having it. And this is the kind of
> thing 3rd parties can offer to industry - products that make them
> compliant when they aren't and satisfy unhappy users.
>
> Owen Rachal
> Tenacity, Inc.
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto:teitac-telecom-
> = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
> Sent: Friday, June 22, 2007 8:37 AM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: Re: [teitac-telecom] real-time text
>
> Hi Gunnar,
>
> Thanks again for your contribution here.
>
> Please understand that my position is not based on any
> technological issues. I only note the following,
> which you may also agree with:
>
> 1. Deaf users have adopted line-by-line text conversation
> and SMS with great enthusiasm because the options open
> to them are mobile, easy to use, and accepted by many
> non-deaf people. This last point allows for direct
> communication rather than relay.
>
> 2. It is likely that if we require character-by-character
> conversation in 255/508 that vendors will either not
> provide it or support it as well as they do line-by-line,
> and non-deaf users may not adopt it either. This would
> perpetuate the communication ghetto we had with wireline
> TTY.
>
> ******
> Jim Tobias
> Inclusive Technologies
> = EMAIL ADDRESS REMOVED =
> +1 732.441.0831 voice/tty
> skype jimtobias
> +1 908.907.2387 mobile
>
>> -----Original Message-----
>> From: Gunnar Hellström [mailto: = EMAIL ADDRESS REMOVED = ]
>> Sent: Thursday, June 21, 2007 10:23 AM
>> To: 'TEITAC Telecommunications Subcommittee'
>> Subject: Re: [teitac-telecom] real-time text
>>
>> The goal is to get a good conversational flow without
>> stressfull waiting.
>> Stressful and confusion-creating waitng appears if you do not
>> send regularly with a good conversational flow.
>>
>> Regularly means originally not more than a half second
>> between transmissions, but in our discussion here it is
>> stretched to one second, that takes us into the border area
>> of risk for conversational collissions.
>>
>> Line-by-line is not good conversational flow, even if the
>> line is transmitted rapidly once sent.
>> Have you not noticed how you get a desire to shorten off
>> sentences in IM, so that you keep the other party informed on
>> your thoughts. That forces change in behaviour for you that
>> is not needed if text was sent regularly without any specific
>> action from you.
>>
>> Gunnar
>> -------------------------------------------------------------------
>> Gunnar Hellström
>> Omnitor
>> = EMAIL ADDRESS REMOVED =
>> Tel: +46708204288
>> www.omnitor.se
>>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
>> Jim Tobias
>> Sent: Thursday, June 21, 2007 3:40 PM
>> To: 'TEITAC Telecommunications Subcommittee'
>> Subject: Re: [teitac-telecom] real-time text
>>
>> The problem is using the phrase "real-time text" to mean only
>> character by character. Line-by-line is also real-time, and
>> both are distinct from store and forward technologies like
>> email and SMS. That's the important
>> distinction: whether the end-to-end system is making a good
>> faith effort to send text as it is received, or whether the
>> system assumes that the text will remain in a server until
>> retrieved somehow by the recipient. The latter is not a
>> conversation. The goal is to require a capability for text
>> conversation, not require how many characters are processed at a
>> time.
>>
>> ******
>> Jim Tobias
>> Inclusive Technologies
>> = EMAIL ADDRESS REMOVED =
>> +1 732.441.0831 voice/tty
>> skype jimtobias
>> +1 908.907.2387 mobile
>>
>>> -----Original Message-----
>>> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
>>> Sent: Wednesday, June 20, 2007 2:39 PM
>>> To: 'TEITAC Telecommunications Subcommittee'
>>> Subject: Re: [teitac-telecom] real-time text
>>>
>>> What you would receive is exactly the same as what you
>> receive on TTYs
>>> today.
>>>
>>> All corrections are in place. You can see people backspace
>>> - that is true.
>>> But only if person sending wants to. That person has the option of
>>> holding text back if they wish. It wouldn't be real-time text in
>>> that case. but
>>> the requirement is only that devices be capable of
>> real-time text. it
>>> does not require people to use real-time text.
>>>
>>> As Jim pointed out - they may wish to operate in IM mode,
>> in message
>>> mode.
>>> Or send email. Just as all of us with real-time voice also
>>> use all of
>>> these other modes sometimes and want real-time
>> communication at other
>>> times.
>>>
>>>
>>>
>>> Gregg
>>> -- ------------------------------
>>> Gregg C Vanderheiden Ph.D.
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: = EMAIL ADDRESS REMOVED =
>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>>> Of Tom Brett
>>>> Sent: Wednesday, June 20, 2007 1:08 PM
>>>> To: 'TEITAC Telecommunications Subcommittee'
>>>> Subject: Re: [teitac-telecom] real-time text
>>>>
>>>> The t140 includes this option but I what I receive is
>>>>
>>>> Ga ood morning, I s am wrting writing you....
>>>>
>>>>
>>>>
>>>> Tom Brett
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: = EMAIL ADDRESS REMOVED =
>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>> Of Gregg
>>>> Vanderheiden
>>>> Sent: Wednesday, June 20, 2007 1:27 PM
>>>> To: 'TEITAC Telecommunications Subcommittee'
>>>> Subject: Re: [teitac-telecom] real-time text
>>>>
>>>> Hi Tom
>>>>
>>>> T140 includes backspaces so you still get a corrected
>>> message at the
>>>> far end.
>>>>
>>>> And you can always have an option to hold back text if you
>>>> wish. That is,
>>>> a system with real-time text could ALSO have a mode that
>>> was message
>>>> like.
>>>>
>>>>
>>>> Gregg
>>>> -- ------------------------------
>>>> Gregg C Vanderheiden Ph.D.
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: = EMAIL ADDRESS REMOVED =
>>>> [mailto:teitac-telecom-
>>>>> = EMAIL ADDRESS REMOVED = ] On Behalf Of Tom Brett
>>>>> Sent: Wednesday, June 20, 2007 7:38 AM
>>>>> To: 'TEITAC Telecommunications Subcommittee'
>>>>> Subject: Re: [teitac-telecom] real-time text
>>>>>
>>>>>>> 1. Although the characters are to be transmitted
>>>> quickly, there is
>>>>>>> no
>>>>> reference to how they are handled once they're transmitted.
>>>> That is,
>>>>> a server in the middle somewhere could add significant
>> delays by
>>>>> design or congestion. If we want to make text conversation
>>>> real-time,
>>>>> we have to make it clear what the permissible
>> end-to-end delay is.
>>>>>
>>>>>> From my understanding of the real time text definition I
>>>> thought that
>>>>>> it
>>>>> applied only to the device that was doing the output.
>>>> There can be
>>>>> significant delay in the receipt of the characters
>> depending upon
>>>>> receiving device or traffic on the transmission lines. The
>>>> end to end
>>>>> delay is, I think, beyond the control of the subcommittee
>>>> because the
>>>>> transmission is either via the internet or telephone lines.
>>>>>
>>>>>>> 3. Most importantly, I don't understand why we would want
>>>> to exclude
>>>>>>> the
>>>>> huge mainstream advantages of chat and IM. I have not
>>>> heard anything
>>>>> from the many deaf users of these systems that the "Enter"
>>>> key imposes
>>>>> a conversational barrier. Moreover, it is unlikely that
>>> mainstream
>>>>> chat/IM program vendors will modify their programs to transmit
>>>>> character by character. This leaves deaf and other users
>>>> still in a
>>>>> communication ghetto, instead of being able to use the
>> same tools
>>>>> everyone else is
>>>> using.
>>>>>
>>>>> As a user of text communication tools that include
>>> chat/im I do not
>>>>> find this to be a barrier. In many respects I find this to be
>>>>> superior to character by character transmission....we all make
>>>>> typos...imagine receiving a character by character message:
>>>>>
>>>>> "Gaood xxx good mraning, I qaxxx am wriging you today..."
>>>>>
>>>>> This becomes very confusing. I find it better to receive a
>>>> complete
>>>>> message with fewer typos that I can then decipher easier.
>>>>>
>>>>> Tom Brett
>>>>>
>>>>> -----Original Message-----
>>>>> From: = EMAIL ADDRESS REMOVED =
>>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On
>> Behalf Of Jim
>>>>> Tobias
>>>>> Sent: Wednesday, June 20, 2007 8:21 AM
>>>>> To: 'TEITAC Telecommunications Subcommittee'
>>>>> Subject: [teitac-telecom] real-time text
>>>>>
>>>>> Hi All,
>>>>>
>>>>> As drafted on our call monday, the definition of
>>> real-time text is:
>>>>>
>>>>> "Communications that employ the transmission of text
>> wherein the
>>>>> characters are transmitted by a terminal w/in a maximum of
>>>> 1 sec. of
>>>>> character input."
>>>>>
>>>>> I think there are a few problems here:
>>>>>
>>>>> 1. Although the characters are to be transmitted quickly,
>>>> there is no
>>>>> reference to how they are handled once they're transmitted.
>>>> That is,
>>>>> a server in the middle somewhere could add significant
>> delays by
>>>>> design or congestion. If we want to make text conversation
>>>> real-time,
>>>>> we have to make it clear what the permissable
>> end-to-end delay is.
>>>>>
>>>>> 2. If the intention in this definition was to distinguish
>>> TTY-style
>>>>> (characters are transmitted as soon as they are keyed in)
>>>> from IM and
>>>> chat,
>>>>> where you type a bunch of characters and then press "Enter" to
>>>>> transmit, we should say so explicitly, somewhere.
>>>>>
>>>>> 3. Most importantly, I don't understand why we would want
>>>> to exclude
>>>>> the huge mainstream advantages of chat and IM. I have
>> not heard
>>>>> anything from the many deaf users of these systems that
>>> the "Enter"
>>>>> key imposes a conversational barrier. Moreover, it is
>>>> unlikely that
>>>>> mainstream chat/IM program vendors will modify their
>> programs to
>>>>> transmit character by character. This leaves deaf and
>>> other users
>>>>> still in a communication ghetto, instead of being able to
>>>> use the same
>>>>> tools everyone else is
>>>> using.
>>>>>
>>>>> ******
>>>>> Jim Tobias
>>>>> Inclusive Technologies
>>>>> = EMAIL ADDRESS REMOVED =
>>>>> +1 732.441.0831 voice/tty
>>>>> skype jimtobias
>>>>> +1 908.907.2387 mobile
>>>>>
>>>>>

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