RE: Challenges on JavaScript Techniques

Where is the "Scripting Techniques Document" located? I just want to
ensure there isn't a version in-progress that isn't available publicly.
Is it http://www.w3.org/TR/2004/WD-WCAG20-SCRIPT-TECHS-20041119/ ?
 
    Regards,
 
    Norman Robinson

	-----Original Message-----
	From: w3c-wai-gl-request@w3.org
[mailto:w3c-wai-gl-request@w3.org] On Behalf Of David MacDonald
	Sent: Thursday, July 07, 2005 11:34 AM
	To: w3c-wai-gl@w3.org
	Subject: Challenges on JavaScript Techniques
	
	

	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.

	 

	The Scripting Techniques document has been an elephant in our
living room for some time...

	 

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

	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. 

	3)       When we get into higher level programming languages
like JavaScript there are dozens ways to approach any particular
problem. The document would inadequately cover the subject of
accessibility. Much less adequately than our CSS and HTML documents.

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

	5)       We don't have a large team of volunteers who are expert
in JavaScript which would be necessary to mount the kind of effort
needed to produce the JavaScript Techniques document we had been
planning. 

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

	7)       We are under a time gun and perhaps we need to focus
our energies on *achievable* goals such as completing the HTML, CSS,
reviewing 200 HTML test files and creating test files for all the CSS
techniques.

	 

	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

	 

	...Access empowers people
	            ...barriers disable them...

	www.eramp.com

	 

	 

	...Access empowers people
	            ...barriers disable them...

	www.eramp.com