- From: David Poehlman <poehlman1@comcast.net>
- Date: Thu, 12 Jun 2003 07:32:06 -0400
- To: w3c-wai-ig@w3.org
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