EASI Archives

Equal Access to Software & Information: (distribution list)

EASI@LISTSERV.ICORS.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
David Poehlman <[log in to unmask]>
Reply To:
* EASI: Equal Access to Software & Information
Date:
Tue, 17 Jul 2001 11:04:30 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (86 lines)
no, it is not an audio stream at all.  the speech is synthesized from
the text on the fly and yes, it does have forms capability.  for more
info on this, see:
http://www.inter-next.net/

----- Original Message -----
From: "Paul Chapin" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Tuesday, July 17, 2001 10:34 AM
Subject: Re: Web Access; When the Rubber Meets the Road


That actually surprises me although it probably shouldn't when you stop
to
think about it.  You're just going to get the contents read to you
whether
using a computer or the cell phone so there isn't much difference unless
you
entering data.  In fact, even as a sighted user I would rather have the
contents of a web page read to me rather than try to read it off of a
mini
screen.

It raises an interesting question of whether we've been going about this
backwards.  The strategy has been to put the intelligence at the user's
end.
This creates problems with a proliferation of configurations and, in the
case of cell phones and the like, some question about whether they can
really become readers.  Wouldn't it make more sense to make this a
server
function.  A slight modification to the request for a web page could cue
the
server to produce what would amount to streaming audio.

There are some really nice advantages to this approach.  The first is
that
the issue of cost to the user goes away as the cost would be covered by
the
server site.  Given that the number of different types of servers out
there
is, in practical terms, fairly limited but the number of different
individual servers is high, the per server cost would be low and would
disappear into the base cost of the server.

The second, an possible most important advantage, is that designers
could
readily find out how their pages worked without having to buy and
install
expensive screen reading software.  This is especially valuable for
academic
and personal sites where you have a lot of developers most of whom are
working on a limited number of pages.

And to get back to where this all started, it would simplify the issue
of
standards.  The user wouldn't care how I build my pages.  That's now
strictly a designer issue.  If my server can deal with JavaScript, I can
use
it.  If my server can't deal, I find another solution.  I now have a
single
set of standards, dictated by my server, to match.

Unfortunately, there is still a problem.  While this would work great
for
output, dealing with input could be an issue.  You can't fill in the
blank
in an audio stream.  This would probably require a new way of
interacting
with the server; one that would require that the server remember where
you
"were" on the page and respond appropriately.  As a former programmer
this
looks like it could be tricky, but certainly not impossible.

> -----Original Message-----
> From: David Poehlman [mailto:[log in to unmask]]
> Sent: Tuesday, July 17, 2001 9:59 AM
> To: [log in to unmask]
> Subject: Re: Web Access; When the Rubber Meets the Road
>
>
> Paul, Just so you know, reading the manual by phone is exactly what I
> want to do.  I won't be doing it on a tiny screen though, I will be
> listening to it.
>

ATOM RSS1 RSS2