Re: Proposed omission of explicit baseline in WCAG 2

Joe,

In essence, I agree completely ... except for with one thing:  I do not 
agree that javascript versions of navbars (or anything else that has a 
relatively ok HTML+CSS implementation) should be banned /unless /they 
cannot be made accessible.  Otherwise, anything that can be made 
accessible (and I agree wholeheartedly that js can be used and 
implemented in an accessible fashion, with techniques listed in several 
places out there, some of which we do use) should never be banned.  I am 
anti-banning altogether.  I know that goes against a lot of what is 
being discussed with baseline, but banning is just setting a bad 
precedent, and I think it will completely undermine the validity, 
usefulness and therefore adoption and support, of WCAG 2.0. 

-Kerstin

Joe Clark wrote:

>
> 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.
>