Re: Automatic Detection of Screen Readers and Other AssistiveTechnology

This is a direction that scares me for more than the reasons stated here.  A
screen reader is not an oral browser in the sense that pwweb speak was and
perhaps IBM HomePage reader is.  A screen reader is and should be designed
to lend audio navigability to the platform for which it is designed.  It
seems to me that we are looking at a form of discrimination not unlike the
"text only" version of a site.  This is further complicated by the fact that
it is often the case that screen readers are used on shared systems and
often, the screen reader is running for the benefit of one of the people
sharing the system.  We have already seen problems with screen readers on
shared systems using internet explorer and  jaws for instance where a person
using a screen reader wants to present something on the web to a non screen
reading audience or to seek assistance from one who does not use a screen
reader or to assist someone who does not use a screen reader because of the
way the pages are redrawn by this combination.  The aim of the "web content
accessability guidelines v1.0" is to facilitate the use of web sites by the
broadest audience possible without the need for special server tweeks or
text only pages or specially designed pages.  Also, if you start down the
road of special delivery based on the fact that there is a screen reader
present, you will then need to find out which screen reaer is available and
on what platform because each is unique and what works for one screen reader
may/will not work for another.  Screen readers also vary from browser to
browser due to enherent differences in the way they interact with the
browser.  You might detect the presense of msaa on windows for instance and
while you are at it, what version of msaa and ie are being used, but this is
a slippery slope due to the fact that the curve gets pretty steep as to what
screen reader is ultimately being used and what version of the screen reader
because again, we have differences in the way they interact in the
environment.

Any move toward providing "screen reader facilitation" only furthers the
accessability devide at a time when it should be narrowing due to dwindling
resolves and resources.  One last point here is that technology is a moving
target and there are platforms now and in the future that will be accessing
the web and they will constantly change.  The screen reader of tomorrow if
forced to take what is handed to it automatically due to the fact that the
presence of a screen reader has been detected may not render what has been
sent in an acceptable way.  Also, There are many people who need content the
way it is delivered to everyone else for a myriad of reasons, they might
want to print the page, they might want to audit the page for standards
compliance etc.  If you do anything along these lines, the best solution all
things having been considered is to offer the user a choice.  This gets at
the issue of bandwidth and many others.  When offering the choice though, it
is important that the resultant interactability be as equal as possible to
the other available choices making it almost moot to provide choices in the
first place.

Lastly, When I explain to developpers that some users who are offered a
choice of a high bandwidth site versus a text only site can have issues with
either and that a low frills or lite site might be a better choice, they
often opt for developping a site that needs no alternate.

Received on Thursday, 12 June 2003 07:32:15 UTC