More scripting thoughts (was RE: Accessible road maps)

> I am also confused by the idea that submitting a form to a server and
> having it sent back to the user due to an error/omission on the form is
> a better, faster, or more accessible approach.  There is a significant
> amount of discussion about load times, this approach requires doubling
> the load time.  Triggering an alert dialog box on the client side is not
> unique to browser applications, yet when this technique is employed via
> a browser objections are raised.  Please help me to understand the
> difference between a word processing program and browser
> rendering an alert.
>

Kurt,
What happens if the user agent does not render the alert?  What if it is
incapable of doing so, even if the rendering agent is otherwise standards
compliant?  This is a judgment call, and has an answer that can never be
codified, as  the real answer is "it depends..."

The danger is assuming that there is a base level user agent which you can
state with absolute certainty that all of your clients are using.  In an
Intranet setting, this may in fact be possible, but once you release to the
world, all bets are off.  As a conscientious developer, why would I put my
total reliance on an unknown?  Don't get me wrong, I like client side
scripting, I use it occasionally, but I am also aware of the potential
issues of accessibility I may be introducing and develop accordingly.  I
also have stated, on more than one occasion, that relying on client side
scripting for *Mission Critical* functionality is foolhardy, and even
potentially crippling to a site.  If it is your personal blog or vanity
site, no problems, have at it.  But if you (I) am being paid by a client to
produce a working web site, why would I take a chance that it doesn't work -
no matter how remote that chance is?

As for your question regarding comparing a word processor vs. a web
browser - word processors generally are installed on tower or laptop
computers, whereas web browsers now are being installed in car dashboards,
cell phones, refrigerators, you name it (see: http://www.icesoft.com/), not
to mention accessing web content via alternative browsers such as WebTV.
None of this is directly related to users with disabilities per se, but
rather only alternative user agents.

It reaches a point where either you accept the randomness of the user agent
stew and develop accordingly, or you forge on knowing that you are
potentially causing access issues, but are willing to take the risk.  The
WCAG currently cautions on the conservative side, to be safe, and I for one
agree with them.  If you believe that it's a non-issue, if you cannot accept
the arguments being presented which attempt to explain why some users would
prefer to not have to rely on client side scripting, which have attempted to
illustrate the potential dangers here, then ultimately, your mind has
already been made up - you have reached the point of dogma. But I believe
that there are currently enough of us in the accessibility community which
will continue to speak out against the use of client side scripting in
Mission Critical applications that it will probably never be an accepted
component of "universal web accessibility".  If you are mandated to be
compliant to WCAG now (or in the future) then you will need to accept this
point regardless of your personal point of view.

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 Wednesday, 2 June 2004 16:56:08 UTC