RE: Questions about WCAG 6.3

Joel,

I understand where you are coming from.

However, before I had even thought about accessibility, I found JavaScript
to be so flaky in its implementation between browsers and platforms that I
gave up on it and opted for a server side solution for form pre-processing.
(that may say more about my JS programming skills than anything!)

This has the nice side effect of being potentially far more accessible -
although the functionality is reduced over client side pre-processing.

Just my 2p's worth anyway.

- Paul

--
Paul Booth, Project Officer, DISinHE Office.
Disability and Information Systems in Higher Education
t: 01382 345050 f: 01382 345509 w: http://www.disinhe.ac.uk/



-----Original Message-----
From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org]On
Behalf Of Joel Sanda
Sent: Friday, March 24, 2000 21:44
To: W3C/WAI
Subject: Questions about WCAG 6.3


Hi;

I've got some questions (well, alright, problems:)
with WCAG 6.3. Wondering if anyone can shed some light
on that requirement for me.

1. Since no browser supports all WCAG requirements,
it's impossible to build a site that is 100% compliant
with all WCAG levels AND functions in all browsers.

2. Since the best support for the WCAG lies in
Internet Explorer 4.x, it seems logical most people
looking for an accessible site will hit it in IE4.x.
This is born out by my research of screen readers.
JAWs is the most popular, and that runs with IE4.x or
higher. HomePage Reader requires a 4.x version of
Netscape.

3. Give 1. and 2., I argue that the scripting
requirement 6.3 is far too restrictive.

In my environment, we rely on JavaScript to ensure
forms are filled out correctly and the database
doesn't get cluttered with incorrect information. In
fact, anyone using a database and a form will probably
use JavaScript to ensure forms are filled out
correctly. Imagine the chaos with eCommerce if a site
couldn't ensure it's users entered data correctly.
This site would be accessible, but one mistake and the
user is out of their money, the product, and the
vendor and shopper have to solve a problem that could
have been prevented with JavaScript.

That in and of itself is an aid to accessibility: it
gives people two chances to fill out forms - their
data entry pass and the verification pass. Usually,
the JavaScript error checking gives more detailed
information to the user if there is an error.

I know there's the component of "universal
accessibility", but IMHO #6.3 is just far too
restrictive for most companies to consider.

Thoughts? Am I missing the boat on this one?

Thanks!

Joel Sanda
joelsanda@yahoo.com

=====
Joel Sanda
Rocky Mountains | United States
---------------------------------
joelsanda@yahoo.com  |  Yahoo! Messenger: joelsanda
---------------------------------
 Nature is indifferent to our love, but never unfaithful
- Edward Abbey

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Received on Saturday, 25 March 2000 10:50:57 UTC