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)

Received on Tuesday, 1 June 2004 23:44:40 UTC