- From: david poehlman <poehlman1@comcast.net>
- Date: Wed, 2 Jun 2004 09:26:22 -0400
- To: <Kurt_Mattes@bankone.com>, <foliot@wats.ca>, <kerstin.goldsmith@oracle.com>, <sdale@stevendale.com>
- Cc: <pjenkins@us.ibm.com>, <david@djwhome.demon.co.uk>, <w3c-wai-ig@w3.org>
what if I need it at 2 in the morning or from across the pond etc? The argument that you can get it some other way has never washed. Need is not the operative word. What we *need* to do is to make what is available accessible in the medium in which it is available. Electronic services in oone form or another are here to stay and to tell someone that they can get something that everyone or almost everyone else can get in electronic form in some other way is discrimination and makes for a lop sided playing field. No gheto please. ----- Original Message ----- From: <Kurt_Mattes@bankone.com> To: <foliot@wats.ca>; <kerstin.goldsmith@oracle.com>; <sdale@stevendale.com> Cc: <pjenkins@us.ibm.com>; <david@djwhome.demon.co.uk>; <w3c-wai-ig@w3.org> Sent: Wednesday, June 02, 2004 7:53 AM Subject: RE: Scripting (was RE: Accessible road maps) More on the WANT vs NEED debate. Makes me wonder...do we NEED the Internet or WANT it? How did anyone ever survive without it or cell phones or PDA's? I manage billions of lines of code, many of which use client-side scripting that works fine with Window-Eyes and JAWS. All of the content represented by this code is available via several other means - by phone, in print[including brail and multiple languages], or in person. No one NEEDS to get this information via the Internet. Browsers that do not support client-side scripts need to be enhanced. Users that disable scripts in their browser make a concious decision to do so and inhibit themselves. Interesting side note on this one. I have read over and over on this list how users are unable to make simple configuration changes to their applications yet when it comes to disabiling scripts, seems they have no problem! So which is it - can we count on users to understand how to use the tools they have or not? Prior to anyone rushing out to look at any of the sites I oversee user interface coding for, I will state they are not fully accessible - yet. Despite the thoughts of many on this list, rewriting all of this code for accessibility is not an easy task. The first battles, getting management to accept the idea, are difficult. But even more difficult is attempting to understand vague and ambigous guidelines. A simple example... On the W3C site - http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html is the following statement: "Note. The following checkpoints apply until user agents (including assistive technologies) address these issues. These checkpoints are classified as "interim", meaning that the Web Content Guidelines Working Group considers them to be valid and necessary to Web accessibility as of the publication of this document. However, the Working Group does not expect these checkpoints to be necessary in the future, once Web technologies have incorporated anticipated features or capabilities." Which clearly seems to put the NEED to make changes on the user agents. It is only in the "interim" that web site designers/developers must accomidate the deficiencies in user agents. This statement is 5+ years old, yet the pressure seems to persist on design/development. Where is the pressure to have the user agents change? Additionally, on this page http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#until-user-agents is the statement: "In most of the checkpoints, content developers are asked to ensure the accessibility of their pages and sites. However, there are accessibility needs that would be more appropriately met by user agents (including assistive technologies). As of the publication of this document, not all user agents or assistive technologies provide the accessibility control users require (e.g., some user agents may not allow users to turn off blinking content, or some screen readers may not handle tables well). Checkpoints that contain the phrase "until user agents ..." require content developers to provide additional support for accessibility until most user agents readily available to their audience include the necessary accessibility features." Why do I see comments about the need to accomidate users of ALL browsers and AT applications when this clealy states "...until most user agents...". Lynx seems to be one of the more popular browsers sited when something like scripting is raised. Is it not the responsibility of the Lynx developers to make changes? Kurt Mattes Application Development Analyst - Lead Developer Kurt_Mattes@BankOne.com -----Original Message----- From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org]On Behalf Of John Foliot - WATS.ca Sent: Tuesday, June 01, 2004 11:30 PM To: Kerstin Goldsmith; sdale@stevendale.com Cc: pjenkins@us.ibm.com; david@djwhome.demon.co.uk; w3c-wai-ig@w3.org Subject: Scripting (was RE: Accessible road maps) > OK, just a quick response. We are not talking about amateurish uses of scripting > here - these are exceptionally talented web applications developers who are > using scripting in very creative ways. It's not our place to tell them HOW > to do their job - it's only our job to tell them HOW TO DO IT ACCESSIBLY. Kerstin - is this server-side scripting or client side scripting you're talking about? I too have seen wonderful, server-side scripting examples which improve and support accessible design and delivery. Scripting, per se, is not the issue. Where some of us become concerned is when sites/applications depend on Client Side scripting to provide key functionality - something I see all too often, even from talented script jockeys. Common problem areas are form validation (easy to spoof and "break"), dynamic page navigation or content (using document.write), removal of common navigational functions and "chrome" from the browser window (often, alas, a pop-up window), trickery to lock the user into a site, etc. Assuming that the end user has a client application which supports client side scripting is akin to assuming that *all* birds can fly... it just ain't a bankable bet. Our job may not be to tell them how to do their job, but it may just be to tell them *HOW NOT* to do their job. > These guys are using scripting to make the lives of people with and without > disabilities easier. One example is partial-page refresh, which is done with > scripting and forms submittal. Blind users, at least, who have tested it agree > that our partial-page refresh actually makes their lives easier - they > don't lose focus, and their screen readers work well with it. Other customers, > without disabilities, agree that partial page refresh rocks. Hmmm... I wonder how users with cognitive disabilities (who may take longer to read and comprehend your content than the refresh allows), or those with browsers (Lynx for example) which do not support client side scripting feel about your partial refresh. Or how about those users in an environment where security concerns (paranoia?) has even the ubiquitous Internet Explorer's JavaScript disabled. If the partial refresh is a "bonus" or user enhancement which does not remove general access, then perhaps fine. But if the script delivers key functionality, or if the "page" does not work with the client side scripting disabled, then you (we?) have a problem. > Again, I think your focus is way off here. We should not be in the business of > telling people what to use, but to tell them how to use all their choices > accessibly. From there, they will make the right choice according to the myriad > of other requirements that come into play for their products/sites in addition > to accessibility. I must disagree. Sometimes we need to tell those that do not know better not to do something - period. Hopefully, as we tell them "NO", we also explain and illustrate why (or why not) - a key point that Steve has commented on. But given varied experience, skills levels, and understanding of the issues, we cannot expect every developer to be fully understanding of all of the accessibility issues which make using client side scripting dangerous. At that point, sometimes it is simpler and quicker to just say don't, either through mandated standards or internal policy decisions. Is that fair? Probably not, but neither is perpetuating the myth that it's OK to use client side scripting for mission critical functionality. With the sophistication of ColdFusion, ASP, PHP, Perl/CGI, etc. why developers would rely on lightweight solutions such as JavaScript to provide key functionality to me defies logic. You stated, "We should not be in the business of telling people what to use...". I am so glad those are your words. Using exactly the same argument, we cannot "expect" or tell end users that they *must* use a user agent which supports client side scripting... which is perhaps the best argument against doing so I can think of. Kersten, you said earlier in this thread, "It's our job to realistically look at all technologies out there that people WILL use, and come up with ways for them to use them accessibly." But what happens if they *can't* be made accessible? Steven's initial question, "why do we NEED client side scripting" still has not been answered. Once that has been satisfactorily answered, then we can look to ensure that it is done accessibly. But until that time, the move to discourage client side scripting has the advantage, and my vote. JF -- John Foliot foliot@wats.ca Web Accessibility Specialist / Co-founder of WATS.ca Web Accessibility Testing and Services http://www.wats.ca 1.866.932.4878 (North America) ********************************************************************** This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you **********************************************************************
Received on Wednesday, 2 June 2004 09:27:11 UTC