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.

-- 

     Joe Clark | joeclark@joeclark.org
     Accessibility <http://joeclark.org/access/>
       --This.
       --What's wrong with top-posting?

Received on Tuesday, 29 March 2005 18:31:31 UTC