Re: Scripting (was RE: Accessible road maps)

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