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: Tom Brett
Date: Wed, Jun 20 2007 12:10 PM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Gregg Vanderheiden: "Re: real-time text"
- Previous message in thread: Gregg Vanderheiden: "Re: real-time text"
- Messages sorted by: Author | Thread | Date
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
>
>
- Next message in Thread: Gregg Vanderheiden: "Re: real-time text"
- Previous message in Thread: Gregg Vanderheiden: "Re: real-time text"