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 6:40 AM
- 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: Jim Tobias: "real-time text"
- Messages sorted by: Author | Thread | Date
>> 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: Jim Tobias: "real-time text"