- From: Fitzgerald, Jimmie <Jimmie.Fitzgerald@jbosc.ksc.nasa.gov>
- Date: Tue, 23 Jan 2001 12:58:19 -0500
- To: "'w3c-wai-ig@w3.org'" <w3c-wai-ig@w3.org>
Let me begin by stating that I am all for accessibility. At least as it is defined by the 508. I do not agree with all of the priority 1 guidelines from the WAI however. And, by the way, they ARE guidelines. Not rules. The 508 standard is a LAW so we must follow that but the WAI is not a law so does not required implementation. Some things in the WAI are covered by the 508 while other items are slightly modified. In general, there are people who have various disabilities and these people should be access our web sites. As I've said, I'm all for this. Where we reach a dilemma is when we desire to build a nich 'high-tech' web site with eye candy galore and then realize that to make it 508 compliant is either impossible or cost prohibitive. One solution could be to have user agents identify any accessibility software/hardware to the host server upon a file request. The server could then include particular style sheets or 'filter' the requested document through an in-process package to make the requested page accessible for the technology that is being used by the requestor. Scenario number 1: A deaf person requests your web page which contains audio (not related to content) and video which is part of the content. The in-process application would take note of the fact that the person is using assitive technology for the deaf (whatever that may be) and modifies the requested page to (a) remove the non-content audio, and (b) provide a link to the transcript of the video or to a SMIL compliant video. A non-disable person would get the site without modifications. Scenario number 2: A blind person requests a web page from your server and it contains animated files and movies and other such things they will be unable to enjoy. The in-process application would again identify the fact that they are using assistive technology (screen reader or braille) and modify the requested page to remove the video and replace it with a text transcript; add accesskey attributes to links if not already present; and any other things which would minmize the hassle that the visually impaired must experience when visiting most web sites. I've only used IBM's Home Page Reader to see what it was like and even a simple page was hard to navigate and easy to lose myself in. Complex pages would only be that much worse. If a blind person could access any web site and have it configured to the minimum he/she needs to access the data (that's the important part after all), then this kind of tool would be a great boon to them all. They don't really need a graphic sent to the page, just a description. Maybe the tool could have configuration settings to allow the user to enable certain things such as graphics to always be sent. Somewhere, there is a blind person who regularly saves images and forwards them to friends based on the alt text sounding cool. Can't preclude that with this tool but it could be an optional event. With the in-process application, we could deliver entirely different pages to the disable/impaired people without having to 'code down' as I've seen some mention on this list. This application would not take a poorly designed site and 'make it right' but it could modify it for the person requesting it so that it worked well on their assistive technology. This application could also be extended to browser types so we can automatically detect if the browser is capable of style or not. If not, the in-process application could modify the document on-the-fly with the associated style sheet by adding the style content into the html. Positioning would be hard or impossible to figure out with the application but there can be a code to preclude such processing too if need be. We might also be able to determine is styles or scripting is simply disabled in the browser and either prompt the user or reconfigure the page to accomodate their preferences. It is their browser after all and if they want to disable such things, they can. Now, admittedly, this is an imperfect solution. Please refrain from any nitpicking of it to death. It is presented as a theoretical solution. As of today, I do not believe that the user agents 'send' any kind of identifying data with each file request. Doesn't mean they won't in the future. It is just an idea. A prediction I'll make is that any company producing this kind of in-process application would flat make tons of money. And, if you need someone to be the developmental lead on it...well, you know how to reach me. :) Jim Fitzgerald FDC Logicon - Space Gateway Support, Kennedy Space Center
Received on Tuesday, 23 January 2001 13:01:23 UTC