Thread Subject: Re: Postpone the Real-time text discussion

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: Peter Korn
Date: Mon, Aug 13 2007 12:15 AM

Hi Gregg,

For #1 below ("A proposal from Peter on his alternate approach"), I
don't have a "formal proposal" to hand.

> In prep for the next discussion on Real-time text we were supposed to
have
>
> 1) A proposal from Peter on his alternate approach
> 2) A list of needs/requirements from consumers
> 3) The combination proposals of D & E and also B& C if possible.
>
> #3 is completed and can be found from a link off of the EWG pages
for this section at
> http://teitac.org/wiki/EWG:_Draft_July_18:_Section_5_Comments
>
>
> Gregg

My thoughts on this come from the draft provisions requiring support for
RTT (Real-Time-Text) everywhere that we current have audio
communications on the desktop (which nearly by definition includes
video), and everywhere where we have "chat" communications on the
desktop. I do not come at this from a Telecom background, and have not
thought through whether or how this would impact traditional
telecommunications.

The idea is that, from a user point of view, the desktop experience for
RTT is very similar to the experience of following hyperlinks.

Today on most graphical desktops, when a URL appears in your e-mail
(Thunderbird, Evolution, Outlook, Eudora, etc.), it appears underlined
and in blue, ready to be clicked on. Similarly when a URL appears in
your office suite (MS-Office, StarOffice, OpenOffice.org), in your PDF
viewer (Adobe Reader), etc. Whenever we see these "enabled hyperlinks",
in a wide variety of different programs used for displaying text, we
know we can click on them to invoke the hyperlink. And when we do,
these various applications will all launch the "desktop web browser
application" - typically Internet Explorer or Firefox. What these
applications don't do is attempt to display the web page from within
their own application (e.g. showing the web page there inside the
OpenOffice.org window, or the Adobe Reader window) - they invoke the web
browsing "helper application".

In much the same way, I think we can address the requirement for RTT on
the desktop. Rather than requiring that every audio/video/chat
application itself implement a RTT option (and every audio/video/chat
prototol support RTT directly, and every audio/video/chat server support
RTT), instead these applications must simply invoke a desktop RTT
"helper application" that handles the RTT communication, which could
happen in parallel with the audio/video/chat conversation.

If we address the RTT support in this fashion, it greatly reduces the
expense on industry because it doesn't require that every
audio/video/chat server support RTT directly. It doesn't require that
the existing network protocols used for audio/video/chat be extended to
support RTT (via RFC 4103 or any other specific protocol mechanism). It
does require a few, fairly small things:
1. that the desktop define a "RTT application" that handles RTT
protocols, in the same way as the desktop defines what "the default web
browser" is (and what application should be invoked to read .gif files,
.jpg files, etc.).
2. that every audio/video/chat application that conforms to the draft
refreshed 508 standard be able to invoke the desktop RTT application
3. that the vcard information for users of every audio/video/chat
application include a field for the users' RTT address (and that we
define such a standard addressing scheme)

I've talked with the Sun engineers involved in the video and chat
applications we include in Solaris (and that we get from the open source
GNOME community), and they have confirmed my suspicion - implementation
of what I am proposing is a small number of engineer-months;
implementing RTT into the applications directly (and the protocols and
the servers) is multiple years of effort.

Another attraction from going the "helper application" route is that it
doesn't constrain innovation in communication protocols and mechanisms.
We are seeing a lot of innovation in computer-based communication
mechanisms - things like Skype for the desktop that didn't exist just a
few years ago (and in Skype's case, a technology that uses peer-to-peer
networking in order to be network utilization efficient and avoid the
need for a large server infrastructure). I am personally very reluctant
to insist that all future communications protocols explicitly include an
implementation of RFC 4103 or any specific protocol. But I am quite
comfortable saying that we should have a RTT helper application that
handles such things, and that our audio/video/chat software should know
enough to invoke it when the users requests it.


What this means in end-user terms is that when they are engaging in a
non-RTT conversation with someone, and want to shift to or supplement
with RTT, that they use some keyboard or mouse gesture (which may differ
from one audio/video/chat application to another) to indicate that they
want to have a RTT conversation with the person they are communication
with, and their RTT application initiates a connection to the remote
users' system, doing so in another widow with another application (and
via a different network protocol). As the RTT conversation is with a
different application in a different window, the user may need to
arrange/re-arrange two different windows in order to have them not
overlap on their screen [something that they might have had to do even
if RTT was "integrated" into their audio/video/chat application, as
multi-windows for this might be an implementation detail - certainly the
draft provision makes no mention of this]. Also, as the RTT
conversation is potentially using a different network protocol (and
different servers, gateways, etc.), the performance characteristics may
be different from the audio/video/chat conversation. E.g. a Skype user
whose audio conversation is happening via a distributed peer-to-peer
network might invoke a point-to-point RTT conversation (in which case,
the RTT might in fact be faster!). Likewise an IRC chat conversation
between two users in California might be going through a server in
Sweden; the RTT conversation they invoke might again be point-to-point
(or perhaps it goes through a different gateway in some other location
than Sweden). This has implications on the relative performance
guarantees one can make. Frankly because text consumes so much less
bandwidth than audio or video, I believe in most cases an overall
bandwidth deficit for RTT won't in practice be an issue. This is
something we would need to model in practice, with prototype
implementations in a variety of situations, to verify.


In our con-call last week, if memory serves Gregg Vanderheiden suggested
that the existing draft provisions would accommodate the "helper
application" approach I have sketched out. Perhaps so, but I am not so
certain of that. I find the language too ambiguous to feel comfortable
telling my engineers that such an implementation would comply under the
draft language. For example, if a user I am communicating with doesn't
choose to have an RTT vcard field (e.g. they expressly decline to engage
in RTT conversations), would the helper application implementation then
fail to meet 508 (how can my implementation require an end user expose
certain information)? Likewise, if the desktop selection of the RTT
helper application were to get altered/corrupted, would that then make
my chat application non-compliant? And, as I noted in my original
concerns about the Section 5 draft language on RTT requirements, when
the audio/video/chat software is part of a larger operating system
release (which contains a RTT helper application), but I am having to
provide a 508 assessment of *just* the audio/video/chat software alone,
how can I state whether that software complies with the RTT provisions?


What I would like to do is:
1. Verify that the implementation I have sketched out does or does not
meet the desires of the community seeking RTT support
2. If this does meet those desires, review and update the language to
make this unambiguously clear
3. If this does meet those desires, figure out how this impacts the
more traditional (e.g. non-desktop) telecommunications world, especially
when it comes to interoperability


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

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