RE: Questions about WCAG 6.3

Bruce;

Thanks for the the comments! Now my turn <GRIN>:

> complex applications would
> usually be better
> implemented on the server side.  

Not necessarily. Client-side is great for reducing
server load. We have a lot of users hitting our
databases, and there are peak times. We run the risk
of having them time out or experience intense slow
down if server-side scripting is used. Out of respect
for users with slower modem speeds we use client-side
scripting. This is faster than PHP, Perl and ASP, and
safer if you have a server opt out for a vacation from
the server farm (complicated clustering aside).

> Right, because one of the earliest and most vocal
> objections to creating
> accessible web pages was the perceived need to
> create two versions of
> everything.  This turns out not only to be
> unnecessary, but also ill
> advised.

Precisely my point. We can create one web page that
works in most browsers - Opera, Lynx, IE and Netscape
- and we've done it. But the <NOSCRIPT> tag doesn't
work in all versions of Netscape, as I said earlier.
Which means two web pages from the get go. And we used
CSS for the layout - which means you MUST use
JavaScript calling to the BODY object, because
Netscape loses page formatting (CSS) when the window
is resized. Thus...one page means a Netscape user
cannot resize their program's window (perfectly fine,
unless you're using Windows <GRIN>) and some versions
will display <NOSCRIPT> contents.

So the issue remains - we're talking about two web
pages, unless you sniff for and redirect some versions
of Netscape and older versions of IE and Netscape away
from the site. Otherwise, you sniff and send them
to...a second web page. So it is necessary, though I
agree ill advised. 

> Sorry, the WCAG was very close to its current
> working form more than a year
> ago!

Indeed they were. But what organization is going to
put all its eggs in one basket, when the Guidelines
are that - Guidelines.

> I am amazed that site developers are willing to test
> their content against
> "17 versions of Navigator" but not a single
> non-Netscape / non-MSIE browser!
Why? We have limited resources, so we design for
browsers that people use. It would be nice if more
sites worked in Lynx - I'd use that more often because
I want the meat and potatoes and can skip the fancy
tableware that sucks bandwidth.

The fact is 85% - 90% of all web surfers today use
either Internet Explorer or Netscape Navigator.
Now...in terms of pure numbers, that's accessible -
designing sites that work for 90% of all users. These
figures can be found at statmarket.com,
browserwatch.com, and yahoo's random link checker. 

> N.B., this is a moving target, so if you choose this
> path, you should expect
> to re-code your entire site every six months or so. 

This is true to a point, but it's certainly not six
months. The sites we've had up for two years do quite
well, and have, despite two new major browser releases
and several minor updates from Netscape. All I ever
update is code reflecting server changes. Other than
that, even the client-side JavaScript still functions.

> Hmm, how much testing did you do?  How
> confident are you of the
> results?  How many different screen readers did you
> use?  

A tremendous amount. And I have never run into a
client - ours are colleges and universities - that use
Lynx. Every single one of them that expresses an
interest in accessible web sites use Internet Explorer
and Netscape. And everyone of them has a JAWs for
Windows license.

> The
> fact remains though, that most shops don't have
> access to screen readers or
> relationships with blind customers who could beta
> test for them.  If you
> follow the WCAG, however, such resources are not
> necessary.

We don't. So I pounded the pavement (the real and
usenet) looking for people to do usability testing. I
found a lot of blind and visually impaired people who
were very helpful, and was able to maintain a balance
of experienced and non-experienced users of computers.

The results were: Internet Explorer and JAWs for
Windows.

> Do YOU
> want to try and write
> clear unambiguous guidelines for when JavaScript is
> accessible and when its
> not?  I wouldn't go near that task with the
> proverbial ten foot pole!

Well...you're braver than, cause I'd run and hide! The
guidelines now are a little unambiuous. WCAG #6.3 says
"ensure pages are usable". Fine. I can ditch the
client-side error checking, even though Netscape
doesn't support the TITLE attribute most of the time
in <DIV> tags, nor can it use any of the new HTML 4.0
features. Heck...if you want to watch Netscape crash
write a correctly formatted Anchor Tag and place it in
a <DIV> tag, so the image and link are formatted
properly, yet still conform to the WCAG. It will crash
most 4.x versions of Netscape on the Macintosh
(OS7.5.1 and above). If you turn CSS off in Netscape,
all the positioned elements sit on top of one other,
so you can't see them, hence the page is not
accessible to people who can see (what a switch that
is!). What makes CSS work so 80% - 90% of all Internet
users today can access the site, and use the most
popular screen readers available? JavaScript.

I'm afriad that this debate/discussion is moving away
from several of my original intentions. 

One, I don't want to be an advocate of JavaScript - I
prefer Lynx first, then Opera, then IE for my personal
use and enjoyment at home and work.

Two, I think WCAG #6.3, given the state of
non-compliance to most W3C Guidelines/Recommendations
with user agents, will hinder the acceptance of the
WCAG. The passage of the ADA was, and is, an uphill
battle still. The Internet will be a fiercly fought
battle, because of its decentralized nature. Who has
the regulatory authority to enforce the WCAG (in
general, I know many countries have implemented rules
about Internet accessibility)?

Three, since the W3C Recommendations are voluntary,
and because of the lack of enforcement potential, at
least in the U.S., who will voluntarily adopt the WCAG
when it means dropping any functionality afforded by
the most popular scripting language?

Four, I know there are solutions around WCAG #6.3. We
could stick with ASP or any of the other sever-side
languages out there to accomplish much of the
JavaScript funtionality. But given my three points
immediately prior, I still have to wonder if there is
any future of widespread adoption of the WCAG in our
future.

Again...thanks to everyone giving me feedback! I think
this is a healthy discussion, and I'm carrying a
tremendous amount away from it.

Joel Sanda
joelsanda@yahoo.com

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

Received on Monday, 27 March 2000 16:09:53 UTC