RE: JavaScript in WCAG2 (was RE: Proposed omission...)

At CSUN Richard Schwerdtfeger and Becky Gibson did a demonstration of the
Gap analysis that was used to create a strategy to solve the DHTML
accessibility problem. It demonstrated how the resulting roadmap is being
employed to address the problems and described the standards being
developed. (in XHTML etc.)

It looks like accessibility for dynamic menus is not out of reach...of
course that sounds a bit like an "until user agents..." thing. Nevertheless
the demo was very cool. And perhaps by the time we get this thing out it
will be fine...I don't think we should forbid them, if used under the
proposed conditions.

Cheers
David MacDonald

...Access empowers people...
	...barriers disable them...
www.eramp.com 

-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Bailey, Bruce
Sent: Tuesday, March 29, 2005 2:46 PM
To: WAI-GL
Cc: Joe Clark
Subject: JavaScript in WCAG2 (was RE: Proposed omission...)


Joe, you make very compelling observations in your post below.  I can find
no fault with your conclusions.  Forgive the top-posting, but I would just
end up quoting the whole thing back!

I have a tangential question I would very much being addressed.

The Section 508 Web standards (1194.22) diverged from WCAG1 in allowing
JavaScript as long as "the information provided by the script shall be
identified with functional text that can be read by assistive technology".
The nominal justification for this:

http://www.access-board.gov/sec508/508standards.htm#Background
<blockquote>
Several commenters found the proposed provision [consistent with WCAG1] too
restrictive.  They noted that, as proposed, it could severely discourage
innovation both for web page developers and for designers of assistive
technology.  It was argued that if producers of assistive technology know
that a web page would never require access to scripts, there would be no
incentive to develop better access to these features.
[snip]
For this reason, the provision requires that functional text, that is text
that when read conveys an accurate message as to what is being displayed by
the script, be provided.
[snip]
Determining whether a web page meets this requirement may require careful
testing by web site designers, particularly as both assistive technology and
the JavaScript standard continue to evolve.
</blockquote>

Now, I shouldn't complain too much since my job security is largely ensured
because the last sentence turned out to be alarmingly prescient!  Still,
after all this time, the only examples of accessible JavaScript I have ever
encountered are menus and client-side data validation.

As Joe points out, menus are much better done in CSS.  Most experts are also
well aware that client-side data validation must always be backed-up with
server-side validation anyway.

Can anyone cite an example of accessible (i.e., screen-reader compatible)
JavaScript that is integral to a site's content?

If not, what is really wrong with the WCAG1 requirement that sites function
without JavaScript?


-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]On
Behalf Of Joe Clark
Sent: Tuesday, March 29, 2005 1:31 PM
To: WAI-GL
Subject: Re: Proposed omission of explicit baseline in WCAG 2

Let's keep in mind why we're even dealing with the issue of baseline 
requirements (apart from the fact that the esteemed Working Group has 
grown up and learned to accept the Web, at least incrementally):

WCAG 1.0 essentially banned JavaScript unless you could also provide a 
non-JS implementation that did the same thing. You could provide X only 
if you also provided anti-X or not-X. Clearly, if we could make something 
work without JavaScript, we would have already. Development in standards 
compliance and progressive enhancement has taught us that some functions 
previously thought to be achievable only in JS can be done in pure 
HTML+CSS, like nice tidy navbars, but in the main, we use JavaScript 
because HTML+CSS are not sufficient in and of themselves.

Hence:

> If you flip these two techniques over and re-word a little i.e
>
> 1. How to write content in such a way that if scripting support is not
> available (for whatever reason) content is still accessible.
> 2. How to make scripted content accessible where scripting support is
> available.

1 and 2 are contradictory and are a restatement of WCAG 1.0.

I believe it is noncontroversial to say that JavaScript should be added to 
a page only with all due accessibility provisions (most of which are very 
well documented online, but seldom used). In that case, go ahead and use 
it. In cases where HTML+CSS does the same function, as with nice tidy 
navbars, we should *ban* you from using JavaScript.

In other cases, where your JavaScript cannot be made intrinsically 
accessible, perhaps some half-arsed alternative could be provided, and 
perhaps we could require you to provide it, but that doesn't mean that 
both X and anti-X will be able to do the same thing. Let us not be in 
denial about that. And let us not be in denial of the fact that this 
circumstance will come up *rarely*.

Some things cannot be made accessible to everyone. We acknowledge this 
implicitly. What we need to do is acknowledge it explicitly and inform 
authors that their task is to use JavaScript accessibly first of all, not 
use it when existing alternatives are known to work, and not to worry 
about it too much if their specific implementation cannot be made 
accessible.

Additional complication: Adaptive technology and browsers have to play a 
role here, as we know. If we had some imaginable JavaScript validator and 
it flunked a piece of code as being inaccessible, and we knew that blind 
people were a disabled group with relevant concerns, and we also knew that 
the hacks in three out of four screen readers made the page work fine for 
blind people just the same, then functional accessibility would have been 
achieved and the content should be deemed conformant.

Received on Tuesday, 29 March 2005 21:09:40 UTC