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: Jim Tobias
Date: Thu, Jun 21 2007 7:45 AM

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