There are a number of reasons not to go with text only.  One is that
depending on the individual, pdf may not work and they may still have vision
and need cognaive cues.  Another is that with todays at, it is easy to jump
through something that is well formatted with headings, links and yes,
tables.  Another is that the way text is displayed on the web is often
unpredictable and even with a modern scren reader, you may find that some
information is skipped, scrambled or run together.  An exception is
downloadable text rather than text viewed in the browser if it is marked
with searchable features and annotated as such.

----- Original Message -----
From: "Martin McCormick" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Tuesday, December 30, 2003 8:36 AM
Subject: Re: legal accessability of PDF documents


        As a lynx user, I certainly like a good hypertext page with
links that actually work, but I don't see anything wrong with plain
text if there are no links to select.  I always want to see the
simplest solution that works applied to a given problem because all
involved are more likely to know that it works and doesn't contain
hidden traps that will catch users of the service later.

        For about ten or fifteen years, we have seen access technology
get more and more complex and still, here's a guy that can't read the
train schedule or there's a girl that can't read the television
listings.  These should be no brainers, but the arms race just goes on
and on.

        The one good thing I have noticed to a small degree is that
newer web servers that use XML and who adjust their output to fit the
client's needs appear to be working better under lynx than did the
javascript monsters of two or three years ago.

        My employer is switching from Lotus Notes and Domino to a
Microsoft Exchange environment.  Our new web sites appear to work
somewhat better under lynx than do the Domino-composed web sites we
have had for several years.

        All is not perfect, but any improvement is welcome.  I think
client-side processing such as what happens with javascript is doomed
to fail while server-side evaluation of what the client needs has a
much greater probability of producing something useful because the
whole process isn't built upon the assumption that the client is set
up this way or that.

        I work for our Network Operations group and we have dismissed
several schemes for handling wireless mobility around campus because
they require the client to have a specific configuration.  The scheme
we most likely will go with for now requires nothing other than a
working wireless computer for the client with enough web access to
register his or her system once.  Simple is beautiful.

Martin McCormick

David Poehlman writes:
>I hope they are required to provide something better than text.  Text is
>usually stripped of formatting and is difficult to do any real navigation
>of.

-------------------------------------------------------------
 See EASI Special October Bonus offer at http://easi.cc/clinic.htm
EASI November courses are:
Barrier-free E-learning, Accessible Internet Multimedia and Business
Benefits of Accessible IT Design:
http://easi.cc/workshop.htm
EASI Home Page http://www.rit.edu/~easi

>>> Error in line 8 of EASI.MAILTPL: unknown formatting command <<<
 -> ............. <-

-------------------------------------------------------------
 See EASI Special October Bonus offer at http://easi.cc/clinic.htm
EASI November courses are:
Barrier-free E-learning, Accessible Internet Multimedia and Business Benefits of Accessible IT Design:
http://easi.cc/workshop.htm
EASI Home Page http://www.rit.edu/~easi

>>> Error in line 8 of EASI.MAILTPL: unknown formatting command <<<
 -> ............. <-