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