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.
>