Re: Questions about WCAG 6.3

Thanks for the comments everyone. I must say, though
there were varied in their reasons, everyone that
responded to my question defended #6.3.

I don't know what percentage of sites use JavaScript,
but my guess is, outside of personal home pages, there
are more sites that use JavaScript than do not.

One of my concerns is that the WACG will see slow
adoption if sites that are currently depenedent upon
JavaScript have to be re-engineered to conform to the
WCAG.

Personally, I think #6.3 should be moved to Level AA,
and not be a Level A requirement. I'm not talking
about simple stuff like error checking or mouse
rollers, or even dynamically updated framesets and
content that are all driven by client-side JavaScript.
There are a tremendous number of sites out there that
use JavaScript to build menuing systems that work
great with screenreaders. We've experimented with JS
and CSS to build menus that are not always read when a
screenreader moves from one page to the next - why
have a listener have to listen to the same eight or
nine main buttons over and over again?

Furthermore, the only way to really build a 'decent'
site that is going to use the core W3C technologies -
CSS and HTML 4.0 - is to restrict their usage to 4.0
browsers. And if you include Netscape in your
audience, you're in for a real headache.

Example: my company built a dynamic site with a very
attractive layout and two levels of mouseovers - the
button changed and a picture elsewhere on the page was
updated. The ONLY way we could build this site with
CSS instead of embedded tables was to use JavaScript
to get around the window resize bug in Netscape. The
ENTIRE site, except for logical tables for forms and
data presentation is built in CSS and it works for Mac
and Windows in all 4.0 browsers. It's extremely
accessible for JAWs and HomePage Reader. But the only
way to ensure Netscape users can use it is to include
JavaScript.

It's a Catch 22 for developers. Who has the money to
redesign enterprise level applications that currently
use client-side JavaScript? 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.

If we had to yank that JavaScript out of there, we'd
be forced to build several sites, at least. And that
runs the risk of 'ghettoizing' the accessible site,
since I know there will be more Netscape users hitting
the site than users with assistive tools like
screenreaders. That also perpetuates the belief -
which I'm beginning to seem some validity in - that
WCAG conforming sites will have to be second versions
of existing sites.

Wow...sorry for such a long post. 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.

I know I'm sharing the same crowded little boat with a
lot of other folks, which again makes me wonder if
#6.3 should be a Level AA requirement instead of Level
A.

Thanks for the great responses, and I look forward to
more discussion of this!

Joel Sanda
joelsanda@yahoo.com

--- Charles McCathieNevile <charles@w3.org> wrote:
> It is true that alternative browsing is on the rise
> (and a fairly rapid rise
> to what is generally expected to be a large part of
> the audience - 100
> million or more in a year or three).
> 
> In addition, there is less work required than may
> seem at first. It is
> possible to run javascripts on the server side as
> well as the client, so you
> can write once and implement at both ends of the
> communication chain, and
> there are many javascript features that are actually
> unnecessary (although
> some, such as form validation, are extremely useful,
> and beneficial to
> accesibility when done correctly).
> 
> An example of a major site that retooled was the
> Sydney Olympics website. The
> first time I went there it required javascript to
> enter the site (or some
> very elaborate and unpleasant work hacking through
> the source code and
> finding the way in). It now provides straightforward
> access. In part perhaps
> this was because Australian law sets high standards
> for accessibility, but it
> is also important to note that the site developers
> were able to change the
> site from an accessibility nightmare, and did so (at
> least at the bits I
> looked at - I haven't done a formal review).
> 
> As developers realise that accessibility is going to
> be a requirement and
> they need to learn about it they will have fewer
> problems, becuase it will be
> part of their ordinary skills in trade, not a
> specialised area they try to
> bolt on afterwards. This changes it from a difficult
> exercise in reworking a
> site to a simple exercise in getting the design
> right from the beginning.
> 
> Just my 5c worth (we no longer have 2c coins in
> Australia)
> 
> Charles McCN
> 
> On Sat, 25 Mar 2000, David Poehlman wrote:
> 
>   you raise good points, but alternative browsing is
> on the rise and if they
>   want to make money, they will find that they will
> loose an increasing share
>   of it if they don't accomodate.  However, the good
> news is that there is new
>   technology on the way that may make it lest
> serverly costly but I fear the
>   retooling curve may be just as expensive.
>   
>   Greate discussion!
> 
> 

=====
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 21:50:42 UTC