Re: Challenges on JavaScript Techniques

Dear David and All,

At 17:34 7/07/2005, David MacDonald wrote:
>I took an action item, from the Wednesday techniques call, to summarize 
>our discussion around a possible change in direction for our Scripting 
>Techniques document.
>  (...)
>
>We are considering looking at the Scripting Techniques document 
>differently than we have in the past. Up until now we have thought of all 
>of the techniques documents as a sort of “Mr. Potato Head” game where all 
>we have to do is change the name of the technology and apply the same 
>format for whatever technology we are speaking about to create the new 
>techniques document. In theory it makes sense but I think it begins to 
>break apart in actual practice…
>
>Perhaps there are good reasons to consider HTML, and CSS techniques 
>documents differently than Scripting and other complex programming 
>language techniques documents.

I think the more logical distinction would be between technologies that 
need a host technology (JavaScript/ECMAScript, CSS, ...) and technologies 
that can be used independently of other technologies (HTML, SVG, ...). Note 
that JavaScript can also be used with SVG, not only (X)HTML.

>Here are some of the difficulties in approaching the JavaScript techniques 
>document the same way as we approach HTML and CSS:
>
>1)       There are issues around to length and complexity of code 
>examples. The amount of code it takes to generate even a simple JavaScript 
>menu is voluminous and would turn document into large book on ‘how to” 
>program JavaScript. This is beyond our ability and scope as a small group 
>of part time volunteer contributors to the initiative.

It is not so much the length of code examples that would turn the 
techniques document into a "how to program JavaScript" book, but the level 
of required JavaScript knowledge implied by the level and depth of the 
comments on the code.

>2)       Accessible JavaScript is still a thing which is very much in its 
>infancy, and there are still many problems to iron out, even among experts 
>in the field, which may not be fixed until XHTML 2.0, or later…Even if we 
>did have working examples, there is a good chance that we would get 
>inundated by thousands of emails from people who would say the examples 
>don’t work…because they missed a comma or some other little detail in the 
>code. JavaScript is not very forgiving……much more so than in CSS or HTML.

If people can't make the code work because they miss a comma or other 
detail, that is not a reflection on the techniques but on their own skills 
(assuming that our code is correct).

>3)       (...)
>4)       Some JavaScript techniques that may be proposed by experts use 
>code which are outside of the spec but are supported by leading browsers. 
>This may get us into issues about whether we should include “accessible” 
>techniques that are not in the spec…this could be a bit of a rat hole for 
>us…and divert our limited energy and resources..

If WCAG has a guideline requiring that technologies are used to 
specification, I don't think that techniques that use non-standard language 
features are a good idea.

>5)       (...)
>6)       Under our present requirements we would have to produce a test 
>case for every JavaScript technique, which more than doubles the workload.

That depends on how we want to proceed with the techniques and the test 
suites. See my comments on Tim Boland's mail 
(http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JulSep/0235.html).

>7)      (...)
>
>For these reasons and others, we are suggesting that we approach complex 
>programming language techniques documents such as JavaScript differently 
>than our HTML and CSS documents which are quite simple, stable and well 
>developed. We are considering other ways to meet our requirements and 
>provide meaningful advice about scripts The JavaScript Techniques document 
>would present, in a general way, some of the issues in working with 
>JavaScript. It would describe *conceptually* how to approach and overcome 
>those issues. It would also cover things that don’t work and would list 
>some of the top “gotchas” that inhibit accessibility when working in 
>JavaScript. It would be a document that would appeal to people who are 
>already strong JavaScript Programmers and would perhaps point to outside 
>resources for additional information.
>
>We present this recommendation to group members who were not present at 
>our meeting on July 6, and also to the Working Group as a whole, for 
>consideration.
>
>Cheers
>David MacDonald
>


Regards,

Christophe Strobbe


-- 
Christophe Strobbe
K.U.Leuven - Departement of Electrical Engineering - Research Group on 
Document Architectures
Kasteelpark Arenberg 10 - 3001 Leuven-Heverlee - BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/

Received on Monday, 1 August 2005 17:46:33 UTC