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: Owen Rachal
Date: Fri, Jun 22 2007 9:25 AM

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: = 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