RE: Questions about WCAG 6.3

I think a good part of my criticism with WCAG #6.3
lies in what I argue are tensions in the WCAG 1.0
Guidelines.

One of the assumptions of the WCAG is that accessible
web pages don't have to look different than current
web pages do. In other words, we don't have to give up
all the eye candy web users are used to - like Flash,
Shock, MouseOvers, and so on. I'm not a big fan of
that stuff, but those technologies are probably here
to stay.

Indeed, WCAG 11.4 says a seperate page should be build
only "If, after best efforts, you cannot create an
accessible page, provide a link to an alternative
page...". Big problem, coupled with WCAG #6.3.

Here's the problem: Most complex applications deployed
over the web use JavaScript for a variety of
functions, and most of that is client side. For anyone
to adopt the WCAG Guidelines, they'd have to
re-engineer significant portions of their application.
They'd also have to re-engineer server configurations
and development teams/build schedules/testing to
accommodate server-side scripting languages. A lot of
resources.

We've spent the better part of a year developing our
next generation back end, which uses JavaScript -
client side - for all sorts of functionality. A good
part of it in response to disabled user testing.

For us to adopt the WCAG, we'd have to go back and
reinvent our already working wheel - as will nearly
all the complex (forms that write to a database,
eCommerce, and so on) sites.

Adoption of the WCAG will require not only convincing
folks accessible web design is good and will benefit
them, but also they should regress their sites against
Lynx. That's an extremely hard, and IMHO, presumptuous
claim to make.

In a similar vein with the real world, the ADA never
mandated getting rid of stairs, but rather making
accommodations that permitted the use of assistive
technology. I think requiring Lynx compatibility (or
suggesting it as a litmus test) is akin to saying
architects have to drop the use of stairs. Instead,
architects made accommodations to their design
standards to accommodate the existing technologies,
with the assumption most people are going to use the
same level of assistive technology - wheel chairs or
similar modes of transportation.

The flip side of this is to say that web designers
have to not only code for 4.x+ browsers, but make
their sites work in a DOS browser, or come close to
working in that browser.

Hence - the tensions I think exist in the WCAG 1.0. To
use CSS, proper table markup (HTML 4.0), and
synchronized multimedia the user agent MUST be a 4.x
browser, and that will more than likely have to be IE,
since Netscape supports so little of the CSS and HTML
Recommendations. Indeed, to use CSS-P (to avoid tables
for layout) you HAVE to use JavaScript for Netscape to
correctly render CSS-P formatted page elements.

And the NOSCRIPT tag doesn't help - some version of
Netscape 4.x don't support that and display the
contents of NOSCRIPT on the page.

In conclusion, (finally), the tensions amount to a
mandatory adoption of WCAG #11.4 (second page built to
the WCAG), which in essence means at least two
(Netscape and IE), if not three (Netscape and IE and
Accessible), web sites will have to be built if an
organization wants to conform to the WCAG.

These tensions, user expectation of what pages should
look like, and the wide use of client side JavaScript
(great idea given the unpredictability of bandwidth)
spell, I argue, a very long and steep uphill battle
for wide spread WCAG adoption.

Apologies for the long post - residual grumpiness that
I am unable to debate this at CSUN because my company
didn't send me this year! <GRIN>

Joel Sanda





--- Bruce Bailey <bbailey@clark.net> wrote:
> Dear Joel,
> 
> A couple more quick questions / comments inline,
> after much snippage...
> 
> > Personally, I think #6.3 should be moved to Level
> AA,
> > and not be a Level A requirement.
> 
> Based on what?  Level A (wrt 6.3) means that some
> uses of some JavaScript
> means that some people will NOT be able to access
> the page/site.  It's clear
> and unambiguous.  The fact that you have done a
> great job ensuring
> compatibility with your JavaScript is commendable,
> but does NOT warrant
> changing priority level!  Most coders of JavaScript
> will not be as careful
> as you!
> 
> > Indeed, our reliance on
> > JavaScript ensures our CSS site is accessible to
> an
> > even larger audience than not - it works in the
> nearly
> > 17 different versions of 4.x Netscape browsers and
> all
> > 4.x IE browsers on Mac and IE.
> 
> Okay, but did you check usability with Lynx?  What
> is the rational for
> dismissing this browser, but not certain versions of
> IE / Navigator?
> 
> > I really want a site
> > that conforms to the WCAG Level A, at a minimum,
> but
> > #6.3 would mean a complete re-engineer of our
> current
> > product, making our pursuit of Level A Conformance
> an
> > academic question instead of a reality.
> 
> 6.3 does NOT require you to give up JavaScript, just
> that your site is
> useable without it!  I know a number of folks who
> disable scripting on their
> browsers -- since the bad JavaScript and Java people
> publish would routinely
> crash their computers!  I have no idea how common
> place this practice is,
> but I bet it is more popular than the folks at Sun
> would like to admit!
> 
> Cheers,
> Bruce Bailey
> 
> 

=====
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 Monday, 27 March 2000 12:34:34 UTC